From owner-freebsd-emulation Wed Oct 15 01:59:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00674 for emulation-outgoing; Wed, 15 Oct 1997 01:59:10 -0700 (PDT) (envelope-from owner-freebsd-emulation) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00661 for ; Wed, 15 Oct 1997 01:59:03 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by Campino.Informatik.RWTH-Aachen.DE (8.8.7/RBI-Z13) with ESMTP id KAA03735; Wed, 15 Oct 1997 10:59:17 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id LAA11128; Wed, 15 Oct 1997 11:08:20 +0200 (MEST) Message-ID: <19971015110819.62289@gil.physik.rwth-aachen.de> Date: Wed, 15 Oct 1997 11:08:19 +0200 From: Christoph Kukulies To: Mike Smith Cc: Christoph Kukulies , freebsd-emulation@FreeBSD.ORG Subject: Re: some observations with xmaple (Maple V4 R5, Linux version) References: <199710150719.JAA10735@gil.physik.rwth-aachen.de> <199710150826.RAA02352@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199710150826.RAA02352@word.smith.net.au>; from Mike Smith on Wed, Oct 15, 1997 at 05:56:12PM +0930 Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Oct 15, 1997 at 05:56:12PM +0930, Mike Smith wrote: > > > > When running xmaple (Maple V4 R5, the Linux version - there ain't > > a FreeBSD one), to things seem strange : > > > > When I set the DISPLAY variable to a remote host the program > > just seg faults (segmentation violation) and dies. It shouldn't IMO. > > Obviously. What sort of remote display are you trying to use? xdpyinfo: name of display: :0.0 version number: 11.0 vendor string: X Inside Inc. vendor release number: 1302 maximum request size: 4194300 bytes motion buffer size: 0 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 6 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 167 focus: window 0x800002, revert to Parent number of extensions: 16 BIG-REQUESTS DEC-XTRAP GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD Multi-Buffering SGI-GLX SHAPE X3D-PEX XI-ShmLink XIE XIdle XTEST XTestExtension1 XsightExtension default screen number: 0 number of screens: 1 screen #0: dimensions: 1280x1024 pixels (433x346 millimeters) resolution: 75x75 dots per inch depths (2): 1, 24 root window id: 0x24 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x22 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0x58003d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask number of visuals: 2 default visual id: 0x20 visual: visual id: 0x20 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x21 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits > > > Running the non GUI version (maple) it comes up fine but (since I didn't > > know how to quit) when I send it the Quit signal (^\) it comes with > > > > LINUX: 'ioctl' fd=0, typ=0x54(T), num=0x12 not implemented > > > > and finally core dumps and quits through the FreeBSD signal mechanism. > > That's TIOCSTI, "simulate terminal input" on standard in. It looks > like a fairly disgusting hack to me (ie. simulate terminal input rather > than communicate with the parser directly). > > Could you apply this to /sys/i386/linux/linux_ioctl.c and see if it > appears to work? If so, I'll commit it. > > Will try that. Content-Description: linux_ioctl.c.diff > Index: linux_ioctl.c > =================================================================== > RCS file: /local3/ncvs/src/sys/i386/linux/linux_ioctl.c,v > retrieving revision 1.20 > diff -u -r1.20 linux_ioctl.c > --- linux_ioctl.c 1997/07/20 16:05:59 1.20 > +++ linux_ioctl.c 1997/10/15 08:28:27 > @@ -519,6 +519,10 @@ > args->cmd = TIOCSPGRP; > return ioctl(p, (struct ioctl_args *)args, retval); > > + case LINUX_TIOCSTI: > + args->cmd = TIOCSTI; > + return ioctl(p, (struct ioctl_args *)args, retval); > + > case LINUX_TIOCGWINSZ: > args->cmd = TIOCGWINSZ; > return ioctl(p, (struct ioctl_args *)args, retval); -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de