From evstack-request@ontv.com Sun Jan 4 11:20:12 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA19246 for ; Sun, 4 Jan 1998 11:20:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id NAA08550; Sun, 4 Jan 1998 13:45:10 -0500 Resent-Date: Sun, 4 Jan 1998 13:45:10 -0500 Message-Id: <199801041849.NAA31164@beans.visus.com> Subject: Mulithead capable release almost ready. To: evstack@ontv.com Date: Sun, 4 Jan 1998 13:49:48 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"Fqd0A.0.A52.QYzhq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/185 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com After a long a long silence, I'm almost ready to release EvStck-2.1.77a. Some new features: *) Boots! *) Multihead works! *) Loading/unloading of display drivers works! *) IBM VGA and Hercules drivers have been modified to work with the new kgi_mode struct. This should be out in a few hours... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sun Jan 4 12:20:14 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA19306 for ; Sun, 4 Jan 1998 12:20:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA09179; Sun, 4 Jan 1998 14:45:20 -0500 Resent-Date: Sun, 4 Jan 1998 14:45:20 -0500 Message-Id: <199801041950.OAA31434@beans.visus.com> Subject: EvPatch-2.1.77a / CVS -r EvStack-0-0-9 To: evstack@ontv.com Date: Sun, 4 Jan 1998 14:50:10 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"q8XtE2.0.3F2.0R-hq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/186 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Released. See details on http://salsa.visus.com/~jmcc -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 5 05:03:37 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA20425 for ; Mon, 5 Jan 1998 05:03:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA18174; Mon, 5 Jan 1998 07:28:34 -0500 Resent-Date: Mon, 5 Jan 1998 07:28:34 -0500 Message-Id: From: Andrew Apted Subject: new debug.c committed To: evstack@ontv.com Date: Mon, 5 Jan 1998 23:29:24 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"p5qXo.0.VR4.j6Diq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/187 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I've just committed an overhauled debug module. Just use "make modules" and it'll get made with all the other modules. I've found attaching it to an unused termstack is the best. To use it, do something like: bash> insmod modules/debug.o bash> echo "create" > /proc/sys/evstack/class/debug bash> stacktree -l bash> echo "+ 12345678" > proc/sys/evstack/stack/10040007-termstack Various run-time options can set by just writing to the /proc entry. What can be written can be seen when cat'ing the /proc entry. An example: bash> echo "var show_unconsumed 0" > /proc/sys/.../12345678-debug It is especially useful when working on input drivers :-). Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 5 16:58:30 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA21181 for ; Mon, 5 Jan 1998 16:58:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA26303; Mon, 5 Jan 1998 19:23:10 -0500 Resent-Date: Mon, 5 Jan 1998 19:23:10 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Sneaking suspicion... Date: 6 Jan 1998 00:25:37 GMT Organization: OnTV Pittsburgh, L.P. Lines: 23 Message-ID: <68rtm1$krb$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"KsRn02.0.WQ6.ObNiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/188 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I have a sneaking suspicion that my Linux-2.1.77 is a little rusty and currupt.. I am _right_now_ downloading a pristine (9Mb) Linux-2.1.77.tar.gz from ftp.kernel.org, and will re-diff it with my modified kernel. I think something's missing..... Otherwise, why hasn't anyone been able to get it to work? (It won't even boot on my work machine when I patched a clean kernel) Until then, _please_ everybody look at the ARCHITECTURE file, include/ggi/{console,kgi,scroll,scroll_struct}.h, and other misc code, and tell me what I'm doing wrong or what is unclear. BTW: Do we have any people who like documentation on this list? (I kinda suck at it.... But I'm good at answering questions!) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 5 18:14:45 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA21291 for ; Mon, 5 Jan 1998 18:14:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA27107; Mon, 5 Jan 1998 20:39:31 -0500 Resent-Date: Mon, 5 Jan 1998 20:39:31 -0500 Message-Id: <199801060144.UAA15355@beans.visus.com> Subject: Hmm..... To: evstack@ontv.com Date: Mon, 5 Jan 1998 20:44:13 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"5lNlr.0.9d6.siOiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/189 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Well, I re-checked the patch, and I can't find anything out of the ordinary... I'm re-compiling here again, with the same `difference' as at my office - I'm only compiling in the VGA boot driver, and NOT the MDA driver (as I usually do for multihead testing...) Maybe there lies the rub... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 5 21:07:45 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA21671 for ; Mon, 5 Jan 1998 21:07:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA28771; Mon, 5 Jan 1998 23:32:41 -0500 Resent-Date: Mon, 5 Jan 1998 23:32:41 -0500 Message-Id: From: Andrew Apted Subject: Re: Sneaking suspicion... To: evstack@ontv.com Date: Tue, 6 Jan 1998 15:32:52 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <68rtm1$krb$1@grits.visus.com> from "Jason McMullan" at Jan 6, 98 00:25:37 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9s4EX.0.C17.QFRiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/190 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > I have a sneaking suspicion that my Linux-2.1.77 is a little > rusty and currupt.. I am _right_now_ downloading a pristine > (9Mb) Linux-2.1.77.tar.gz from ftp.kernel.org, and will re-diff > it with my modified kernel. > > I think something's missing..... Otherwise, why hasn't > anyone been able to get it to work? (It won't even > boot on my work machine when I patched a clean kernel) It works for me. The relevent bits of my .config are shown below. I tried disabling PRINTK_FOLLOWING a few days ago (on 2.1.72c), and the resulting kernel wouldn't boot... could that be it ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ # # Automatically generated by make menuconfig: don't edit # # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Processor type and features # CONFIG_M386=y # CONFIG_MATH_EMULATION is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KERNELD is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_BIOS=y # CONFIG_PCI_DIRECT is not set # CONFIG_MCA is not set CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_VIDEO_SELECT is not set CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # # Console setup # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_VT_VCS=y CONFIG_VT_PRINTK_FOLLOWING=y CONFIG_GGI=y CONFIG_GGI_SPLASH_SCREEN=y CONFIG_GGI_XTERM=y CONFIG_GGI_DEVGRAPH=y CONFIG_GGI_DEVEVENT=y # CONFIG_GGI_CONLINUX is not set CONFIG_GGI_DEBUG=y CONFIG_GGI_DEBUG_LEVEL=2 CONFIG_GGI_KEYMAP_AMERICAN=y CONFIG_GGI_i386_KEYB=y CONFIG_GGI_i386_JOY=m CONFIG_GGI_i386_COLOR=y CONFIG_GGI_i386_MONO=y CONFIG_GGI_i386_BEEP=y # # Character devices # CONFIG_SERIAL=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_PRINTER=y # CONFIG_PRINTER_READBACK is not set # CONFIG_MOUSE is not set # CONFIG_UMISC is not set # CONFIG_QIC02_TAPE is not set # CONFIG_APM is not set # CONFIG_WATCHDOG is not set # CONFIG_RTC is not set # CONFIG_VIDEO_DEV is not set # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_PMS is not set # CONFIG_NVRAM is not set # CONFIG_JOYSTICK is not set # CONFIG_MISC_RADIO is not set # # Kernel hacking # # CONFIG_PROFILE is not set CONFIG_VGA_CONSOLE=y From evstack-request@ontv.com Tue Jan 6 05:16:20 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA22227 for ; Tue, 6 Jan 1998 05:16:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA00936; Tue, 6 Jan 1998 07:41:13 -0500 Resent-Date: Tue, 6 Jan 1998 07:41:13 -0500 Message-Id: From: Andrew Apted Subject: New serialmouse scheme To: evstack@ontv.com Date: Tue, 6 Jan 1998 23:42:08 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"DzZcr2.0.9E.oOYiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/191 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi everyone, I have just committed some new code for handling serial mice (etc). Basically it just muliplexes the N_MOUSE line discipline, so that more than one kernel module can receive serial data and convert it EvStack events. The relevent files are 'include/ggi/nmouse.h' and 'drivers/console/nmouse.c'. If it's alright with you guys, I'll also commit the updated version of the serialmouse driver, the new SpaceOrb driver, and the setmouse & stacktree utilities to the repository as soon as they're ready. If not, I can just post an EvUtil-0.4 package... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 6 07:13:20 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA22360 for ; Tue, 6 Jan 1998 07:13:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA02132; Tue, 6 Jan 1998 09:37:46 -0500 Resent-Date: Tue, 6 Jan 1998 09:37:46 -0500 Message-Id: <199801061442.JAA24283@beans.visus.com> Subject: Re: Sneaking suspicion... To: evstack@ontv.com Date: Tue, 6 Jan 1998 09:42:24 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 6, 98 03:32:52 pm From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"Nv7oy3.0.nW.N6aiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/192 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > > Jason McMullan writes: > > > I have a sneaking suspicion that my Linux-2.1.77 is a little > > rusty and currupt.. I am _right_now_ downloading a pristine > > (9Mb) Linux-2.1.77.tar.gz from ftp.kernel.org, and will re-diff > > it with my modified kernel. > > > > I think something's missing..... Otherwise, why hasn't > > anyone been able to get it to work? (It won't even > > boot on my work machine when I patched a clean kernel) Well, nothing was missing - a fresh kernel => bootable EvStack. > It works for me. The relevent bits of my .config are shown below. > I tried disabling PRINTK_FOLLOWING a few days ago (on 2.1.72c), and the > resulting kernel wouldn't boot... could that be it ? > Aha! For now, everybody turn on PRINTK_FOLLOWING until I fix it... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 6 08:09:18 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA22398 for ; Tue, 6 Jan 1998 08:09:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id KAA02857; Tue, 6 Jan 1998 10:33:58 -0500 Resent-Date: Tue, 6 Jan 1998 10:33:58 -0500 Message-Id: <199801061538.KAA25334@beans.visus.com> Subject: Re: New serialmouse scheme To: evstack@ontv.com Date: Tue, 6 Jan 1998 10:38:43 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 6, 98 11:42:08 pm From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"L6TtN.0.Gi.Axaiq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/193 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > I have just committed some new code for handling serial mice (etc). > Basically it just muliplexes the N_MOUSE line discipline, so that more > than one kernel module can receive serial data and convert it EvStack > events. The relevent files are 'include/ggi/nmouse.h' and > 'drivers/console/nmouse.c'. Cool! I though about that problem way back when I first wrote the serialmouse driver, but I'll like to see your solution... Please commit it to ggi[EvStack]/driver/input/... > If it's alright with you guys, I'll also commit the updated version of > the serialmouse driver, the new SpaceOrb driver, and the setmouse & > stacktree utilities to the repository as soon as they're ready. > If not, I can just post an EvUtil-0.4 package... Go on ahead. Although please put all such stuff [input devices] in the ggi/driver/input directory unless it is NEEDED at boot time. [ie, a keyboard device]. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 7 07:15:50 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA24947 for ; Wed, 7 Jan 1998 07:15:48 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA17629; Wed, 7 Jan 1998 09:40:14 -0500 Resent-Date: Wed, 7 Jan 1998 09:40:14 -0500 Message-Id: <199801071443.JAA11358@beans.visus.com> Subject: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Wed, 7 Jan 1998 09:43:49 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan Reply-To: jmcc@ontv.com Content-Type: text Resent-Message-ID: <"AjMBK1.0.qI4.jDviq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/194 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com CVS now has the `FOLLOWING_PRINTK' fix. Please try stuff out now. Also, please try out [for those of you with both Herc & VGA displays] this technique: *) Compile a kernel with VGA support *) Boot, and load the Herc driver as display=0 - Watch all your VTs `magically' move to the Herc display *) Rmmod the Herc driver - VTs pop back to your VGA display *) Insmod the Herc driver as display=1 *) Echo "Hello VT10" >/dev/vty10 (Make sure to run ggi/patches/Linux/MAKEDEV.ggi in /dev) - prints `Hello VT10' on Display 1, VT 0 *) Rmmod Herc *) Insmod Herc as Display 0 *) Insmod VGA as Display 1 - Now your VGA display has `Hello VT10'! Pretty spiff stuff. Now to get /dev/graph working (setmode works, but the MMAP and VT-switching code isn't all that perfect yet....) Also, can someone tell me what the SAK key is on the American keymap??? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 7 15:48:04 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA26056 for ; Wed, 7 Jan 1998 15:48:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA22523; Wed, 7 Jan 1998 18:12:13 -0500 Resent-Date: Wed, 7 Jan 1998 18:12:13 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Wed, 7 Jan 1998 23:43:40 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"kIVLX3.0.UV5.ak0jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/195 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks ... (alive again ...) > CVS now has the `FOLLOWING_PRINTK' fix. Please try stuff out now. Will do. > Pretty spiff stuff. Now to get /dev/graph working > (setmode works, but the MMAP and VT-switching code > isn't all that perfect yet....) Wow ... nice work up to now ... > Also, can someone tell me what the SAK key is on the > American keymap??? ROTFL ... none ... I just double-checked ... only german users can SAK ;-))) O.K. - seriously. Noone seems to have cared for setting SAK on the non-german keymaps. The action code for SAK is 0xf20f. The german keymap binds it to the "PRINT" key in plain mode and to the Break-Key in Alt-Ctrl mode. Changing the other maps should be simple with this info ... I'd vote for binding it to the print-key in plain and in Alt-Mode and in Ctrl-Mode (why not in all modes ... ?), as it is AFAIK not used in Linux, and it is nicely labeled SREQ (System-Request) or S-Abf (Systemabfrage, a ugly German translation) on all keyboards I know, so it seems reasonable. CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Wed Jan 7 20:54:56 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA26574 for ; Wed, 7 Jan 1998 20:54:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25456; Wed, 7 Jan 1998 23:18:19 -0500 Resent-Date: Wed, 7 Jan 1998 23:18:19 -0500 Message-Id: From: Andrew Apted Subject: Re: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Thu, 8 Jan 1998 15:18:21 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 7, 98 11:43:40 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"iDGUu.0.ND6.vD5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/196 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de writes: > The action code for SAK is 0xf20f. The german keymap binds it to the "PRINT" > key in plain mode and to the Break-Key in Alt-Ctrl mode. > > Changing the other maps should be simple with this info ... > > I'd vote for binding it to the print-key in plain and in Alt-Mode and in > Ctrl-Mode (why not in all modes ... ?), as it is AFAIK not used in Linux, > and it is nicely labeled SREQ (System-Request) or S-Abf (Systemabfrage, > a ugly German translation) on all keyboards I know, so it seems reasonable. I don't think that putting it on a plain key is a good idea. You could easily press it accidentally, and SAK being what it is... Goodbye work. It's not like you need to press it all the time, only occasionally, so making it hard to press (e.g. with Ctrl+Alt) wouldn't be a Bad Thing. My preference would be Ctrl+Alt+Escape. Not all keyboards have a key with SysRq on it... (non-IBM ones in particular) Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 7 21:02:21 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26583 for ; Wed, 7 Jan 1998 21:02:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25550; Wed, 7 Jan 1998 23:26:34 -0500 Resent-Date: Wed, 7 Jan 1998 23:26:34 -0500 Message-Id: From: Andrew Apted Subject: CVS probs To: evstack@ontv.com Date: Thu, 8 Jan 1998 15:27:02 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9nYak.0.rE6.hL5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/197 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com CVS did a few strange (to me at least) things while I was checking in the serialmouse stuff. I got this when I added the joystick directory. /home/ev_ggi/driver/input> cvs add joystick ? joystick/Makefile ? joystick/spaceorb.c Terminated with fatal signal 10 Core dumped; preserving /tmp/cvs-serv3331 on server. CVS locks may need cleaning up. Is that serious ? Should I contact Steffen ? The other funny thing happened when updating the kernel stuff. I got: /home/ev_ggi/patches/Linux/linux/drivers/console> cvs -z1 update RCS file: /disk/cvs/ggi/ggi/patches/Linux/linux/drivers/console/Attic/console.c,v retrieving revision 1.1.2.7 retrieving revision 1.1.2.8 Merging differences between 1.1.2.7 and 1.1.2.8 into console.c /uni/global/bin/gdiff3: extra operand /uni/global/bin/gdiff3: Try `/uni/global/bin/gdiff3 --help' for more information. rcsmerge: warning: overlaps or other problems during merge My guess is there was a conflict, but it seems something went wrong with gdiff3. Is that serious ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 7 21:14:14 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26639 for ; Wed, 7 Jan 1998 21:14:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25729; Wed, 7 Jan 1998 23:38:43 -0500 Resent-Date: Wed, 7 Jan 1998 23:38:43 -0500 Message-Id: From: Andrew Apted Subject: Serialmouse stuff committed To: evstack@ontv.com Date: Thu, 8 Jan 1998 15:39:55 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Y8u013.0.fH6.7X5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/199 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Yep it's all there. I've committed the serialmouse driver and the spaceorb driver (in $GGIHOME/driver/input), the stacktree and updated setmouse utilities (in $GGIHOME/util), and a few fixes to the nmouse code. Just recompile the kernel, and you're ready to go. Jason, could you please put parsearg.h into include/ggi ? The input modules need it for configuration on /proc, and #include is pretty gruesome... Okay people, test it out! Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 7 21:16:21 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26644 for ; Wed, 7 Jan 1998 21:16:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25642; Wed, 7 Jan 1998 23:33:42 -0500 Resent-Date: Wed, 7 Jan 1998 23:33:42 -0500 Message-Id: <199801080438.XAA03797@beans.visus.com> Subject: Re: CVS probs To: evstack@ontv.com Date: Wed, 7 Jan 1998 23:38:41 -0500 (EST) Cc: steffen@physik.tu-chemnitz.de Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 8, 98 03:27:02 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"t6vUa1.0.FG6.OS5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/198 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > CVS did a few strange (to me at least) things while I was checking in > the serialmouse stuff. I got this when I added the joystick directory. > > /home/ev_ggi/driver/input> cvs add joystick > ? joystick/Makefile > ? joystick/spaceorb.c > Terminated with fatal signal 10 > Core dumped; preserving /tmp/cvs-serv3331 on server. > CVS locks may need cleaning up. > > Is that serious ? Should I contact Steffen ? It looks serious, yes, but all the times it's happened to me I could go ahead and commit stuff in the newly created directory... [I'm CCing this to Steffen] > The other funny thing happened when updating the kernel stuff. I got: > > /home/ev_ggi/patches/Linux/linux/drivers/console> cvs -z1 update > RCS file: /disk/cvs/ggi/ggi/patches/Linux/linux/drivers/console/Attic/console.c,v > retrieving revision 1.1.2.7 > retrieving revision 1.1.2.8 > Merging differences between 1.1.2.7 and 1.1.2.8 into console.c > /uni/global/bin/gdiff3: extra operand > /uni/global/bin/gdiff3: Try `/uni/global/bin/gdiff3 --help' for more > information. > rcsmerge: warning: overlaps or other problems during merge > > My guess is there was a conflict, but it seems something went wrong > with gdiff3. Is that serious ? Yep, Steffen has know about the `gdiff3' problem for some time now [at LEAST 2 years].. Just remove console.c and re-update to get the latest rev. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 7 21:20:00 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26648 for ; Wed, 7 Jan 1998 21:20:00 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25812; Wed, 7 Jan 1998 23:44:32 -0500 Resent-Date: Wed, 7 Jan 1998 23:44:32 -0500 Message-Id: <199801080449.XAA03881@beans.visus.com> Subject: Re: Serialmouse stuff committed To: evstack@ontv.com Date: Wed, 7 Jan 1998 23:49:26 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 8, 98 03:39:55 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"27KE81.0.vI6.Tc5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/200 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > > Yep it's all there. I've committed the serialmouse driver and the > spaceorb driver (in $GGIHOME/driver/input), the stacktree and updated > setmouse utilities (in $GGIHOME/util), and a few fixes to the nmouse > code. Just recompile the kernel, and you're ready to go. > > Jason, could you please put parsearg.h into include/ggi ? The input > modules need it for configuration on /proc, and #include > is pretty gruesome... Consider it done. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 7 21:21:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26652 for ; Wed, 7 Jan 1998 21:21:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25861; Wed, 7 Jan 1998 23:45:16 -0500 Resent-Date: Wed, 7 Jan 1998 23:45:16 -0500 Message-Id: From: Andrew Apted Subject: Re: CVS probs To: evstack@ontv.com Date: Thu, 8 Jan 1998 15:46:48 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <199801080438.XAA03797@beans.visus.com> from "Jason McMullan" at Jan 7, 98 11:38:41 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1xb__1.0.iJ6.Ed5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/201 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > It looks serious, yes, but all the times it's happened to me > I could go ahead and commit stuff in the newly created directory... > [I'm CCing this to Steffen] Cheers. > > My guess is there was a conflict, but it seems something went wrong > > with gdiff3. Is that serious ? > > Yep, Steffen has know about the `gdiff3' problem for some time now > [at LEAST 2 years].. Just remove console.c and re-update to get the > latest rev. Okay, thanks. _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 7 21:32:58 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA26668 for ; Wed, 7 Jan 1998 21:32:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA25996; Wed, 7 Jan 1998 23:57:05 -0500 Resent-Date: Wed, 7 Jan 1998 23:57:05 -0500 Message-Id: From: Andrew Apted Subject: Re: Serialmouse stuff committed To: evstack@ontv.com Date: Thu, 8 Jan 1998 15:58:18 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <199801080449.XAA03881@beans.visus.com> from "Jason McMullan" at Jan 7, 98 11:49:26 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uLJ1A2.0.jL6.Jo5jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/202 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > > 'Andrew Apted wrote with particular insight...' > > > > Jason, could you please put parsearg.h into include/ggi ? The input > > modules need it for configuration on /proc, and #include > > is pretty gruesome... > > Consider it done. Thanks! I've just fixed the two input modules. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 8 05:12:59 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA27274 for ; Thu, 8 Jan 1998 05:12:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA30585; Thu, 8 Jan 1998 07:37:29 -0500 Resent-Date: Thu, 8 Jan 1998 07:37:29 -0500 Message-Id: From: Andrew Apted Subject: Small fix To: evstack@ontv.com Date: Thu, 8 Jan 1998 23:35:20 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TZaN_2.0.ST7.TXCjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/203 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, There was a small problem with the POINTER cursor, the mouse was moving the wrong one around... I've applied the fix to kgiscroll.c Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 8 06:20:14 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27385 for ; Thu, 8 Jan 1998 06:20:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA31191; Thu, 8 Jan 1998 08:44:35 -0500 Resent-Date: Thu, 8 Jan 1998 08:44:35 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Thu, 8 Jan 1998 14:07:06 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 8, 98 03:18:21 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"W__qV.0.mc7.qVDjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/204 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > I'd vote for binding it to the print-key in plain and in Alt-Mode and in > > Ctrl-Mode (why not in all modes ... ?), as it is AFAIK not used in Linux, > > and it is nicely labeled SREQ (System-Request) or S-Abf (Systemabfrage, > > a ugly German translation) on all keyboards I know, so it seems reasonable. > I don't think that putting it on a plain key is a good idea. You could > easily press it accidentally, and SAK being what it is... Goodbye work. Right you are. However it is configureable, so no big deal. Not even to have multiple SAKs. > It's not like you need to press it all the time, only occasionally, so > making it hard to press (e.g. with Ctrl+Alt) wouldn't be a Bad Thing. Yep. I' Personally say any modifier combo on printf except shift. Hard enough to press accidentially for my taste. > My preference would be Ctrl+Alt+Escape. Not all keyboards have a key > with SysRq on it... (non-IBM ones in particular) Yes. However I think we should use the defaults users are accustomed to on other machines. E.g. STOP-A on SUN. CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Thu Jan 8 06:40:30 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA27418 for ; Thu, 8 Jan 1998 06:40:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA31549; Thu, 8 Jan 1998 09:04:57 -0500 Resent-Date: Thu, 8 Jan 1998 09:04:57 -0500 Message-Id: <199801081409.JAA11614@beans.visus.com> Subject: Re: Small fix To: evstack@ontv.com Date: Thu, 8 Jan 1998 09:09:35 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 8, 98 11:35:20 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"tqIO53.0.Zi7.bpDjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/205 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > > Hi, > > There was a small problem with the POINTER cursor, the mouse was moving > the wrong one around... I've applied the fix to kgiscroll.c > Oops... Thanks! Other than that, how's your trials and tribulations with EvStack? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 8 13:44:00 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA27978 for ; Thu, 8 Jan 1998 13:43:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id QAA04118; Thu, 8 Jan 1998 16:08:22 -0500 Resent-Date: Thu, 8 Jan 1998 16:08:22 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Small fix To: evstack@ontv.com (Evstack Mailing List) Date: Thu, 8 Jan 1998 16:56:26 +0100 (MET) In-Reply-To: <199801081409.JAA11614@beans.visus.com> from "Jason McMullan" at Jan 8, 98 09:09:35 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"5V75B1.0.e_.d0Kjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/206 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > There was a small problem with the POINTER cursor, the mouse was moving > > the wrong one around... I've applied the fix to kgiscroll.c > Oops... Thanks! Other than that, how's your trials and > tribulations with EvStack? I just re-tried with the 2.1.77a patch from the webpage and it hung at boot. At the very same position as the last time. I tried with and without MGA support in kernel. Maybe someone who has this working could send me his .config, so I could try this. And see if I can find the dependency which prevents the new versions from working for me ... CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Thu Jan 8 19:01:02 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA28403 for ; Thu, 8 Jan 1998 19:01:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA07460; Thu, 8 Jan 1998 21:25:21 -0500 Resent-Date: Thu, 8 Jan 1998 21:25:21 -0500 Message-Id: From: Andrew Apted Subject: Re: Small fix To: evstack@ontv.com Date: Fri, 9 Jan 1998 13:26:53 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <199801081409.JAA11614@beans.visus.com> from "Jason McMullan" at Jan 8, 98 09:09:35 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"O0-AF3.0.Aq1.-fOjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/207 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Other than that, how's your trials and > tribulations with EvStack? It's working nicely. [Apart from those ARGH messages :-)]. The VGA driver inserts just fine and removes just fine too which is cool. Even the pointer-hack is working. There's a slight problem with the block/hardware cursor being in the wrong place -- looks like either kgiscroll or xterm has got the wrong idea about the font_width. On the boot display the mouse pointer is completely wrong -- limited to a tiny box on the top-left corner (same problem I suspect). As soon as I get my hands on an MDA monitor, I'll try the Herc too. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 8 19:07:14 1998 Return-Path: Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA28434 for ; Thu, 8 Jan 1998 19:07:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA07568; Thu, 8 Jan 1998 21:30:49 -0500 Resent-Date: Thu, 8 Jan 1998 21:30:49 -0500 Message-Id: From: Andrew Apted Subject: Re: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Fri, 9 Jan 1998 13:32:31 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 8, 98 02:07:06 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"okILU2.0.pr1.AlOjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/208 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de writes: > > I don't think that putting it on a plain key is a good idea. You could > > easily press it accidentally, and SAK being what it is... Goodbye work. > > Right you are. However it is configureable, so no big deal. Not even to have > multiple SAKs. Yep, no big deal. > > My preference would be Ctrl+Alt+Escape. Not all keyboards have a key > > with SysRq on it... (non-IBM ones in particular) > > Yes. However I think we should use the defaults users are accustomed to on > other machines. E.g. STOP-A on SUN. Two SAKs sounds perfect -- one in a GGI standard place (Ctrl+Alt+Escape), and the other in the platform standard place (SysRq, STOP, etc). Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 9 06:01:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA29721 for ; Fri, 9 Jan 1998 06:01:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA13718; Fri, 9 Jan 1998 08:25:10 -0500 Resent-Date: Fri, 9 Jan 1998 08:25:10 -0500 Message-Id: <199801091326.OAA30191@zafir.e.kth.se> To: evstack@ontv.com Subject: Re: CVS now has FOLLOWING_PRINTK fix In-reply-to: Your message of "Fri, 09 Jan 1998 13:32:31 +1100." Date: Fri, 09 Jan 1998 14:26:59 +0100 From: Marcus Sundberg Resent-Message-ID: <"j0URz3.0.nL3.8KYjq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/209 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Two SAKs sounds perfect -- one in a GGI standard place (Ctrl+Alt+Escape), > and the other in the platform standard place (SysRq, STOP, etc). Ctrl+Alt+Escape isn't very good since it's something you might want to use in your wm for example. Actually Ctrl+Alt+Escape is allready a standard binding for Destroy Window in KDE. Even if it is configurable it's allways preferable to have good defaults. Just my $0.02 //Marcus From evstack-request@ontv.com Fri Jan 9 06:02:55 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA29725 for ; Fri, 9 Jan 1998 06:02:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA13780; Fri, 9 Jan 1998 08:27:15 -0500 Resent-Date: Fri, 9 Jan 1998 08:27:15 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Small fix To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 9 Jan 1998 14:03:02 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 9, 98 01:16:27 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Kx6hq1.0.sM3.MMYjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/210 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > I just re-tried with the 2.1.77a patch from the web and it hung at boot. > > At the very same position as the last time. I tried with and without > > MGA support in kernel. > Below is my .config (warts and all). TNX. Jason's patch cut it. One should mark the webpage patch as bad ... I am now happily running EvStack again. What are the most important tasks ? If noone answers until then, I will attack dynamic keyboard configuration via /proc this night. I am having slight problems with compiling the EvUtils, but I'm sure I can figure it out ... Emacs is working fine here, so I assume all the major console bugs are gone ... We should make a TODO list to coordinate our efforts. What is needed ? CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Fri Jan 9 06:40:09 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA29796 for ; Fri, 9 Jan 1998 06:40:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA14398; Fri, 9 Jan 1998 09:04:29 -0500 Resent-Date: Fri, 9 Jan 1998 09:04:29 -0500 Message-Id: <199801091409.JAA00226@beans.visus.com> Subject: Re: Small fix To: evstack@ontv.com Date: Fri, 9 Jan 1998 09:09:02 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 9, 98 01:26:53 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"MkZ4z1.0.TW3._uYjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/211 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > > Jason McMullan writes: > > > Other than that, how's your trials and > > tribulations with EvStack? > > It's working nicely. [Apart from those ARGH messages :-)]. The VGA > driver inserts just fine and removes just fine too which is cool. Even > the pointer-hack is working. There's a slight problem with the > block/hardware cursor being in the wrong place -- looks like either > kgiscroll or xterm has got the wrong idea about the font_width. On the > boot display the mouse pointer is completely wrong -- limited to a tiny > box on the top-left corner (same problem I suspect). Thanks for the report! Those ARGH! messages will get fixed [eventually] - they're indications that I'm calling the console_helper functions at the wrong time from console.c Ahhh... The mouse problem is probably because we're (mistakenly) sending R/C instead of X/Y... And Fontsize _does_ seem to be the problem with the cursors... I'll get on it... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 9 06:42:40 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA29802 for ; Fri, 9 Jan 1998 06:42:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA14472; Fri, 9 Jan 1998 09:07:00 -0500 Resent-Date: Fri, 9 Jan 1998 09:07:00 -0500 Message-Id: <199801091411.JAA00326@beans.visus.com> Subject: Re: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com Date: Fri, 9 Jan 1998 09:11:41 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "Andrew Apted" at Jan 9, 98 01:32:31 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"TSxMi3.0.gX3.VxYjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/212 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'Andrew Apted wrote with particular insight...' > becka@rz.uni-duesseldorf.de writes: > > > My preference would be Ctrl+Alt+Escape. Not all keyboards have a key > > > with SysRq on it... (non-IBM ones in particular) > > > > Yes. However I think we should use the defaults users are accustomed to on > > other machines. E.g. STOP-A on SUN. > > Two SAKs sounds perfect -- one in a GGI standard place (Ctrl+Alt+Escape), > and the other in the platform standard place (SysRq, STOP, etc). Tangentially, I would just like to express the opinion that CTRL-ALT-DEL _should_ be application re-mappable. That way you can prevent people accidently walking up to your fvwm95 displaying machine and `wanting to log into the NT'.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 9 12:46:54 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA30427 for ; Fri, 9 Jan 1998 12:46:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA18645; Fri, 9 Jan 1998 15:10:51 -0500 Resent-Date: Fri, 9 Jan 1998 15:10:51 -0500 Date: Fri, 9 Jan 1998 13:23:43 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list Subject: Just curious Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"s3i9u3.0.wY4.fGejq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/213 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This list is starting to get a little busier now that GGI/Dali's out, eh? :) [or something like that] So how would one get CVS-access to download 'evstack'? (same as GGI?) And - out of curiousity - can GGI drivers be loaded yet? :) [if so I'll start hacking with EvStacks/ViRGE and see if I can get a nice 3D demo going.... That 6 consoles on the sides of a cube sounds like fun :] Either that or where does the TODO stand in regards to KGI/GGI? [and keyboard + mouse? - I'll need both for that demo...] Is there (yet) a way to make a userspace console? G'day, eh? :) - Teunis Just some random questions to start the day - I've been sick a few weeks and am just starting to catch up.... and this list is a lot less busy than GGI :) From evstack-request@ontv.com Fri Jan 9 13:19:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA30519 for ; Fri, 9 Jan 1998 13:19:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA19053; Fri, 9 Jan 1998 15:42:40 -0500 Resent-Date: Fri, 9 Jan 1998 15:42:40 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: CVS now has FOLLOWING_PRINTK fix To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 9 Jan 1998 18:50:54 +0100 (MET) In-Reply-To: <199801091411.JAA00326@beans.visus.com> from "Jason McMullan" at Jan 9, 98 09:11:41 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Z7EWZ3.0.je4.bkejq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/214 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Two SAKs sounds perfect -- one in a GGI standard place (Ctrl+Alt+Escape), > > and the other in the platform standard place (SysRq, STOP, etc). > Tangentially, I would just like to express the opinion that > CTRL-ALT-DEL _should_ be application re-mappable. That way > you can prevent people accidently walking up to your fvwm95 > displaying machine and `wanting to log into the NT'.... *grin* Nothing bad would happen here ... My init system is set up to reject reboot via CAD except, if some trusted user is logged on. To make it clear : Keys like SAK, VT-switching and rebooting should _not_ be overridable by the ordinary user (only by root). This prevents the occasional user from rendering the system uncontrollable by binding these to a weird key only. I'd let the ordinary user _add_ its own bindings, but the superuser-preset binding should always work, too. If you want to do "NT-Emulation" with your box, you can do so, if root helps. You can either unbind the CAD special sequence and handle it in the window manager or modify the init (which gets notified of reboot events normally) to check for a running WM and eventually communicate the event to it. CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Fri Jan 9 13:19:30 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA30522 for ; Fri, 9 Jan 1998 13:19:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA19052; Fri, 9 Jan 1998 15:42:40 -0500 Resent-Date: Fri, 9 Jan 1998 15:42:40 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Small fix To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 9 Jan 1998 19:08:03 +0100 (MET) In-Reply-To: <199801091535.KAA01862@beans.visus.com> from "Jason McMullan" at Jan 9, 98 10:35:52 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"EoZld1.0.-e4.ekejq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/215 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Actually, you'll need to have the keymap tables to be created per-instance > first.... but dynamic keyboard config is a MUST. Yeah. I'll probably attack this first, as I know what to do for that ... > > How about the following as an `input format' - it's (largely) > backwards compatible with the loadkeys format... O.K. - let's see ... > # Define keyCode => Basecode [Send to the keyboard input device?] > C 0x21 => B 0x12 > C 0x22 => B 0x14 Hmm - do you mean mapping the Linux-nonstandard "keyCode"s as we call them now to what Andrew suggested as "BaseSyms" ? > --- Cut here -- > # Send this to the keymap stack > # Define modifier key => mask > B 0x98 => M 1 # Shift > B 0x21 => M 1 # Shift > B 0x23 => L 1 # Capslock > B 0x23 => M 2 # Control > B 0x44 => M 4 # Alt > B 0x56 => L 8 # Numlock > ... Yeah - I like this one. > # Basesym and Keysym for `A' > B 0x88 M 0 => K 'a' > B 0x88 M 1 => K 'A' > B 0x88 M 2 => K 0x01 # Control-A > B 0x88 M 3 => K 0x01 # Control-Shift-A > B 0x88 M 4 => K 0x1b K "[?P" # ALT-A is a macro > ... Hmm - I am unsure if we should really parse all those formats ... I'd rather leave some of the work to a userspace utility (loadkeys) and send the action-codes directly. I will play around with loadkeys a bit to see what output it already can produce. Maybe we can find a way without even changing loadkeys ... > B 0x81 B 0x88 M 0 => K 0x78 # Compose ' and A to make a' Ugh ... this doesn't fit well into the current scheme. I am just thinking : How many of us do use dead keys regularly ? Most of us have the potential dead-key-sequences like "a,"o,"u for me directly on the native language keyboard. Thus it might be a good idea to have rather a seperate generic "replacer" Module which does what you suggest. It would take a replacement table like " a -> ä -> ^[[[A etc. Most of these sequences should normally be handled by the terminal code, so the need for this module would not be too common, while you can do really spiffy things, when you load it. E.g. you might have noticed, that I often misspell Andy in my signatures as ANdy ... ANdy -> Andy would cure this .... ;-) Something like the famous WitchPen application ... ;-). Good idea ? CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Fri Jan 9 13:19:36 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA30526 for ; Fri, 9 Jan 1998 13:19:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA19111; Fri, 9 Jan 1998 15:43:40 -0500 Resent-Date: Fri, 9 Jan 1998 15:43:40 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: O.K. - loadable keymaps ... To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 9 Jan 1998 21:27:25 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"bKkvH2.0.Bg4.blejq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/216 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folx ! Here is my first hit at loadable keymaps ... The diff to keymap.c is attached. The syntax for changing the active keymap is bind keycode mapnumber keysymbol which has to be echoed to the keymap /proc entry. Take care not to to remap a key you might need to type to change it back ;-). The protocol can be trivially derived from the output of loadkeys -m, thus I think it is a suitable start. Functionality to change strings and dead keys is still missing as well as the possibility to have multiple maps, override maps and to allocate new maps with yet unused modifier combination. Now for another thing : I would have commited to the repository, but I could not spot the new files there. I.e. patches/Linux/linux/console was not present. Am I missing something here ? Should I make cattable files for the keymaps ? BTW: the SIZE not defined bug is still there for many keymaps and due to some strange reason, the german map says it has 14 maps (instead of 13 as all others) which is not true and might eventually cause trouble ... Could someone fix this in the main repository files ? CU,Andy begin 644 keymap.c.diff M+2TM(&ME>6UA<"YC+F]L9`E3=6X@2F%N("`T(#`T.C,X.C$R(#$Y.3@**RLK M(&ME>6UA<"YC"49R:2!*86X@(#D@,C`Z-3,Z-#0@,3DY.`I`0"`M,S`L-B`K M,S`L-R!`0`H@(VEN8VQU9&4@/&=G:2]C;VYS;VQE+F@^"B`C:6YC;'5D92`\ M9V=I+V5V6UA<%]U2!A;&QO8V%T960@:V5Y=&%B;&5S+@I`0"`M-3(V+#8@*S4R M.2PU,"!`0`H@"B!S=&%T:6,@:6YT(&ME>6UA<%]WPHK"6EN="!H96QP.PHK"6-H87(@8G5F9F5R M6S(U-ET["BL)6UA<%]S=&%T92`J6UA<"`J:R`]('-T+3YM87`["BL)"BL)8G5F9F5R M6S(U-5T])UPP)SL@+RH@6UB M;VP],'AF,C`P.PHK"0EU;FEC;V1E("IM87`["BL**PD)1$5"54"(L M)F-O9&4L)FUO9&EF+"9S>6UB;VPI.PHK"BL)"41%0E5'-"@B8FEN9#H@:V5Y M/25D(&UO9#TE9"`]/B!S>6T])7@B+&-O9&4L;6]D:68L6UA<%]S:7IE M*2`_(&LM/FME>6UA<%MM;V1I9ET@.B!.54Q,.PHK"BL)"6EF("AM87`I('L* M*PD)"6EF("AK+3YK97EM:6X@/#T@8V]D92`F)@HK"0D)("`@(&-O9&4@/#T@ M:RT^:V5Y;6%X("D@>PHK"0D)"2\J($9)6$U%+B!#:&5C:R!I9B!W92!O=F5R M3TE9"!M;V0] M)60@/3X@PHK"0D)"7!R:6YT:R@B2V5Y8V]D92!O=70@;V8@8F]U;F1S+EQN(BD["BL) M"0E]"BL)"7T@96QS92!["BL)"0EP From evstack-request@ontv.com Fri Jan 9 14:56:42 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA30836 for ; Fri, 9 Jan 1998 14:56:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id RAA20410; Fri, 9 Jan 1998 17:20:51 -0500 Resent-Date: Fri, 9 Jan 1998 17:20:51 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Small fix Date: 9 Jan 1998 22:23:19 GMT Organization: OnTV Pittsburgh, L.P. Lines: 27 Distribution: local Message-ID: <69680n$igs$1@grits.visus.com> References: <6962ht$edu$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"2vA9z2.0.W-4.ZAgjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/217 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > > > How about the following as an `input format' - it's (largely) > > backwards compatible with the loadkeys format... > > > > # Define keyCode => Basecode [Send to the keyboard input device?] > > C 0x21 => B 0x12 > > C 0x22 => B 0x14 > Hmm - do you mean mapping the Linux-nonstandard "keyCode"s as we > call them now to what Andrew suggested as "BaseSyms" ? Exactly. And only base-syms are used in the rest of the mapping tables. That way the keymapping tables can be (almost) architecture independant... Esp. considering the standardization of keyboard layout that has occured over the last ~5 years... > [snip snip] The rest of it looks great. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 9 15:00:03 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA30845 for ; Fri, 9 Jan 1998 15:00:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id RAA20495; Fri, 9 Jan 1998 17:24:18 -0500 Resent-Date: Fri, 9 Jan 1998 17:24:18 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Just curious Date: 9 Jan 1998 22:26:56 GMT Organization: OnTV Pittsburgh, L.P. Lines: 44 Distribution: local Message-ID: <69687g$igs$2@grits.visus.com> References: <6960pq$crr$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"gN2AR2.0.f_4.yDgjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/218 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > So how would one get CVS-access to download 'evstack'? > (same as GGI?) Yep, just the same as GGI. Remember to: $ cvs update -dP -r EvStack-0-0-9 every time you update or the old non-evstack code will be sucked into your tree. > And - out of curiousity - can GGI drivers be loaded yet? :) > [if so I'll start hacking with EvStacks/ViRGE and see if I can get a nice > 3D demo going.... That 6 consoles on the sides of a cube sounds like fun :] KGI drivers can be loaded (VGA and Herc), however: * they require some modifications (kgi_mode has changed) * /dev/graph doesn't work... yet... > Either that or where does the TODO stand in regards to KGI/GGI? > [and keyboard + mouse? - I'll need both for that demo...] Keyboard and mouse both work. > Is there (yet) a way to make a userspace console? Hmmm.. Ask Andreas how his /dev/event code works.. Also, you could take a peek at the code for rxvt to find out how to use the /dev/pty devices (which, in all probablility, you _WILL_ need to use...) > Just some random questions to start the day - I've been sick a few weeks > and am just starting to catch up.... and this list is a lot less busy > than GGI :) Glad to see you back! I was worried there at ~Christmas.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 9 15:30:41 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA30892 for ; Fri, 9 Jan 1998 15:30:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id RAA20821; Fri, 9 Jan 1998 17:53:58 -0500 Resent-Date: Fri, 9 Jan 1998 17:53:58 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: O.K. - loadable keymaps ... Date: 9 Jan 1998 22:56:35 GMT Organization: OnTV Pittsburgh, L.P. Lines: 30 Distribution: local Message-ID: <6969v3$kd8$1@grits.visus.com> References: <6962hu$edv$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"WqVOP2.0.t45.lfgjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/219 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > Here is my first hit at loadable keymaps ... The diff to keymap.c > is attached. And committed to the repository. > I would have commited to the repository, but I could not spot the new files > there. I.e. patches/Linux/linux/console was not present. > Am I missing something here ? $ cvs -z 9 -q update -dP -r EvStack-0-0-9 > Should I make cattable files for the keymaps ? That would be great - esp. if you also have a little program to convert to/from the drivers/console/default/*.inc format... > BTW: the SIZE not defined bug is still there for many keymaps and due to some > strange reason, the german map says it has 14 maps (instead of 13 as all > others) which is not true and might eventually cause trouble ... Hmm..... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 9 17:31:38 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA31144 for ; Fri, 9 Jan 1998 17:31:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA22156; Fri, 9 Jan 1998 19:55:50 -0500 Resent-Date: Fri, 9 Jan 1998 19:55:50 -0500 Date: Fri, 9 Jan 1998 18:06:02 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: Jason McMullan cc: evstack@ontv.com Subject: Re: Just curious In-Reply-To: <69687g$igs$2@grits.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rAaB91.0.hP5.uRijq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/220 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 9 Jan 1998, Jason McMullan wrote: > teunis (teunis@mauve.computersupportcentre.com) wrote: > > So how would one get CVS-access to download 'evstack'? > > (same as GGI?) > > Yep, just the same as GGI. Remember to: > > $ cvs update -dP -r EvStack-0-0-9 > > every time you update or the old non-evstack code will > be sucked into your tree. *dang* - there isn't a guest-available account yet is there? I'm not yet exalted enough to earn my own password... *sigh* > > And - out of curiousity - can GGI drivers be loaded yet? :) > > [if so I'll start hacking with EvStacks/ViRGE and see if I can get a nice > > 3D demo going.... That 6 consoles on the sides of a cube sounds like fun :] > > KGI drivers can be loaded (VGA and Herc), however: > > * they require some modifications (kgi_mode has changed) > * /dev/graph doesn't work... yet... What's wrong with "/dev/graph"?? The modification problem is no big deal *grin* > > Either that or where does the TODO stand in regards to KGI/GGI? > > [and keyboard + mouse? - I'll need both for that demo...] > > Keyboard and mouse both work. Can ya cascade event-handlers yet? Or is it just like a traditional I/O interface? > > Is there (yet) a way to make a userspace console? > > Hmmm.. Ask Andreas how his /dev/event code works.. Also, > you could take a peek at the code for rxvt to find out how > to use the /dev/pty devices (which, in all probablility, > you _WILL_ need to use...) Already working *grin* - The big problem is grabbing the IOCTL's and the like... which is why I asked. I have _EVERYTHING_ else working - a complete linux emulation console. And if I could intercept the ioctl's and events I could also pull off font-loading, keyboard-loading and other tricks.... (it's a fully graphical console) [at the moment though the graphics code is going through a rebuild or I'd distribute the -icky- source *grin*] > > Just some random questions to start the day - I've been sick a few weeks > > and am just starting to catch up.... and this list is a lot less busy > > than GGI :) > > Glad to see you back! I was worried there at ~Christmas.... Got sick *sigh*. [a whole bunch of things] Also got an S3-ViRGE and am still trying to stablize... (I still have the S3-Trio64V+ - and can't figure out how to get it working... Just as a FWIW Microsoft Windows/98 runs perfectly as dual-monitor on these cars - it just doesn't use the second card as yet *grin*) ViRGE and svgalib don't mix. ViRGE and XFree86 are highly unstable. So GGI/EvStacks has become my prime target (good, right?) - and since I need the communication more than I need graphics, EvStacks is my first target... I'll try the last patch on the WWW site out this weekend and see how it goes with 2.1.77.... G'day, eh? :) - Teunis (if I ever get irrational on this list just toss a wet haddock at me - that was part of the illness I've been fighting off.. *really deep sigh*) *thwap with wet haddock* :) From evstack-request@ontv.com Fri Jan 9 17:46:15 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA31184 for ; Fri, 9 Jan 1998 17:46:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA22436; Fri, 9 Jan 1998 20:10:16 -0500 Resent-Date: Fri, 9 Jan 1998 20:10:16 -0500 Message-Id: From: Andrew Apted Subject: Re: Small fix To: evstack@ontv.com Date: Sat, 10 Jan 1998 12:12:18 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 9, 98 02:03:02 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Pe6UI1.0.5U5.efijq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/221 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de writes: > I am having slight problems with compiling the EvUtils, but I'm sure I can > figure it out ... EvUtil is gone, the stuff is now in the repository. Look in $GGIHOME/driver/input and $GGIHOME/util. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 9 18:09:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA31202 for ; Fri, 9 Jan 1998 18:09:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA22652; Fri, 9 Jan 1998 20:33:33 -0500 Resent-Date: Fri, 9 Jan 1998 20:33:33 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Small fix To: evstack@ontv.com (Evstack Mailing List) Date: Sat, 10 Jan 1998 01:31:57 +0100 (MET) In-Reply-To: <69680n$igs$1@grits.visus.com> from "Jason McMullan" at Jan 9, 98 10:23:19 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RZLsz2.0.WX5.Q_ijq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/222 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > # Define keyCode => Basecode [Send to the keyboard input device?] > > > Hmm - do you mean mapping the Linux-nonstandard "keyCode"s as we > > call them now to what Andrew suggested as "BaseSyms" ? > > Exactly. And only base-syms are used in the rest of the mapping > tables. That way the keymapping tables can be (almost) architecture > independant... Esp. considering the standardization of keyboard > layout that has occured over the last ~5 years... Hmm - Andrew had suggested to simply use the Base _Symbols_ ... not good for array indexing and stuff ... O.K. - we could do something "in-between" and make a table which maps numbers to all known key-inscriptions. This gives some language customization at code->base level (e.g. the german y/z swapping) and another one at base->symbol level e.g. that the key labeled with 2 has a shifted meaning of " on german keyboards, while it says @ on american ones. Would this be "the way to go" ? CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Fri Jan 9 18:09:47 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA31206 for ; Fri, 9 Jan 1998 18:09:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA22699; Fri, 9 Jan 1998 20:33:53 -0500 Resent-Date: Fri, 9 Jan 1998 20:33:53 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sat, 10 Jan 1998 02:06:41 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"b4PKE1.0.8Y5.o_ijq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/223 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > becka@rz.uni-duesseldorf.de wrote: > > Here is my first hit at loadable keymaps ... The diff to keymap.c > > is attached. > > And committed to the repository. TNX. I will recheck, if your command below helps me to get the right version ... we will see ... > > Should I make cattable files for the keymaps ? > > That would be great - esp. if you also have a little > program to convert to/from the drivers/console/default/*.inc > format... Yes. will make one ... > > BTW: the SIZE not defined bug is still there for many keymaps and due to some > > strange reason, the german map says it has 14 maps (instead of 13 as all > > others) which is not true and might eventually cause trouble ... If the new checkout/update works, I will fix those. Otherwise I'll make diffs for you. CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Fri Jan 9 18:18:15 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA31235 for ; Fri, 9 Jan 1998 18:18:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA22816; Fri, 9 Jan 1998 20:42:27 -0500 Resent-Date: Fri, 9 Jan 1998 20:42:27 -0500 Message-Id: From: Andrew Apted Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sat, 10 Jan 1998 12:44:38 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 9, 98 09:27:25 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TUHBO1.0.3a5.p7jjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/224 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de writes: > The syntax for changing the active keymap is > > bind keycode mapnumber keysymbol Excellent! This fits in with the configuration scheme I'm using for the input drivers. What I'm using is: var somename somevalue which is displayed by reading /proc, and understood by writing /proc. Take a look at the i386/joystick.c code to see what I've done. Something I'd like to do is go through all the EvStack code and make the /proc output more consistent. The format I had in mind was: info somename somevalue which is analogous to 'var', but for stuff that cannot be changed. For example, catting the console stack would look like: info stack 10010001 info class console info maintainer "Jason McMullan <...>" var report_to 0 + 10040006 + 10040008 + 1004000A + 1004000C end How does that sound ? > Should I make cattable files for the keymaps ? Yep. It would be great if you made the output of /proc the same as the input I.E. doing 'cat /proc/.../12345678-keymap' would show: bind 16 0 'Q' bind 17 0 'W' bind 18 0 'E' bind 19 0 'R' bind 20 0 'T' (just a hypothetical example). > BTW: the SIZE not defined bug is still there for many keymaps and due > to some strange reason, the german map says it has 14 maps (instead > of 13 as all others) which is not true and might eventually cause > trouble ... > > Could someone fix this in the main repository files ? I fixed it before, but for some reason it slipped out, so I can try again. It'd be like this: #if defined(AMERICAN) #include ... #elif defined(GERMAN) #include ... #elif #error Sorry, ... #endif Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 9 18:37:18 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA31260 for ; Fri, 9 Jan 1998 18:37:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA23183; Fri, 9 Jan 1998 21:01:29 -0500 Resent-Date: Fri, 9 Jan 1998 21:01:29 -0500 Message-Id: From: Andrew Apted Subject: Re: Small fix To: evstack@ontv.com Date: Sat, 10 Jan 1998 13:03:41 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69680n$igs$1@grits.visus.com> from "Jason McMullan" at Jan 9, 98 10:23:19 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_eMq_1.0.qf5.gPjjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/225 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > > Hmm - do you mean mapping the Linux-nonstandard "keyCode"s as we > > call them now to what Andrew suggested as "BaseSyms" ? > > Exactly. And only base-syms are used in the rest of the mapping > tables. That way the keymapping tables can be (almost) architecture > independant... Esp. considering the standardization of keyboard > layout that has occured over the last ~5 years... Yes, that's something I had in mind too. Keymapping with 16 bit basesyms becomes a bit harder (no more lookup tables !), but even a linear search is no big deal over 100 or so keys... It'd be nice if we could _replace_ the keycode with the basesym. The main problem I can see with that is XGGI, which _needs_ 8 bit keycodes to send along in the X protocol. Although... as soon as XGGI is able to read KGI keymaps, this problem would go away ? Another problem I just thought of is the libGGI X target (maybe all non-KGI targets ?) which would need to generate the basesym values from what they get... OH SH**! Any ideas ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 10 03:55:32 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA31846 for ; Sat, 10 Jan 1998 03:55:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id GAA29097; Sat, 10 Jan 1998 06:19:30 -0500 Resent-Date: Sat, 10 Jan 1998 06:19:30 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Small fix To: evstack@ontv.com Date: Sat, 10 Jan 1998 11:59:58 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 10, 98 01:03:41 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"fFo0O2.0.p57.karjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/226 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > Hmm - do you mean mapping the Linux-nonstandard "keyCode"s as we > > > call them now to what Andrew suggested as "BaseSyms" ? > Yes, that's something I had in mind too. Keymapping with 16 bit > basesyms becomes a bit harder (no more lookup tables !), but even a > linear search is no big deal over 100 or so keys... Yes, but ... > It'd be nice if we could _replace_ the keycode with the basesym. Hmm - I'd like to keep it for backwards compatibility ... We already miss RAW kbd mode, we should at least be able to give MEDIUMRAW. > The main problem I can see with that is XGGI, which _needs_ 8 bit > keycodes to send along in the X protocol. Although... as soon as XGGI > is able to read KGI keymaps, this problem would go away ? Yes. Hashtable would map back and that's it. > Another problem I just thought of is the libGGI X target (maybe all > non-KGI targets ?) which would need to generate the basesym values from > what they get... OH SH**! Any ideas ? Yes. This is always a problem ... We need to map these symbols around anyway, so we can as well map the corresponding basesyms, too. CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sat Jan 10 03:55:33 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA31849 for ; Sat, 10 Jan 1998 03:55:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id GAA29101; Sat, 10 Jan 1998 06:19:32 -0500 Resent-Date: Sat, 10 Jan 1998 06:19:32 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sat, 10 Jan 1998 12:20:31 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 10, 98 12:44:38 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"jyn4v.0.067.marjq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/227 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > bind keycode mapnumber keysymbol > Excellent! This fits in with the configuration scheme I'm using for the > input drivers. What I'm using is: > var somename somevalue Good. consistency is _very_ important for EvStack ... > Something I'd like to do is go through all the EvStack code and make the > /proc output more consistent. The format I had in mind was: > info somename somevalue I had thought of simply putting those in comments, i.e. lines starting with "#". This is automatically ignored by the generic proc write code: for (cptr=bptr; *cptr!='#' && *cptr!='\0'; cptr++) ; Seems the simplest and most consistent way to do it. > which is analogous to 'var', but for stuff that cannot be changed. For > example, catting the console stack would look like: Or with the scheme I propose: > # stack 10010001 > # class console > # maintainer "Jason McMullan <...>" > var report_to 0 > + 10040006 > How does that sound ? Quite good. What should we adopt ? I vote for the # (not because it is my design, but because every shell programm will intuitively know, that this is not a settable value. > > Should I make cattable files for the keymaps ? > Yep. It would be great if you made the output of /proc the same as the > input I.E. doing 'cat /proc/.../12345678-keymap' would show: Yes. Am working on that. However this would make a rather large proc output (around 2000 lines ...) I am thinking of having an alternate keyword like bindall keycode [mod0-mapping] [mod1-mapping] [mod2-mapping] ... which would fold all meanings of a key in one line and thus result in a max of about 128 lines to be displayed. This would also aid quickly setting a whole keymap using some utility. > I fixed it before, but for some reason it slipped out, so I can try > again. It'd be like this: Tnx. Please do so. CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Sat Jan 10 07:08:33 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA32116 for ; Sat, 10 Jan 1998 07:08:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA30881; Sat, 10 Jan 1998 09:32:36 -0500 Resent-Date: Sat, 10 Jan 1998 09:32:36 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: sscanf problems ... To: evstack@ontv.com (Evstack Mailing List) Date: Sat, 10 Jan 1998 15:33:54 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"q8NLE.0.4Y7.ePujq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/228 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi all ! I have been working on the inc->proc convertor, which should now be working. I will commit it (anything special about that ? Will I need to tell commit the right tag, or will it know from CVS/Tag ?). However I noticed something which is most probably a bug in the sscanf function we include : DEBUG4("bind: args=%s",str); sscanf(str," %d %d %x",&code,&modif,&symbol); DEBUG4("bind: key=%d mod=%d => sym=%x",code,modif,symbol); This seems to leave the modifier unchanged ... please check that out and see if you can find a fix. Funnily enough, the symbol is set right ... ??? CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sat Jan 10 15:23:16 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA32614 for ; Sat, 10 Jan 1998 15:23:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id RAA03063; Sat, 10 Jan 1998 17:47:14 -0500 Resent-Date: Sat, 10 Jan 1998 17:47:14 -0500 Message-Id: From: Andrew Apted Subject: Re: sscanf problems ... To: evstack@ontv.com Date: Sun, 11 Jan 1998 09:47:56 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 10, 98 03:33:54 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wafDF1.0.Ql.Uf_jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/229 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > (anything special about that ? Will I need to tell commit > the right tag, or will it know from CVS/Tag ?). If you did a full checkout with -r EvStack-0-0-9, then the tag is 'sticky' (if I understand correctly), and you don't need to specify -r for each update/commit/add etc. If you did an update over you old GGI tree with -r, then I think you need to specify it each time. > However I noticed something which is most probably a bug in the sscanf > function we include : > > DEBUG4("bind: args=%s",str); > sscanf(str," %d %d %x",&code,&modif,&symbol); > DEBUG4("bind: key=%d mod=%d => sym=%x",code,modif,symbol); > > This seems to leave the modifier unchanged ... please check that out and > see if you can find a fix. Funnily enough, the symbol is set right ... ??? Weird. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 10 15:28:15 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA32623 for ; Sat, 10 Jan 1998 15:28:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id RAA03152; Sat, 10 Jan 1998 17:52:20 -0500 Resent-Date: Sat, 10 Jan 1998 17:52:20 -0500 Message-Id: <199801102257.RAA18947@beans.visus.com> Subject: Re: Just curious To: evstack@ontv.com Date: Sat, 10 Jan 1998 17:57:03 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "teunis" at Jan 9, 98 06:06:02 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"aE6QY.0.nm.xj_jq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/230 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'teunis wrote with particular insight...' > On 9 Jan 1998, Jason McMullan wrote: > > teunis (teunis@mauve.computersupportcentre.com) wrote: > > > So how would one get CVS-access to download 'evstack'? > > > (same as GGI?) > > > > Yep, just the same as GGI. Remember to: > > > > $ cvs update -dP -r EvStack-0-0-9 > > > > every time you update or the old non-evstack code will > > be sucked into your tree. > > *dang* - there isn't a guest-available account yet is there? I'm not yet > exalted enough to earn my own password... *sigh* Hmmm... Steffen, what is the state of the GGI CVS mirrors??? > > KGI drivers can be loaded (VGA and Herc), however: > > > > * they require some modifications (kgi_mode has changed) > > * /dev/graph doesn't work... yet... > > What's wrong with "/dev/graph"?? MMAP doesn't work, Kernel Oops every now and then, etc... > Can ya cascade event-handlers yet? Or is it just like a traditional I/O > interface? Yep - just: $ echo "+ " >/proc/sys/evstack/stack/ > Already working *grin* - The big problem is grabbing the IOCTL's and the > like... which is why I asked. Hmm... Maybe you can enhance the conlinux console helper driver to emit a Event (ie, CmdIoctl), and you just have to handle them... Of course, this gets into the `Events don't have return codes' problem.... > I have _EVERYTHING_ else working - a complete linux emulation console. > And if I could intercept the ioctl's and events I could also pull off > font-loading, keyboard-loading and other tricks.... > (it's a fully graphical console) Wild! Hope to see it once you clean up the code! > ViRGE and svgalib don't mix. ViRGE and XFree86 are highly unstable. > So GGI/EvStacks has become my prime target (good, right?) - and since I > need the communication more than I need graphics, EvStacks is my first > target... > > I'll try the last patch on the WWW site out this weekend and see how it > goes with 2.1.77.... Just make sure to enable CONFIG_GGI_PRINTK_FOLLOWING and all will be well. Hmm.... Maybe I can set up a nightly `pack up the EvStack tree' job on salsa... Anyone else want that? > (if I ever get irrational on this list just toss a wet haddock at me - > that was part of the illness I've been fighting off.. *really deep sigh*) > *thwap with wet haddock* :) Not to worry - I've got a whole BUCKETFUL! -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 10 15:49:53 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA32649 for ; Sat, 10 Jan 1998 15:49:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA03468; Sat, 10 Jan 1998 18:13:34 -0500 Resent-Date: Sat, 10 Jan 1998 18:13:34 -0500 Message-Id: From: Andrew Apted Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sun, 11 Jan 1998 10:14:09 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 10, 98 12:20:31 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ed-zu1.0.lr.A20kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/231 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > Good. consistency is _very_ important for EvStack ... Agreed. > > Something I'd like to do is go through all the EvStack code and make the > > /proc output more consistent. The format I had in mind was: > > info somename somevalue > > I had thought of simply putting those in comments, i.e. lines starting > with "#". That's no good for programs that want to parse these values when reading /proc. IMHO comments should be left for _comments_, such as # this variable is in microseconds var timeout 3000 And we can ignore lines beginning with 'info ' before they even get to the ev_ops->write() function. > > How does that sound ? > > Quite good. What should we adopt ? I vote for the # (not because it is my > design, but because every shell programm will intuitively know, that this > is not a settable value. ?? How does a shell come into it ? programmER ? Anyway, I vote for 'info' (better yet: 'const') which is the read-only analog of 'var'. If that's agreeable, I'll get right on it... > > Yep. It would be great if you made the output of /proc the same as the > > input I.E. doing 'cat /proc/.../12345678-keymap' would show: > > Yes. Am working on that. However this would make a rather large proc output > (around 2000 lines ...) :-) It's not too bad. > I am thinking of having an alternate keyword like > > bindall keycode [mod0-mapping] [mod1-mapping] [mod2-mapping] ... > > which would fold all meanings of a key in one line and thus result in a max > of about 128 lines to be displayed. Sounds OK, but if it goes all the way upto [mod255-mapping], then those lines are gonna be long ... :) Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 10 15:55:09 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA32654 for ; Sat, 10 Jan 1998 15:55:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA03564; Sat, 10 Jan 1998 18:19:09 -0500 Resent-Date: Sat, 10 Jan 1998 18:19:09 -0500 Date: Sat, 10 Jan 1998 19:24:52 -0500 (EST) From: MenTaLboY X-Sender: mental@moonbase Reply-To: EvStack ML To: EvStack ML Subject: event return codes In-Reply-To: <199801110009.TAA02545@moonbase.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"g8wlI3.0.At.T70kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/232 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Hmm... Maybe you can enhance the conlinux console helper > driver to emit a Event (ie, CmdIoctl), and you just have to handle > them... Of course, this gets into the `Events don't have return codes' > problem.... Two thoughts for this -- one, do like the Berlin folks are thinking in the Berlin Core ... have two types of events: asynchronous and synchronous. Asynchronous events being the usual, and synchronous events having the producer block until the event is consumed, and then getting a return code back. Idea two is to have a 'claim ticket' that you can obtain from an event ... with the 'ticket', you can either set a value for that ticket, block until another thread or process sets a value for the ticket (or until a certain timeout), or poll to see if the ticket has been set. thoughts? -=MenTaLboY=- From evstack-request@ontv.com Sat Jan 10 17:53:43 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA00028 for ; Sat, 10 Jan 1998 17:53:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA04906; Sat, 10 Jan 1998 20:17:41 -0500 Resent-Date: Sat, 10 Jan 1998 20:17:41 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sun, 11 Jan 1998 02:22:24 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 11, 98 10:14:09 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9Xm541.0.IC1.Xs1kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/233 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > Something I'd like to do is go through all the EvStack code and make the > > > /proc output more consistent. The format I had in mind was: > > > info somename somevalue > > I had thought of simply putting those in comments, i.e. lines starting > > with "#". > That's no good for programs that want to parse these values when reading > /proc. IMHO comments should be left for _comments_, such as > # this variable is in microseconds > var timeout 3000 Hmm - yet another true point ... O.K. - let's take "const" as you suggested. > And we can ignore lines beginning with 'info ' before they even get to > the ev_ops->write() function. Let them get there. There might be cases, where one would really really write to consts ... I.e. root might be allowed to do so, while the ordinary user may only write vars. Nothing too bad happens, if such a line comes in and adding a single more if () for catching it cleanly won't be too bad, right ? > > I vote for the # (not because it is my design, but because every shell > > programm will intuitively know, that this is not a settable value. > ?? How does a shell come into it ? programmER ? er - yes ... silly typo ... > Anyway, I vote for 'info' (better yet: 'const') which is the read-only > analog of 'var'. Agreed. > If that's agreeable, I'll get right on it... Yep. But keep it so the write() function gets const-requests. Cutting out comments from the very start seems o.k., but everything else should go through ... Adding a simple if (command="const") do_nothing; shouldn't be a problem - right ? > > I am thinking of having an alternate keyword like > > bindall keycode [mod0-mapping] [mod1-mapping] [mod2-mapping] ... > Sounds OK, but if it goes all the way upto [mod255-mapping], then those > lines are gonna be long ... :) Yeah, but the usual case is 13 and I do not expect it to go beyond 32. This would result in 32*4=128 chars for an already weird case and 13*4=52 for the normal one. With the heading 12 chars, the normal case still nicely fits on one line ... CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sat Jan 10 19:11:44 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00146 for ; Sat, 10 Jan 1998 19:11:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA05672; Sat, 10 Jan 1998 21:34:24 -0500 Resent-Date: Sat, 10 Jan 1998 21:34:24 -0500 Date: Sat, 10 Jan 1998 19:47:10 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: Jason McMullan cc: evstack@ontv.com Subject: Re: Just curious In-Reply-To: <199801102257.RAA18947@beans.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"dUTRD.0.4O1.M-2kq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/234 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sat, 10 Jan 1998, Jason McMullan wrote: > > > KGI drivers can be loaded (VGA and Herc), however: > > > > > > * they require some modifications (kgi_mode has changed) > > > * /dev/graph doesn't work... yet... > > > > What's wrong with "/dev/graph"?? > > MMAP doesn't work, Kernel Oops every now and then, etc... Hmm - incomplete code? Or does it need rewriting? (perhaps somewhere I can finally attack! :) [nah - someone else'll get to it first - I'll start hacking out those 6-consoles on a gouraud-shaded cube though :] > > Already working *grin* - The big problem is grabbing the IOCTL's and the > > like... which is why I asked. > > Hmm... Maybe you can enhance the conlinux console helper > driver to emit a Event (ie, CmdIoctl), and you just have to handle > them... Of course, this gets into the `Events don't have return codes' > problem.... I'll attack this one.... hmmmm... is it possible to emit events onto the stack as a response from another event? ... just curious. That return-value thing could end up important - but I'd think something along the lines of a network protocol-based idea would work best. (queued responses) Perhaps something along the line of a message-number is needed? (unless it exists) Ref: X.11 docs for more info on this idea - although X.11 isn't the only protocol that uses it... (aside: yep - X.11 is a network protocol... *grin*... not a specific variety of graphics-server :) > > I have _EVERYTHING_ else working - a complete linux emulation console. > > And if I could intercept the ioctl's and events I could also pull off > > font-loading, keyboard-loading and other tricks.... > > (it's a fully graphical console) > > Wild! Hope to see it once you clean up the code! Should be soon. I'm using the TGA font from the kernel at the moment BTW... though I really can use any VGA-compatible font at this time (scalable 0-16 x 0-16.... it's an optimization thing. Making any font usable would slow it down some..... Call it a test in font-code caching :) [along the GGI lines I don't mind having many rendering functions for the same job - as long as the results are more efficient *grin*] > > ViRGE and svgalib don't mix. ViRGE and XFree86 are highly unstable. > > So GGI/EvStacks has become my prime target (good, right?) - and since I > > need the communication more than I need graphics, EvStacks is my first > > target... > > > > I'll try the last patch on the WWW site out this weekend and see how it > > goes with 2.1.77.... > > Just make sure to enable CONFIG_GGI_PRINTK_FOLLOWING and > all will be well. Hmm.... Maybe I can set up a nightly `pack up > the EvStack tree' job on salsa... Anyone else want that? This could help the EvStack-takes-over-the-world campaign :) How goes the portability with EvStacks anyways? It doesn't seem as though the system would be any OS-specific - although some OS's would do it best (linux with kernel-mods, QNX *grin*, Windows/32 (don't ask)) [I actually know a fair amount about Windows/32 internals - I once tried to build a replacement for Windows NT.... The code still exists but it needs a lot of work (such as a real PE file loader like the one a friend of mine wrote *grin*)] > > (if I ever get irrational on this list just toss a wet haddock at me - > > that was part of the illness I've been fighting off.. *really deep sigh*) > > *thwap with wet haddock* :) > > Not to worry - I've got a whole BUCKETFUL! *slurp* - yum! (haddock has uses other than slaps - as do cream pies et al :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 10 19:16:05 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00150 for ; Sat, 10 Jan 1998 19:16:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA05750; Sat, 10 Jan 1998 21:38:54 -0500 Resent-Date: Sat, 10 Jan 1998 21:38:54 -0500 Date: Sat, 10 Jan 1998 19:51:53 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: EvStack ML Subject: Re: event return codes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"eymBS3.0.TP1.Y23kq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/235 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sat, 10 Jan 1998, MenTaLboY wrote: > > Hmm... Maybe you can enhance the conlinux console helper > > driver to emit a Event (ie, CmdIoctl), and you just have to handle > > them... Of course, this gets into the `Events don't have return codes' > > problem.... > > Two thoughts for this -- one, do like the Berlin folks are thinking in the > Berlin Core ... have two types of events: asynchronous and synchronous. > Asynchronous events being the usual, and synchronous events having the > producer block until the event is consumed, and then getting a return code > back. > > Idea two is to have a 'claim ticket' that you can obtain from an event > ... with the 'ticket', you can either set a value for that ticket, > block until another thread or process sets a value for the ticket (or until > a certain timeout), or poll to see if the ticket has been set. This works - but opens up a lot of possibilities of deadlocks... but that's always the case to synchronous events - that's what makes realtime coding so much fun *big grin*..... Definitely support asynchronous events though - and perhaps some way of identifying past events (aka X11's transaction-numbering)... though perhaps this should be done for only specific events.... not every event requires returns.... ... although this would be really handy for handling status/abort messages though (tracking an ongoing event and aborting/erroring :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 10 19:19:33 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00173 for ; Sat, 10 Jan 1998 19:19:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id VAA05836; Sat, 10 Jan 1998 21:42:34 -0500 Resent-Date: Sat, 10 Jan 1998 21:42:34 -0500 Date: Sat, 10 Jan 1998 19:55:49 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: O.K. - loadable keymaps ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"w01yf2.0.mQ1.763kq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/236 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sun, 11 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > Something I'd like to do is go through all the EvStack code and make the > > > > /proc output more consistent. The format I had in mind was: > > > > info somename somevalue > > > I had thought of simply putting those in comments, i.e. lines starting > > > with "#". > > That's no good for programs that want to parse these values when reading > > /proc. IMHO comments should be left for _comments_, such as > > # this variable is in microseconds > > var timeout 3000 > > Hmm - yet another true point ... > > O.K. - let's take "const" as you suggested. How about "const" for true constants and "sysvar" for variables that require special access? (or "sys", "avatarvar", ... *grin*... though "sysvar" is possibly the most intuitive I can think of) Anyone remember that 'root' may eventually dissappear? Perhaps something for access-rights should be required of some kind (though a 'uid=0' test would do for now :) Just a couple of thoughts.... ignore if ya feel like it :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 10 19:56:17 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00239 for ; Sat, 10 Jan 1998 19:56:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA06281; Sat, 10 Jan 1998 22:20:15 -0500 Resent-Date: Sat, 10 Jan 1998 22:20:15 -0500 Message-Id: From: Andrew Apted Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sun, 11 Jan 1998 14:20:46 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 11, 98 02:22:24 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gvusU1.0.jX1.Xf3kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/237 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > > I had thought of simply putting those in comments, i.e. lines starting > > > with "#". > > That's no good for programs that want to parse these values when reading > > /proc. IMHO comments should be left for _comments_, such as > > # this variable is in microseconds > > var timeout 3000 > > Hmm - yet another true point ... > > O.K. - let's take "const" as you suggested. Alright, I'll get onto it ASAP. > > And we can ignore lines beginning with 'info ' before they even get to > > the ev_ops->write() function. > > Let them get there. There might be cases, where one would really > really write to consts ... I.e. root might be allowed to do so, while > the ordinary user may only write vars. Maybe... but I'd prefer something like 'sysvar' that someone else suggested... > > If that's agreeable, I'll get right on it... > > Yep. But keep it so the write() function gets const-requests. Cutting > out comments from the very start seems o.k., but everything else > should go through ... Adding a simple if (command="const") > do_nothing; shouldn't be a problem - right ? Yes, no problem. The usual behaviour of ev_ops->write() is to just return -EINVAL on something not understood, so unless we _need_ to return EOK we don't even need to check for it. > > > I am thinking of having an alternate keyword like > > > bindall keycode [mod0-mapping] [mod1-mapping] [mod2-mapping] ... > > > Sounds OK, but if it goes all the way upto [mod255-mapping], then those > > lines are gonna be long ... :) > > Yeah, but the usual case is 13 and I do not expect it to go beyond 32. > > This would result in 32*4=128 chars for an already weird case and > 13*4=52 for the normal one. With the heading 12 chars, the normal case still > nicely fits on one line ... Okay, but how will you specify which columns correspond to which modifier combinations ? It just seems to me to be a lot of fiddling just to make 'cat /proc/xxx' look nice, but that's only my two cents worth. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 10 20:28:06 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA00280 for ; Sat, 10 Jan 1998 20:28:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA06553; Sat, 10 Jan 1998 22:52:04 -0500 Resent-Date: Sat, 10 Jan 1998 22:52:04 -0500 Message-Id: <199801110357.WAA20395@beans.visus.com> Subject: Re: Just curious To: evstack@ontv.com Date: Sat, 10 Jan 1998 22:57:06 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "teunis" at Jan 10, 98 07:47:10 pm From: Jason McMullan Content-Type: text Resent-Message-ID: <"1WQTp3.0.qb1.D74kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/238 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'teunis wrote with particular insight...' > On Sat, 10 Jan 1998, Jason McMullan wrote: > > > What's wrong with "/dev/graph"?? > > > > MMAP doesn't work, Kernel Oops every now and then, etc... > > Hmm - incomplete code? Or does it need rewriting? Incomplete and mostly undebugged code - it's a `syntax' port from the 0.0.9 /dev/graph driver, and a _lot_ of stuff needs to be looked at in it... > hmmmm... is it possible to emit events onto the stack as a > response from another event? > ... just curious. Yep - check with Andreas to see if his /dev/event driver supports that... > That return-value thing could end up important - but I'd think something > along the lines of a network protocol-based idea would work best. > (queued responses) I have no good ideas on how to fix this... Andreas? > Perhaps something along the line of a message-number is needed? > (unless it exists) There is the jiffie timestamp in the event... > > Just make sure to enable CONFIG_GGI_PRINTK_FOLLOWING and > > all will be well. Hmm.... Maybe I can set up a nightly `pack up > > the EvStack tree' job on salsa... Anyone else want that? > > This could help the EvStack-takes-over-the-world campaign :) > > How goes the portability with EvStacks anyways? It doesn't seem as though > the system would be any OS-specific - although some OS's would do it best > (linux with kernel-mods, QNX *grin*, Windows/32 (don't ask)) We need to think more on it.. I'm in favor of an event model like this: A -> send event to B. Doesn't care about error notification. B -> gets A's event. processes A's event. Done. A -> sends event to B. Event is marked `want retcode' and has A's address in it. B -> gets A's event. A -> does other stuff while waiting for B's return code. if it doesn't get it in a timely fashion, it assumes failure. B -> finished processing A's event. Sends the EvRetcode event to A with the event Id of A's event and the return code. This model won't require too much re-writing, and we can have code that looks similar to this: ev_retcode_queue A_rets; A_send_event() { /* Build `notification' event ev */ ev_send(B_address,ev,NULL); /* Build `want return code' event ev */ ev_send(B_address,ev,&A_rets); retcode=ev_waitfor_retcode(ev,&A_rets,100); /* Waits for 100 ms, then returns ** -ETIME (timeout) if failure, otherwise ** returns the retcode of the event */ } ..... B_handle_event(ggi_event *ev) { /* Process event */ /* Send retcode */ ev_send_retcode(ev,EOK); } > [I actually know a fair amount about Windows/32 internals - I once tried > to build a replacement for Windows NT.... The code still exists but it > needs a lot of work (such as a real PE file loader like the one a friend > of mine wrote *grin*)] Did you ever send any code to the Wine project? Sounds like stuff right up their alley... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 10 21:10:05 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA00363 for ; Sat, 10 Jan 1998 21:10:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA07094; Sat, 10 Jan 1998 23:33:59 -0500 Resent-Date: Sat, 10 Jan 1998 23:33:59 -0500 Message-Id: <199801110439.XAA20597@beans.visus.com> Subject: Every-two-hours .tar.gz To: evstack@ontv.com Date: Sat, 10 Jan 1998 23:39:08 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan Content-Type: text Resent-Message-ID: <"1kvgj1.0.Vk1.dk4kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/239 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com GGI-EvStack is now available as an `updated every two hours' .tar.gz and a browseable source tree. See http://salsa.visus.com/~jmcc for more details. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sun Jan 11 02:45:54 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA00751 for ; Sun, 11 Jan 1998 02:45:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id FAA10924; Sun, 11 Jan 1998 05:09:53 -0500 Resent-Date: Sun, 11 Jan 1998 05:09:53 -0500 Message-Id: From: Andrew Apted Subject: Joystick moved To: evstack@ontv.com Date: Sun, 11 Jan 1998 21:09:35 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TihAT1.0.Gg2.ve9kq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/240 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, I've moved the joystick driver out of the kernel tree and into the GGI tree, $GGIHOME/driver/input/joystick/ to be precise. You'll now get it with 'make input' along with all the other input drivers. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 11 06:17:59 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA00926 for ; Sun, 11 Jan 1998 06:17:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA12868; Sun, 11 Jan 1998 08:41:51 -0500 Resent-Date: Sun, 11 Jan 1998 08:41:51 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Sun, 11 Jan 1998 13:12:40 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 11, 98 02:20:46 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"d7AMi2.0.w73.FmCkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/242 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > O.K. - let's take "const" as you suggested. > Alright, I'll get onto it ASAP. > > > And we can ignore lines beginning with 'info ' before they even get to > > > the ev_ops->write() function. > > Let them get there. > Maybe... but I'd prefer something like 'sysvar' that someone else > suggested... Yes. Right. However I still do not like the idea of cutting off arbitrary commands too early. Might confuse people. Yet another if won't kill anyone ... > Yes, no problem. The usual behaviour of ev_ops->write() is to just > return -EINVAL on something not understood, so unless we _need_ to > return EOK we don't even need to check for it. Please check this. IIRC the error code goes through to the write() that called and thus would probably abort writing ... > > > > I am thinking of having an alternate keyword like > > > > bindall keycode [mod0-mapping] [mod1-mapping] [mod2-mapping] ... > Okay, but how will you specify which columns correspond to which modifier > combinations ? Simply by the numeric ordering. Just as the tables are referenced in the "static unicode *keymaps[]" section not-available sections are filled with some dummy-value. I'll add that later today ... CU, ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sun Jan 11 06:18:00 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA00928 for ; Sun, 11 Jan 1998 06:17:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA12876; Sun, 11 Jan 1998 08:41:54 -0500 Resent-Date: Sun, 11 Jan 1998 08:41:54 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 11 Jan 1998 15:39:14 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"SOAy4.0.D83.HmCkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/243 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks ! O.K. - finally we have it back : Dynamic keymapping. I have it working fine now, including the userspace utility to convert kbd-*.c files to the /proc protocol. The suspected bug of sscanf was in my brain ... silly type-overflow which caused the once correctly set value to be zeroed out again ... However the long file that is now in the keystack proc file, as it reflects the keymapping now in its output uncovered a /proc bug. It seems we are getting rubbish at buffer-overflows. You can see this by simply catting the keymap stack. You will see some rubbish at a few places. Using dd you can find, that the rubbish occurs at buffer boundaries ... We have to check our code in this area ... You can now swap out your keymap on the fly by just doing util/procloadkeys /usr/src/linux/drivers/console/default/kbd-something.c \ >/proc/sys/evstack/stack/*-keymap I will commit the new code while uploading this mail. What more projects are there to get tackled ? I'd like to do a few of the more obvious ones first, to get into evstacks again - I have not yet gotten the full view of the current code back ... CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Sun Jan 11 06:18:00 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA00927 for ; Sun, 11 Jan 1998 06:17:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA12871; Sun, 11 Jan 1998 08:41:52 -0500 Resent-Date: Sun, 11 Jan 1998 08:41:52 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: Just curious To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 11 Jan 1998 13:06:43 +0100 (MET) In-Reply-To: <199801110357.WAA20395@beans.visus.com> from "Jason McMullan" at Jan 10, 98 10:57:06 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"N5Owd2.0.h73.DmCkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/241 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > hmmmm... is it possible to emit events onto the stack as a > > response from another event? > Yep - check with Andreas to see if his /dev/event driver supports > that... Not really. Yes you can send an event in repsonse to another event via the /dev/event interface, but it will get distributed on its own event page. Otherwise we would have to block for the usermode answering ... not good... Especially if we do not know, if the usermode wants to answer at all ... > > That return-value thing could end up important - but I'd think something > > along the lines of a network protocol-based idea would work best. > > (queued responses) > I have no good ideas on how to fix this... Andreas? > > Perhaps something along the line of a message-number is needed? > > (unless it exists) > There is the jiffie timestamp in the event... Well - basically Teunis is right, a timestamp is not enough, as there can and will be multiple events per jiffie. I see three options for retval-containing events : 1. Reserve such a field in the event and fill it out as it gets processed. This cannot be done across modes (kernel/user), but is otherwise simple and straightforward : ev=make_event();send_event(...ev...);if (ev->retcode) ... 2. Have a callback. This is not advisable because of transferring function call addresses over a not too secure channel. This, too would inhibit cross-mode answers. It is nicely asynchronous, though ... 3. Have a network-like request-reply pair. This requires the addition of a "serial-number" and is complicated to program if you have more than one outstanding request. But it would get around the user<->kernel cliffs ... > A -> sends event to B. Event is marked `want retcode' and > has A's address in it. > B -> gets A's event. > A -> does other stuff while waiting for B's return code. > if it doesn't get it in a timely fashion, it assumes > failure. > B -> finished processing A's event. Sends the EvRetcode event > to A with the event Id of A's event and the return code. Yeah, i.e. 3. CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sun Jan 11 07:05:06 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA00972 for ; Sun, 11 Jan 1998 07:05:05 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA13399; Sun, 11 Jan 1998 09:29:03 -0500 Resent-Date: Sun, 11 Jan 1998 09:29:03 -0500 Message-ID: <34B8D65F.44B5808B@bitsmart.com> Date: Sun, 11 Jan 1998 15:25:35 +0100 From: "Jonas Borgström" X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Evstack Mailing List Subject: Unpatch kernel script Content-Type: multipart/mixed; boundary="------------0BD5BCFBE44309C14F668009" Resent-Message-ID: <"XbT1X3.0.mG3.QSDkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/244 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This is a multi-part message in MIME format. --------------0BD5BCFBE44309C14F668009 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi I have just hacked the do_patch-2.1.x and made a new un_patch-2.1.x so we can now unpatch the evstack kernel. The do_patvh-2.1.x makes a link to ascii.h but in my kernel source tree I already have a ascii.h so I moved it to ascii.h.bak when patching and then move it back when unpatching, but it would be better to do it in the patch-file. The script also create the .kernelsrc file I also tested the Evstack kernel, It booted just fine but the keyboard didn't work. Can someone commit the scripts if they work. / Jonas Borgström --------------0BD5BCFBE44309C14F668009 Content-Type: application/x-unknown-content-type-WinZip; name="Patch.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Patch.tgz" H4sIAPDSuDQAA+1WW0/bMBTmtf4VhxBRaVKSJr0gQemEWMcQuyAYe5mmEhK3tUjtzk4K7NfP sZPQorYb2hhD8vcSxz4+l88n+RyzwTRMo7ETuL57u/Ek8BuNnXYbNiBH48ETIGi3fYBOq93x WzvtnSaA77earQ1oPE06i8hEGnKADc5Yus7uV+svFFub3hWhnhijLbQFcEwlHUkioD87T8Po Gq4xpzgB1SPaxPZrtRM9K1jGIwwx4WohqNWOjo4hZVMnwTO5Xi40qx3KD+jVlAHR4RAiQ/gK zg+wbN8Ch+lhcD9sWvBtD9IxpqgWhSl0uxfnB0f9Qf/TW/B72wG6EOEI7yJkNwC6OumBTi/v 73EPuqMRGcjUBip4rzKaYS4Ioz1UOUQ1fEtS8NGQIHTSP/v45vhs3/bV8Kz/Zd9uIlmmmgzy 0enB58N36lVPe6pILLz3hGa3CEUx2IUbXadlv7Zgcx+sRlUVgIwajZlca+zCYUjrKdSjuJ6T VG7etCDobftFeoFKT/nbBGcI9Q/hNR6SBNdz0uRUDDEneXXVe8gl9xWN9+GOQWRiiqO0CgVE 5BncjDHHuTmoUspm0LwK6Q+7rrs2K3uOH82LYxc8LstEFz4kNNadktcDQ8bLyLNy86qgskrb 9wiNkizGnjzyKgoUYfozoRpbd2KYcBzGdxBOpwnBsWvtlae/p5xqK2fqg+N8zwiWnbeupJXn u1Aky5I4rzMPerfwha3ja9nx80lO8qUizAWHhhMMr1zGyegSoYSCI6BsynlOyvGcSRU0yU/a K1rHixgVTJ5B+Y4ms2q3tgxFRIg7Xj7rXoXXq4P8jiOkeLN96Mn/S5GW52rOBI8eSXgcA8U3 kLeVgCFnkyVpLeNZ+zpVRxSxyTTBKQYH5DMUGHhGoT6Rnx9MMM0kZUMyqhfuiw/KQs/9o1+B jD6//gdBs9L/TtBW+t/qGP3/F3ig/xeUmBuAuQH8tRvAI+WYsnSlFD/LpaLQf4fjnEf8VDeB 0v2f3wXmuC5mHkj5A7sF7V2p7rmOr9iy7gqi1yrdFvPCXWjqBZ0uqKr73yqlgYGBgYGBgYGB gYGBgYGBgYGBgYGBgYHBy8BPDPwf8QAoAAA= --------------0BD5BCFBE44309C14F668009-- From evstack-request@ontv.com Sun Jan 11 08:46:30 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA01144 for ; Sun, 11 Jan 1998 08:46:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id LAA14412; Sun, 11 Jan 1998 11:09:07 -0500 Resent-Date: Sun, 11 Jan 1998 11:09:07 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Alert ... CMOS checksum error ... To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 11 Jan 1998 18:10:25 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"GnFyt3.0.mW3.HwEkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/245 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi ! I forgot in my last post ... I have now re-set my CMOS for the 3rd time. I am not sure, If the EvStack patch has anything to do with it, but if I soft-reboot my system by issueing shutdown -rt 5 now, The system hangs at the place, where it should reboot and then my CMOS get f***ed up. It might be a general problem with 2.1.77, but ... simply going to telinit 1 and umount -a and then pressing reset works fine, though ... I will check further ... e.g. what happens on shutdown -ht 5 now ... CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Sun Jan 11 14:16:56 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA01523 for ; Sun, 11 Jan 1998 14:16:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id QAA17431; Sun, 11 Jan 1998 16:40:47 -0500 Resent-Date: Sun, 11 Jan 1998 16:40:47 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: keymapping works o.k. now. Date: 11 Jan 1998 21:43:23 GMT Organization: OnTV Pittsburgh, L.P. Lines: 37 Distribution: local Message-ID: <69bedr$j13$1@grits.visus.com> References: <69aimi$trb$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"vQ8Dk1.0.yF4.0nJkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/246 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > What more projects are there to get tackled ? I'd like to do a few of the > more obvious ones first, to get into evstacks again - I have not yet gotten > the full view of the current code back ... Did you fix the keymap code such that we can have a global keymap (for ALT-F1-F10, SAK, etc) and per-VT keymaps? How about implemting the `return-capable' evstack code? Ie: /* Sets the event id to a unique integer, ** and the struct's `type' to type */ ggi_event *ev_setup_event(ggi_event *fresh_event,ev_type type,bool want_ret); typedef /* something */ ev_event_queue; /* Set up the `wait queue' for a evstack id ** (the EvStack ID can be for a device, a class of stacks, ** or a singe stack) ** ** Done on module init. */ int ev_attach_event_queue(ev_event_queue *queue,ev_id stack_id); int ev_detach_event_queue(ev_id stack_id); /* Send and wait for results */ void ev_send(ggi_event *ev,ev_id target); int ev_waitfor(ggi_event_id id,ulong millisec_timeout); -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sun Jan 11 16:50:24 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA01696 for ; Sun, 11 Jan 1998 16:50:23 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA19056; Sun, 11 Jan 1998 19:14:11 -0500 Resent-Date: Sun, 11 Jan 1998 19:14:11 -0500 Message-Id: From: Andrew Apted Subject: Re: Unpatch kernel script To: evstack@ontv.com Date: Mon, 12 Jan 1998 11:14:42 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <34B8D65F.44B5808B@bitsmart.com> from "Jonas Borgström" at Jan 11, 98 03:25:35 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GsZir3.0.If4.y0Mkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/247 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jonas Borgström writes: > I also tested the Evstack kernel, It booted just fine but the keyboard > didn't work. You probably got a CVS snapshot at a bad time. (same thing happened to me). There's now a CONFIG_GGI_EVKEYMAP option, so you just need to 'make oldconfig' (and probably 'make dep; make clean' too), and it should work again. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 11 18:01:19 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA01769 for ; Sun, 11 Jan 1998 18:01:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA19755; Sun, 11 Jan 1998 20:25:09 -0500 Resent-Date: Sun, 11 Jan 1998 20:25:09 -0500 Date: Sun, 11 Jan 1998 18:38:08 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: Jason McMullan cc: evstack@ontv.com Subject: Re: Just curious In-Reply-To: <199801110357.WAA20395@beans.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cxb2x1.0.8q4.I3Nkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/248 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sat, 10 Jan 1998, Jason McMullan wrote: > 'teunis wrote with particular insight...' > > On Sat, 10 Jan 1998, Jason McMullan wrote: > > > > What's wrong with "/dev/graph"?? > > > > > > MMAP doesn't work, Kernel Oops every now and then, etc... > > > > Hmm - incomplete code? Or does it need rewriting? > > Incomplete and mostly undebugged code - it's a `syntax' port > from the 0.0.9 /dev/graph driver, and a _lot_ of stuff needs to > be looked at in it... I'll start taking a peek - but I suspect that Andy'll get to it long before I will.... (I'll just use svgalib/X for now - evstacks DOES work there, right? :) > > hmmmm... is it possible to emit events onto the stack as a > > response from another event? > > ... just curious. > > Yep - check with Andreas to see if his /dev/event driver supports > that... > > > That return-value thing could end up important - but I'd think something > > along the lines of a network protocol-based idea would work best. > > (queued responses) > > I have no good ideas on how to fix this... Andreas? > > > Perhaps something along the line of a message-number is needed? > > (unless it exists) > > There is the jiffie timestamp in the event... That might do.... jiffies + source-ID becomes a farely unique ID, right? ... and as long as the sender/receiver remembers that for future info... ...hmmm.... no, perhaps an "ID" field should be used.... [still thinking] > We need to think more on it.. I'm in favor of an event model > like this: > > A -> send event to B. Doesn't care about error notification. > B -> gets A's event. processes A's event. Done. > > A -> sends event to B. Event is marked `want retcode' and > has A's address in it. > B -> gets A's event. > A -> does other stuff while waiting for B's return code. > if it doesn't get it in a timely fashion, it assumes > failure. > B -> finished processing A's event. Sends the EvRetcode event > to A with the event Id of A's event and the return code. I have one more model to toss by: (example is clearer if you think of "A" as a movie-player and "B" as the display... :) A -> broadcasts start message with ID B -> catches message and starts watching A -> broadcasts intermittent update-messages with same start ID (update notification / ...) B -> broadcasts ID + error if there's an error anywhere.... (abort-handling) A -> broadcasts ID + AOK when broadcast is finished. A -> broadcasts ID + ABOR if aborts for some reason A -> broadcasts ID + INTERRUPTED if interrupted for some reason A -> broadcasts ID + CONTINUING if continuing after interrupt This uses EvStacks as a token-based facility... very handy when transferring large amounts of data through another media - eg. disk buffers, memory-maps, and the like. And with this error recovery/abort/pause it's a LOT easier to do real-time system management (use this to monitor file-management for a RT kernel such as RT-linux or QNX :) > This model won't require too much re-writing, and we can have code > that looks similar to this: [clipped code - cool :] I don't think the additional model I just wrote will add any either - but I'm still exploring *grin* > > [I actually know a fair amount about Windows/32 internals - I once tried > > to build a replacement for Windows NT.... The code still exists but it > > needs a lot of work (such as a real PE file loader like the one a friend > > of mine wrote *grin*)] > > Did you ever send any code to the Wine project? Sounds like stuff > right up their alley... I'm working with only Win/32 and they have a lot of win/16 support. Perhaps I'll check it out again. (last time I looked they were too incomplete to even look at copying my code over... perhaps once I've got this console-demon working I'll look at making a GGI-native Wine :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sun Jan 11 18:05:51 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA01773 for ; Sun, 11 Jan 1998 18:05:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA19834; Sun, 11 Jan 1998 20:29:37 -0500 Resent-Date: Sun, 11 Jan 1998 20:29:37 -0500 Date: Sun, 11 Jan 1998 18:42:44 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: Evstack Mailing List Subject: Re: Just curious In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"j0exf3.0.Wr4.n7Nkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/249 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sun, 11 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > hmmmm... is it possible to emit events onto the stack as a > > > response from another event? > > > Yep - check with Andreas to see if his /dev/event driver supports > > that... > > Not really. Yes you can send an event in repsonse to another event via the > /dev/event interface, but it will get distributed on its own event page. > > Otherwise we would have to block for the usermode answering ... not good... > Especially if we do not know, if the usermode wants to answer at all ... Oh - that's quite good enough *grin*.... All I need is that both userspace and kernel programs can broadcast events to eachother.... > > > That return-value thing could end up important - but I'd think something > > > along the lines of a network protocol-based idea would work best. > > > (queued responses) > > I have no good ideas on how to fix this... Andreas? > > > Perhaps something along the line of a message-number is needed? > > > (unless it exists) > > There is the jiffie timestamp in the event... > > Well - basically Teunis is right, a timestamp is not enough, as there can > and will be multiple events per jiffie. But are multiple possible from the same source ID? (how complete is source ID? does it include thread-ID? :) > I see three options for retval-containing events : > > 1. Reserve such a field in the event and fill it out as it gets processed. > This cannot be done across modes (kernel/user), but is otherwise simple and > straightforward : > > ev=make_event();send_event(...ev...);if (ev->retcode) ... > > 2. Have a callback. This is not advisable because of transferring function > call addresses over a not too secure channel. This, too would inhibit > cross-mode answers. It is nicely asynchronous, though ... > > 3. Have a network-like request-reply pair. This requires the addition of > a "serial-number" and is complicated to program if you have more than one > outstanding request. But it would get around the user<->kernel cliffs ... I'll work on 3. For obvious reasons 1 and 2 aren't duable.... *sigh* (I need kernel/user talking back and forth) 3 makes the most sense to me anyways. > > A -> sends event to B. Event is marked `want retcode' and > > has A's address in it. > > B -> gets A's event. > > A -> does other stuff while waiting for B's return code. > > if it doesn't get it in a timely fashion, it assumes > > failure. > > B -> finished processing A's event. Sends the EvRetcode event > > to A with the event Id of A's event and the return code. > > Yeah, i.e. 3. Check out my other message about continuing messages *grin* G'day, eh? :) - Teunis From evstack-request@ontv.com Sun Jan 11 19:44:59 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA01885 for ; Sun, 11 Jan 1998 19:44:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA20986; Sun, 11 Jan 1998 22:08:34 -0500 Resent-Date: Sun, 11 Jan 1998 22:08:34 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Mon, 12 Jan 1998 01:13:15 +0100 (MET) In-Reply-To: <69bedr$j13$1@grits.visus.com> from "Jason McMullan" at Jan 11, 98 09:43:23 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"BkNAT1.0.W75.HaOkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/250 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > becka@rz.uni-duesseldorf.de wrote: > > What more projects are there to get tackled ? I'd like to do a few of the > > more obvious ones first, to get into evstacks again - I have not yet gotten > > the full view of the current code back ... > Did you fix the keymap code such that we can have a global > keymap (for ALT-F1-F10, SAK, etc) and per-VT keymaps? No - not yet. I will probably try this as the next thing ... > How about implemting the `return-capable' evstack code? Ie: Hmm - we should think well about that. This is very deadlock-prone IMHO ... The current code is rather synchronous, so no big problems here and we could simply reserve RC fields in the command-type event which get filled out. This is much better for the situation where multiple stacks might have an answer and much simpler to code (i.e. nothing to code actually) ... What for do we need it really ? CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Sun Jan 11 21:34:17 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA02048 for ; Sun, 11 Jan 1998 21:34:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA21865; Sun, 11 Jan 1998 23:57:54 -0500 Resent-Date: Sun, 11 Jan 1998 23:57:54 -0500 Message-Id: From: Andrew Apted Subject: Re: O.K. - loadable keymaps ... To: evstack@ontv.com Date: Mon, 12 Jan 1998 15:58:33 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 11, 98 01:12:40 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7FSkg1.0.GL5.vAQkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/251 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > The usual behaviour of ev_ops->write() is to just > > return -EINVAL on something not understood, so unless we _need_ to > > return EOK we don't even need to check for it. > > Please check this. IIRC the error code goes through to the write() > that called and thus would probably abort writing ... I've checked it, and you're right, the write is aborted. (the bits above an unknown line get through, the bits below it don't). We could just return EOK when a line is not understood, it kinda matches the EvStack philosophy of ignoring unknown events... Otherwise we need to put something like this in each handler the outputs 'const' information: if (strcmp(str, "const") == 0) { return EOK; } Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 11 21:43:22 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA02060 for ; Sun, 11 Jan 1998 21:43:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id AAA22106; Mon, 12 Jan 1998 00:07:06 -0500 Resent-Date: Mon, 12 Jan 1998 00:07:06 -0500 Message-Id: From: Andrew Apted Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Mon, 12 Jan 1998 16:07:57 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 11, 98 03:39:14 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dlUGE2.0.qO5.bJQkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/252 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > You can now swap out your keymap on the fly by just doing > > util/procloadkeys /usr/src/linux/drivers/console/default/kbd-something.c \ > >/proc/sys/evstack/stack/*-keymap Sounds great! > However the long file that is now in the keystack proc file, as it reflects > the keymapping now in its output uncovered a /proc bug. > > It seems we are getting rubbish at buffer-overflows. > > You can see this by simply catting the keymap stack. You will see some > rubbish at a few places. Using dd you can find, that the rubbish occurs > at buffer boundaries ... > We have to check our code in this area ... I've checked this, and I think the problem is to do with a 4K (i.e. page-size) limit on /proc buffers. What we would need to do then is to return one line at a time, instead of the whole damn lot. If you like, I can try to implement this whilst I'm revamping the /proc output... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 12 04:42:51 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA02545 for ; Mon, 12 Jan 1998 04:42:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA27428; Mon, 12 Jan 1998 07:06:16 -0500 Resent-Date: Mon, 12 Jan 1998 07:06:16 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Mon, 12 Jan 1998 12:25:17 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 12, 98 04:07:57 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"7MuVg.0.Wh6.9SWkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/253 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > the keymapping now in its output uncovered a /proc bug. > > > > It seems we are getting rubbish at buffer-overflows. > > > > You can see this by simply catting the keymap stack. You will see some > > rubbish at a few places. Using dd you can find, that the rubbish occurs > > at buffer boundaries ... > > We have to check our code in this area ... > I've checked this, and I think the problem is to do with a 4K (i.e. > page-size) limit on /proc buffers. Using dd you can find out, that it happens on read-boundaries, too. > What we would need to do then is to return one line at a time, instead > of the whole damn lot. > If you like, I can try to implement this whilst I'm revamping the /proc > output... Would be great ... People would shoot us, if they get random rubbish out of our /proc entries ... CU, ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 04:42:52 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA02548 for ; Mon, 12 Jan 1998 04:42:51 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA27429; Mon, 12 Jan 1998 07:06:18 -0500 Resent-Date: Mon, 12 Jan 1998 07:06:18 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Mon, 12 Jan 1998 14:07:02 +0100 (MET) In-Reply-To: <199801120327.WAA01362@beans.visus.com> from "Jason McMullan" at Jan 11, 98 10:27:38 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"i_RuK3.0.nh6.HSWkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/254 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > How about implemting the `return-capable' evstack code? Ie: > > Hmm - we should think well about that. This is very deadlock-prone IMHO ... > > The current code is rather synchronous, so no big problems here and we could > > simply reserve RC fields in the command-type event which get filled out. > It is NOT deadlock-prone with the time-outs. If you don't get > a response in time, -ETIME is returned. As simple as that. Yes. O.K. - let's see. What kind of RCs do you want to transport ? Only integers or arbitrary data ? In the latter case we could simply allocate a range of commands for GGI-command events and use them. If integers suffice, we are done with allocating a single CMD_RC_REPLY. O.K. ? > > This is much better for the situation where multiple stacks might have an > > answer and much simpler to code (i.e. nothing to code actually) ... > I am of the feeling that the 2 days worth of coding to `get > it right' now will be worth the 5 years of `PLEASE rewrite > it so we can do XXX!' and `No, it would break YY and ZZ!' O.K. - so what happens if multiple stacks answer ? In the scheme you propose the first answer would get through, as this would unblock the wait - right ? I am unsure, if it wouldn't be good, if the answer would be "overridable" ... There is another issue to be discussed: Currently when ev_send returns, the Evpage has been fully passed through its queue, except for usermode-parts which run asynchronously on a copy of the EvPage. Should this be changed ? How should it work, then ? Kernel threads would be one possibility, but this is a "Linux-only" feature. I do not actually expect EvStack to be ported, but ... > If we do it right, the retcode events are just that - > special events that return data to their parents. Yeah and this is the catch with the above behaviour : Say A calls B with a retcode-requiring event. So how does B send the RC back ? O.K. - it can: 1. Add its RC event to the EvPage. Simple and can be checked after the ev_send of A has returned. But it misses the whole purpose of using a RC event instead of just setting a var in the original request - being able to go kernel<->user. 2. Use ev_send by itself and so somehow route the RC event to A. Now here is the catch : A will still be stuck in its ev_send and has not yet reached the ev_wait_for_RC(). Thus one would have to sort of "cache" the RC in A's event handler and later transferred ton the ev_wait_for_RC ... An idea would be to allocate some kind of RC-descriptor _before_ even sending the event. The kernel RC-event handler would know all such descriptors, and if an RC drops in, it gets stored there. The descriptor would hold a wait_queue, so it can be waited for getting set. This would take care of both situations, where the RC is sent before the original ev_send completes and when it comes in later. Good idea ? > The timeout-queue structure is the `interesting' part. This shouldn't be a big deal ... many drivers use such constructs (e.g. CDROM drivers waiting for door-close etc ...) CU,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 07:04:18 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA02703 for ; Mon, 12 Jan 1998 07:04:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA28842; Mon, 12 Jan 1998 09:27:55 -0500 Resent-Date: Mon, 12 Jan 1998 09:27:55 -0500 Message-Id: From: Andrew Apted Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Tue, 13 Jan 1998 01:26:45 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 12, 98 02:07:02 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"n2kCu3.0.427.zVYkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/255 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > How about implemting the `return-capable' evstack code? Ie: > > Hmm - we should think well about that. This is very deadlock-prone IMHO ... > The current code is rather synchronous, so no big problems here and we could > simply reserve RC fields in the command-type event which get filled out. For kernel <-> kernel event transfers, that's the way to do it, and this whole return code thingy is no problem. Therefore I think the return code problem is very much a part of the kernel <-> usermode problem. > There is another issue to be discussed: > > Currently when ev_send returns, the Evpage has been fully passed through > its queue, except for usermode-parts which run asynchronously on a copy of > the EvPage. > > Should this be changed ? How should it work, then ? This is the main issue I think, and it's something I've been pondering on for a while. I'm not sure the functionality of in-kernel event handler() functions can't be exported to usermode. By functionality I mean: - The ability to modify events before others in the chain see them. This includes marking the event as consumed. This reduces the usermode stuff to just reading and writing events asynchronously. Thus you can't implement an evring-like parser in usermode (an event converter, e.g. a mouse accelerator). So I guess this really IS a problem. If we try to implement the handler() function in usermode, I see the following problem: - Since ev_send() is synchronous, we must wait for the usermode process to receive the evpage, get scheduled to run, ..., and send the new evpage back into the kernel. Even on a unloaded system this will slow things down quite a bit. On a loaded system (e.g. with ggidoom running full pelt) ... [hmmm, maybe not as bad as I thought...] What do you guys think ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 12 09:19:05 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA02922 for ; Mon, 12 Jan 1998 09:19:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id LAA30424; Mon, 12 Jan 1998 11:42:17 -0500 Resent-Message-Id: <199801121644.IAA03404@nova.botz.org> Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: [Feature Wish] GGI in Linux 2.3 To: jerijian@jaddams.csw.uic.edu (Arthur Jerijian) Date: Mon, 12 Jan 1998 15:37:06 +0000 (GMT) Cc: linux-kernel@vger.rutgers.edu In-Reply-To: from "Arthur Jerijian" at Jan 12, 98 07:59:51 am Content-Type: text X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Resent-To: linux-ggi@eskimo.com, evstack@ontv.com Resent-Date: Mon, 12 Jan 1998 08:44:26 -0800 Resent-From: Jurgen Botz Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/256 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Graphics Interface, which is much more stable and robust than the previous > version. My personal opinion is that plans should be made to incorporate > GGI in Linux 2.3. It's about time that we get fast graphics in Linux I had a good look at the current GGI and it has several problems to say the least. o Its console emulation isnt Linux but a sort of pseudo xterminal o It appears to have no provision for non byte wide fonts o It breaks all the existing low level mouse/keyboard interfaces and replaces them with its own which has policy in kernel space Having said that if combined with the current fbcon code it does give you support for reliable SVGA mode switching and kernel side acceleration where useful (eg DMA driven video blits from main memory) and there is useful stuff that can be salvaged from it. The nicest looking bits are actually the userspace support libraries which show some promise. Alan From evstack-request@ontv.com Mon Jan 12 09:54:52 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA03042 for ; Mon, 12 Jan 1998 09:54:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA30989; Mon, 12 Jan 1998 12:17:49 -0500 Resent-Date: Mon, 12 Jan 1998 12:17:49 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Mon, 12 Jan 1998 18:29:41 +0100 (MET) In-Reply-To: from "Andrew Apted" at Jan 13, 98 01:26:45 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"od9sl2.0.KY7.mwakq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/257 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi ! > > Currently when ev_send returns, the Evpage has been fully passed through > > its queue, except for usermode-parts which run asynchronously on a copy of > > the EvPage. > > Should this be changed ? How should it work, then ? > > This is the main issue I think, and it's something I've been pondering > on for a while. I'm not sure the functionality of in-kernel event > handler() functions can't be exported to usermode. By functionality I mean: > > - The ability to modify events before others in the chain see > them. This includes marking the event as consumed. > > This reduces the usermode stuff to just reading and writing events > asynchronously. Thus you can't implement an evring-like parser in > usermode (an event converter, e.g. a mouse accelerator). So I guess > this really IS a problem. Yes. You cannot "modify" an event that came from kernelmode. All you could do is make up a new one and send this. Say for the mouse-accel you would probably end up with sending events for a second "virtual" mouse which follows the real one, but accelerated. > If we try to implement the handler() function in usermode, I see the > following problem: > - Since ev_send() is synchronous, we must wait for the usermode > process to receive the evpage, get scheduled to run, ..., and > send the new evpage back into the kernel. Even on a unloaded > system this will slow things down quite a bit. On a loaded > system (e.g. with ggidoom running full pelt) ... Yes. Usermode must be kept asynchronous. > [hmmm, maybe not as bad as I thought...] It is. Scheduling granularity is about 1/100sec ... guess the rest ... CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 09:56:34 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA03061 for ; Mon, 12 Jan 1998 09:56:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA31035; Mon, 12 Jan 1998 12:20:11 -0500 Resent-Date: Mon, 12 Jan 1998 12:20:11 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: jmcc@ontv.com Date: Mon, 12 Jan 1998 18:23:36 +0100 (MET) In-Reply-To: <199801121414.JAA10398@beans.visus.com> from "Jason McMullan" at Jan 12, 98 09:14:47 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"q8TY4.0.cY7.3xakq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/258 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Yes. O.K. - let's see. What kind of RCs do you want to transport ? Only > > integers or arbitrary data ? > I want to do just like C - return (at max) the architecture's integer > size of data. Ie, 32bit for intel/sparc/amiga, 64bit for Alpha/UltraSparc/etc. O.K. - I.e. return integer and eventually cast appropriately. > > O.K. - so what happens if multiple stacks answer ? In the scheme you propose > > the first answer would get through, as this would unblock the wait - right ? > Correct. [Although, in 99% of the cases, idea is to consume the event > before you reply to it...] Yes. But it might be good, if one could kill off some "sorry, can't" reply by "hey, but I can !". > > I am unsure, if it wouldn't be good, if the answer would be "overridable" ... > Agreed. O.K. - so we should think about a scheme for that. > > There is another issue to be discussed: > > Currently when ev_send returns, the Evpage has been fully passed through > > its queue, except for usermode-parts which run asynchronously on a copy of > > the EvPage. > > Should this be changed ? How should it work, then ? > > All we change is documentation - on ev_send return, the EvPage's data > is `undefined' - if you _really_ need to know whether an event has > been read by it's target, use the retcode system. This will work > for both kernel and user mode. Danger here ! The danger is the disposal of the EvPage ... You _have_ to know it is not in use anymore before freeing it, thus we need locking,m if we go fully asynchronous. > > Yeah and this is the catch with the above behaviour : > > > > Say A calls B with a retcode-requiring event. So how does B send the RC back ? > > 2. Use ev_send by itself and so somehow route the RC event to A. Now here is > > the catch : A will still be stuck in its ev_send and has not yet reached the > > ev_wait_for_RC(). Thus one would have to sort of "cache" the RC in A's > > event handler and later transferred ton the ev_wait_for_RC ... > > Which is why `ev_retqueue_register' overrides the A's event handler > with the `queue retcode events and pass through all others' handler. Hmm - i.e. you have something like a retcode handler _per_stack_ from the very beginning and thus catch retcode events and queue them up internally - right ? > > An idea would be to allocate some kind of RC-descriptor _before_ even sending > > the event. The kernel RC-event handler would know all such descriptors, > > and if an RC drops in, it gets stored there. > An idea, but by allocating the RC queue on a per-stack basis, you > don't have to worry about old RCs in the queue for evstack modules > that have already unloaded themselves. ??? Such a descriptor would be expected to be destroyed, when it has been waited for. What I do not like with the RC-handler you propose above, is that it would eventually build yet another queueing layer in_every_stack in case multiple RCs came in ... The descriptor solution puts the equivalent (the list of currently active descriptors) in one central place ... What I am talking about is something like { descid di; di=ev_get_rcdesc(); __make_event__(); ev.data.RC=di; ev_send(); ev_waitfor_rc(di,timeout); ev_destroy_rcdesc(di); } Advantages : By handing a single argument to teh get_rcdesc function, one could allocate arbitrarily large amounts of storage for the RC allowing to return things like structs or whole events. Central queue for such "locks", which can be auto-cleaned, if necessary. Ability to simply schedule waiting for later, if the answer is not urgently needed. No additional queueing code or event identification needed in the stacks. This is handled by the new rc-functions. Comments ? -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 10:31:52 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA03129 for ; Mon, 12 Jan 1998 10:31:51 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA31359; Mon, 12 Jan 1998 12:55:32 -0500 Resent-Date: Mon, 12 Jan 1998 12:55:32 -0500 Date: Mon, 12 Jan 1998 11:08:28 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list Subject: installing from CVS-source Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"-Em4e2.0.Wf7.mZbkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/259 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Call me unworthy or whatever but How Does One Install EvStack from the CVS source? Is it the same as standard GGI? Am curious as there's no mention of EvStack in the docs.... (hint-hint!) (I also haven't installed GGI since 2.1.56 and a lot has changed... is 2.1.78 supported yet?) G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 12 10:42:41 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA03143 for ; Mon, 12 Jan 1998 10:42:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id NAA31616; Mon, 12 Jan 1998 13:06:02 -0500 Resent-Date: Mon, 12 Jan 1998 13:06:02 -0500 Date: Mon, 12 Jan 1998 14:10:51 -0500 (EST) From: MenTaLboY X-Sender: mental@moonbase Reply-To: mentalboy@geocities.com To: EvStack ML Subject: EvPage locks In-Reply-To: <199801121833.NAA06124@moonbase.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8xg4T3.0.Mj7.Libkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/260 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > Currently when ev_send returns, the Evpage has been fully passed through > > > its queue, except for usermode-parts which run asynchronously on a copy of > > > the EvPage. > > > Should this be changed ? How should it work, then ? > > > > All we change is documentation - on ev_send return, the EvPage's data > > is `undefined' - if you _really_ need to know whether an event has > > been read by it's target, use the retcode system. This will work > > for both kernel and user mode. > > Danger here ! The danger is the disposal of the EvPage ... > You _have_ to know it is not in use anymore before freeing it, thus > we need locking,m if we go fully asynchronous. Or at least a usage count; the count starts at one when the EvPage is created, 'claiming' an EvPage increments it, 'releasing' an EvPage decrements it, and when the usage count hits zero as a result of being 'released', it EvPage is destroyed. -=MenTaLboY=- From evstack-request@ontv.com Mon Jan 12 13:07:54 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA03343 for ; Mon, 12 Jan 1998 13:07:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA00623; Mon, 12 Jan 1998 15:30:19 -0500 Resent-Date: Mon, 12 Jan 1998 15:30:19 -0500 Message-Id: <199801122033.PAA15581@beans.visus.com> Subject: Re: installing from CVS-source To: evstack@ontv.com Date: Mon, 12 Jan 1998 15:33:58 -0500 (EST) Reply-To: jmcc@ontv.com In-Reply-To: from "teunis" at Jan 12, 98 11:08:28 am From: Jason McMullan Content-Type: text Resent-Message-ID: <"dQq-m.0.59.hpdkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/261 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'teunis wrote with particular insight...' > Call me unworthy or whatever but How Does One Install EvStack from the CVS > source? > Is it the same as standard GGI? Yep - just do a `install GGI kernel' from the top level, make config (and make SURE to turn on most everything in the Console/GGI configuration!) > Am curious as there's no mention of EvStack in the docs.... (hint-hint!) > (I also haven't installed GGI since 2.1.56 and a lot has changed... is > 2.1.78 supported yet?) 2.1.78 is the _only_ kernel supported - I keep on track with the latest kernels, if at all possible. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 12 13:17:56 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA03365 for ; Mon, 12 Jan 1998 13:17:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id PAA00767; Mon, 12 Jan 1998 15:41:26 -0500 Resent-Date: Mon, 12 Jan 1998 15:41:26 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: keymapping works o.k. now. Date: 12 Jan 1998 20:43:47 GMT Organization: OnTV Pittsburgh, L.P. Lines: 76 Distribution: local Message-ID: <69dva3$idd$1@grits.visus.com> References: <69djcc$8r4$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"3QSLm.0.QB.6_dkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/262 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > I want to do just like C - return (at max) the architecture's integer > > size of data. Ie, 32bit for intel/sparc/amiga, 64bit for Alpha/UltraSparc/etc. > O.K. - I.e. return integer and eventually cast appropriately. Exactly. Keep it small. > > > O.K. - so what happens if multiple stacks answer ? In the scheme you propose > > > the first answer would get through, as this would unblock the wait - right ? > > Correct. [Although, in 99% of the cases, idea is to consume the event > > before you reply to it...] > Yes. But it might be good, if one could kill off some "sorry, can't" reply > by "hey, but I can !". Hmmm.. Don't like that too much... I would prefer to say: "Before your do a retcode event, you MUST consume the querying event" > > All we change is documentation - on ev_send return, the EvPage's data > > is `undefined' - if you _really_ need to know whether an event has > > been read by it's target, use the retcode system. This will work > > for both kernel and user mode. > Danger here ! The danger is the disposal of the EvPage ... > You _have_ to know it is not in use anymore before freeing it, thus > we need locking,m if we go fully asynchronous. Uh.. I didn't mean to say we'd go _fully_ asynch - just async on retcode events [which are queued by the stack's (subverted) handler] > Hmm - i.e. you have something like a retcode handler _per_stack_ from the > very beginning and thus catch retcode events and queue them up internally - > right ? Yes. That's the general idea. > > An idea, but by allocating the RC queue on a per-stack basis, you > > don't have to worry about old RCs in the queue for evstack modules > > that have already unloaded themselves. > ??? Such a descriptor would be expected to be destroyed, when it has > been waited for. Ahh - but what about this case: A -> sends event to B B -> is real sluggish at processing event... A -> time out on waiting for retcode B -> is still working on it... A unloads itself B -> sends retcode event to A (retcode event is now in your RC queue. It will never be waited on) > What I do not like with the RC-handler you propose above, is that it would > eventually build yet another queueing layer in_every_stack in case multiple > RCs came in ... The descriptor solution puts the equivalent (the list of > currently active descriptors) in one central place ... Hmm... What about `generalizing' the retcode event handler to an `asynch' handler, ie stack->op->handler_async(ev ...). But then, this leads back to the question of why we went with sync events in the first place.... > Advantages : By handing a single argument to teh get_rcdesc function, one > could allocate arbitrarily large amounts of storage for the RC allowing to > return things like structs or whole events. Gack... Structs on return... Ick.... [IMHO] -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 12 13:53:31 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA03463 for ; Mon, 12 Jan 1998 13:53:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id QAA01263; Mon, 12 Jan 1998 16:16:55 -0500 Resent-Date: Mon, 12 Jan 1998 16:16:55 -0500 Date: Mon, 12 Jan 1998 17:22:59 -0500 (EST) From: MenTaLboY X-Sender: mental@moonbase Reply-To: mentalboy@geocities.com To: EvStack ML Subject: Re: your mail In-Reply-To: <199801122154.QAA06751@moonbase.dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8hPbP.0.HJ.dWekq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/263 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Yes. But it might be good, if one could kill off some "sorry, can't" reply > > by "hey, but I can !". > > Hmmm.. Don't like that too much... I would prefer to say: > "Before your do a retcode event, you MUST consume the querying event" That's definitely a very good idea > Uh.. I didn't mean to say we'd go _fully_ asynch - just async on > retcode events [which are queued by the stack's (subverted) handler] Fully async would be rather nice, especially for multithreaded situations. > > ??? Such a descriptor would be expected to be destroyed, when it has > > been waited for. > > Ahh - but what about this case: > > A -> sends event to B > B -> is real sluggish at processing event... > A -> time out on waiting for retcode > B -> is still working on it... > A unloads itself > B -> sends retcode event to A > (retcode event is now in your RC queue. It will never be waited on) That's why you'd want to provide facilities for explicitly releasing an rc descriptor instead of having it be released implicitly upon a successful wait; maybe even a reference count mechanism like I suggested for EvPages in an earler message, although that might well be overkill here... > Gack... Structs on return... Ick.... [IMHO] We're going to have to pass some data (~200 bytes worth) around in the event structure anyhow ... may as well permit utilization of it. -=MenTaLboY=- From evstack-request@ontv.com Mon Jan 12 15:41:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA03678 for ; Mon, 12 Jan 1998 15:41:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA02557; Mon, 12 Jan 1998 18:04:50 -0500 Resent-Date: Mon, 12 Jan 1998 18:04:50 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Tue, 13 Jan 1998 00:17:38 +0100 (MET) In-Reply-To: <69dva3$idd$1@grits.visus.com> from "Jason McMullan" at Jan 12, 98 08:43:47 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"83d9v2.0.Td.h5gkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/264 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > > O.K. - so what happens if multiple stacks answer ? > > Yes. But it might be good, if one could kill off some "sorry, can't" reply > > by "hey, but I can !". > Hmmm.. Don't like that too much... I would prefer to say: > "Before your do a retcode event, you MUST consume the querying event" Basically yes ... I just want to keep the door open ... > > > All we change is documentation - on ev_send return, the EvPage's data > > > is `undefined' - if you _really_ need to know whether an event has > > > been read by it's target, use the retcode system. This will work > > > for both kernel and user mode. > > Danger here ! The danger is the disposal of the EvPage ... > > You _have_ to know it is not in use anymore before freeing it, thus > > we need locking,m if we go fully asynchronous. > Uh.. I didn't mean to say we'd go _fully_ asynch - just async on > retcode events [which are queued by the stack's (subverted) handler] Well - for this we do not need to make any assumption about the content of the EvPage. > > ??? Such a descriptor would be expected to be destroyed, when it has > > been waited for. > > Ahh - but what about this case: > > A -> sends event to B > B -> is real sluggish at processing event... > A -> time out on waiting for retcode A has timed out. Thus it destroys the descriptor, except if it wants to do something like "retry later", in which case it has to do some bookkeeping on its "still missing RCs" anyway ... > B -> is still working on it... > A unloads itself A is expected to destroy its descriptors, just as it releases its EvPages etc. > B -> sends retcode event to A > (retcode event is now in your RC queue. It will never be waited on) No. It won't even get in there, because the decriptor has been destroyed. They RC-sending stack will get an errorcode stating that it could not deliver the RC which is usually a sign for a timeout. > > Advantages : By handing a single argument to teh get_rcdesc function, one > > could allocate arbitrarily large amounts of storage for the RC allowing to > > return things like structs or whole events. > Gack... Structs on return... Ick.... [IMHO] Well - it would be very useful for querying some value, like say a macro-binding or something like it. Saves things like "return-hidden-by-call-by-reference" as you normally do in C (which is not bad IMHO, but we cannot mess with pointers in EvStack due to the crossing of protection rings). So say we want to know a macrobinding from another stack. We would do : { ev_rc_desc descr; ggi_event report_macrobinding_event; macrobinding result; descr=ev_rc_alloc(sizeof(macrobinding)); report_macrobinding_event.RC=descr.ID; /* set up the rest of the event */ ev_send(...,report_macrobinding_event); if (ev_wait_rc(descr,timeout)==0) /* things went well, we have an RC */ result=*(macrobinding *)&(descr.data); /* we now either have an RC or have timed out. We do not want to wait further, in any case, so we destroy the rc-descriptor. */ ev_rc_free(descr); } The receiving stack would just call ev_rc_set(curr_event->RC,&returncode);. This can nicely hide that a direct call to the rc-descriptor-handling system is made when in kernelmode and an event is sent when in usermode which is grabbed by a default handler in the kernel and sent to the descr-handler. The descr-handler would be a simple linked list which gets appended to by rc_alloc, entries removed by rc_free and the data portion of entries changed by rc_set (as well as a semaphore engaged by this). Should be quite simple to program ... right ? CU,Andy -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 15:41:47 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA03684 for ; Mon, 12 Jan 1998 15:41:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA02605; Mon, 12 Jan 1998 18:05:23 -0500 Resent-Date: Mon, 12 Jan 1998 18:05:23 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: Subject: Re: [Feature Wish] GGI in Linux 2.3 To: evstack@ontv.com Date: Tue, 13 Jan 1998 01:01:06 +0100 (MET) Cc: alan@lxorguk.ukuu.org.uk In-Reply-To: from "Alan Cox" at Jan 12, 98 03:37:06 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"qKVjz2.0.De.W6gkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: archive/latest/265 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi Alan ! Someone forwarded your reply to me, and as you are respected greatly in the kernel hackers scene, I'd like to reply. You might have notices that we have not yet officially requested inclusion in the 2.3.x development tree, and there are reasons for this. > > Graphics Interface, which is much more stable and robust than the previous > > version. My personal opinion is that plans should be made to incorporate > > GGI in Linux 2.3. It's about time that we get fast graphics in Linux > I had a good look at the current GGI and it has several problems to say the > least. > > o Its console emulation isnt Linux but a sort of pseudo xterminal Yes. However this is swappable easily. When requesting inclusion, we will have a fully functioning Linux comaptible console plugin. The current EvStack sourcetree (which follows a radically different design than previous GGI console implementations) already allows X to run again fine and is completely optional (i.e. you can choose to use it at kernel compile time). > o It appears to have no provision for non byte wide fonts ? Where did you get this from ? Yes the VGA boot-driver does not have such provisions as well as other drivers, because the cards can't do other widths, but there is no technical reason that no other fonts should exists. Here again EvStack will change many things. When we request inclusion in the 2.3.x tree officially, we will have made sure that we run at least on x86 and Alpha. Depending on if we find someone from the other archs, we will try to be runnable there, too. EvStack is designed to handle any type of console, be it VGA style text or a framebuffer. > o It breaks all the existing low level mouse/keyboard interfaces > and replaces them with its own which has policy in kernel space Yes. Again this will be fixed before we request official inclusion. > Having said that if combined with the current fbcon code it does give you > support for reliable SVGA mode switching and kernel side acceleration > where useful (eg DMA driven video blits from main memory) and there is > useful stuff that can be salvaged from it. > > The nicest looking bits are actually the userspace support libraries which > show some promise. TNX. LibGGI is really a nice piece of SW ... I'm amazed myself *grin*. O.K. - to cut it short : Yes you have correctly noticed some glitches and we are actively working on alleviating them. If you like to, have a look at the EvStack code, which is available from http://salsa.visus.com/~jmcc/ and should include (outdated but ...) documentation in .tex format. I think the docs are a bit hidden, so you might consider using find -name "*.tex", if you have trouble finding them. Thank you for your comments. BTW: As I cannot follow linux-kernel (already too many mails here ...) - any dates set for 2.3.x ? We will try to get things ready for it. Cu,ANdy -- Andreas Beck | Email : From evstack-request@ontv.com Mon Jan 12 16:11:28 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA03748 for ; Mon, 12 Jan 1998 16:11:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA02940; Mon, 12 Jan 1998 18:34:59 -0500 Resent-Date: Mon, 12 Jan 1998 18:34:59 -0500 Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: [Feature Wish] GGI in Linux 2.3 To: becka@rz.uni-duesseldorf.de Date: Tue, 13 Jan 1998 00:01:00 +0000 (GMT) Cc: evstack@ontv.com, alan@lxorguk.ukuu.org.uk In-Reply-To: from "becka@rz.uni-duesseldorf.de" at Jan 13, 98 01:01:06 am Content-Type: text Resent-Message-ID: <"IfdBd3.0.Wj.kXgkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/266 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > ? Where did you get this from ? Yes the VGA boot-driver does not have > such provisions as well as other drivers, because the cards can't do > other widths, but there is no technical reason that no other fonts > should exists. Obviously vga text mode cannot. The reason I note this is one thing we had to put into the fb_con code recently is support for small font sizes (6x11) for the Macintosh 68K boxes with low resolution displays (512 x 348) I didnt see anything in the code to handle arbitary bitwidth font. I must have missed it > on x86 and Alpha. Depending on if we find someone from the other archs, > we will try to be runnable there, too. > EvStack is designed to handle any type of console, be it VGA style text > or a framebuffer. Ok. Then it should merge nicely with fb_con on the M68K. The only other "really weird" console we have to handle is the SGI - here the console is driven by making requests to the graphics controller chip (the "newport") which draws the writing. The latency on that means its desperately important you can batch requests. Everything else is constrained by the usual things - memory bandwidth, slow CPU's and processors that have real trouble working with objects under 32bits wide. > Thank you for your comments. BTW: As I cannot follow linux-kernel (already > too many mails here ...) - any dates set for 2.3.x ? 3 to 6 months I think. Alan From evstack-request@ontv.com Mon Jan 12 16:31:19 1998 Return-Path: Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA03776 for ; Mon, 12 Jan 1998 16:31:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA03212; Mon, 12 Jan 1998 18:54:49 -0500 Resent-Date: Mon, 12 Jan 1998 18:54:49 -0500 Date: Mon, 12 Jan 1998 17:07:39 -0700 (MST) From: teunis X-Sender: teunis@sigil.computersupportcentre.com To: Jason McMullan cc: evstack@ontv.com Subject: Re: installing from CVS-source In-Reply-To: <199801122033.PAA15581@beans.visus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"vXCci3.0.gn.Kqgkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: archive/latest/267 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Mon, 12 Jan 1998, Jason McMullan wrote: > 'teunis wrote with particular insight...' > > Call me unworthy or whatever but How Does One Install EvStack from the CVS > > source? > > Is it the same as standard GGI? > > Yep - just do a `install GGI kernel' from the top level, > make config (and make SURE to turn on most everything in the > Console/GGI configuration!) configure fails to setup the kernel. .config:2: *** missing separator. Stop. make fails..... > > Am curious as there's no mention of EvStack in the docs.... (hint-hint!) > > (I also haven't installed GGI since 2.1.56 and a lot has changed... is > > 2.1.78 supported yet?) > > 2.1.78 is the _only_ kernel supported - I keep on track with > the latest kernels, if at all possible. 2.1.78 is listed as "unsupported" by "make"... I realise this prolly looks very newbie - but none of these scripts existed the last time I installed GGI/..... and I can't remember how it was originally done. (but looking :) .config: (this doesn't look healthy) KERNELSRC = dialog version 0.3, by Savio Lam (lam836@cs.cuhk.hk). patched to version 0.4 by Stuart Herbert (S.Herbert@shef.ac.uk) * Display dialog boxes from shell scripts * Usage: dialog --clear dialog [--title ] [--backtitle <backtitle> ] [--clear] <Box options> Box options: --yesno <text> <height> <width> --msgbox <text> <height> <width> --infobox <text> <height> <width> --inputbox <text> <height> <width> --textbox <file> <height> <width> --menu <text> <height> <width> <menu height> <tag1> <item1>... --checklist <text> <height> <width> <list height> <tag1> <item1> <status1>.../* --radiolist <text> <height> <width> <list height> <tag1> <item1> <status1>...*/ From evstack-request@ontv.com Mon Jan 12 16:37:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA03818 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 16:37:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA03432; Mon, 12 Jan 1998 19:00:33 -0500 Resent-Date: Mon, 12 Jan 1998 19:00:33 -0500 Date: Mon, 12 Jan 1998 17:13:21 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: 2.1.78 support? Message-ID: <Pine.LNX.3.96.980112170925.387E-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rlaOA1.0.Dp.pvgkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/268 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I finally got the kernel patched (no thanks to configure/make) with: (in patches/Linux of course) ./do_patch-2.1.x /usr/src/linux /usr/src/CVS/ggi-evstack 2.1.77 I just downloaded this GGI a few hours ago - but I don't know if it'll work *sigh*.... especially since I just read in GGI that 2.1.78 isn't supported yet..... [and read that 2.1.78 is the _ONLY_ supported kernel here] *deep sigh* I hope all goes well :) G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 12 16:46:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA03822 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 16:46:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA03595; Mon, 12 Jan 1998 19:09:51 -0500 Resent-Date: Mon, 12 Jan 1998 19:09:51 -0500 Date: Mon, 12 Jan 1998 17:21:49 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: keymapping works o.k. now. In-Reply-To: <69dva3$idd$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980112171610.387F-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6TSQs2.0.ht.f1hkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/269 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 12 Jan 1998, Jason McMullan wrote: > becka@rz.uni-duesseldorf.de wrote: > > > > O.K. - so what happens if multiple stacks answer ? In the scheme you propose > > > > the first answer would get through, as this would unblock the wait - right ? > > > Correct. [Although, in 99% of the cases, idea is to consume the event > > > before you reply to it...] > > > Yes. But it might be good, if one could kill off some "sorry, can't" reply > > by "hey, but I can !". > > Hmmm.. Don't like that too much... I would prefer to say: > "Before your do a retcode event, you MUST consume the querying event" On the flip side what about continuing events? abort? continue-events? finished-events? cancel-events? (yep - I'm thinking of other uses - return values aren't much use to me :) > > Hmm - i.e. you have something like a retcode handler _per_stack_ from the > > very beginning and thus catch retcode events and queue them up internally - > > right ? > > Yes. That's the general idea. hmmm..... make this flagged and build it in for those return-value providing events? (eg: signal opening a display window and return an event describing where to talk... perhaps?) > > > An idea, but by allocating the RC queue on a per-stack basis, you > > > don't have to worry about old RCs in the queue for evstack modules > > > that have already unloaded themselves. > > > ??? Such a descriptor would be expected to be destroyed, when it has > > been waited for. > > Ahh - but what about this case: > > A -> sends event to B > B -> is real sluggish at processing event... > A -> time out on waiting for retcode > B -> is still working on it... > A unloads itself > B -> sends retcode event to A > (retcode event is now in your RC queue. It will never be waited on) Good description! then wake-up A... and if it doesn't remember the event it ignores the event.... perhaps? > > What I do not like with the RC-handler you propose above, is that it would > > eventually build yet another queueing layer in_every_stack in case multiple > > RCs came in ... The descriptor solution puts the equivalent (the list of > > currently active descriptors) in one central place ... > > Hmm... What about `generalizing' the retcode event handler to > an `asynch' handler, ie stack->op->handler_async(ev ...). But then, > this leads back to the question of why we went with sync events in > the first place.... I still prefer async :) What do you need synch-events for anyways? And are they truely synchronous or asynchronous in disguise? (userspace is such) > > Advantages : By handing a single argument to teh get_rcdesc function, one > > could allocate arbitrarily large amounts of storage for the RC allowing to > > return things like structs or whole events. > > Gack... Structs on return... Ick.... [IMHO] Valid for above example - and many others... (go ahead : ask me :) But most operations can be asynchronous.... I really can't think of any synch-only events. Hey - RT-coding is asynchronous even... G'day, eh? :) - Teunis [wandering off to smell the ice-tulips as he realises he prolly shouldn't have stepped into this conversation :] From evstack-request@ontv.com Mon Jan 12 17:27:21 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA03883 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 17:27:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA04057; Mon, 12 Jan 1998 19:50:25 -0500 Resent-Date: Mon, 12 Jan 1998 19:50:25 -0500 Date: Mon, 12 Jan 1998 16:02:52 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: keyboard API Message-ID: <Pine.LNX.3.96.980112155956.349A-101000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="656384-941221270-884617372=:349" Resent-Message-ID: <"b1uSE.0.s-.Sehkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/270 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --656384-941221270-884617372=:349 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached is my (rough) outline. I haven't followed this list too close, but I know my ideas are similiar to yours. Please have a look and tell me what you think. Needless to say I'm willing to code it. Matthias Grimrath --656384-941221270-884617372=:349 Content-Type: APPLICATION/ZIP; name="key-ggi.zip" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980112160252.349B@lidschi.wgnet> Content-Description: UEsDBAoAAAAAACS4KyQAAAAAAAAAAAAAAAAIAAAAa2V5LWdnaS9QSwMEFAAA AAgA8pQrJBnomqHIAgAAkgYAAA0AAABrZXktZ2dpL2tleS5ofVVdT9swFH3P r7gS0iihUG17rDQJ2jIqWg1ReJimKXKTG2o1tSPbKesm/vuundhJOkZfat+c e879TEYxXMQXMDk/d//xKDrhucgwh+Ru9j25TaITunCB4R6N4iiO4ZppXB12 wLYM7vBQsDUWkFci1RGRRNqoKjXhyUwYdYA/EdBP89+YGDAbrhN7HsNoBCs6 QK7kDtb4zIXg4hmMhJwr3bKsDEu3joMLA9vGOg4WRV4yz/sGJ9GzpJVStYWE F5gbkCUKyKWiBEylEPCXQaG5FNrDLi8v/fEWCXHqqU/70b3l8KRRZcww2LED qRSFfIENkUSv438K5UiaQtl4S4VaU0h1vIW0ZeE7qllNXTAqT1USO2Zdutke hQltqen6vYipfGhP43cKGtStlsISrY4rVCoFSXAUaZ2GRX9FM+V5ft84DQij j0cgPmvAD9RmbVD5x3pwBAwBDl0ootqRqz3dKMTWy/PNNdmu9oyTvcBBN5/G j8JbyJQVwdmBFObUCkrDQ5v5ptley+5E1+Z7qTUnAVjKjOcclYYPkCHLSKzG +X1Zfpsmq9v5zSN87Nkmjw8LgE+hZJ7omptSahfTrjHZaLzrdHY1TR7ni+mM +EK5SbjjZ+NoM1iysrRrtGTpxjKEAsPFFxjU+Z2ddbfVTc2T4KnMsDODVW3R h107GT5E3Zp8FVoL135mxm5IzKFE+2pBambDn0lhUqZwSFM8pNuLiF5tbWkP DP74/OnnEGyS4drbmGsusk6cYX6h+dHQclFWxiE8qQ1d28P4GBGEXCoNpodo KgG2FNBRkZWxEL8IK+pqXfx2B1ysdqbXdGgn0uPeQFAbwfbxAfdUZ6Tll9uq BNsw6zzZYLqtu/h/FS9DHAtyfyrte9buzF7yDOaCt08GzhTXKi75Jsp3EEOr uT7SdKjVlpeTKmz3m+TRCQqaIqA8m4+L/f78BVBLAwQUAAAACACriiskZ7jh EEYBAAB5AgAADgAAAGtleS1nZ2kva2V5LmNjZZLNbsIwEITP+CkWkMBJAHEP jsShlare2lsRhxAWMAmmsp1WFOXduw4x4ScXW593Z2bt9KXKinKNMEuNQW0n u4T1r8zYdSFXjrWwl+Npsusx9o6nIl1h8aKsPkEYEkfaSjQxY1JZeDNUMv9J JZUVyB3Km56AnRnQp9GWWgH3HBIBw/kQBoNrKcwIfQ2DmFUX2Q/cSmNRe3/D H5OUNAm1mxG4elUevN1lRt5to5JsfdISEKDwF+5Fw2BBMsumeHPU8GSao2hF Rs5YimkMsiuok9YoGoEPFkUBnFmHesjtGjdmHU4oGCdZqTUp0eGU4J3dp02z HMLciEcUcJ7tUu02TiVqtLRU2+NmE9SR9i4S67ghYN8VNyVG/mEM+yZZfSVm nHxrNKbUKFwOD608XEBV30blH+ZVI7aP4u98jQVaXCzh9v+o2D9QSwMEFAAA AAgAr4grJC7Hj6xhAQAAJAMAABAAAABrZXktZ2dpL01ha2VmaWxlnVLBTsMw DD03X2GpnbRStR8wMWnQCThsgLQD4jLUJWkX1tZVkoL29zihhSHtwnJI2vjl PdvPIQthXRxkqWoJFmHXq1qAwUZCp7HSRWMASyhrdZBHw0KW5wHM5lAlCX3m d6ub+437TytIX4q6ZqslfK8BxLLnh6fHV5iBi5KaIK1WWYWtgRI1EC+ElyzG jeZv7jlJ0ZFxDlYaSyfD3bsZQ9HUA0lV0M2MwvMMYyZkdwLxD34gOM+EQxg7 Ihwxc+nn2DTYAsemcy3rCmulplL+n/4kQ5hkgjozoZyCIAhB998ujOx5kpAX vebSsCCa5nkMbvddjyFdLyHlEF1DihBdZcj+cG7OUhbGyGZXSw2fyu7JZNkh 0RvUo8IZWqr71g+G/JD6aPeqrS7zzNVNc0D5RdOxvTELFpLvh9mTAqKtVxzc uFjoV/FEyyuP0xG7kldLaurW17pgTLW87oX06XUD6AtQSwMEFAAAAAgAlrgr JEEdzLQCCwAA+BcAAA4AAABrZXktZ2dpL1JFQURNRY1Y72/jNhL9XP4VrIHC 9p2S7Q/cl7S7gLeb3RrdNL1LikP2S0BLtM2LJKokZde9u//93sxQkrNbFLco Ckc/yJk3b9486gf3uVL3exc1/mtOugu+89HUeuuDNnpnWxtcqZ/saeNNqLRr uz7pvWmr2rW7S63v91aVfQi2TdpV1kRtgtX0kGvptXi5x1Pf+zbibtAuaXpE b4JxbUw+NJdKrdM86l97l6yOrnG1M0Enr497Q1tFvbG21aYO1lQnXblY9jHa SvtWp73V9hCTKZ9UYxzFpGsXE7b8wR/twYZCr7FGxU9KfHgNifpjq69eLhVl b6f8kH9pY6R1AEjlW0t5fKNjsl0s9NfyQ/stLdhQrsocsLHZ1JYxo31M19Wu NMlhKyCFa32kmw3fXf28Jtx8ZU5I+3vfACwb1BAC0MH+u1bPYmna0lc2zggN a8p93tcFQZbRjwBteFAR9tHSlp73ur3jhwwBTH933qFOx73Fc2O1ASViQmYm pHjJeJS+BXaREvCB6xavlFp8tdR3eS8t/y5e6cXXS/2jPQECW0e9eG2ivTs1 S771zVL/0jp+fhFPzcbXcan/qm985bYOGyitv7u4uADGgKAF7fDHKyz7H7lM YV3QP6nS1oWYuAJUnGSeQIuSUhZY9Poffxdq2oC014mein0nKSavJKvEz46Y 0d6e8OQENF8bkR0vU6Gjbyxzsm8p+mpaA8/fubYkLtpw0tvaHHwfKKyRWMRj l6Ii3kWb6N4UQqIGHPJqLTHQhNOlXvx0e399pedDGHPcV6Wpa2w+z0DPhz7I /M/0X+se8Z+9ubGloUvrm1vF+x1RWUCaqL9SYsjeWqS6DdYSf4LtaoOcXFqO TTJhRMAHx/ARs4XsjA7zrA+EuhQG1/Aq1ikUGoSfwfazLlDVqxnF7yjkW3QL sbCtCLABuYIWRI2pzn3skfxJ4X+65qAjN1jldpTHwlz8XuivLr5c8tXY2dKB U9QrBWThyervgk19aF8V6rsNNCN2SPBVoW0qwXNdm3bXm52VN7fQPfQ/FXfx S1MbSJqhWHcW6bZn/Uptb38zTVfbJdTsza1G2XTjfhsRA9gu7XXugM8B9PRK od1Wn3yvSd4WS8DvoSsKuTWOOoIy2YEwFK+emznj0Qpl8CdBafSjLP3IT7ce kaphb+y2whVgOOx4BfHhJedfMHlMTukMcopnbw5WgQddAB2hRnu3TTPpwULP /jYDjUvr24qbxfe7PVceFAtMdn4NPP1aCf5Mi+B3wTT6Xz36OOB1d7AkyDZD A/QGJaFWahPdrE86mpPwyOgSDWxktEyzIe/1ItgaCm+rQjFnIHqt15L7maK5 zLd7egbFQwnMRG7el1AdBxJBptRnMYW+TPqa7o9R/lt9RjI4/H3dJvT/X7CY pV/fyl3S3GH9s0scdR8sLv33W6jretciGO5ZfnvOzGr9Ef33gIJEa5/D+IR7 UT9SRz3+ISAF82Hvj+oR0ft296gXN+s3az2RFxpEne4hiw3tDphbqc+MVuy7 FxUka1bo6JVLjCiVYeM9oG6XgPEnz2/+Qe2oZdOpc6RYJ2JGpTenZ9NRihqs DAALCayUEzkzZeqleSWZqIPhSnKEi6FXl1OzDorgg5Ka535DjO9MYyUehOcQ Hk/IjRXh9Mi29E1D004a/pZjyMvQSCkG0KMICYtnNgs+EL1zv+Jn7KiV497a FAtF2pJ1i/zEPMnImqqWcfJT0bDraf4cFG6DjEy5NwHoIDLzZGgYsR7T77GL Vl0Xz17PXuxZcYaYjgZUpAkIMonJwPrtjnZXPCiTSeOEHXlDEwbKUVWO6lgg CnIJ796twY2Bno05qdrTGGDzxc5x62HePl5NVz0DMGpehFyW+8Fg8szriQHx 1JZ78NhFoQ92gu9qOJrG7ByEBMpF0GF0ncjEvbm9vUED1BX+UMRkGf4pmC3v rxer9/cEj5AA4hGXWWElCOSDyGBXtpY87qjLhRaxoU3yEswlNEVyjS2y8ZvW Yf3GUhSRMjtoGKLm8GJymGcQ9PYpylqTelLIslb0Q278vOIcsHuhN2K2t+BE fp1Yxsma9pR78y17U7JNUEQoIfgOLzA4QJn3O1gHVHF+rmYY8fPsJhW7yWui COvT0HnUWYwld/OJnM95j7tnTIQNQ+ClJbdBk45YRwQS50TQSZi0nhCR5rpg ScuyxlEwZ3xayiuIpOZZCXJ3FVhLo2lx/5EhJ8FDm3qV5w8wypqfZCpC4MTe kUXrmQESCIndejt1uphCri5Vqg/EBQxTaA3RD2VDWQdU8YQVOOEFcB3ak4NU R5nnkh6HP/aLtMvAFj4noVzR0WljMHTi81VLCOraU59g2EHu60/6bCFO70pH DGxgNb2jr8TkRY6COjQhqGfaYDa+F3cH5gPLgx2UQnxululLtTrTGuaJ2AF/ cDx+5WR5MMHxoSm634ENYbfpqckyxdS0dk4BanOAYbYCzx4SO9wcX7zn4WgP zvcR0rPb2eoZkYJtyDv0aNH67E1uiG1Nw9SRiXUkgkagVdAOMFfn1QZtjPzO MTjg2ZLgEm3sYMXz7DqYurfnaidm8EqcB8s+bNdpUlXFNpGvjYojI0IWbuig QY17dv6cJhf4RirG7nga8Is8Fovskgu97duSWoGbjORO5KWx4zRSg3VG7c8M l6xYnBtezmyGg3w3Y6QRxV1/Zo5lTsgZEociV4FTGBloFFqE9xs9ADuL4TDN Fm4MVc/XEaq0Gu4ulnOUwsLBj4duop+lMxiwETnCAPsV+NP7l/kAOS73zqb3 Hr7EDlpHK7KVDmxlDTBrOiY/K6XB5bZSHOvvL06oUddRFuN54NloXLxGp6A3 t718SBEfMVgWHNMhArauSVDePqwL/cAl+MAoxCOWlq8bnxhzfQxpEGOoTHAk ZtmysDg8uZa7AomCQywsAT9ZmFrWlyhzcfYzu/oHxQm2cPXNjAeJUBe+YDgC jM4E8WWFJLjRFA6ipixoWibqgCQqLJ8Y1vSdhurcu7inA+aRv+GQtBCG6uIj 1zfMT5GNqWP+5METydGZPOTeG7CiknualRi73Fb8rSizFlp2yGY6Z5+/1tD1 5xNLaj5swvEhioezIU0FH782CR3xxnAEzociRdNE/Ci9CqZiToIMFXRX3KY+ d5uivzu2reBabs9c3UHeUY6VMKdQwzRYsTZhQd/Rox+YRwNVPmpLrhcLHZw9 5hDPhI2Vg4DD8R7Wj8iSBhzzVyX6cicfIRYvX2aOLseeL/QUy0TrrSFXYMBf PuDK16zs54E0B6TOA9JjODK06Jh8fvihfCorw9gK5FQUJU50VbCcfBh92DQ3 KU4CMmJZyk72oc8merZ68XCF9HHwHQ4+lDOtRDTpp3KG/09R8hen+GwAiEJV dmv6Oo2wDYwmSIeCLT9FHN2Ore88fzbIPU1jmo3dGegFQcgYeUxCiutxpV/q T6P88frh/er19fvH1fLb4ckPf/7kBzyp1lO7EZq1tPuV4s8628Xshjopo6i/ KF98UeIQOUQy/uKl2KJx5/FJRgrC6+jVi+cMptxQpD/6DnOZP2QDkeCJXk4O qziMkZ7NSjqwzvSFvjMHZjV2xZH+zB5JBcBCmQHccweomw/sUeDWDH8mdzsQ lZqdBRNeUjoGg0JspthcFAMhqbuHm9e37++ulPonJJ8OihjPWPiYzbIYf7L3 aBFxmNNVPnHvvEdTYYzjNUVWTEi9nmMh+xusZpZEkRe0KkwN+7nvcQTF4Fc3 mGZ7h6HzLriGTtFK/Q9QSwECFAMKAAAAAAAkuCskAAAAAAAAAAAAAAAACAAA AAAAAAAAABAA7UEAAAAAa2V5LWdnaS9QSwECFAMUAAAACADylCskGeiaocgC AACSBgAADQAAAAAAAAABAAAApIEmAAAAa2V5LWdnaS9rZXkuaFBLAQIUAxQA AAAIAKuKKyRnuOEQRgEAAHkCAAAOAAAAAAAAAAEAAACkgRkDAABrZXktZ2dp L2tleS5jY1BLAQIUAxQAAAAIAK+IKyQux4+sYQEAACQDAAAQAAAAAAAAAAEA AACkgYsEAABrZXktZ2dpL01ha2VmaWxlUEsBAhQDFAAAAAgAlrgrJEEdzLQC CwAA+BcAAA4AAAAAAAAAAQAAAKSBGgYAAGtleS1nZ2kvUkVBRE1FUEsFBgAA AAAFAAUAJwEAAEgRAAAAAA== --656384-941221270-884617372=:349-- From evstack-request@ontv.com Mon Jan 12 21:24:48 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA04236 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 21:24:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id XAA07370; Mon, 12 Jan 1998 23:48:22 -0500 Resent-Date: Mon, 12 Jan 1998 23:48:22 -0500 Date: Mon, 12 Jan 1998 22:01:15 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com cc: becka@rz.uni-duesseldorf.de, alan@lxorguk.ukuu.org.uk Subject: Re: [Feature Wish] GGI in Linux 2.3 In-Reply-To: <m0xrtmv-0005FtC@lightning.swansea.linux.org.uk> Message-ID: <Pine.LNX.3.96.980112215327.15666A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"plR7P1.0.jo1.z7lkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/271 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998, Alan Cox wrote: > > ? Where did you get this from ? Yes the VGA boot-driver does not have > > such provisions as well as other drivers, because the cards can't do > > other widths, but there is no technical reason that no other fonts > > should exists. > > Obviously vga text mode cannot. The reason I note this is one thing we > had to put into the fb_con code recently is support for small font sizes > (6x11) for the Macintosh 68K boxes with low resolution displays (512 x 348) > > I didnt see anything in the code to handle arbitary bitwidth font. I must > have missed it Really? Okay - I'll hunt this down - font management is something I've been hacking a while :) [remember the Unicode debate? *grin* - I never stopped coding - just continued working in other directions so the project was doable :] Is there a particular max-size for a font? My current code goes from 0x0 (useless) to 16x16 without a problem.... (I just limited to 16x16 because it made more sense for VGA-font compatibility.. though I suppose 8x16 is more usable as a limit. VGA hardware is capable of as low as 6x8 font quality AFAIK - though 8x8 could be the real limit) [if that helps for debugging such font-sizes that is] [though I've seen a 2x3 font in operation... hard to read. 6x8 was really the lowest readable font I've seen] > > on x86 and Alpha. Depending on if we find someone from the other archs, > > we will try to be runnable there, too. > > EvStack is designed to handle any type of console, be it VGA style text > > or a framebuffer. > > Ok. Then it should merge nicely with fb_con on the M68K. The only other > "really weird" console we have to handle is the SGI - here the console > is driven by making requests to the graphics controller chip (the "newport") > which draws the writing. The latency on that means its desperately important > you can batch requests. something EvStacks takes to naturally :) [not that I've checked ... yet .... ] > Everything else is constrained by the usual things - memory bandwidth, > slow CPU's and processors that have real trouble working with objects under > 32bits wide. > > > Thank you for your comments. BTW: As I cannot follow linux-kernel (already > > too many mails here ...) - any dates set for 2.3.x ? > > 3 to 6 months I think. Good :) This project should be beta-ready by then :) (not that I would know - I'm just a lowly toy-programmer with delusions of grandeur :) [but in the last 6 months this system has gone from a "toy" into a usable system for most operations on most graphics cards - and even got real commercial support from Cyrix for the Media/GX chips :] G'day, eh? :) - Teunis 'pologies for taking up time and bandwidth.... From evstack-request@ontv.com Mon Jan 12 22:41:11 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA04339 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 22:41:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id BAA09076; Tue, 13 Jan 1998 01:04:44 -0500 Resent-Date: Tue, 13 Jan 1998 01:04:44 -0500 Date: Mon, 12 Jan 1998 23:18:02 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: 2.1.78 boot... Message-ID: <Pine.LNX.3.96.980112231559.294A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"48YF2.0.LD2.aFmkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/272 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Well - it worked great... providing you can live without keyboard *grin* Okay - so whenever someone finally patches up 2.1.78 - how do I repatch? Or should I just redownload and rebuild *grin* [I'm on a 33.6 connect so this could take a while] Cool - as long as graphics apps (read XFree86) still work... and I get some kinda mouse-interface (now RTFM - back in a bit :) G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 12 22:48:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA04344 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 22:48:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id BAA09161; Tue, 13 Jan 1998 01:12:03 -0500 Resent-Date: Tue, 13 Jan 1998 01:12:03 -0500 Date: Mon, 12 Jan 1998 23:25:22 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: EvStack list <evstack@ontv.com> Subject: amusing update... Message-ID: <Pine.LNX.3.96.980112231922.346A-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-1157061974-884672722=:355" Resent-Message-ID: <"TiVtx1.0.iE2.XMmkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/273 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-1157061974-884672722=:355 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay (on 2.1.78)... I've successfully started X and svgalib from a telnet session *Grin* Well - at least I know everything will work once keyboard is active again :) Here's the syslog from my boot..... please take a look and see if anything's... odd... :) (the "Argh"s have me worried a little) [I can always run a lookup for more specific info - and I _DID_ compile with evstack-debug enabled if that matters] (my .config is attached) Apologies for posting such a large message (just in case).... perhaps it'll help someone. G'day, eh? :) - Teunis Jan 12 23:15:26 sigil syslogd 1.3-3: restart. Jan 12 23:15:26 sigil kernel: klogd 1.3-3, log source = /proc/kmsg started. Jan 12 23:15:28 sigil kernel: Loaded 7583 symbols from /usr/src/linux/System.map. Jan 12 23:15:28 sigil kernel: Symbols match kernel version 2.1.78. Jan 12 23:15:28 sigil kernel: Error seeking in /dev/kmem Jan 12 23:15:28 sigil kernel: Error adding kernel module table entry. Jan 12 23:15:28 sigil kernel: Linux version 2.1.78 (root@sigil) (gcc version egcs-2.90.17 971114 (gcc2-970802 experimental)) #15 Mon Jan 12 21:48:27 MST 1998 Jan 12 23:15:28 sigil kernel: PCI: BIOS32 Service Directory structure at 0xc00fb000 Jan 12 23:15:28 sigil kernel: PCI: BIOS32 Service Directory entry at 0xfb400 Jan 12 23:15:28 sigil kernel: PCI: PCI BIOS revision 2.10 entry at 0xfb430 Jan 12 23:15:28 sigil kernel: Probing PCI hardware. Jan 12 23:15:28 sigil kernel: Calibrating delay loop... 99.94 BogoMIPS Jan 12 23:15:28 sigil kernel: Memory: 38424k/40960k available (1208k kernel code, 392k reserved, 896k data, 40k init) Jan 12 23:15:28 sigil kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Jan 12 23:15:28 sigil kernel: Swansea University Computer Society NET3.039 for Linux 2.1 Jan 12 23:15:28 sigil kernel: NET3: Unix domain sockets 0.16 for Linux NET3.038. Jan 12 23:15:28 sigil kernel: Swansea University Computer Society TCP/IP for NET3.037 Jan 12 23:15:28 sigil kernel: IP Protocols: ICMP, UDP, TCP, IGMP Jan 12 23:15:28 sigil kernel: Linux IP multicast router 0.06 plus PIM-SM Jan 12 23:15:28 sigil kernel: Initializing RT netlink socket Jan 12 23:15:28 sigil kernel: CPU: Cyrix 6x86 2x Core/Bus Clock stepping 16 Jan 12 23:15:28 sigil kernel: Checking 386/387 coupling... Ok, fpu using exception 16 error reporting. Jan 12 23:15:28 sigil kernel: Checking 'hlt' instruction... Ok. Jan 12 23:15:28 sigil kernel: POSIX conformance testing by UNIFIX Jan 12 23:15:28 sigil kernel: Starting kswapd v 1.23 Jan 12 23:15:28 sigil kernel: 00000036:scroll.c:88: Scroll: null registered as 0 Jan 12 23:15:28 sigil kernel: 00000037:scroll.c:88: Scroll: kgi registered as 1 Jan 12 23:15:28 sigil kernel: Registered termstack. Jan 12 23:15:28 sigil kernel: 00000039:keyboard.c:1022: Created keyboard dev (c031ea20). Jan 12 23:15:28 sigil kernel: 0000003a:keyboard.c:1026: Attached 'keyboard' device to input stack Jan 12 23:15:28 sigil kernel: color display detected. Jan 12 23:15:28 sigil kernel: kgi_arch_init(): 1 displays detected. Jan 12 23:15:28 sigil kernel: Serial driver version 4.24 with MANY_PORTS MULTIPORT SHARE_IRQ enabled Jan 12 23:15:28 sigil kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A Jan 12 23:15:28 sigil kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A Jan 12 23:15:28 sigil kernel: Real Time Clock Driver v1.07 Jan 12 23:15:28 sigil kernel: Ramdisk driver initialized : 16 ramdisks of 0K size Jan 12 23:15:28 sigil kernel: Uniform CD-ROM driver Revision: 2.11 Jan 12 23:15:28 sigil kernel: PIIX3: IDE controller on PCI bus 0 function 57 Jan 12 23:15:28 sigil kernel: PIIX3: not 100ative mode: will probe irqs later Jan 12 23:15:28 sigil kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio Jan 12 23:15:28 sigil kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio Jan 12 23:15:28 sigil kernel: hda: FUJITSU MPA3035ATU, ATA DISK drive Jan 12 23:15:28 sigil kernel: hdb: MATSHITA CR-585, ATAPI CDROM drive Jan 12 23:15:28 sigil kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Jan 12 23:15:28 sigil kernel: hda: FUJITSU MPA3035ATU, 3337MB w/0kB Cache, CHS=847/128/63, DMA Jan 12 23:15:28 sigil kernel: hdb: media changed Jan 12 23:15:28 sigil kernel: hdb: ATAPI 24X CDROM drive w/128kB Cache Jan 12 23:15:28 sigil kernel: Floppy drive(s): fd0 is 1.44M Jan 12 23:15:28 sigil kernel: FDC 0 is an 8272A Jan 12 23:15:28 sigil kernel: aic7xxx: <Adaptec AHA-294X Ultra SCSI host adapter> at PCI 8 Jan 12 23:15:28 sigil kernel: aic7xxx: Warning - detected auto-termination. Please verify driver Jan 12 23:15:28 sigil kernel: detected settings and use manual termination if necessary. Jan 12 23:15:28 sigil kernel: aic7xxx: BIOS enabled, IO Port 0x6000, IO Mem 0xe8000000, IRQ 10, Revision B Jan 12 23:15:28 sigil kernel: aic7xxx: Wide Channel, SCSI ID 7, 16/16 SCBs, QFull 16, QMask 0x1f Jan 12 23:15:28 sigil kernel: scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 4.1/3.2 Jan 12 23:15:28 sigil kernel: scsi : 1 host. Jan 12 23:15:28 sigil kernel: scsi0: Scanning channel A for devices. Jan 12 23:15:28 sigil kernel: scsi0: Target 0, channel A, refusing WIDE negotiation; using 8 bit transfers. Jan 12 23:15:28 sigil kernel: (scsi0:0:0) Reset device, active_scb 0 Jan 12 23:15:28 sigil kernel: scsi0: (targ 0/chan A) matching scb to (targ 0/chan A) Jan 12 23:15:28 sigil last message repeated 2 times Jan 12 23:15:28 sigil kernel: scsi0: Unexpected busfree, LASTPHASE = 0xe0, SEQADDR = 0x42 Jan 12 23:15:28 sigil kernel: Vendor: QUANTUM Model: LPS540S Rev: 5900 Jan 12 23:15:28 sigil kernel: Type: Direct-Access ANSI SCSI revision: 02 Jan 12 23:15:28 sigil kernel: Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Jan 12 23:15:28 sigil kernel: scsi0: Target 2, channel A, refusing WIDE negotiation; using 8 bit transfers. Jan 12 23:15:28 sigil kernel: Vendor: TOSHIBA Model: CD-ROM XM-4101TA Rev: 2893 Jan 12 23:15:30 sigil inetd[168]: mtalkd/tcp: unknown service Jan 12 23:15:28 sigil kernel: Type: CD-ROM ANSI SCSI revision: 02 Jan 12 23:15:28 sigil kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 Jan 12 23:15:28 sigil kernel: scsi0: Target 4, channel A, refusing WIDE negotiation; using 8 bit transfers. Jan 12 23:15:28 sigil kernel: Vendor: MAXTOR Model: 7245-SCSI Rev: 1560 Jan 12 23:15:28 sigil kernel: Type: Direct-Access ANSI SCSI revision: 01 CCS Jan 12 23:15:28 sigil kernel: Detected scsi disk sda at scsi0, channel 0, id 4, lun 0 Jan 12 23:15:28 sigil kernel: scsi0: Target 5, channel A, refusing WIDE negotiation; using 8 bit transfers. Jan 12 23:15:28 sigil kernel: scsi0: Target 5, channel A, refusing synchronous negotiation; using asynchronous transfers. Jan 12 23:15:28 sigil kernel: Vendor: ARCHIVE Model: Python 25588-005 Rev: 2.19 Jan 12 23:15:28 sigil kernel: Type: Sequential-Access ANSI SCSI revision: 02 Jan 12 23:15:28 sigil kernel: Detected scsi tape st0 at scsi0, channel 0, id 5, lun 0 Jan 12 23:15:31 sigil named[191]: starting. named 4.9.4-P1 Fri Jun 20 12:47:43 MDT 1997 ^Iroot@sigil:/usr2/src/redhat/BUILD/bind-4.9.4/named Jan 12 23:15:31 sigil named[191]: cache zone "" loaded (serial 0) Jan 12 23:15:32 sigil named[191]: primary zone "wwe.net" loaded (serial 19951124) Jan 12 23:15:32 sigil named[191]: primary zone "42.168.192.in-addr.arpa" loaded (serial 19951124) Jan 12 23:15:32 sigil named[191]: primary zone "computersupportcentre.com" loaded (serial 19971225) Jan 12 23:15:32 sigil named[191]: primary zone "0.168.192.in-addr.arpa" loaded (serial 19971225) Jan 12 23:15:32 sigil named[191]: named.local:15: data "localhost" outside zone "0.0.127.in-addr.arpa" (ignored) Jan 12 23:15:32 sigil named[191]: primary zone "0.0.127.in-addr.arpa" loaded (serial 19951127) Jan 12 23:15:28 sigil kernel: scsi : detected 1 SCSI tape 1 SCSI cdrom 2 SCSI disks total. Jan 12 23:15:28 sigil kernel: SCSI device sda: hdwr sector= 512 bytes. Sectors= 1057616 [516 MB] [0.5 GB] Jan 12 23:15:28 sigil kernel: SCSI device sda: hdwr sector= 512 bytes. Sectors= 479656 [234 MB] [0.2 GB] Jan 12 23:15:28 sigil kernel: IP-Config: No network devices available. Jan 12 23:15:28 sigil kernel: Partition check: Jan 12 23:15:28 sigil kernel: sda: sda1 sda2 sda3 Jan 12 23:15:28 sigil kernel: sdb: sdb1 Jan 12 23:15:28 sigil kernel: hda: hda1 hda2 hda4 Jan 12 23:15:28 sigil kernel: VFS: Mounted root (ext2 filesystem) readonly. Jan 12 23:15:28 sigil kernel: Freeing unused kernel memory: 40k freed Jan 12 23:15:28 sigil kernel: 00000c8a:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:28 sigil kernel: 00000c8d:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:28 sigil kernel: Adding Swap: 52412k swap-space (priority -1) Jan 12 23:15:28 sigil kernel: Adding Swap: 32764k swap-space (priority -2) Jan 12 23:15:32 sigil named[192]: Ready to answer queries. Jan 12 23:15:28 sigil kernel: 000015cc:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:28 sigil kernel: Swansea University Computer Society IPX 0.38 for NET3.037 Jan 12 23:15:28 sigil kernel: IPX Portions Copyright (c) 1995 Caldera, Inc. Jan 12 23:15:28 sigil kernel: loading device 'eth0'... Jan 12 23:15:28 sigil kernel: ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov) Jan 12 23:15:28 sigil kernel: NE*000 ethercard probe at 0x240: 00 00 1b 4c 8f c9 Jan 12 23:15:28 sigil kernel: eth0: NE2000 found at 0x240, using IRQ 11. Jan 12 23:15:28 sigil kernel: loading device 'eth1'... Jan 12 23:15:30 sigil kernel: 00001bf8:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:30 sigil kernel: 00001bf9:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:30 sigil kernel: 00001c16:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:33 sigil mountd[202]: Unknown keyword "root_quash" Jan 12 23:15:34 sigil nfsd[212]: Unknown keyword "root_quash" Jan 12 23:15:36 sigil kernel: 00001e50:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa3:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa3:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa4:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa4:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa5:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa6:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa6:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:39 sigil kernel: 00001fa8:console.c:392: Argh: conlinux, VT 0 isn't closed Jan 12 23:15:40 sigil kernel: 00001fdc:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:40 sigil kernel: 00001fdc:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:40 sigil kernel: 00001fdd:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:40 sigil kernel: 00001fde:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:15:40 sigil kernel: 00001fde:console.c:440: Argh: conlinux, VT 0 isn't open Jan 12 23:18:11 sigil kernel: 00005af5:console.c:392: Argh: conlinux, VT 6 isn't closed Jan 12 23:18:11 sigil kernel: 00005b25:console.c:392: Argh: conlinux, VT 6 isn't closed Jan 12 23:18:23 sigil kernel: 00005fa0:console.c:392: Argh: conlinux, VT 0 isn't closed ---1463800064-1157061974-884672722=:355 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980112232522.355A@sigil.computersupportcentre.com> Content-Description: Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCg0KIw0KIyBDb2RlIG1hdHVyaXR5IGxldmVs IG9wdGlvbnMNCiMNCkNPTkZJR19FWFBFUklNRU5UQUw9eQ0KDQojDQojIFBy b2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcw0KIw0KIyBDT05GSUdfTTM4NiBp cyBub3Qgc2V0DQojIENPTkZJR19NNDg2IGlzIG5vdCBzZXQNCkNPTkZJR19N NTg2PXkNCiMgQ09ORklHX002ODYgaXMgbm90IHNldA0KQ09ORklHX01BVEhf RU1VTEFUSU9OPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9ydA0K Iw0KQ09ORklHX01PRFVMRVM9eQ0KIyBDT05GSUdfTU9EVkVSU0lPTlMgaXMg bm90IHNldA0KQ09ORklHX0tFUk5FTEQ9eQ0KDQojDQojIEdlbmVyYWwgc2V0 dXANCiMNCkNPTkZJR19ORVQ9eQ0KQ09ORklHX1BDST15DQpDT05GSUdfUENJ X0JJT1M9eQ0KQ09ORklHX1BDSV9ESVJFQ1Q9eQ0KIyBDT05GSUdfUENJX09Q VElNSVpFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DQSBpcyBub3Qgc2V0DQpD T05GSUdfU1lTVklQQz15DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19CSU5G TVRfQU9VVD15DQpDT05GSUdfQklORk1UX0VMRj15DQpDT05GSUdfQklORk1U X01JU0M9eQ0KIyBDT05GSUdfQklORk1UX0pBVkEgaXMgbm90IHNldA0KIyBD T05GSUdfVklERU9fU0VMRUNUIGlzIG5vdCBzZXQNCkNPTkZJR19QQVJQT1JU PW0NCkNPTkZJR19QQVJQT1JUX1BDPW0NCg0KIw0KIyBDb25zb2xlIHNldHVw DQojDQpDT05GSUdfVlQ9eQ0KQ09ORklHX1ZUX0NPTlNPTEU9eQ0KQ09ORklH X1ZUX1ZDUz15DQpDT05GSUdfVlRfUFJJTlRLX0ZPTExPV0lORz15DQpDT05G SUdfR0dJPXkNCg0KIw0KIyBHR0kgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklH X0dHSV9TUExBU0hfU0NSRUVOPXkNCkNPTkZJR19HR0lfWFRFUk09eQ0KQ09O RklHX0dHSV9ERVZHUkFQSD1tDQpDT05GSUdfR0dJX0RFVkVWRU5UPW0NCkNP TkZJR19HR0lfQ09OTElOVVg9eQ0KQ09ORklHX0dHSV9FVktFWU1BUD1tDQpD T05GSUdfR0dJX0VWTk1PVVNFPW0NCkNPTkZJR19HR0lfREVCVUc9eQ0KQ09O RklHX0dHSV9ERUJVR19MRVZFTD0xDQpDT05GSUdfR0dJX0tFWU1BUF9BTUVS SUNBTj15DQojIENPTkZJR19HR0lfS0VZTUFQX0JSSVRJU0ggaXMgbm90IHNl dA0KIyBDT05GSUdfR0dJX0tFWU1BUF9EQU5JU0ggaXMgbm90IHNldA0KIyBD T05GSUdfR0dJX0tFWU1BUF9GUkVOQ0ggaXMgbm90IHNldA0KIyBDT05GSUdf R0dJX0tFWU1BUF9HRVJNQU4gaXMgbm90IHNldA0KQ09ORklHX0dHSV9pMzg2 X0NPTE9SPXkNCiMgQ09ORklHX0dHSV9pMzg2X01PTk8gaXMgbm90IHNldA0K Q09ORklHX0dHSV9pMzg2X0tFWUI9eQ0KQ09ORklHX0dHSV9pMzg2X0JFRVA9 bQ0KDQojDQojIFBsdWcgYW5kIFBsYXkgc3VwcG9ydA0KIw0KQ09ORklHX1BO UD15DQpDT05GSUdfUE5QX1BBUlBPUlQ9bQ0KDQojDQojIEZsb3BweSwgSURF LCBhbmQgb3RoZXIgYmxvY2sgZGV2aWNlcw0KIw0KQ09ORklHX0JMS19ERVZf RkQ9eQ0KQ09ORklHX0JMS19ERVZfSURFPXkNCiMgQ09ORklHX0JMS19ERVZf SERfSURFIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURJU0s9eQ0K Q09ORklHX0JMS19ERVZfSURFQ0Q9eQ0KQ09ORklHX0JMS19ERVZfSURFVEFQ RT1tDQpDT05GSUdfQkxLX0RFVl9JREVGTE9QUFk9eQ0KQ09ORklHX0JMS19E RVZfSURFU0NTST1tDQpDT05GSUdfQkxLX0RFVl9DTUQ2NDA9eQ0KIyBDT05G SUdfQkxLX0RFVl9DTUQ2NDBfRU5IQU5DRUQgaXMgbm90IHNldA0KQ09ORklH X0JMS19ERVZfUloxMDAwPXkNCkNPTkZJR19CTEtfREVWX0lERVBDST15DQpD T05GSUdfQkxLX0RFVl9JREVETUE9eQ0KIyBDT05GSUdfQkxLX0RFVl9PUFRJ NjIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVFJNMjkwIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTlM4NzQxNSBpcyBub3Qgc2V0DQoj IENPTkZJR19JREVfQ0hJUFNFVFMgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfTE9PUD1tDQojIENPTkZJR19CTEtfREVWX01EIGlzIG5vdCBzZXQNCkNP TkZJR19CTEtfREVWX1JBTT15DQpDT05GSUdfQkxLX0RFVl9JTklUUkQ9eQ0K IyBDT05GSUdfQkxLX0RFVl9YRCBpcyBub3Qgc2V0DQpDT05GSUdfUEFSSURF X1BBUlBPUlQ9bQ0KQ09ORklHX1BBUklERT1tDQpDT05GSUdfUEFSSURFX1BE PW0NCkNPTkZJR19QQVJJREVfUENEPW0NCkNPTkZJR19QQVJJREVfUEY9bQ0K Q09ORklHX1BBUklERV9BVEVOPW0NCkNPTkZJR19QQVJJREVfQlBDSz1tDQpD T05GSUdfUEFSSURFX0NPTU09bQ0KQ09ORklHX1BBUklERV9EU1RSPW0NCkNP TkZJR19QQVJJREVfRVBBVD1tDQpDT05GSUdfUEFSSURFX0VQSUE9bQ0KQ09O RklHX1BBUklERV9GUlBXPW0NCkNPTkZJR19QQVJJREVfS0JJQz1tDQpDT05G SUdfUEFSSURFX09OMjA9bQ0KQ09ORklHX1BBUklERV9PTjI2PW0NCiMgQ09O RklHX0JMS19ERVZfSEQgaXMgbm90IHNldA0KDQojDQojIE5ldHdvcmtpbmcg b3B0aW9ucw0KIw0KQ09ORklHX1BBQ0tFVD15DQpDT05GSUdfTkVUTElOSz15 DQpDT05GSUdfUlRORVRMSU5LPXkNCkNPTkZJR19ORVRMSU5LX0RFVj1tDQpD T05GSUdfRklSRVdBTEw9eQ0KQ09ORklHX05FVF9BTElBUz15DQpDT05GSUdf RklMVEVSPXkNCkNPTkZJR19VTklYPXkNCkNPTkZJR19JTkVUPXkNCkNPTkZJ R19JUF9NVUxUSUNBU1Q9eQ0KQ09ORklHX0lQX0FEVkFOQ0VEX1JPVVRFUj15 DQpDT05GSUdfUlRORVRMSU5LPXkNCkNPTkZJR19ORVRMSU5LPXkNCkNPTkZJ R19JUF9NVUxUSVBMRV9UQUJMRVM9eQ0KQ09ORklHX0lQX1JPVVRFX01VTFRJ UEFUSD15DQpDT05GSUdfSVBfUk9VVEVfVE9TPXkNCkNPTkZJR19JUF9ST1VU RV9WRVJCT1NFPXkNCkNPTkZJR19JUF9ST1VURV9MQVJHRV9UQUJMRVM9eQ0K Q09ORklHX0lQX1JPVVRFX05BVD15DQpDT05GSUdfSVBfUE5QPXkNCkNPTkZJ R19JUF9QTlBfQk9PVFA9eQ0KIyBDT05GSUdfSVBfUE5QX1JBUlAgaXMgbm90 IHNldA0KQ09ORklHX0lQX0ZJUkVXQUxMPXkNCkNPTkZJR19JUF9GSVJFV0FM TF9ORVRMSU5LPXkNCkNPTkZJR19JUF9GSVJFV0FMTF9WRVJCT1NFPXkNCkNP TkZJR19JUF9UUkFOU1BBUkVOVF9QUk9YWT15DQpDT05GSUdfSVBfQUxXQVlT X0RFRlJBRz15DQpDT05GSUdfSVBfQUNDVD15DQpDT05GSUdfSVBfTUFTUVVF UkFERT15DQpDT05GSUdfSVBfTUFTUVVFUkFERV9JQ01QPXkNCkNPTkZJR19J UF9NQVNRVUVSQURFX0lQQVVUT0ZXPW0NCkNPTkZJR19JUF9NQVNRVUVSQURF X0lQUE9SVEZXPW0NCkNPTkZJR19JUF9ST1VURVI9eQ0KQ09ORklHX05FVF9J UElQPW0NCkNPTkZJR19ORVRfSVBHUkU9bQ0KQ09ORklHX05FVF9JUEdSRV9C Uk9BRENBU1Q9eQ0KQ09ORklHX0lQX01ST1VURT15DQpDT05GSUdfSVBfUElN U01fVjE9eQ0KQ09ORklHX0lQX1BJTVNNX1YyPXkNCkNPTkZJR19JUF9BTElB Uz1tDQojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQNCkNPTkZJR19TWU5fQ09P S0lFUz15DQojIENPTkZJR19JTkVUX1JBUlAgaXMgbm90IHNldA0KQ09ORklH X0lQX05PU1I9eQ0KQ09ORklHX1NLQl9MQVJHRT15DQpDT05GSUdfSVBWNj1t DQpDT05GSUdfSVBWNl9FVUk2ND15DQojIENPTkZJR19JUFY2X05PX1BCIGlz IG5vdCBzZXQNCkNPTkZJR19JUFg9bQ0KQ09ORklHX0lQWF9JTlRFUk49eQ0K Q09ORklHX0FUQUxLPW0NCiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0DQojIENP TkZJR19MQVBCIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JSSURHRSBpcyBub3Qg c2V0DQojIENPTkZJR19MTEMgaXMgbm90IHNldA0KIyBDT05GSUdfV0FOX1JP VVRFUiBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfSVNfU0xPVyBpcyBub3Qg c2V0DQpDT05GSUdfTkVUX1NDSEVEPXkNCkNPTkZJR19ORVRfU0NIX0NCUT1t DQpDT05GSUdfTkVUX1NDSF9DU1o9bQ0KQ09ORklHX05FVF9TQ0hfSEZRPW0N CkNPTkZJR19ORVRfU0NIX1JFRD1tDQpDT05GSUdfTkVUX1NDSF9TRlE9bQ0K Q09ORklHX05FVF9TQ0hfVEJGPW0NCkNPTkZJR19ORVRfU0NIX1BGSUZPPW0N CkNPTkZJR19ORVRfU0NIX1BSSU89bQ0KDQojDQojIFNDU0kgc3VwcG9ydA0K Iw0KQ09ORklHX1NDU0k9eQ0KQ09ORklHX0JMS19ERVZfU0Q9eQ0KQ09ORklH X0NIUl9ERVZfU1Q9eQ0KQ09ORklHX0JMS19ERVZfU1I9eQ0KQ09ORklHX0JM S19ERVZfU1JfVkVORE9SPXkNCkNPTkZJR19DSFJfREVWX1NHPXkNCkNPTkZJ R19TQ1NJX01VTFRJX0xVTj15DQpDT05GSUdfU0NTSV9DT05TVEFOVFM9eQ0K Q09ORklHX1NDU0lfTE9HR0lORz15DQoNCiMNCiMgU0NTSSBsb3ctbGV2ZWwg ZHJpdmVycw0KIw0KIyBDT05GSUdfU0NTSV83MDAwRkFTU1QgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9BSEExNTJYIGlzIG5vdCBzZXQNCkNPTkZJR19T Q1NJX0FIQTE1NDI9eQ0KIyBDT05GSUdfU0NTSV9BSEExNzQwIGlzIG5vdCBz ZXQNCkNPTkZJR19TQ1NJX0FJQzdYWFg9eQ0KIyBDT05GSUdfQUlDN1hYWF9U QUdHRURfUVVFVUVJTkcgaXMgbm90IHNldA0KIyBDT05GSUdfT1ZFUlJJREVf Q01EUyBpcyBub3Qgc2V0DQojIENPTkZJR19BSUM3WFhYX1BBR0VfRU5BQkxF IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FJQzdYWFhfUFJPQ19TVEFUUyBpcyBu b3Qgc2V0DQpDT05GSUdfQUlDN1hYWF9SRVNFVF9ERUxBWT0xNQ0KIyBDT05G SUdfU0NTSV9BRFZBTlNZUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0lO MjAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FNNTNDOTc0IGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9EVEMzMjgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf RUFUQV9ETUEgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9GVVRVUkVfRE9NQUlOIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfR0RUSCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0dFTkVSSUNf TkNSNTM4MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX05DUjUzQzQwNkEg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9OQ1I1M0M3eHggaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9OQ1I1M0M4WFggaXMgbm90IHNldA0KQ09ORklH X1NDU0lfUFBBPW0NCkNPTkZJR19TQ1NJX1BQQV9IQVZFX1BFREFOVElDPTIN CiMgQ09ORklHX1NDU0lfUEFTMTYgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9QQ0kyMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUENJMjIyMEkg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9QU0kyNDBJIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfUUxPR0lDX0ZBUyBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX1FMT0dJQ19JU1AgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9T RUFHQVRFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfREMzOTBUIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfVDEyOCBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX1UxNF8zNEYgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9VTFRS QVNUT1IgaXMgbm90IHNldA0KDQojDQojIE5ldHdvcmsgZGV2aWNlIHN1cHBv cnQNCiMNCkNPTkZJR19ORVRERVZJQ0VTPXkNCiMgQ09ORklHX0FSQ05FVCBp cyBub3Qgc2V0DQpDT05GSUdfRFVNTVk9bQ0KQ09ORklHX0VRVUFMSVpFUj1t DQojIENPTkZJR19FVEhFUlRBUCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX0VU SEVSTkVUPXkNCiMgQ09ORklHX05FVF9WRU5ET1JfM0NPTSBpcyBub3Qgc2V0 DQojIENPTkZJR19MQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVO RE9SX1NNQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SX1JBQ0FM IGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfSVNBPXkNCiMgQ09ORklHX0FUMTcw MCBpcyBub3Qgc2V0DQojIENPTkZJR19FMjEwMCBpcyBub3Qgc2V0DQojIENP TkZJR19ERVBDQSBpcyBub3Qgc2V0DQojIENPTkZJR19FV1JLMyBpcyBub3Qg c2V0DQojIENPTkZJR19FRVhQUkVTUyBpcyBub3Qgc2V0DQojIENPTkZJR19F RVhQUkVTU19QUk8gaXMgbm90IHNldA0KIyBDT05GSUdfRk1WMThYIGlzIG5v dCBzZXQNCiMgQ09ORklHX0hQTEFOX1BMVVMgaXMgbm90IHNldA0KIyBDT05G SUdfSFBMQU4gaXMgbm90IHNldA0KIyBDT05GSUdfSFAxMDAgaXMgbm90IHNl dA0KIyBDT05GSUdfRVRIMTZJIGlzIG5vdCBzZXQNCkNPTkZJR19ORTIwMDA9 bQ0KIyBDT05GSUdfU0VFUTgwMDUgaXMgbm90IHNldA0KIyBDT05GSUdfU0tf RzE2IGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfRUlTQT15DQojIENPTkZJR19Q Q05FVDMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FDMzIwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19BUFJJQ09UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NTODl4 MCBpcyBub3Qgc2V0DQojIENPTkZJR19ERTRYNSBpcyBub3Qgc2V0DQojIENP TkZJR19ERUNfRUxDUCBpcyBub3Qgc2V0DQojIENPTkZJR19ER1JTIGlzIG5v dCBzZXQNCkNPTkZJR19FRVhQUkVTU19QUk8xMDA9bQ0KIyBDT05GSUdfVExB TiBpcyBub3Qgc2V0DQojIENPTkZJR19FUzMyMTAgaXMgbm90IHNldA0KIyBD T05GSUdfWk5FVCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9DS0VUIGlz IG5vdCBzZXQNCiMgQ09ORklHX0ZEREkgaXMgbm90IHNldA0KIyBDT05GSUdf RExDSSBpcyBub3Qgc2V0DQojIENPTkZJR19MVFBDIGlzIG5vdCBzZXQNCiMg Q09ORklHX0NPUFMgaXMgbm90IHNldA0KQ09ORklHX0lQRERQPW0NCiMgQ09O RklHX0lQRERQX0VOQ0FQIGlzIG5vdCBzZXQNCkNPTkZJR19JUEREUF9ERUNB UD15DQpDT05GSUdfUExJUD1tDQpDT05GSUdfUFBQPW0NCkNPTkZJR19TTElQ PW0NCkNPTkZJR19TTElQX0NPTVBSRVNTRUQ9eQ0KQ09ORklHX1NMSVBfU01B UlQ9eQ0KQ09ORklHX1NMSVBfTU9ERV9TTElQNj15DQojIENPTkZJR19ORVRf UkFESU8gaXMgbm90IHNldA0KIyBDT05GSUdfVFIgaXMgbm90IHNldA0KQ09O RklHX1NIQVBFUj1tDQoNCiMNCiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0DQoj DQojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgSVNETiBz dWJzeXN0ZW0NCiMNCiMgQ09ORklHX0lTRE4gaXMgbm90IHNldA0KDQojDQoj IENELVJPTSBkcml2ZXJzIChub3QgZm9yIFNDU0kgb3IgSURFL0FUQVBJIGRy aXZlcykNCiMNCiMgQ09ORklHX0NEX05PX0lERVNDU0kgaXMgbm90IHNldA0K Q09ORklHX0NEUk9NPXkNCg0KIw0KIyBGaWxlc3lzdGVtcw0KIw0KIyBDT05G SUdfUVVPVEEgaXMgbm90IHNldA0KQ09ORklHX01JTklYX0ZTPXkNCkNPTkZJ R19FWFQyX0ZTPXkNCkNPTkZJR19JU085NjYwX0ZTPXkNCkNPTkZJR19KT0xJ RVQ9eQ0KQ09ORklHX0ZBVF9GUz15DQpDT05GSUdfTVNET1NfRlM9eQ0KIyBD T05GSUdfVU1TRE9TX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19WRkFUX0ZTPXkN CkNPTkZJR19QUk9DX0ZTPXkNCkNPTkZJR19ORlNfRlM9eQ0KQ09ORklHX1JP T1RfTkZTPXkNCkNPTkZJR19ORlNEPXkNCkNPTkZJR19TVU5SUEM9eQ0KQ09O RklHX0xPQ0tEPXkNCiMgQ09ORklHX0NPREFfRlMgaXMgbm90IHNldA0KQ09O RklHX1NNQl9GUz1tDQpDT05GSUdfU01CX1dJTjk1PXkNCkNPTkZJR19OQ1Bf RlM9bQ0KQ09ORklHX0hQRlNfRlM9bQ0KQ09ORklHX05URlNfRlM9bQ0KQ09O RklHX05URlNfUlc9eQ0KQ09ORklHX1NZU1ZfRlM9bQ0KQ09ORklHX0FGRlNf RlM9bQ0KQ09ORklHX0hGU19GUz1tDQpDT05GSUdfUk9NRlNfRlM9eQ0KQ09O RklHX0FVVE9GU19GUz15DQpDT05GSUdfQU1JR0FfUEFSVElUSU9OPXkNCkNP TkZJR19VRlNfRlM9bQ0KQ09ORklHX0JTRF9ESVNLTEFCRUw9eQ0KQ09ORklH X1NNRF9ESVNLTEFCRUw9eQ0KQ09ORklHX1NPTEFSSVNfWDg2X1BBUlRJVElP Tj15DQpDT05GSUdfTUFDX1BBUlRJVElPTj15DQpDT05GSUdfTkxTPXkNCg0K Iw0KIyBOYXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MU19D T0RFUEFHRV80Mzc9bQ0KQ09ORklHX05MU19DT0RFUEFHRV83Mzc9bQ0KQ09O RklHX05MU19DT0RFUEFHRV83NzU9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84 NTA9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84NTI9bQ0KQ09ORklHX05MU19D T0RFUEFHRV84NTU9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84NTc9bQ0KQ09O RklHX05MU19DT0RFUEFHRV84NjA9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84 NjE9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84NjI9bQ0KQ09ORklHX05MU19D T0RFUEFHRV84NjM9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84NjQ9bQ0KQ09O RklHX05MU19DT0RFUEFHRV84NjU9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84 NjY9bQ0KQ09ORklHX05MU19DT0RFUEFHRV84Njk9bQ0KQ09ORklHX05MU19D T0RFUEFHRV84NzQ9bQ0KQ09ORklHX05MU19JU084ODU5XzE9bQ0KQ09ORklH X05MU19JU084ODU5XzI9bQ0KQ09ORklHX05MU19JU084ODU5XzM9bQ0KQ09O RklHX05MU19JU084ODU5XzQ9bQ0KQ09ORklHX05MU19JU084ODU5XzU9bQ0K Q09ORklHX05MU19JU084ODU5XzY9bQ0KQ09ORklHX05MU19JU084ODU5Xzc9 bQ0KQ09ORklHX05MU19JU084ODU5Xzg9bQ0KQ09ORklHX05MU19JU084ODU5 Xzk9bQ0KQ09ORklHX05MU19LT0k4X1I9bQ0KDQojDQojIENoYXJhY3RlciBk ZXZpY2VzDQojDQpDT05GSUdfU0VSSUFMPXkNCkNPTkZJR19TRVJJQUxfRVhU RU5ERUQ9eQ0KQ09ORklHX1NFUklBTF9DT05TT0xFPXkNCkNPTkZJR19TRVJJ QUxfTUFOWV9QT1JUUz15DQpDT05GSUdfU0VSSUFMX1NIQVJFX0lSUT15DQpD T05GSUdfU0VSSUFMX01VTFRJUE9SVD15DQojIENPTkZJR19IVUI2IGlzIG5v dCBzZXQNCkNPTkZJR19TRVJJQUxfQ09OU09MRT15DQpDT05GSUdfU0VSSUFM X0NPTlNPTEVfUE9SVD0xDQpDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkN CiMgQ09ORklHX1JPQ0tFVFBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfRElH SUVQQ0EgaXMgbm90IHNldA0KIyBDT05GSUdfRElHSSBpcyBub3Qgc2V0DQpD T05GSUdfQ1lDTEFERVM9bQ0KIyBDT05GSUdfU1RBTERSViBpcyBub3Qgc2V0 DQojIENPTkZJR19SSVNDT004IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NQRUNJ QUxJWCBpcyBub3Qgc2V0DQojIENPTkZJR19FU1BTRVJJQUwgaXMgbm90IHNl dA0KQ09ORklHX1BSSU5URVI9bQ0KQ09ORklHX1BSSU5URVJfUkVBREJBQ0s9 eQ0KQ09ORklHX01PVVNFPXkNCiMgQ09ORklHX0FUSVhMX0JVU01PVVNFIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JVU01PVVNFIGlzIG5vdCBzZXQNCiMgQ09O RklHX01TX0JVU01PVVNFIGlzIG5vdCBzZXQNCkNPTkZJR19QU01PVVNFPXkN CkNPTkZJR184MkM3MTBfTU9VU0U9eQ0KIyBDT05GSUdfUEMxMTBfUEFEIGlz IG5vdCBzZXQNCkNPTkZJR19VTUlTQz15DQojIENPTkZJR19RSUMwMl9UQVBF IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FQTSBpcyBub3Qgc2V0DQojIENPTkZJ R19XQVRDSERPRyBpcyBub3Qgc2V0DQpDT05GSUdfUlRDPXkNCkNPTkZJR19W SURFT19ERVY9bQ0KQ09ORklHX1ZJREVPX0JUODQ4PW0NCkNPTkZJR19WSURF T19CV1FDQU09bQ0KQ09ORklHX1ZJREVPX1BNUz1tDQpDT05GSUdfTlZSQU09 bQ0KIyBDT05GSUdfSk9ZU1RJQ0sgaXMgbm90IHNldA0KIyBDT05GSUdfTUlT Q19SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgRnRhcGUsIHRoZSBmbG9wcHkg dGFwZSBkZXZpY2UgZHJpdmVyDQojDQojIENPTkZJR19GVEFQRSBpcyBub3Qg c2V0DQoNCiMNCiMgU291bmQNCiMNCkNPTkZJR19TT1VORD1tDQpDT05GSUdf UEFTPW0NCkNPTkZJR19TQj1tDQpDT05GSUdfQURMSUI9bQ0KQ09ORklHX0dV Uz1tDQojIENPTkZJR19HVVMxNiBpcyBub3Qgc2V0DQojIENPTkZJR19HVVNN QVggaXMgbm90IHNldA0KQ09ORklHX01QVTQwMT1tDQpDT05GSUdfUFNTPW0N CkNPTkZJR19NU1M9bQ0KQ09ORklHX1NTQ0FQRT1tDQpDT05GSUdfVFJJWD1t DQpDT05GSUdfTUFEMTY9bQ0KQ09ORklHX0NTNDIzMj1tDQpDT05GSUdfTUFV ST1tDQpDT05GSUdfT1BMM1NBMT1tDQpDT05GSUdfU09GVE9TUz1tDQpDT05G SUdfWU0zODEyPW0NCkNPTkZJR19WTUlEST1tDQpDT05GSUdfTE9XTEVWRUxf U09VTkQ9eQ0KQ09ORklHX0FDSV9NSVhFUj1tDQpDT05GSUdfQVdFMzJfU1lO VEg9bQ0KQ09ORklHX0FFRFNQMTY9bQ0KQUVEU1AxNl9CQVNFPTIyMA0KQ09O RklHX1NDNjYwMD15DQpDT05GSUdfU0M2NjAwX0pPWT15DQpDT05GSUdfU0M2 NjAwX0NEUk9NPTQNCkNPTkZJR19TQzY2MDBfQ0RST01CQVNFPTANCg0KIw0K IyBLZXJuZWwgaGFja2luZw0KIw0KIyBDT05GSUdfUFJPRklMRSBpcyBub3Qg c2V0DQpDT05GSUdfVkdBX0NPTlNPTEU9eQ0K ---1463800064-1157061974-884672722=:355-- From evstack-request@ontv.com Mon Jan 12 23:17:40 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA04362 for <ggi@synergy.foo.net>; Mon, 12 Jan 1998 23:17:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id BAA09394; Tue, 13 Jan 1998 01:41:12 -0500 Resent-Date: Tue, 13 Jan 1998 01:41:12 -0500 Date: Mon, 12 Jan 1998 23:54:30 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: grr.... kernel-developer frenzy again... Message-ID: <Pine.LNX.3.96.980112235147.463A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"b-Zwi1.0.II2.pnmkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/274 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I don't know what's all been incorporated (there was no announcement), but 2.1.79 is out. And the patch is 800K gzipped. They've made a lot of changes and I wonder how it'll affect evstacks. Gaia! Why do they keep doing this so _QUICKLY_! :) Ah well, it's all in the name of making the greatest OS out there :) [there's some in the wings possibly - but they have a while to go before they catch up with linux! :] I'm going to start playing tomorrow... but please post either when the keyboard's working with 2.1.78+ or where I can start looking :) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 13 02:31:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA04692 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 02:31:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id EAA11298; Tue, 13 Jan 1998 04:55:09 -0500 Resent-Date: Tue, 13 Jan 1998 04:55:09 -0500 Message-Id: <m0xs3To-0005FzC@lightning.swansea.linux.org.uk> From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: [Feature Wish] GGI in Linux 2.3 To: teunis@mauve.computersupportcentre.com (teunis) Date: Tue, 13 Jan 1998 10:21:56 +0000 (GMT) Cc: evstack@ontv.com, becka@rz.uni-duesseldorf.de, alan@lxorguk.ukuu.org.uk In-Reply-To: <Pine.LNX.3.96.980112215327.15666A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 12, 98 10:01:15 pm Content-Type: text Resent-Message-ID: <"kOlY3.0.4m2.Sdpkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/275 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Is there a particular max-size for a font? My current code goes from 0x0 > (useless) to 16x16 without a problem.... (I just limited to 16x16 because > it made more sense for VGA-font compatibility.. though I suppose 8x16 is > more usable as a limit. VGA hardware is capable of as low as 6x8 font > quality AFAIK - though 8x8 could be the real limit) [if that helps for > debugging such font-sizes that is] Unless there is a good reason for not doing it supporting large fonts isnt a bad thing. Running 320x200 with 32x32 fonts is a common thing for the partially sighted. (Along with running X11 via Xmag all the time) > commercial support from Cyrix for the Media/GX chips :] Got any source code out of them yet ;) From evstack-request@ontv.com Tue Jan 13 04:15:53 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA04852 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 04:15:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id GAA12223; Tue, 13 Jan 1998 06:39:27 -0500 Resent-Date: Tue, 13 Jan 1998 06:39:27 -0500 Message-ID: <34BBD0D7.1754@bitsmart.com> Date: Tue, 13 Jan 1998 21:38:47 +0100 From: Jonas Borgström <jonas_b@bitsmart.com> X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: 2.1.78 boot... X-URL: http://synergy.caltech.edu/~ggi/mailinglist/ev-jan98/87.html Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"74hMj1.0.W-2.G9rkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/276 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com >> Well - it worked great... providing you can live without keyboard *grin* I use a 2.1.78 kernel and my keyboard works, But to get my keyboard working with 77-78 I had to compile the keyboard-mapping(or what it was called) into the kernel and not as a module. / Jonas Borgström From evstack-request@ontv.com Tue Jan 13 04:36:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA04907 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 04:36:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA12521; Tue, 13 Jan 1998 07:00:09 -0500 Resent-Date: Tue, 13 Jan 1998 07:00:09 -0500 Message-Id: <m0xs51m-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: amusing update... To: evstack@ontv.com Date: Tue, 13 Jan 1998 23:01:06 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980112231922.346A-200000@sigil.computersupportcentre.com> from "teunis" at Jan 12, 98 11:25:22 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5Olr01.0.C13.GSrkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/277 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > Well - at least I know everything will work once keyboard is active again :) [...] > CONFIG_GGI_EVKEYMAP=m That explains it. Unless you want to telnet in each time and insmod the keymapper :-), better set that to 'yes please'. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 04:49:52 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA04920 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 04:49:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA12653; Tue, 13 Jan 1998 07:13:27 -0500 Resent-Date: Tue, 13 Jan 1998 07:13:27 -0500 Message-Id: <m0xs5EY-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Tue, 13 Jan 1998 23:14:18 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xrhzZ-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 12, 98 12:25:17 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Tv9al3.0.953.Zerkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/278 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [FWIW my previous post on this didn't get through] Andreas Beck writes: > > What we would need to do then is to return one line at a time, instead > > of the whole damn lot. > > If you like, I can try to implement this whilst I'm revamping the /proc > > output... > > Would be great ... People would shoot us, if they get random rubbish out > of our /proc entries ... I've mostly fixed it and committed the change to evstack.c. Doing "cat /proc/keymap" now works OK, also "cp /proc/keymap xxx". What's weird is that doing "less /proc/keymap" doesn't get it the whole lot, it stops part-way. Maybe this is something to do with the way less works, I don't know... BTW, does anyone know what 'P' means when doing a CVS update ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 06:22:16 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA04999 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 06:22:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA13444; Tue, 13 Jan 1998 08:45:43 -0500 Resent-Date: Tue, 13 Jan 1998 08:45:43 -0500 Message-ID: <34BBEE5F.50C@bitsmart.com> Date: Tue, 13 Jan 1998 23:44:47 +0100 From: Jonas Borgström <jonas_b@bitsmart.com> X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: evstack@ontv.com Subject: evstack ps2aux mousedriver. X-URL: http://synergy.caltech.edu/~ggi/mailinglist/ev-jan98/87.html Content-Type: multipart/mixed; boundary="------------4B18497B579E" Resent-Message-ID: <"T6U1J1.0.aH3.M_skq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/279 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This is a multi-part message in MIME format. --------------4B18497B579E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I have ported the ps2aux mouse driver to evstack, I don't know if I did it the right way but it works for me. I don't know how evstack works. But beeper and nmouse modules did this: sprintf(buf, "attach %s\n", par_stack_to_string(ps2aux.stack)); input_stack->ops->write(input_stack, buf); What does it do? I did the same in the ps2aux driver, but it worked without it to. I have only access to internet from school (win3.1 :-{) so I can't commit the file until this weekend so if anyone has time they could commit it for me. / Jonas Borgström --------------4B18497B579E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="PS2AUX.C" /* --------------------------------------------------------------------------- * PS/2 auxiliary pointing device driver * --------------------------------------------------------------------------- * * Copyright (C) 1995-1997 by Steffen Seeger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2, or (at your option) * any later version. * * You should have received a copy of the GNU General Public License * along with this program; see the file COPYING. If not, write to * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. * * ------------------------------------------------------------------------- * * $Log: ps2aux.c,v $ * Revision 1.6.2.1 1997/12/17 14:38:02 ezrec * Merged with Dec13 revision of the mail tree, and modified the * kgi_mode/kgi_display structs. See kgi.h for more details. * * Revision 1.7 1997/12/14 21:56:11 becka * uint/sint namespace fixed ... please test ... * * Revision 1.6 1997/10/19 22:18:32 becka * Mouse numbering changed. * * Revision 1.5 1997/09/12 07:28:46 taylorj * Minor: Reformatted source to be consistent with GGI coding style guidelines, * modified all debugging output to use the DEBUGx macros, and added CVS * revision logging to headers where needed. * * * --------------------------------------------------------------------------- * */ #include <ggi/maintainers.h> #define DEVICE_NAME "ps2aux" #define MAINTAINER Steffen_Seeger #define DRIVER_NAME "PS/2 Auxiliary mouse driver" #define DRIVER_REV "$Revision: 1.6.2.1 $" #if defined(__alpha__) && !defined(CONFIG_PCI) #define AUX_IRQ 9 /* Jensen is odd indeed */ #else #define AUX_IRQ 12 #endif #define INIT_DEVICE /* force initialization */ /* ===================================================================== *\ |* ----- there are no 'user servicable' parts below this line :-) ------ *| \* ======================================================================*/ #include <linux/config.h> #include <linux/module.h> #include <ggi/kgi.h> #include <ggi/evstack.h> #include <ggi/events.h> #include <asm/io.h> #include <linux/random.h> #include <ggi/parsearg.h> #include <linux/string.h> #include <linux/ctype.h> #define LEFT_HANDED 0x01 #define RIGHT_HANDED 0x02 struct ps2aux_struct { ggi_uint psaux_irq; /* IRQ to use */ ev_id dev_id; int uses, mode; evstack *stack; ggi_sint state; /* decode state */ ggi_uint buttons; /* button state */ }; static struct ps2aux_struct ps2aux; extern uchar aux_device_present; extern uchar psaux_read_mask; /* psaux controller ports */ #define AUX_INPUT_PORT 0x60 /* Aux device output buffer */ #define AUX_OUTPUT_PORT 0x60 /* Aux device input buffer */ #define AUX_COMMAND 0x64 /* Aux device command buffer */ #define AUX_STATUS 0x64 /* Aux device status reg */ /* psaux controller status bits */ #define AUX_OBUF_FULL 0x21 /* outbuffer (from device) full */ #define AUX_IBUF_FULL 0x02 /* inbuffer (to device) full */ /* psaux controller commands */ #define AUX_CMD_WRITE 0x60 /* write to controller */ #define AUX_MAGIC_WRITE 0xd4 /* send psaux device data */ #define AUX_INTS_ON 0x47 /* enable controller interrupts */ #define AUX_INTS_OFF 0x65 /* disable controller interrupts*/ #define AUX_DISABLE 0xa7 /* disable psaux device */ #define AUX_ENABLE 0xa8 /* enable psaux */ /* psaux device commands */ #define AUX_SET_RES 0xe8 /* set resolution */ #define AUX_SET_SCALE11 0xe6 /* set 1:1 scaling */ #define AUX_SET_SCALE21 0xe7 /* set 2:1 scaling */ #define AUX_GET_SCALE 0xe9 /* get scaling factor */ #define AUX_SET_STREAM 0xea /* set stream mode */ #define AUX_SET_SAMPLE 0xf3 /* set sample rate */ #define AUX_ENABLE_DEV 0xf4 /* enable psaux device */ #define AUX_DISABLE_DEV 0xf5 /* disable psaux device */ #define AUX_RESET 0xff /* reset psaux device */ #define MAX_RETRIES 60 /* some operations take long time*/ static void psaux_interrupt(int cpl, void *dev_id, struct pt_regs * regs) { static char left_buttonmap[8] = { 0, 2, 1, 3, 4, 6, 5, 7 }; static char right_buttonmap[8] = { 0, 1, 2, 3, 4, 5, 6, 7 }; char *buttonmap; static ggi_uint b; static ggi_sint dx, dy; ggi_event event; buttonmap = (ps2aux.mode == LEFT_HANDED ? left_buttonmap : right_buttonmap); if ((inb(AUX_STATUS) & AUX_OBUF_FULL) != AUX_OBUF_FULL) { return; } switch (ps2aux.state) { case 0: add_mouse_randomness(b = (uchar)inb(AUX_INPUT_PORT)); ps2aux.state++; break; case 1: add_mouse_randomness(dx = (uchar) inb(AUX_INPUT_PORT)); if (b & 0x10) { dx |= (-1 & ~0xFF); } ps2aux.state++; break; case 2: add_mouse_randomness(dy = (uchar) inb(AUX_INPUT_PORT)); if (b & 0x20) { dy |= (-1 & ~0xFF); } ps2aux.state = 0; b = buttonmap[b & 7]; DEBUG2("packet %.2x %i, %i", b, dx, dy); /* !!! do mouse acceleration here! */ event.any.time = jiffies; /* Change in position? */ if (dx || dy) { event.any.size = sizeof(ggi_pmove_event); event.any.type = evPtrRelative; event.any.origin = EV_ORIGIN(ps2aux.stack->eid); event.any.target = EV_TARGET_VT_HEAD_CURRENT(0); event.any.time = jiffies; event.pmove.x = dx; event.pmove.y = -dy; ev_send(NULL, NULL, &event, ps2aux.stack->report_to); } /* Change in button state? */ if ((event.pbutton.button = ps2aux.buttons ^ b)) { event.any.origin = EV_ORIGIN(ps2aux.stack->eid); event.any.target = EV_TARGET_VT_HEAD_CURRENT(0); event.pbutton.size = sizeof(ggi_pbutton_event); ps2aux.buttons = event.pbutton.state = b; event.pbutton.type = (event.pbutton.button & event.pbutton.state) ? evPtrButtonPress : evPtrButtonRelease; ev_send(NULL, NULL, &event, ps2aux.stack->report_to); } break; } } static int psaux_poll_status(void) { int retries = 0; while ((inb(AUX_STATUS) & 0x03) && (retries < MAX_RETRIES)) { if ((inb_p(AUX_STATUS) & AUX_OBUF_FULL) == AUX_OBUF_FULL) { inb_p(AUX_INPUT_PORT); } current->state = TASK_INTERRUPTIBLE; current->timeout = jiffies + (5 * HZ + 99) / 100; schedule(); retries++; } return retries != MAX_RETRIES; } static void psaux_write_dev(int val) { psaux_poll_status(); outb_p(AUX_MAGIC_WRITE, AUX_COMMAND); /* Write magic cookie */ psaux_poll_status(); outb_p(val, AUX_OUTPUT_PORT); /* Write data */ } static void psaux_write_cmd(int val) { psaux_poll_status(); outb_p(AUX_CMD_WRITE, AUX_COMMAND); psaux_poll_status(); outb_p(val, AUX_OUTPUT_PORT); } #if defined INIT_DEVICE static int psaux_poll_status_nosleep(void) { int retries = 0; while ((inb(AUX_STATUS) & 0x03) && retries < 1000000) { if ((inb_p(AUX_STATUS) & AUX_OBUF_FULL) == AUX_OBUF_FULL) { inb_p(AUX_INPUT_PORT); } retries++; } return retries != 1000000; } static int psaux_write_ack(int val) { /* Write and handle acknowledge */ psaux_poll_status_nosleep(); outb_p(AUX_MAGIC_WRITE, AUX_COMMAND); psaux_poll_status_nosleep(); outb_p(val, AUX_OUTPUT_PORT); psaux_poll_status_nosleep(); if ((inb(AUX_STATUS) & AUX_OBUF_FULL) == AUX_OBUF_FULL) { return (inb(AUX_INPUT_PORT)); } return 0; } #endif /** ** EvStack interface. **/ static int mouse_ev_open(evstack *blank) { DEBUG3("mouse_ev_open: stack=%p", blank); blank->maintainer=MAINTAINER; blank->priv=NULL; /* setup later on... */ ps2aux.uses++; MOD_INC_USE_COUNT; return EOK; } static int mouse_ev_close(evstack *self) { DEBUG3("mouse_ev_close: stack=%p", self); ps2aux.uses--; MOD_DEC_USE_COUNT; return EOK; } static void mouse_ev_handler(evstack *self, ggi_event *ev, int *left) { DEBUG4("mouse_ev_handler: stack=%p", self); /* loop through all events in the page */ for(; ev->size; ev=ev_evpage_next(ev)); switch(ev->any.type) { /* there's nothing we really care about... */ case evCommand: { break; } default: break; } } static int mouse_ev_uses(evstack *self) { return ps2aux.uses; } static int mouse_ev_write(evstack *self, char *str) { DEBUG4("mouse_ev_write: stack=%p", self); ASSERT(stack == self); if ((strncmp(str, "mode", 4) == 0) && isspace(str[4])) { char mode_str[100]; str += 5; if (sscanf(str, "%99s", mode_str) != 1) { DEBUG2("mouse_ev_write: missing parser name."); return -EINVAL; } if(strcmp("left", mode_str) == 0) ps2aux.mode = LEFT_HANDED; else if(strcmp("right", mode_str) == 0) { ps2aux.mode = RIGHT_HANDED; } else { DEBUG2("mouse_ev_write: unknown mode"); return -EINVAL; } DEBUG2("mouse_ev_write: setting mode to '%s'", mode_str); return EOK; } return -EINVAL; } static int mouse_ev_read(evstack *self, int lineno, int maxlen, char *str) { DEBUG4("mouse_ev_read: stack=%p", self); ASSERT(stack == self); ASSERT(lineno >= 0); switch (lineno) { case 0: sprintf(str, "# Ps2aux config:"); return EOK; case 1: { sprintf(str, "mode %s", ps2aux.mode == RIGHT_HANDED ? "right" : "left"); return EOK; } default: lineno -= 2; break; } return -EINVAL; } static struct evstack_operations mouse_ev_ops = { mouse_ev_open, mouse_ev_close, mouse_ev_handler, mouse_ev_uses, mouse_ev_write, mouse_ev_read }; #ifdef MODULE static #endif int psaux_init(void) { char buf[256]; if (aux_device_present != 0xaa) { DEBUG2("%s device not detected!", DRIVER_NAME); return -EIO; } if (request_irq(ps2aux.psaux_irq, psaux_interrupt, 0, DEVICE_NAME, NULL)) { DEBUG2("Failed to claim IRQ %i.", psaux_irq); return -EIO; } DEBUG2("%s device detected.", DRIVER_NAME); psaux_read_mask = AUX_OBUF_FULL; outb_p(AUX_ENABLE, AUX_COMMAND); /* Enable Aux */ #ifdef INIT_DEVICE psaux_write_ack(AUX_SET_SAMPLE); psaux_write_ack(100); /* 100 samples/sec */ psaux_write_ack(AUX_SET_RES); psaux_write_ack(3); /* 8 counts per mm */ psaux_write_ack(AUX_SET_SCALE21);/* 2:1 scaling */ psaux_poll_status_nosleep(); #endif psaux_write_dev(AUX_ENABLE_DEV); psaux_write_cmd(AUX_INTS_ON); psaux_poll_status(); ps2aux.state = 0; ps2aux.buttons = 0; ps2aux.dev_id = ev_register_device(DEVICE_NAME, &mouse_ev_ops); ps2aux.stack = ev_instance_device(ps2aux.dev_id); NOTICE("Registered %s.", DEVICE_NAME); sprintf(buf, "attach %s\n", par_stack_to_string(ps2aux.stack)); input_stack->ops->write(input_stack, buf); DEBUG1("Atached '%s' device to input stack", DEVICE_NAME); return EOK; } #ifdef MODULE static int old_read_mask; int init_module(void) { ps2aux.psaux_irq = AUX_IRQ; ps2aux.mode = RIGHT_HANDED; old_read_mask = psaux_read_mask; return psaux_init(); } void cleanup_module(void) { char buf[256]; psaux_write_cmd(AUX_INTS_OFF); psaux_poll_status(); outb_p(AUX_DISABLE, AUX_COMMAND); psaux_poll_status(); psaux_read_mask = old_read_mask; free_irq(ps2aux.psaux_irq, NULL); sprintf(buf,"detach %s\n", par_stack_to_string(ps2aux.stack)); input_stack->ops->write(input_stack, buf); DEBUG1("Detached '%s' device from input stack", DEVICE_NAME); ev_destroy_device(ps2aux.stack); ev_unregister_device(ps2aux.dev_id); DEBUG1("%s driver unloaded.", DRIVER_NAME); } #endif --------------4B18497B579E-- From evstack-request@ontv.com Tue Jan 13 06:37:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA05014 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 06:37:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA13717; Tue, 13 Jan 1998 09:01:12 -0500 Resent-Date: Tue, 13 Jan 1998 09:01:12 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: 2.1.78 boot... Date: 13 Jan 1998 14:03:44 GMT Organization: OnTV Pittsburgh, L.P. Lines: 14 Distribution: local Message-ID: <69fs80$1mh$1@grits.visus.com> References: <69f0pe$e18$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"azrxw.0.lL3.1Etkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/280 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > Well - it worked great... providing you can live without keyboard *grin* Odd... With CONFIG_GGI_DEBUG_LEVEL=2, what is the LAST 4 messages you get from the kernel? Is CONFIG_VT_PRINTK_FOLLOWING=y ? > Okay - so whenever someone finally patches up 2.1.78 - how do I repatch? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 13 06:55:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA05028 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 06:55:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA13918; Tue, 13 Jan 1998 09:18:54 -0500 Resent-Date: Tue, 13 Jan 1998 09:18:54 -0500 Message-Id: <m0xs7CT-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keyboard API To: evstack@ontv.com Date: Wed, 14 Jan 1998 01:20:17 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980112155956.349A-101000@lidschi.wgnet> from "Matthias Grimrath" at Jan 12, 98 04:02:52 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6rGhz.0.0P3.dUtkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/281 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Matthias Grimrath writes: > Attached is my (rough) outline. I haven't followed this list too close, but > I know my ideas are similiar to yours. Please have a look and tell me what > you think. Needless to say I'm willing to code it. OK, here's my critique :) [or should that be rant :)] Key Labels ---------- Yeah I like that term better that BaseSym. When we extend the key event, the following looks very nice to me : ggi_event.key.sym ggi_event.key.code ggi_event.key.label The last one is the new one, the first two are the same as before. [KeySym is a bit misleading, it is more of an 'action code' which says "hey, do this!" such as K_DECREASE_CONS which says "hey, decrease the console, dude". But keeping it as 'sym' is OK with me and we don't break things (more than we do already :)] > These keylabel are somewhat unified scancodes Not really. What I have in mind for the KeyLabel is the symbol on the key. For normal keys like 'A' and '1', the label is just the unicode value for the symbol. This handles russian keyboards and japanese keyboards and every other thing under the sun. [I'm assuming russian keyboards have russian letters on 'em, but I've never actually seen one]. For special keys like ALT, ENTER, F1, etc. we use values in the unicode application specific zone (0xe000-0xf7ff if I remember correctly), which is just what the linux keymaps do now. Thus KeyLabels are really just the KeySym you get when you press the key _without modifiers_. So long as we have mapping tables from scancode -> KeySym, we get the KeyLabels for free. [Note that the normal linux kernel puts Latin1 letters in the 'Linux-Zone' as well (0xf000-0xfbff), which looks like a massive kludge to me. E.g. KT_LETTER is there just to make capslock easy to implement... tough luck if you want capslock to work with a russian keyboard for example...] Musical Keyboards ----------------- Interesting idea... you could have KeySyms for C#3 etc., but just think of all those keys with no labels on them! :-) Key Positions ------------- > At this point I distinguish between apps that > - are interested in the label of the key > - are interested in the layout of the key on the keyboard. Hmmm, while determining the position of a key pressed/release is doable, it is not doable easily. The problems are : - we would need to make up tables for each keyboard, since we can't just glean the position information from the scancode or keysym. [I think X has some stuff on this, but I don't know how we'd go using it...] - it's not easy to encode the position in 8 bits, and darn near imposible in 7, and end up with something _standard_. Some keyboards have 34 functions keys for example. And specifing the position in millimeters is, well, silly. So IMHO it's not worth it. [too much pain for too little gain :)] Switching VTs whilst playing DOOM --------------------------------- [got bored ? :-)] I think this requires applications & games to notice VtSwitchedAway events and act appropriately. For example DOOM would see this event and think to itself "hey, the user's gone away" and reset it's keyboard state as 'nothing pressed', it's joystick state to 'centred & no buttons pressed', etc. [I can just hear Duke saying "Hey, where y'goin' ?" :-)] When switched back, it can just ignore KeyRelease & ButtonRelease events that don't correspond to it's keyboard state (such as the F1-up ALT-up it would get). Or with Andy's model it will get KeyState, ValState and PtrState events which would bring it up-to-date. Application Usage ----------------- > Each entry specifies a key that your application is interested to > trace. From now on, every time this key changes (and the app has the > input focus) this field gets updated. That's a good idea, and I think the right place to do this is libGII. SVGAlib has this nice function "keyboard_keypressed(KEY)" which lets you check if a particular key is pressed or not. Having a similiar thing in libGII would be great. Since KeyLabels are 16 bit, you would need to register the keys you're interested in (just as in your proposal). > These apps often want to know about the relative change of keypresses. Well you get these for free just by looking at normal events. > the function 'IsKeyAvailable()' checks for the presence of a key in > question. Another interesting idea... and doable so long as libGII can read the keymapping table... but probably not necessary. Any program that used the 'STOP' key (for example) solely for a particular function wouldn't be very portable. And remember there's no harm in checking for keys that aren't there. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 07:33:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA05107 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 07:33:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA14411; Tue, 13 Jan 1998 09:56:24 -0500 Resent-Date: Tue, 13 Jan 1998 09:56:24 -0500 Message-Id: <m0xs7mf-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: evstack ps2aux mousedriver. To: evstack@ontv.com Date: Wed, 14 Jan 1998 01:57:41 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <34BBEE5F.50C@bitsmart.com> from "Jonas Borgström" at Jan 13, 98 11:44:47 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OlL_71.0.bW3.k1ukq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/282 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jonas Borgström writes: > Hi, > > I have ported the ps2aux mouse driver to evstack, I don't know if I did it > the right way but it works for me. Thanks! > I don't know how evstack works. But beeper and nmouse modules did this: > > sprintf(buf, "attach %s\n", par_stack_to_string(ps2aux.stack)); > input_stack->ops->write(input_stack, buf); > > What does it do? It attaches the ps2aux stack to the input stack. Try 'util/stacktree' before and after to see what happens. The usual behaviour of a device stack is to send the events to its parent stack. > I did the same in the ps2aux driver, but it worked without it to. That's because when a stack is not attached to another stack, it has no parent, and stack->report_to is NULL. Thus when you do ev_send(.., .., .., stack->report_to) it gives ev_send the address NULL, which is currently an alias for the input_stack. (This may change, though). It is better if you do this: if (ps2aux.stack->report_to == NULL) { return; } which is what I've done in serialmouse.c (in $GGIHOME/driver/input/mouse). This means you can turn off the events by just "detach"ing the ps2aux stack from the input stack. I've just noticed something: you're calling ev_send() in an interrupt routine! This is BAD, since ev_send goes through the whole event queue (including the xterm), and this (as you can imagine) takes a long time. What needs to happen is that ev_send() should get called from a Bottom Handler (the BH stuff). I don't know much about it (only that bottom handlers are the place to do stuff that takes a long time). Could you please fix this ? Just follow the example in i386/keyboard.c, and it shouldn't be too hard. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 10:18:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05371 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 10:18:23 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA16539; Tue, 13 Jan 1998 12:41:38 -0500 Resent-Date: Tue, 13 Jan 1998 12:41:38 -0500 Date: Tue, 13 Jan 1998 10:54:20 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: amusing update... In-Reply-To: <m0xs51m-00017HC@ajax> Message-ID: <Pine.LNX.3.96.980113105207.806B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Ixx_h.0.x14.SSwkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/283 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998, Andrew Apted wrote: > teunis writes: > > > Well - at least I know everything will work once keyboard is active again :) > [...] > > CONFIG_GGI_EVKEYMAP=m > > That explains it. Unless you want to telnet in each time and insmod the > keymapper :-), better set that to 'yes please'. Thanks! :) [adding 'modprobe keymap' to rc.local now :] ... perhaps that should be added to a README? G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 13 10:31:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05391 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 10:31:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA16807; Tue, 13 Jan 1998 12:55:20 -0500 Resent-Date: Tue, 13 Jan 1998 12:55:20 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xs8ik-0000XVC@charon.beck-sw.de> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Tue, 13 Jan 1998 16:57:41 +0100 (MET) In-Reply-To: <m0xs5EY-00017HC@ajax> from "Andrew Apted" at Jan 13, 98 11:14:18 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"rnsLJ.0.h44.7fwkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/284 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > I've mostly fixed it and committed the change to evstack.c. Doing > "cat /proc/keymap" now works OK, also "cp /proc/keymap xxx". Great. What was it ? Stupid typo as always ? > What's weird is that doing "less /proc/keymap" doesn't get it the whole > lot, it stops part-way. Maybe this is something to do with the way less > works, I don't know... Less generally doesn't work right with /proc files. I do not know why. > BTW, does anyone know what 'P' means when doing a CVS update ? Hmm - funny, this is not documented ... I assume it means something like "Patching" instead of "Updateing", i.e. it occurs, when the file changed in both repository and your source, but changes are compatible (so no "Conflict" occurs ...). However this is a pure guess ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 10:32:28 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05395 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 10:32:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA16817; Tue, 13 Jan 1998 12:55:42 -0500 Resent-Date: Tue, 13 Jan 1998 12:55:42 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsAF8-0000XVC@charon.beck-sw.de> Subject: Re: keyboard API To: evstack@ontv.com Date: Tue, 13 Jan 1998 18:35:14 +0100 (MET) In-Reply-To: <m0xs7CT-00017HC@ajax> from "Andrew Apted" at Jan 14, 98 01:20:17 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"xQMO3.0.U54.Cfwkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/287 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Key Labels > ---------- > Yeah I like that term better that BaseSym. When we extend the key > event, the following looks very nice to me : > ggi_event.key.sym > ggi_event.key.code > ggi_event.key.label Acknowledged. > [KeySym is a bit misleading, it is more of an 'action code' which says > "hey, do this!" such as K_DECREASE_CONS which says "hey, decrease the > console, dude". But keeping it as 'sym' is OK with me and we don't break > things (more than we do already :)] Well - most times it is a unicode symbol. Only at few times it is an action code ... > > These keylabel are somewhat unified scancodes > Not really. What I have in mind for the KeyLabel is the symbol on the > key. For normal keys like 'A' and '1', the label is just the unicode > value for the symbol. This handles russian keyboards and japanese > keyboards and every other thing under the sun. Yes. I vote for this, too, as it has the benefit of the changes for existing apps would be _very_ small. > Thus KeyLabels are really just the KeySym you get when you press the key > _without modifiers_. So long as we have mapping tables from scancode -> > KeySym, we get the KeyLabels for free. Assuming the person in from of the screen is sane enough to have mapped the unshifted meaning to the symbol on the key. I suppose we can safely do so - right ? > [Note that the normal linux kernel puts Latin1 letters in the > 'Linux-Zone' as well (0xf000-0xfbff), which looks like a massive kludge > to me. E.g. KT_LETTER is there just to make capslock easy to > implement... tough luck if you want capslock to work with a russian > keyboard for example...] Yes. IMHO this should be removed. We can do better with EvStack. There is some weird glitch (or has been) in the german mapping table that made q not KT_LETTER and thus you got "qUERY" with capslock on ... I say drop this silly behaviour. Capslock can be implemented cleanly by having a table of affected symbols, so use it. It already hits the the wall for german umlauts ... > Musical Keyboards > ----------------- > Interesting idea... you could have KeySyms for C#3 etc., but just think > of all those keys with no labels on them! :-) *grin* BTW: There is more dynamics information than just how hard you press. Some devices also sense the velocity. Mabye these are cloaked valuators really ... > > At this point I distinguish between apps that > > - are interested in the label of the key > > - are interested in the layout of the key on the keyboard. > Hmmm, while determining the position of a key pressed/release is doable, > it is not doable easily. The problems are : > > - we would need to make up tables for each keyboard, since we > can't just glean the position information from the scancode or > keysym. [I think X has some stuff on this, but I don't know > how we'd go using it...] > > - it's not easy to encode the position in 8 bits, and darn near > imposible in 7, and end up with something _standard_. Some > keyboards have 34 functions keys for example. And specifing > the position in millimeters is, well, silly. > > So IMHO it's not worth it. [too much pain for too little gain :)] Yes. I second that opinion. Every LibGGI application should be configureable. PERIOD. And the good thing about the symbol solution is that it would at least always work "as advertised". I.e. if someone chooses to use A/Z and say so in the docs, this is right. Though the positioning is insane on a German keyboard. I too think we cannot account for any weird keyboard layout. A few examples of available nonstandard keyboards: 1. SUN: A two columns of nifty window-function F-Keys at the left. Four additional device control buttons above the keypad, Caps-lock and control swapped, some extra sun-keys. 2. "Natural" keyboards: Keys that are normally very may close get about 1-2 inch apart depending on where the "split" is. 3. Laptops. Often wildly folded ... Numpad in the middle (though hidden by hardware !). Descent with movent on the keypad would be a pain there ... 4. Remote controls. Yes - there exist full blown keyboards in form of remote controls. They are used for demo- and education-purposes and often use the silly ABCDE FGHIJK ordering ... > > the function 'IsKeyAvailable()' checks for the presence of a key in > > question. > Another interesting idea... and doable so long as libGII can read the > keymapping table... but probably not necessary. Any program that used > the 'STOP' key (for example) solely for a particular function wouldn't > be very portable. And remember there's no harm in checking for keys > that aren't there. Yep. Think so, too. Most of the arguments here are the cause for having LibGII. Hope I can finally talk someone into finishing that. With configuration that easy noone would bother too much about a bad default. CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 10:32:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05399 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 10:32:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA16822; Tue, 13 Jan 1998 12:55:56 -0500 Resent-Date: Tue, 13 Jan 1998 12:55:56 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xs9Cu-0000XVC@charon.beck-sw.de> Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Tue, 13 Jan 1998 17:28:52 +0100 (MET) In-Reply-To: <199801130031.TAA17203@beans.visus.com> from "Jason McMullan" at Jan 12, 98 07:31:00 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"hJpLb1.0.054.8fwkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/285 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > [snip very illuminating stuff] > > The receiving stack would just call ev_rc_set(curr_event->RC,&returncode);. > > Should be quite simple to program ... right ? > > Ok, you have convinced me. I like it. So should I program it, then ? Maybe you would like to code the linked list (you seem to be very proficient with that ;-) ? > However, I think we should take this opportunity > to de-cruft the ev_* family of functions, fix all the evstack > modules, and set the EvStack API in low-temperature plastic. Yes ! > Here's somethings we should ponder: > > * Take uid/gid/perm out of struct evstack > (we can have a `ev_chown',`ev_chgrp',`ev_chmod') Probably better. We would need to "signal" the new mode anyway, so a default plus these calls would be better. > * Take evstack *head out of struct evstack Yep. > * Take proc_dir_entry *de out of struct evstack > (can be better hidden) If you know a place where to put it, fine. > * Re-do the Cmd* event's numbering, so that we encode > a) Length of the Cmd's data > b) Kernel-known vs. module-private vs. user-land Yep. > * Create a way to `allocate' an amount of CmdEvent > numbering space to modules for internal use. Yep. > * Split ev_send into: > ev_send(evstack *stack,ggi_event *ev,ev_retdesc retd); > and > ev_evpage_send(ev_id targ,ggi_evpage *ev,size_t *left); O.K. could be done with a few wrappers. > * Need convenience functions: > ev_event_init(ev_id self,ev_id target, > ev_type type,ev_retdesc retd); > ev_event_cmd_init(ev_id self,ev_id target, > ev_command cmd,void *data,ev_retdesc retd); Yes. very good point. O.K. - let's get at it ! Cu,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 10:32:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05403 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 10:32:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id MAA16814; Tue, 13 Jan 1998 12:55:41 -0500 Resent-Date: Tue, 13 Jan 1998 12:55:41 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xs8qC-0000XVC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Tue, 13 Jan 1998 17:05:24 +0100 (MET) In-Reply-To: <34BBD0D7.1754@bitsmart.com> from "m" at Jan 13, 98 09:38:47 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"gkLXp.0.B54.9fwkq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/286 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > I use a 2.1.78 kernel and my keyboard works, But to get my keyboard working > with 77-78 I had to compile the keyboard-mapping(or what it was called) > into the kernel and not as a module. *grin* Anybody tried to insert it as module ? I'd really be interested in what happens ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 11:07:27 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA05486 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 11:07:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id NAA17300; Tue, 13 Jan 1998 13:30:45 -0500 Resent-Date: Tue, 13 Jan 1998 13:30:45 -0500 Message-Id: <199801131832.TAA30382@zafir.e.kth.se> To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com, e94_msu@elixir.e.kth.se Subject: Re: keymapping and /proc In-reply-to: Your message of "Tue, 13 Jan 1998 16:57:41 +0100." <m0xs8ik-0000XVC@charon.beck-sw.de> Date: Tue, 13 Jan 1998 19:32:50 +0100 From: Marcus Sundberg <e94_msu@elixir.e.kth.se> Resent-Message-ID: <"FYhoh1.0.qD4.mAxkq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/288 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Less generally doesn't work right with /proc files. I do not know why. IIRC it's beacause less tries to stat() the file to get it's size. (Which naturally won't work on most /proc entries.) //Marcus From evstack-request@ontv.com Tue Jan 13 12:04:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA05572 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 12:04:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA18180; Tue, 13 Jan 1998 14:28:01 -0500 Resent-Date: Tue, 13 Jan 1998 14:28:01 -0500 Date: Tue, 13 Jan 1998 12:40:50 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xs8qC-0000XVC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980113123915.326A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"bAwtC1.0.WR4.E0ykq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/289 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > I use a 2.1.78 kernel and my keyboard works, But to get my keyboard working > > with 77-78 I had to compile the keyboard-mapping(or what it was called) > > into the kernel and not as a module. > *grin* Anybody tried to insert it as module ? I'd really be interested in > what happens ... Unresolved symbols: show_mem ctrl_alt_del show_state *sigh*.... entering this through telnet.... Someone forget to EXPORT something? :) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 13 12:11:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA05608 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 12:11:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA18292; Tue, 13 Jan 1998 14:34:59 -0500 Resent-Date: Tue, 13 Jan 1998 14:34:59 -0500 Date: Tue, 13 Jan 1998 12:47:53 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xsAF8-0000XVC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980113124144.326B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6ZFnP.0.MT4.v6ykq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/290 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Musical Keyboards > > ----------------- > > Interesting idea... you could have KeySyms for C#3 etc., but just think > > of all those keys with no labels on them! :-) > *grin* > > BTW: There is more dynamics information than just how hard you press. > Some devices also sense the velocity. Mabye these are cloaked valuators > really ... Yep - I think... Possibly you can alter the pressure while the key is active as well : the MIDI specs imply exactly this! > Yes. I second that opinion. Every LibGGI application should be > configureable. PERIOD. And the good thing about the symbol solution > is that it would at least always work "as advertised". *grin* - am setting up "La Cube Of Silliness" to be massively configurable - and to not require a keyboard if you're up to tapping on virtual-keys in VR :) [handy for testing out other keyboard layouts eventually perhaps? I'm gonna do Microsoft Natural right off the bat ('cause that's what I have), but will try to make that configurable as well :] > I too think we cannot account for any weird keyboard layout. A few examples > of available nonstandard keyboards: > > 1. SUN: A two columns of nifty window-function F-Keys at the left. Four > additional device control buttons above the keypad, Caps-lock and control > swapped, some extra sun-keys. Like traditional-PC keyboard as well... but cleaner and nicer. (and lighter - not made of solid steel :) > 2. "Natural" keyboards: Keys that are normally very may close get about > 1-2 inch apart depending on where the "split" is. But OOHH so comfortable.. Haven't had a wrist problem since I switched *grin*. Typing 8-18 hours a day can tire a person out... > 3. Laptops. Often wildly folded ... Numpad in the middle (though hidden > by hardware !). Descent with movent on the keypad would be a pain there ... Can be all over the place but these systems are starting to stablize. > 4. Remote controls. Yes - there exist full blown keyboards in form of > remote controls. They are used for demo- and education-purposes and often > use the silly ABCDE FGHIJK ordering ... *grin* - it works though... Dvorak layout? Apparently it's a lot more intuitive (and faster to type with) than traditional QWERTY (aside: QWERTY was _DESIGNED_ to slow down typists so that the hardware could handle it.... oh, and so you could type "typewriter" with one hand quickly :) G'day, eh? :) - Teunis PS: I'll use anything you guys code - I'm not yet advanced enough to be any help beyond being a pain-in-the-neck on email lists... yet... From evstack-request@ontv.com Tue Jan 13 12:19:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA05644 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 12:19:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA18429; Tue, 13 Jan 1998 14:40:02 -0500 Resent-Date: Tue, 13 Jan 1998 14:40:02 -0500 Date: Tue, 13 Jan 1998 12:49:46 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: keymapping and /proc In-Reply-To: <m0xs8ik-0000XVC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980113124817.326C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"mouL12.0.NU4.c8ykq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/291 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > What's weird is that doing "less /proc/keymap" doesn't get it the whole > > lot, it stops part-way. Maybe this is something to do with the way less > > works, I don't know... > > Less generally doesn't work right with /proc files. I do not know why. Buffering on files that don't support either buffering or stopped reading AFAIK.... cat /proc/file | less has always worked though IIRC.... Might have something with how it handles the transfer to userspace. G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 13 12:19:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA05648 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 12:19:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA18501; Tue, 13 Jan 1998 14:41:55 -0500 Resent-Date: Tue, 13 Jan 1998 14:41:55 -0500 Date: Tue, 13 Jan 1998 12:53:34 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com cc: becka@rz.uni-duesseldorf.de Subject: Re: keymapping and /proc In-Reply-To: <Pine.LNX.3.96.980113124817.326C-100000@sigil.computersupportcentre.com> Message-ID: <Pine.LNX.3.96.980113125259.357A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Q5x672.0.dV4.4Cykq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/292 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998, teunis wrote: > On Tue, 13 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > What's weird is that doing "less /proc/keymap" doesn't get it the whole > > > lot, it stops part-way. Maybe this is something to do with the way less > > > works, I don't know... > > > > Less generally doesn't work right with /proc files. I do not know why. > > Buffering on files that don't support either buffering or stopped reading > AFAIK.... cat /proc/file | less has always worked though IIRC.... > > Might have something with how it handles the transfer to userspace. Whoops - I'm completely wrong here... Please ignore me :) (the 'stat' call is correct *sigh*) G'day, eh? :) - Teunis (sorry to waste bandwidth and time) From evstack-request@ontv.com Tue Jan 13 12:20:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA05652 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 12:20:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id OAA18498; Tue, 13 Jan 1998 14:41:52 -0500 Resent-Date: Tue, 13 Jan 1998 14:41:52 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: keymapping and /proc Date: 13 Jan 1998 19:44:15 GMT Organization: OnTV Pittsburgh, L.P. Lines: 35 Distribution: local Message-ID: <69gg6f$gec$1@grits.visus.com> References: <69gacm$d79$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"W3ft_3.0.SW4.GDykq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/293 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > BTW, does anyone know what 'P' means when doing a CVS update ? > Hmm - funny, this is not documented ... > I assume it means something like "Patching" instead of "Updateing", i.e. > it occurs, when the file changed in both repository and your source, but > changes are compatible (so no "Conflict" occurs ...). However this is a > pure guess ... -P means prune. $ cvs update -help update: invalid option -- h Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] -A Reset any sticky tags/date/kopts. -P Prune empty directories. -d Build directories, like checkout does. -f Force a head revision match if tag/date not found. -l Local directory only, no recursion. -R Process directories recursively. -p Send updates to standard output (avoids stickiness). -k kopt Use RCS kopt -k option on checkout. -r rev Update using specified revision/tag (is sticky). -D date Set date to update from (is sticky). -j rev Merge in changes made between current revision and rev. -I ign More files to ignore (! to reset). -W spec Wrappers specification line. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 13 16:47:06 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA06215 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 16:47:05 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA21911; Tue, 13 Jan 1998 19:10:17 -0500 Resent-Date: Tue, 13 Jan 1998 19:10:17 -0500 Message-Id: <m0xsGR3-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Wed, 14 Jan 1998 11:11:57 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69gg6f$gec$1@grits.visus.com> from "Jason McMullan" at Jan 13, 98 07:44:15 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0M8vt.0.qL5.A90lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/294 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > > > BTW, does anyone know what 'P' means when doing a CVS update ? > > Hmm - funny, this is not documented ... > > -P means prune. No I meant the output of cvs update. I've seen this a couple times (haven't you ?) : bash> cvs -z1 update P Makefile My guess would be 'Protected' i.e. while someone else is doing a commit on it, but this isn't documented. [I don't think it's important]. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 16:52:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA06229 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 16:52:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA22010; Tue, 13 Jan 1998 19:16:04 -0500 Resent-Date: Tue, 13 Jan 1998 19:16:04 -0500 Message-Id: <m0xsGWk-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Wed, 14 Jan 1998 11:17:50 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xs8ik-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 13, 98 04:57:41 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"T0U-i1.0.ON5.fE0lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/295 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > I've mostly fixed it and committed the change to evstack.c. Doing > > "cat /proc/keymap" now works OK, also "cp /proc/keymap xxx". > Great. What was it ? Stupid typo as always ? Possibly, but the code was hard to follow, so I ended up rewriting it to make it simpler. [If it breaks, you know who to blame :)] > > What's weird is that doing "less /proc/keymap" doesn't get it the whole > > lot, it stops part-way. Maybe this is something to do with the way less > > works, I don't know... > > Less generally doesn't work right with /proc files. I do not know why. Okay, no worries then. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 17:31:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA06297 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 17:31:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA22450; Tue, 13 Jan 1998 19:54:11 -0500 Resent-Date: Tue, 13 Jan 1998 19:54:11 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsHae-0000XXC@charon.beck-sw.de> Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Wed, 14 Jan 1998 02:25:56 +0100 (MET) In-Reply-To: <199801131923.OAA31711@beans.visus.com> from "Jason McMullan" at Jan 13, 98 02:23:53 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"XlSI12.0.DU5.No0lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/297 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > In article <69gacn$d7a$1@grits.visus.com> you wrote: > > > > [snip very illuminating stuff] > > > > The receiving stack would just call ev_rc_set(curr_event->RC,&returncode);. > > > > Should be quite simple to program ... right ? > > > > > > Ok, you have convinced me. I like it. > > So should I program it, then ? O.K. - Let's set the prototypes : typedef some_to_be_worked_out_struct ev_rc_desc; /* or better a pointer ... */ ev_rc_desc ev_rc_alloc(size_t rcsize); /* eventually a macro to have "int" easily */ void ev_rc_free (ev_rc_desc); void ev_rc_set (ev_rc_desc, &the_data /* ,size_of_data ?? */ ); int ev_rc_wait (ev_rc_desc, uint timeout); void *ev_rc_get (ev_rc_desc); Do you think this is a suitable definition ? I tried to make it in a way to completely hide the internal working (thus the rc_get()). > Yes - I've got my hands full with /dev/graph [I've _almost_ got > the mode-setting bug licked... I'll release what I have [and the > 2.1.79 patch] tonight.] Great. Uh - kernel patching and recompiling again ... I start to hate my poor 486/66. > Yep - something like `Event:CmdSetPerm' and `ev_set_perm()' Hmm - Event==Security_Hazard, don't you think ? > > > * Take proc_dir_entry *de out of struct evstack > I'm thinking of placing it in the same list that keeps track > of the currently allocated stacks in ev_instance_stack() O.K. - shove everything there which is not necessary for operation of EvStacks. BTW: I do not know, if you have seen it, but there is someone writing a devfs which might one day supplant part of /proc/. We should keep in touch with him (I will try). The devfs is a bit more flexible. It is designed to hold device entries ... > Once /dev/graph+MMAP is done, we're 90% of the way there! > We can then start moving our code into Degas, fix the > libGGI KGI code, start porting display drivers, etc... Yeah ! Longing for this ! EvStack kernel is so much prettier than standard GGI kernel ... Cu,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 17:31:40 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA06301 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 17:31:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA22510; Tue, 13 Jan 1998 19:55:07 -0500 Resent-Date: Tue, 13 Jan 1998 19:55:07 -0500 Message-Id: <m0xsH8N-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keyboard API To: evstack@ontv.com Date: Wed, 14 Jan 1998 11:56:42 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xsAF8-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 13, 98 06:35:14 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"pHxuI.0.3V5.7p0lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/298 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > Thus KeyLabels are really just the KeySym you get when you press the key > > _without modifiers_. So long as we have mapping tables from scancode -> > > KeySym, we get the KeyLabels for free. > > Assuming the person in from of the screen is sane enough to have mapped the > unshifted meaning to the symbol on the key. I suppose we can safely do so - > right ? Well, yeah, a person could map their keys to anything they like... But the _default_ maps (such as the ones in the kernel) should be sane. Perhaps it's better to do code->label mapping separately (i.e. with its own map) ? If so, we would still get that mapping table pretty cheaply by just using the default code->sym map. > > [Note that the normal linux kernel puts Latin1 letters in the > > 'Linux-Zone' as well (0xf000-0xfbff), which looks like a massive kludge > > to me. E.g. KT_LETTER is there just to make capslock easy to > > implement... tough luck if you want capslock to work with a russian > > keyboard for example...] > > Yes. IMHO this should be removed. We can do better with EvStack. There is > some weird glitch (or has been) in the german mapping table that made q > not KT_LETTER and thus you got "qUERY" with capslock on ... > > I say drop this silly behaviour. Capslock can be implemented cleanly by > having a table of affected symbols, so use it. It already hits the > the wall for german umlauts ... Yes, exactly. We just need to put some capslock info in the keymapper (maybe in a per-VT keymapper ?). The current capslock code is done in xterm.c (numlock too), but I don't think that's where it _should_ be done (e.g. capslock would have to be re-implemented for the graphical console as well ...). Whilst we're on the subject of keysyms, I'd like to propose that we get rid of the U() macro as well. It really confuses people, and there's a better way to do it. What I have in mind is to explicitly put the values of K_LEFT, K_F1, K_ENTER etc. in the range 0xf000-0xffff instead of (as now) they are 0x0000 - 0x0fff. We can do this by using the following in ggi/keyboard.h : #define KT_LATIN 0xf0 #define KT_LETTER 0xfb #define KT_FN 0xf1 #define KT_SPEC 0xf2 #define KT_PAD 0xf3 #define KT_DEAD 0xf4 #define KT_CONS 0xf5 #define KT_CUR 0xf6 #define KT_SHIFT 0xf7 #define KT_META 0xf8 #define KT_ASCII 0xf9 #define KT_BUTTON 0xfc This doesn't affect the keymaps, but it does break some code. I'm willing to go through the kernel code and make the changes, and user code just needs to remove the occurrences U(). Comments ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 17:31:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA06305 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 17:31:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA22404; Tue, 13 Jan 1998 19:53:38 -0500 Resent-Date: Tue, 13 Jan 1998 19:53:38 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsFYo-0000XXC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Wed, 14 Jan 1998 00:15:54 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980113123915.326A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 13, 98 12:40:50 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"jkBES2.0.eT5.sn0lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/296 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > I use a 2.1.78 kernel and my keyboard works, But to get my keyboard working > > > with 77-78 I had to compile the keyboard-mapping(or what it was called) > > > into the kernel and not as a module. > > *grin* Anybody tried to insert it as module ? I'd really be interested in > > what happens ... > > Unresolved symbols: > show_mem > ctrl_alt_del > show_state > > *sigh*.... entering this through telnet.... > Someone forget to EXPORT something? :) Probably. Comment out the references and recompile the module. Nothing bad will happen. These should be changed anyway. The keymap module was not really intended for being modularized ... CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 17:47:43 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA06353 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 17:47:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA22925; Tue, 13 Jan 1998 20:10:47 -0500 Resent-Date: Tue, 13 Jan 1998 20:10:47 -0500 Message-Id: <m0xsHNQ-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Wed, 14 Jan 1998 12:12:16 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xs9Cu-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 13, 98 05:28:52 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"zpVJ11.0.Jb5.l11lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/299 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > However, I think we should take this opportunity > > to de-cruft the ev_* family of functions, fix all the evstack > > modules, and set the EvStack API in low-temperature plastic. > Yes ! Me says Yes! too. :) One thing I need in the evstack structure is: evstack *parent; which is set to the parent stack that a stack is attached to. I need this so when I destroy (for example) a joystick device stack, I can remove it from its parent stack before-hand. [the current code just assumes it is still on the input_stack !]. And with this, the behaviour of input devices will be : if (self->report_to != NULL) { ev_send(..., self->report_to); } else if (self->parent != NULL) { ev_send(..., self->parent); } else { /* don't send the event */ } Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 13 19:46:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA06550 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 19:46:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA24185; Tue, 13 Jan 1998 22:08:59 -0500 Resent-Date: Tue, 13 Jan 1998 22:08:59 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsIS3-0000XXC@charon.beck-sw.de> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Wed, 14 Jan 1998 03:21:07 +0100 (MET) In-Reply-To: <m0xsGR3-00017HC@ajax> from "Andrew Apted" at Jan 14, 98 11:11:57 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"zSOlG1.0.Qv5.jl2lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/300 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > > BTW, does anyone know what 'P' means when doing a CVS update ? > > > Hmm - funny, this is not documented ... > bash> cvs -z1 update > P Makefile > My guess would be 'Protected' i.e. while someone else is doing a commit > on it, but this isn't documented. [I don't think it's important]. No - I get this far too often for that ... I'm afraid we would have to dig it out of the source, if we really care ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Tue Jan 13 22:33:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA06797 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 22:33:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id AAA25854; Wed, 14 Jan 1998 00:56:42 -0500 Resent-Date: Wed, 14 Jan 1998 00:56:42 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: keymapping works o.k. now. Date: 14 Jan 1998 05:59:27 GMT Organization: OnTV Pittsburgh, L.P. Lines: 53 Distribution: local Message-ID: <69hk7v$ecl$1@grits.visus.com> References: <69h304$1ac$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"4NQfo1.0.GI6._D5lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/301 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > O.K. - Let's set the prototypes : > [snip description] > Do you think this is a suitable definition ? I tried to make it in a way > to completely hide the internal working (thus the rc_get()). Looks great! > > Yes - I've got my hands full with /dev/graph [I've _almost_ got > > the mode-setting bug licked... I'll release what I have [and the > > 2.1.79 patch] tonight.] > Great. Uh - kernel patching and recompiling again ... I start to hate my > poor 486/66. Well, after checking, you should be able to use my latest CVS to patch 2.1.77 - 2.1.79. (with a little bit of fuzz for the earlier ones...) > > Yep - something like `Event:CmdSetPerm' and `ev_set_perm()' > Hmm - Event==Security_Hazard, don't you think ? Hmm... Maybe we should have a `SecurityHazard' bit in the Cmd* types? (or a range... hmmm..) anyway, the `SecurityHazard' CmdEvents CANNOT cross kernel<->user boundaries UNLESS dealing with a root application.... Hmm.. > BTW: I do not know, if you have seen it, but there is someone writing > a devfs which might one day supplant part of /proc/. We should keep in > touch with him (I will try). The devfs is a bit more flexible. > It is designed to hold device entries ... From what i've seen of his code, it should be easy to replace our /proc stuff with his /dev stuff (we would only have to change the EvStack backend that sends/gets lines to stack->op.read/stack->op.write) > > Once /dev/graph+MMAP is done, we're 90% of the way there! > > We can then start moving our code into Degas, fix the > > libGGI KGI code, start porting display drivers, etc... > Yeah ! Longing for this ! EvStack kernel is so much prettier than > standard GGI kernel ... I'm currently stuck where setting the mode (after insmodding ggivga.o) kills the machine... But .. I Have A Plan... ^;) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 13 23:00:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA06819 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 23:00:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id BAA26668; Wed, 14 Jan 1998 01:23:55 -0500 Resent-Date: Wed, 14 Jan 1998 01:23:55 -0500 Message-Id: <199801140627.BAA04454@beans.visus.com> Subject: Latest rev... To: evstack@ontv.com Date: Wed, 14 Jan 1998 01:27:55 -0500 (EST) Reply-To: jmcc@ontv.com From: Jason McMullan <jmcc@ontv.com> Content-Type: text Resent-Message-ID: <"9soCR3.0.5W6.Qc5lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/302 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com The newest rev of Evstack is out - nothing much new (except some minor restructing of include/ggi/scroll_struct) and I'm still working on /dev/graph, but it's now _doable_. Hope to have at least mode switching done by Saturday. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 13 23:26:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA06853 for <ggi@synergy.foo.net>; Tue, 13 Jan 1998 23:26:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id BAA26894; Wed, 14 Jan 1998 01:49:23 -0500 Resent-Date: Wed, 14 Jan 1998 01:49:23 -0500 Date: Wed, 14 Jan 1998 01:52:11 -0500 (EST) From: Jordan Mendelson <jordy@wserv.com> To: evstack@ontv.com Subject: small patch to evstack Message-ID: <Pine.LNX.3.96.980114015022.9584A-200000@snappy.wserv.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1775108796-1093622242-884760731=:9584" Resent-Message-ID: <"mfiPX1.0.hZ6.L_5lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/303 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1775108796-1093622242-884760731=:9584 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached is a small patch to evstack to allow 'make dep' in 2.1.78. Unfortunatly, you can't define ALL_SUB_DIRS in a Makefile unless you have some subdirs since it'll try to execute: set -e ; for i in $(ALL_SUB_DIRS) ; do ... if it is defined... This was patched off a copy of evstack-ggi i pulled about 30 mins ago. Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com --1775108796-1093622242-884760731=:9584 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="evstack-1.patch" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980114015211.9584B@snappy.wserv.com> Content-Description: LS0tIGdnaS1ldnN0YWNrLk9MRC9wYXRjaGVzL0xpbnV4L2xpbnV4L2RyaXZl cnMvY29uc29sZS9pMzg2L01ha2VmaWxlCVN1biBKYW4gMTEgMDY6MDI6NDkg MTk5OA0KKysrIGdnaS1ldnN0YWNrL3BhdGNoZXMvTGludXgvbGludXgvZHJp dmVycy9jb25zb2xlL2kzODYvTWFrZWZpbGUJV2VkIEphbiAxNCAwMTo0NDoz NyAxOTk4DQpAQCAtOSwxMCArOSw2IEBADQogIyBwYXJlbnQgbWFrZXMuLg0K ICMNCiANCi1TVUJfRElSUyAgICAgOj0NCi1NT0RfU1VCX0RJUlMgOj0gJChT VUJfRElSUykNCi1BTExfU1VCX0RJUlMgOj0gJChTVUJfRElSUykgDQotDQog Iw0KICMgVGhpcyBpcyB0aGUgY29sbGVjdGlvbiBvZiBhbGwgdGhlIHRvLWJl LWJ1aWxkLWluIG1vZHVsZXMNCiAjDQo= --1775108796-1093622242-884760731=:9584-- From evstack-request@ontv.com Wed Jan 14 05:50:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA07222 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 05:50:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA30262; Wed, 14 Jan 1998 08:13:45 -0500 Resent-Date: Wed, 14 Jan 1998 08:13:45 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsT4j-0000XXC@charon.beck-sw.de> Subject: Re: keymapping works o.k. now. To: evstack@ontv.com (Evstack Mailing List) Date: Wed, 14 Jan 1998 14:41:45 +0100 (MET) In-Reply-To: <69hk7v$ecl$1@grits.visus.com> from "Jason McMullan" at Jan 14, 98 05:59:27 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"nNbqV1.0.CN7.wbBlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/304 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > O.K. - Let's set the prototypes : > Looks great! O.K. will implement it this way, then. I'll simply grab your great linked-list code from some of the other registering functions and try to make a suitable struct to hold the actual data. As the struct is completely opaque, no harm done, if we have to modify it for different OSes (thinking of things like wait queues ...). Right ? > > > Yep - something like `Event:CmdSetPerm' and `ev_set_perm()' > > Hmm - Event==Security_Hazard, don't you think ? > > Hmm... Maybe we should have a `SecurityHazard' bit in the Cmd* types? > (or a range... hmmm..) anyway, the `SecurityHazard' CmdEvents CANNOT cross > kernel<->user boundaries UNLESS dealing with a root application.... Hmm.. Hmm ... well - maybe. I would have liked, if all security critical things went over the read/write channel, so fs-protections apply. > From what i've seen of his code, it should be easy to replace our > /proc stuff with his /dev stuff (we would only have to change the > EvStack backend that sends/gets lines to stack->op.read/stack->op.write) Yep. That was the reason, why I wanted this capsuled and translated to the line-type read/write calls, so we could swap out that part depending on the OS ... > I'm currently stuck where setting the mode (after insmodding > ggivga.o) kills the machine... But .. I Have A Plan... ^;) Great ! I trust you, you know what you're doing ;-) ... CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Wed Jan 14 05:51:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA07232 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 05:51:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA30285; Wed, 14 Jan 1998 08:14:44 -0500 Resent-Date: Wed, 14 Jan 1998 08:14:44 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsT7P-0000XXC@charon.beck-sw.de> Subject: Re: keymapping works o.k. now. To: evstack@ontv.com Date: Wed, 14 Jan 1998 14:44:31 +0100 (MET) In-Reply-To: <m0xsHNQ-00017HC@ajax> from "Andrew Apted" at Jan 14, 98 12:12:16 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RuVb93.0.kN7.-bBlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/306 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > One thing I need in the evstack structure is: > > evstack *parent; > > which is set to the parent stack that a stack is attached to. Please note a stack can theoretically be attached to multiple parents (makes sense for simple translator-type stacks), though it can send events only to one parent. > I need this so when I destroy (for example) a joystick device stack, > I can remove it from its parent stack before-hand. [the current code > just assumes it is still on the input_stack !]. IIRC I had coded an auto-detach feature when a stack gets unregistered some time ... Did this get lost ? CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Wed Jan 14 05:51:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA07236 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 05:51:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA30284; Wed, 14 Jan 1998 08:14:44 -0500 Resent-Date: Wed, 14 Jan 1998 08:14:44 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsTXn-0000XXC@charon.beck-sw.de> Subject: Re: keyboard API To: evstack@ontv.com Date: Wed, 14 Jan 1998 15:11:47 +0100 (MET) In-Reply-To: <m0xsH8N-00017HC@ajax> from "Andrew Apted" at Jan 14, 98 11:56:42 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"YH9jQ3.0.UN7.ybBlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/305 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > Thus KeyLabels are really just the KeySym you get when you press the key > > > _without modifiers_. > > Assuming the person in from of the screen is sane enough to have mapped the > > unshifted meaning to the symbol on the key. > Well, yeah, a person could map their keys to anything they like... But > the _default_ maps (such as the ones in the kernel) should be sane. > > Perhaps it's better to do code->label mapping separately (i.e. with its > own map) ? If so, we would still get that mapping table pretty cheaply > by just using the default code->sym map. How about simply having this associated with a "modifier-value" of "-1" (as now 0 is none, 1 shift, ...) ? Could be done simply and without breaking much. The default map #0 would simply get copied to a newly allocated label-map which has binding accessed with "bind key -1 sym" ? This scheme would easily allow for something you had been heading for: Architecture independent keymaps. I'd say one would do it this way : On a given locale, say germany there are two things in which keyboards can differ from other locales: 1. The base symbols are at other places, i.e. the keycode->keylabel binding is different. 2. The symbols are arranged in another way. E.g. the german keyboard has the " as shift-2 (where american have @), while the @ is at RightAlt-Q. Part 1 depends on two things : The locale and the OS. So we probably cannot standardize it really due to different keyboard layouts. So I'd say we have a per-locale-per-OS mapping table for that. It can eventually be generated from some kind of "crossmapper" that knows how to translate keycodes form one OS/Keyboard layout to another and could thus look up the keylabels from other OSes tables. Part 2 is normally completely independent of OS and keyboard layout. It is simple convention only dependent on the locale. Thus having a table like normal shifted ctrl ALt Altgr 2 " ?? ?? exponent_2 q Q ^q ?? @ could be used by some intelligent map-loading utility in _userspace_ to generate the right tables by first reading out the keylabel mapping and then doing a reverse-lookup of the keynumber via the base symbol and then set the table for the keynumber. This would save us all the hassle of doing label->keysym_with_modifier conversion in kernelspace. Got the point ? (I ask as I think I was unclear - o.k. I retry:) We change nothing in kernel. We expect the keyboard driver to give us some continuous range of keycodes. These are used to do all the mapping. But when setting the mappings, we use the label-table to have a fairly OS-independent way of describing the locale. > Yes, exactly. We just need to put some capslock info in the keymapper > (maybe in a per-VT keymapper ?). Yes. Will be working on that after I have this RC thing done. > The current capslock code is done in xterm.c (numlock too), but I > don't think that's where it _should_ be done (e.g. capslock would > have to be re-implemented for the graphical console as well ...). Yep. We should move that to the keymap code, unless there is specific reason to put it in xterm-code, e.g. because a _terminal_ has the habit of having some keybinding for special reactions. Say e.g. a TERM=HAL9000 has the special property of instantly shutting up speech synthesis, when you press SHIFT-CTRL-ALT-Q. > Whilst we're on the subject of keysyms, I'd like to propose that we get > rid of the U() macro as well. It really confuses people, and there's a > better way to do it. Yeah. Anyone knows why this was introduced in the first place ? Maybe we should ask Steffen ... > What I have in mind is to explicitly put the values of K_LEFT, K_F1, > K_ENTER etc. in the range 0xf000-0xffff instead of (as now) they are > 0x0000 - 0x0fff. We can do this by using the following in > ggi/keyboard.h : > This doesn't affect the keymaps, but it does break some code. It doesn't, if you simply keep the #define U(x) x ... O.K. needs recompile, but so what. This is expected for 0.1.0. CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Wed Jan 14 07:01:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA07325 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 07:01:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id JAA31130; Wed, 14 Jan 1998 09:24:50 -0500 Resent-Date: Wed, 14 Jan 1998 09:24:50 -0500 Message-Id: <m0xsTle-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping works o.k. To: evstack@ontv.com Date: Thu, 15 Jan 1998 01:26:06 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xsT7P-0000XXC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 14, 98 02:44:31 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OO9A43.0.Yb7.LfClq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/307 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > One thing I need in the evstack structure is: > > > > evstack *parent; > > > > which is set to the parent stack that a stack is attached to. > Please note a stack can theoretically be attached to multiple parents > (makes sense for simple translator-type stacks), though it can send > events only to one parent. I kinda hoped you wouldn't say that :). But I can definitely see the advantages... > > I need this so when I destroy (for example) a joystick device stack, > > I can remove it from its parent stack before-hand. [the current code > > just assumes it is still on the input_stack !]. > > IIRC I had coded an auto-detach feature when a stack gets unregistered > some time ... Did this get lost ? Can't see it... just some code that handles report_to... How are we going to implement this auto-detach feature ? Maybe just send "detach 12345678" to _every_ stack in the system ??? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 14 07:49:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA07394 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 07:49:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id KAA31842; Wed, 14 Jan 1998 10:12:54 -0500 Resent-Date: Wed, 14 Jan 1998 10:12:54 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: keymapping works o.k. now. Date: 14 Jan 1998 15:15:20 GMT Organization: OnTV Pittsburgh, L.P. Lines: 25 Distribution: local Message-ID: <69ikq8$67t$1@grits.visus.com> References: <69ie2c$22t$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"7TXpH1.0.0n7.7NDlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/308 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > code from some of the other registering functions and try to make a suitable > struct to hold the actual data. As the struct is completely opaque, no harm > done, if we have to modify it for different OSes (thinking of things like > wait queues ...). Right ? Should work just fine. > > > > Yep - something like `Event:CmdSetPerm' and `ev_set_perm()' > > > Hmm - Event==Security_Hazard, don't you think ? > > > > Hmm... Maybe we should have a `SecurityHazard' bit in the Cmd* types? > > (or a range... hmmm..) anyway, the `SecurityHazard' CmdEvents CANNOT cross > > kernel<->user boundaries UNLESS dealing with a root application.... Hmm.. > Hmm ... well - maybe. I would have liked, if all security critical things > went over the read/write channel, so fs-protections apply. Duh. Excuse me while I stick my brain back in... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 14 10:55:06 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA07623 for <ggi@synergy.foo.net>; Wed, 14 Jan 1998 10:55:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id NAA01497; Wed, 14 Jan 1998 13:17:59 -0500 Resent-Date: Wed, 14 Jan 1998 13:17:59 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsVq5-0000XWC@charon.beck-sw.de> Subject: Re: keymapping works o.k. To: evstack@ontv.com Date: Wed, 14 Jan 1998 17:38:49 +0100 (MET) In-Reply-To: <m0xsTle-00017HC@ajax> from "Andrew Apted" at Jan 15, 98 01:26:06 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"WGNmP.0.xM.l4Glq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/309 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > I need this so when I destroy (for example) a joystick device stack, > > > I can remove it from its parent stack before-hand. [the current code > > > just assumes it is still on the input_stack !]. > > > > IIRC I had coded an auto-detach feature when a stack gets unregistered > > some time ... Did this get lost ? > > Can't see it... just some code that handles report_to... > > How are we going to implement this auto-detach feature ? Maybe just > send "detach 12345678" to _every_ stack in the system ??? I think that was how it was done. Or maybe this was in some never-commited version ... CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 05:36:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA08734 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 05:36:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id HAA13470; Thu, 15 Jan 1998 07:59:38 -0500 Resent-Date: Thu, 15 Jan 1998 07:59:38 -0500 Message-Id: <m0xsovW-00017DC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keyboard API To: evstack@ontv.com Date: Fri, 16 Jan 1998 00:01:42 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xso0b-0000XeC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 15, 98 01:02:53 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2s0dL3.0.xH3.vVWlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/319 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > Sounds like a good idea. I guess you're saying something like this : ? > > > > key.label = map[0][key.code]; > > key.sym = map[1+key.effect][key.code]; > > ^^ > Yes. Either that way or rather having a "labelmap" and using > > key.label=labelmap[key.code]; > > and then special-casing the -1 on external interaction. > > But OTOH what you propose above is easier to do. All you need is changing > two values in the keymaps: 1. adding a second reference to the plain map > to the keymaps table 2. incrementing the mapcount by 1. I prefer the separate map. > > That sounds reasonable. We lose the flow-on effect when changing a > > keylabel, but since changing keymaps is not done very often, no big deal. > > No really. An intelligent usermode program (and I think intelligence should > go to usermode ...) could read out the whole mapping and shift it around. Sane users will use 'loadkeys' or whatever, so yeah no problem. [I was thinking of kernel hackers who like to echo stuff to /proc -- no sanity there though ,-)]. > > The xterm has escape codes (I assume) which changes how it handles > > capslock, numlock, and probably other stuff as well. Yech. Will anyone > > miss that ? I don't know, but I know I won't :). > > Argh ! This is mega-sick. Could you try to track them, so we can see if there > is any sense in that codes ? I'd like to see what we kill before we shoot ... I'll take a closer look whilst I kill off the U macro... > Hmm - would this work ? Dunno if you can get the warning in there this way > without consequences for the source ...: > > #define U(x) (x)\ > #warning The U() makro is useless now. rip it out ...\ I doubt cpp can do such things... I might try it... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 05:58:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA08854 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 05:58:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id IAA13867; Thu, 15 Jan 1998 08:21:32 -0500 Resent-Date: Thu, 15 Jan 1998 08:21:32 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Rewriting display drivers & Bug Report Date: 15 Jan 1998 13:23:45 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Distribution: local Message-ID: <69l2l1$q3$1@grits.visus.com> References: <69jnut$3c6$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"sFas22.0.7O3.TqWlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/320 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan (jmcc@beans.visus.com) wrote: > Jordan Mendelson (jordy@wserv.com) wrote: > > Also, I noticed that when booting the recent version of evstack on my 2.1.78 > > kernel that when init starts up, the screen starts to overwrite itself, this > > is the same problem I had when i moved the non-evstack ggi source to 2.1.78. > > Anyone know what's causing it? > Whoops! 2 line change! It'll be normal by tomorrow. [Replying to myself] Hmm... Now that I look at the code again, I remember what's up: Printk writes _directly_ to the scroll_* interface, bypassing any loaded (or possibly dead) terminal stack. The XTerm stack has it's own idea of where the cursor is, and always draws text at absolute coordinates. Both of these are rational decisions, given our model, and the only solution I see to get back the old printk behaviour would be to have the XTerm stack query the cursor position at every write, and respect it. This, granted, would slow down XTerm. I don't think it's worth the effort - any one have any other ideas? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 15 06:20:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08900 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id GAA12668; Thu, 15 Jan 1998 06:17:11 -0500 Resent-Date: Thu, 15 Jan 1998 06:17:11 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xso0b-0000XeC@charon.beck-sw.de> Subject: Re: keyboard API To: evstack@ontv.com Date: Thu, 15 Jan 1998 13:02:53 +0100 (MET) In-Reply-To: <m0xse3x-00017HC@ajax> from "Andrew Apted" at Jan 15, 98 12:25:41 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"XqTSB.0.K53.s_Ulq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/318 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > How about simply having this associated with a "modifier-value" of "-1" > > (as now 0 is none, 1 shift, ...) ? > > Sounds like a good idea. I guess you're saying something like this : ? > > key.label = map[0][key.code]; > key.sym = map[1+key.effect][key.code]; > ^^ Yes. Either that way or rather having a "labelmap" and using key.label=labelmap[key.code]; and then special-casing the -1 on external interaction. But OTOH what you propose above is easier to do. All you need is changing two values in the keymaps: 1. adding a second reference to the plain map to the keymaps table 2. incrementing the mapcount by 1. > > Thus having a table like > > > > normal shifted ctrl ALt Altgr > > 2 " ?? ?? exponent_2 > > q Q ^q ?? @ > > > > could be used by some intelligent map-loading utility in _userspace_ to > > generate the right tables by first reading out the keylabel mapping > > and then doing a reverse-lookup of the keynumber via the base symbol > > and then set the table for the keynumber. > > That sounds reasonable. We lose the flow-on effect when changing a > keylabel, but since changing keymaps is not done very often, no big deal. No really. An intelligent usermode program (and I think intelligence should go to usermode ...) could read out the whole mapping and shift it around. > > Yep. We should move that to the keymap code, unless there is specific > > reason to put it in xterm-code, e.g. because a _terminal_ has the habit > > of having some keybinding for special reactions. > > The xterm has escape codes (I assume) which changes how it handles > capslock, numlock, and probably other stuff as well. Yech. Will anyone > miss that ? I don't know, but I know I won't :). Argh ! This is mega-sick. Could you try to track them, so we can see if there is any sense in that codes ? I'd like to see what we kill before we shoot ... > > > Whilst we're on the subject of keysyms, I'd like to propose that we get > > > rid of the U() macro as well. > > Yeah. Anyone knows why this was introduced in the first place ? > Legacy of the linux code (kbd_kern.h). O.K. - shoot it down. > > > What I have in mind is to explicitly put the values of K_LEFT, K_F1, > > > K_ENTER etc. in the range 0xf000-0xffff instead of (as now) they are > > > 0x0000 - 0x0fff. We can do this by using the following in > > > ggi/keyboard.h : > > > This doesn't affect the keymaps, but it does break some code. > > > > It doesn't, if you simply keep the #define U(x) x ... > > :-) [I'd still like to see it disappear, and IMHO the easiest time to > get rid of it is NOW...] Hmm - would this work ? Dunno if you can get the warning in there this way without consequences for the source ...: #define U(x) (x)\ #warning The U() makro is useless now. rip it out ...\ > [Also some kernel code has 0xF0 hardcoded in it, but I can fix that] > Okay, is that agreed ? If so, I will do. Please do so ! CU,ANdy P.S.: I might be a bit busy to set some things on the rails (LibGGI2D and clipping etc. so ev_rc_* stuff might be a bit delayed ...). -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 06:20:11 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08903 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA07336; Wed, 14 Jan 1998 22:07:01 -0500 Resent-Date: Wed, 14 Jan 1998 22:07:01 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xse1v-0000XeC@charon.beck-sw.de> Subject: Re: keyboard API To: evstack@ontv.com Date: Thu, 15 Jan 1998 02:23:35 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980114223357.120F-100000@lidschi.wgnet> from "Matthias Grimrath" at Jan 14, 98 10:56:00 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"BYzJk.0.-n1.jqNlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/316 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > Thus KeyLabels are really just the KeySym you get when you press the key > > > _without modifiers_. So long as we have mapping tables from scancode -> > > > KeySym, we get the KeyLabels for free. > NoNoNoNoNo Please don't do it scancode -> sym -> label! A symbol may come > from various scancodes. For example, to get the symbol 'A' I may press > either the key 'A', or I hold down Alt and type 65 on the keypad. No, you got us wrong. The kernel has a table keysym[modifier][keycode]. We could derive the label from the same table by accessing keysym[0][keycode]. > Also, never assume the user configures sane symboltables ... ;-) *grin*. Yes. we will probably copy the default (compiled in) table and keep that unless explicitly overridden. > While it is hassle, there MAY be apps that want to take this into account. > Of course every program should be configurable, however, if you have to > configure it first, it is not 100% userfriendly. Playstation: Buy CD - > insert - gamble. Configuration is left for the experienced users. > > I think GGI/GII shouldn't pose limitations here. It should not. If we have the keylabel, all should be well. The manual would say up/down is on a/z and this will be the case. Whatever the keyboard looks like. If you feel uncomfortable with that mapping, you have to enter config-mode. I think this is the best default behaviour we can get. Assumptions about geometry are not good, as noone will write "the bottommost-leftmost alphanumeric key and the one above" in the manual, but they will write A/Z. And if the result really is on A/Z , even the dumbest user knows what to press. though he will be upset about it, when he has a german keyboard. Normally you then seek out for the config area. > > With configuration that easy noone would bother too much about a bad > > default. > I wouldn't bet on that. Well - the one who is annoyed about a bad default he can change easily, is probably annoyed about the colour of his neighbour's house, too ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 06:20:12 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08906 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id WAA07384; Wed, 14 Jan 1998 22:08:05 -0500 Resent-Date: Wed, 14 Jan 1998 22:08:05 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xseJJ-0000XeC@charon.beck-sw.de> Subject: Re: keyboard API To: evstack@ontv.com Date: Thu, 15 Jan 1998 02:41:33 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980114213010.120D-100000@lidschi.wgnet> from "Matthias Grimrath" at Jan 14, 98 10:32:41 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"hZsLN2.0.co1.LrNlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/317 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > ggi_event.key.sym > > ggi_event.key.code > > ggi_event.key.label > > > > The last one is the new one, the first two are the same as before. > > > > [KeySym is a bit misleading, it is more of an 'action code' which says > > "hey, do this!" such as K_DECREASE_CONS which says "hey, decrease the > > console, dude". But keeping it as 'sym' is OK with me and we don't break > > things (more than we do already :)] > > Couldn't these action code be coded into the private unicode sections? It is. It is encoded in the Unicode vendor area. > sym: unicode symbol, made from a key label (former from scancodes) Yes. > code: scan code? If so, I'd say drop it. Apps should use keylabels for > that purpose. The apps lose nothing but win portability. It is a scancode (well, a Linux unified scancode, the thing you get in mediumraw mode). The app _should_not_ use it. It is reported for backwards compatibility to old software and wrappers. > label: A standardized value that describes the key that caused this event > The actual value of the labels is not important. It's important that the > label code represents the key NOT a symbol! We should stress that very much > in the documentation. For example, american keyboards have a '{' key. Such > a key doesn't exists on a german one. (I have to press AltGr-7). The key > that generates the scancode of '{' on american keyboards is labeled with > umlaut u on my german one. So a german and an american keyboard would > generate different keylabels, though they generate the same scancode. Yes, but it is very nice, if you can deduce the symbol printed on the key from the label. And having unicode values for it seems very reasonable to do this. This is very important for configuration purposes, where you surely want to display what the user chose. > But these keylabel should never be mixed up with symbols you get from a > keymapping table. Well, there must be a table to translate scancode->label, but I'd say we can agree, that this table is used directly and the result is not influenced by modifiers and multi-key input methods. > The processing order should be scan -> label -> sym. Are you saying that? More or less yes. However I suggest to do it scan->label and scan->sym internally, as it saves the hassle of hashing back an array index from the label to address the symbol tables. In the mapping tables external representation (i.e. loadkeys input), it should be as you suggest. Two sections : 1. code->label mapping 2. label->sym mapping (with modifiers et al) In the kernel code I'd rather like to see the second table unfolded at keymap download, so it actually does code->sym, as this is much easier. > 1) Tell the system what kind of keyboard you're using. For example 'echo > setkeyboardtype german >/proc/evstack/...' This ensures correct keylabel > codes. Would mean huge tables in the kernel. I say this belongs to userspace, i.e. loadkeys should set section 1 with a big number of bind-calls. > 2) Tell the system what kind of keymapping you want. Here a user may choose > between keymaps where Caps-Lock acts like a typewriter or like a computer > terminal. > > Scancodes should never be used anymore. There'll only be a backdoor for > compatibility, and should require root priviledges. There is no sense in requiring root priviledges for informative data. It should be stated clearly that it is bad to use them and not portable. Any sensible programmer will do so, the others deserve to loose. > Of course it's possible this way, but not necessary. If DOOM would register > certain keys, these get automatically updated. This requires tables of "registered keys" ... very possible memory leak. > The code doesn't need to re-synchronize, even more it always knows > the exact state of the keys. Ahem - you do not propose an application should be able to track keys pressed/released on a foreign console, do you ? > But not that convenient. How would you code that if you'd only receive > events? I'd have a little FIFO. When I want to know about changes I'll be > looking at the time stamps. When registering a key, you also register a > FIFO that is handled by the OS, so you needn't provide your own routines. Sorry I haven't got the original issue ... What should this FIFO do ? > Not for the program, but for the user. Consider someone is moving his/her > .emacs from a SUN to the Linux PC at home. This .emacs puts info-mode on > the Help key. This key doesn't exists on PC keyboards, and Emacs cannot > even tell the user "Just to let you know, the Help key is not available > here". I wouldn't like to get flooded with such messages ... BTW: If an app wants to, it can download the keymapping tables (I think we should allow that, right ? Though no macro information ...) ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 06:20:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08909 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA06063; Wed, 14 Jan 1998 20:03:58 -0500 Resent-Date: Wed, 14 Jan 1998 20:03:58 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Rewriting display drivers & Bug Report Date: 15 Jan 1998 01:06:29 GMT Organization: OnTV Pittsburgh, L.P. Lines: 40 Distribution: local Message-ID: <69jnel$2bg$1@grits.visus.com> References: <69jivc$vbm$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"qsKzK2.0.IU1.J1Mlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/314 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jordan Mendelson (jordy@wserv.com) wrote: > Ok, given the new EvStack code, what is required for a rewrite of existing > display drivers? I noticed that the multisync driver (and basically > everything) in the drivers directory won't compile with the new evstack > code, so I was curious to know if there was some sort of change document or > a guide-to-updating-your-drivers.txt file :) Not yet - consider display drivers in flux till I can get /dev/graph working... The IBM/VGA/Fixed and Hercules/Fixed drivers should work [well.. to a point...]. the biggest change to the display drivers is the re-arrangement of the kgi_mode structure. See kgi.h for details on that. Also, the addition of a `text_operations' structure that will make it mighty easy to add graphics-based textmode. Please look it over. > Also, I noticed that when booting the recent version of evstack on my 2.1.78 > kernel that when init starts up, the screen starts to overwrite itself, this > is the same problem I had when i moved the non-evstack ggi source to 2.1.78. > Anyone know what's causing it? Whoops! 2 line change! It'll be normal by tomorrow. > One more thing, the defaults for evstack kernel won't allow anything to work > (keyboard mapper isn't turned on by default). Since I couldn't find any > help, I compiled a kernel without it and keyboard didn't respond :) Also, I just fixed the help on that. It now recommends that you turn it on. > I still need CVS access to the main repository so I can get CVS updates, I > mailed sseeger, but he hasn't gotten back to me... Be patient. Failing that, a crowbar. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 15 06:20:15 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08912 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA06271; Wed, 14 Jan 1998 20:23:25 -0500 Resent-Date: Wed, 14 Jan 1998 20:23:25 -0500 Message-Id: <m0xse3x-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keyboard API To: evstack@ontv.com Date: Thu, 15 Jan 1998 12:25:41 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xsTXn-0000XXC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 14, 98 03:11:47 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cXNNN2.0.PX1.SJMlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/315 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > Perhaps it's better to do code->label mapping separately (i.e. with its > > own map) ? If so, we would still get that mapping table pretty cheaply > > by just using the default code->sym map. > > How about simply having this associated with a "modifier-value" of "-1" > (as now 0 is none, 1 shift, ...) ? Sounds like a good idea. I guess you're saying something like this : ? key.label = map[0][key.code]; key.sym = map[1+key.effect][key.code]; ^^ > Could be done simply and without breaking much. The default map #0 > would simply get copied to a newly allocated label-map which has > binding accessed with "bind key -1 sym" ? A bit kludgey, but yeah it should work alright. > Thus having a table like > > normal shifted ctrl ALt Altgr > 2 " ?? ?? exponent_2 > q Q ^q ?? @ > > could be used by some intelligent map-loading utility in _userspace_ to > generate the right tables by first reading out the keylabel mapping > and then doing a reverse-lookup of the keynumber via the base symbol > and then set the table for the keynumber. That sounds reasonable. We lose the flow-on effect when changing a keylabel, but since changing keymaps is not done very often, no big deal. > We change nothing in kernel. We expect the keyboard driver to give us > some continuous range of keycodes. These are used to do all the > mapping. But when setting the mappings, we use the label-table to > have a fairly OS-independent way of describing the locale. Yep, that sounds good. > > The current capslock code is done in xterm.c (numlock too), but I > > don't think that's where it _should_ be done (e.g. capslock would > > have to be re-implemented for the graphical console as well ...). > > Yep. We should move that to the keymap code, unless there is specific > reason to put it in xterm-code, e.g. because a _terminal_ has the habit > of having some keybinding for special reactions. The xterm has escape codes (I assume) which changes how it handles capslock, numlock, and probably other stuff as well. Yech. Will anyone miss that ? I don't know, but I know I won't :). > > Whilst we're on the subject of keysyms, I'd like to propose that we get > > rid of the U() macro as well. It really confuses people, and there's a > > better way to do it. > > Yeah. Anyone knows why this was introduced in the first place ? > Maybe we should ask Steffen ... Legacy of the linux code (kbd_kern.h). > > What I have in mind is to explicitly put the values of K_LEFT, K_F1, > > K_ENTER etc. in the range 0xf000-0xffff instead of (as now) they are > > 0x0000 - 0x0fff. We can do this by using the following in > > ggi/keyboard.h : > > This doesn't affect the keymaps, but it does break some code. > > It doesn't, if you simply keep the #define U(x) x ... :-) [I'd still like to see it disappear, and IMHO the easiest time to get rid of it is NOW...] [Also some kernel code has 0xF0 hardcoded in it, but I can fix that] Okay, is that agreed ? If so, I will do. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 06:20:16 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08915 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id TAA05825; Wed, 14 Jan 1998 19:57:51 -0500 Resent-Date: Wed, 14 Jan 1998 19:57:51 -0500 Message-Id: <m0xsdf6-00017HC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keyboard API To: evstack@ontv.com Date: Thu, 15 Jan 1998 12:00:00 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980114213010.120D-100000@lidschi.wgnet> from "Matthias Grimrath" at Jan 14, 98 10:32:41 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"M8HeD1.0.TQ1.QxLlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/313 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Matthias Grimrath writes: > On Wed, 14 Jan 1998, Andrew Apted wrote: > > > OK, here's my critique :) [or should that be rant :)] > > I'll shoot back now :) [get your pistol ready and start walking 20 paces :)] > > [KeySym is a bit misleading, it is more of an 'action code' which says > > "hey, do this!" such as K_DECREASE_CONS which says "hey, decrease the > > console, dude". But keeping it as 'sym' is OK with me and we don't break > > things (more than we do already :)] > > Couldn't these action code be coded into the private unicode sections? IMHO > better place there among other unicode symbols. They already are -- they sit in the range 0xf000-0xffff. They're just not defined that way in ggi/keyboard.h, but we're going to fix that. > No, wait. What is the meaning of the above fields? > > sym: unicode symbol, made from a key label (former from scancodes) > code: scan code? If so, I'd say drop it. Apps should use keylabels for > that purpose. The apps lose nothing but win portability. > label: A standardized value that describes the key that caused this event That's right, but for the moment we need to keep the 'code' field for backwards compatibility. > > What I have in mind for the KeyLabel is the symbol on the > > key. For normal keys like 'A' and '1', the label is just the unicode > > value for the symbol. This handles russian keyboards and japanese > > keyboards and every other thing under the sun. [I'm assuming russian > > keyboards have russian letters on 'em, but I've never actually seen one]. > > The actual value of the labels is not important. No ? > It's important that the label code represents the key NOT a symbol! But how do you represent a 'key' then ? For normal keys like 'A' and '1', the most intuitive thing to do (IMHO) is to represent it with the symbol on the key (the _primary_ symbol). For other keys like ALT, F1, etc. we use values in the unicode private area 0xf000-0xffff. > For example, american keyboards have a '{' key. Such a key doesn't > exists on a german one. (I have to press AltGr-7). The key that > generates the scancode of '{' on american keyboards is labeled with > umlaut u on my german one. So a german and an american keyboard > would generate different keylabels, though they generate the same > scancode. Yep: same scancode, different keylabels. > Yes, I have also in mind to use unicode values for the keylabels. So I > think we agree on this point. But these keylabel should never be mixed up > with symbols you get from a keymapping table. Keylabels are the input to > the keymapping machine that generates unicode symbols + modifiers + deadkeys > as output. > > > Thus KeyLabels are really just the KeySym you get when you press the key > > _without modifiers_. > > The keylabel processing layer has no modifiers, only keys that can be > pressed and released. The term modifier doesn't exists here. Only the > label->symbol code treats certain keys as modifiers, and keeps track of > deadkeys etc. What I'm saying is that we need to get these keylabels from somewhere, and the easiest place to get 'em is the plain map of a keymap table. Keylabelling and keymapping will still be logically separate. > > So long as we have mapping tables from scancode -> KeySym, we get the > > KeyLabels for free. > > The processing order should be scan -> label -> sym. Are you saying that? Yes. > Scancodes should never be used anymore. There'll only be a backdoor for > compatibility, and should require root priviledges. Right: compatibilty. But root privs ? I don't see the need. > I think the current Linux keymapping thing is nothing but a kludge. Once I > tried to find out the symbol -> videochar mapping from userspace. The > kernelcode wasn't pretty... Yeah... EvStack will fix it !! :-) > > I think this requires applications & games to notice VtSwitchedAway > > events and act appropriately. For example DOOM would see this event and > > think to itself "hey, the user's gone away" and reset it's keyboard > > state as 'nothing pressed', it's joystick state to 'centred & no buttons > > pressed', etc. [I can just hear Duke saying "Hey, where y'goin' ?" :-)] > > > > When switched back, it can just ignore KeyRelease & ButtonRelease events > > that don't correspond to it's keyboard state (such as the F1-up ALT-up > > it would get). Or with Andy's model it will get KeyState, ValState and > > PtrState events which would bring it up-to-date. > > Of course it's possible this way, but not necessary. If DOOM would register > certain keys, these get automatically updated. The code doesn't need to > re-synchronize, even more it always knows the exact state of the keys. See > the point? You lose nothing but win functionality. The problem your approach is that it needs more _kernel_ code, kernel code to register the keys etc. This is because usermode applications don't get key events when the VT is switched away (otherwise you'd be able to get people's passwords). So when you press ALT-down F2-down to switch away, the usermode side won't see the ALT-up F2-up. That's why I'm saying that games _need_ to notice VtSwitchedAway events and act appropriately. > > > These apps often want to know about the relative change of keypresses. > > > > Well you get these for free just by looking at normal events. > > But not that convenient. How would you code that if you'd only receive > events? I'd have a little FIFO. When I want to know about changes I'll be > looking at the time stamps. When registering a key, you also register a > FIFO that is handled by the OS, so you needn't provide your own routines. Sorry, I don't follow you here. Using events is so damn easy :). > > Another interesting idea... and doable so long as libGII can read the > > keymapping table... but probably not necessary. Any program that used > > the 'STOP' key (for example) solely for a particular function wouldn't > > be very portable. And remember there's no harm in checking for keys > > that aren't there. > > Not for the program, but for the user. Consider someone is moving his/her > ...emacs from a SUN to the Linux PC at home. This .emacs puts info-mode on > the Help key. This key doesn't exists on PC keyboards, and Emacs cannot > even tell the user "Just to let you know, the Help key is not available > here". Tough luck. :) When the user gets home and can't find a help key on their keyboard, then they can reconfigure their software. Once again, its doable by looking at the keymap. If Emacs (with or without some helper lib) wants to check its keys, fine. > Of course, default configurations should only use portable keys. On the > other hand, if you have a SUN keyboard, why not use the special keys there? Yes we definitely _allow_ using the nice platform-specific keys, but hardcoding it in a program makes the program non-portable (i.e. requires editing instead of just recompilation). If its not hardcoded (i.e. configurable), then the user can just change it. And yes, default configurations should aim to be as portable as possible. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 06:20:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08917 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id SAA05026; Wed, 14 Jan 1998 18:38:08 -0500 Resent-Date: Wed, 14 Jan 1998 18:38:08 -0500 Message-Id: <199801142340.SAA20241@dew.wserv.com> From: "Jordan Mendelson" <jordy@wserv.com> To: "Evstack" <evstack@ontv.com> Subject: Rewriting display drivers & Bug Report Date: Wed, 14 Jan 1998 18:40:29 -0500 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"ZrUir3.0.2E1._mKlq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/312 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Ok, given the new EvStack code, what is required for a rewrite of existing display drivers? I noticed that the multisync driver (and basically everything) in the drivers directory won't compile with the new evstack code, so I was curious to know if there was some sort of change document or a guide-to-updating-your-drivers.txt file :) Also, I noticed that when booting the recent version of evstack on my 2.1.78 kernel that when init starts up, the screen starts to overwrite itself, this is the same problem I had when i moved the non-evstack ggi source to 2.1.78. Anyone know what's causing it? One more thing, the defaults for evstack kernel won't allow anything to work (keyboard mapper isn't turned on by default). Since I couldn't find any help, I compiled a kernel without it and keyboard didn't respond :) I still need CVS access to the main repository so I can get CVS updates, I mailed sseeger, but he hasn't gotten back to me... Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Thu Jan 15 06:20:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08920 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id QAA03963; Wed, 14 Jan 1998 16:57:23 -0500 Resent-Date: Wed, 14 Jan 1998 16:57:23 -0500 Date: Wed, 14 Jan 1998 22:56:00 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xsAF8-0000XVC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980114223357.120F-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gfAWr3.0.-y.3IJlq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/310 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > Thus KeyLabels are really just the KeySym you get when you press the key > > _without modifiers_. So long as we have mapping tables from scancode -> > > KeySym, we get the KeyLabels for free. > > Assuming the person in from of the screen is sane enough to have mapped the > unshifted meaning to the symbol on the key. I suppose we can safely do so - > right ? NoNoNoNoNo Please don't do it scancode -> sym -> label! A symbol may come from various scancodes. For example, to get the symbol 'A' I may press either the key 'A', or I hold down Alt and type 65 on the keypad. To say it mathematically: The conversion sym->label is not bijective (I hope that's the correct translation :) If I press Shift-3, I get the symbol '@' (american). You'd have to do a reverse lookup of the symbol table and get stuck when there's more than one mapping with this symbol. Also, never assume the user configures sane symboltables ... ;-) > > Musical Keyboards > > ----------------- > > Interesting idea... you could have KeySyms for C#3 etc., but just think > > of all those keys with no labels on them! :-) > *grin* > > BTW: There is more dynamics information than just how hard you press. > Some devices also sense the velocity. Mabye these are cloaked valuators > really ... OK, it was just a quick idea. Valuators and such can do the job. :) > Yes. I second that opinion. Every LibGGI application should be > configureable. PERIOD. And the good thing about the symbol solution > is that it would at least always work "as advertised". > > I.e. if someone chooses to use A/Z and say so in the docs, this is right. > Though the positioning is insane on a German keyboard. > > I too think we cannot account for any weird keyboard layout. A few examples > of available nonstandard keyboards: > > 1. SUN: A two columns of nifty window-function F-Keys at the left. Four > additional device control buttons above the keypad, Caps-lock and control > swapped, some extra sun-keys. > > 2. "Natural" keyboards: Keys that are normally very may close get about > 1-2 inch apart depending on where the "split" is. > > 3. Laptops. Often wildly folded ... Numpad in the middle (though hidden > by hardware !). Descent with movent on the keypad would be a pain there ... > > 4. Remote controls. Yes - there exist full blown keyboards in form of > remote controls. They are used for demo- and education-purposes and often > use the silly ABCDE FGHIJK ordering ... While it is hassle, there MAY be apps that want to take this into account. Of course every program should be configurable, however, if you have to configure it first, it is not 100% userfriendly. Playstation: Buy CD - insert - gamble. Configuration is left for the experienced users. I think GGI/GII shouldn't pose limitations here. Well, it has low priority for me, so I won't insists on anything. > > > the function 'IsKeyAvailable()' checks for the presence of a key in > > > question. > > Another interesting idea... and doable so long as libGII can read the > > keymapping table... but probably not necessary. Any program that used > > the 'STOP' key (for example) solely for a particular function wouldn't > > be very portable. And remember there's no harm in checking for keys > > that aren't there. > > Yep. Think so, too. Most of the arguments here are the cause for having > LibGII. Hope I can finally talk someone into finishing that. See my other mail. > With configuration that easy noone would bother too much about a bad > default. I wouldn't bet on that. Matthias Grimrath From evstack-request@ontv.com Thu Jan 15 06:20:19 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (root@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA08924 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 06:20:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id QAA03968; Wed, 14 Jan 1998 16:57:31 -0500 Resent-Date: Wed, 14 Jan 1998 16:57:31 -0500 Date: Wed, 14 Jan 1998 22:32:41 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xs7CT-00017HC@ajax> Message-ID: <Pine.LNX.3.96.980114213010.120D-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"zaXMY.0.Dz.8IJlq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/311 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 14 Jan 1998, Andrew Apted wrote: > OK, here's my critique :) [or should that be rant :)] I'll shoot back now :) > ggi_event.key.sym > ggi_event.key.code > ggi_event.key.label > > The last one is the new one, the first two are the same as before. > > [KeySym is a bit misleading, it is more of an 'action code' which says > "hey, do this!" such as K_DECREASE_CONS which says "hey, decrease the > console, dude". But keeping it as 'sym' is OK with me and we don't break > things (more than we do already :)] Couldn't these action code be coded into the private unicode sections? IMHO better place there among other unicode symbols. No, wait. What is the meaning of the above fields? sym: unicode symbol, made from a key label (former from scancodes) code: scan code? If so, I'd say drop it. Apps should use keylabels for that purpose. The apps lose nothing but win portability. label: A standardized value that describes the key that caused this event > > These keylabel are somewhat unified scancodes > > Not really. What I have in mind for the KeyLabel is the symbol on the > key. For normal keys like 'A' and '1', the label is just the unicode > value for the symbol. This handles russian keyboards and japanese > keyboards and every other thing under the sun. [I'm assuming russian > keyboards have russian letters on 'em, but I've never actually seen one]. The actual value of the labels is not important. It's important that the label code represents the key NOT a symbol! We should stress that very much in the documentation. For example, american keyboards have a '{' key. Such a key doesn't exists on a german one. (I have to press AltGr-7). The key that generates the scancode of '{' on american keyboards is labeled with umlaut u on my german one. So a german and an american keyboard would generate different keylabels, though they generate the same scancode. Yes, I have also in mind to use unicode values for the keylabels. So I think we agree on this point. But these keylabel should never be mixed up with symbols you get from a keymapping table. Keylabels are the input to the keymapping machine that generates unicode symbols + modifiers + deadkeys as output. That's why I say "unified scancodes". > Thus KeyLabels are really just the KeySym you get when you press the key > _without modifiers_. The keylabel processing layer has no modifiers, only keys that can be pressed and released. The term modifier doesn't exists here. Only the label->symbol code treats certain keys as modifiers, and keeps track of deadkeys etc. > So long as we have mapping tables from scancode -> KeySym, we get the > KeyLabels for free. The processing order should be scan -> label -> sym. Are you saying that? I imagine this configuration steps: 1) Tell the system what kind of keyboard you're using. For example 'echo setkeyboardtype german >/proc/evstack/...' This ensures correct keylabel codes. 2) Tell the system what kind of keymapping you want. Here a user may choose between keymaps where Caps-Lock acts like a typewriter or like a computer terminal. Scancodes should never be used anymore. There'll only be a backdoor for compatibility, and should require root priviledges. > [Note that the normal linux kernel puts Latin1 letters in the > 'Linux-Zone' as well (0xf000-0xfbff), which looks like a massive kludge > to me. E.g. KT_LETTER is there just to make capslock easy to > implement... tough luck if you want capslock to work with a russian > keyboard for example...] I think the current Linux keymapping thing is nothing but a kludge. Once I tried to find out the symbol -> videochar mapping from userspace. The kernelcode wasn't pretty... > Musical Keyboards > ----------------- > > Interesting idea... you could have KeySyms for C#3 etc., but just think > of all those keys with no labels on them! :-) Maybe some private area. No, I'm not attempting to invent an API for all musical keyboards... I'm not a musician :) > Hmmm, while determining the position of a key pressed/release is doable, > it is not doable easily. The problems are : > > - we would need to make up tables for each keyboard, since we > can't just glean the position information from the scancode or > keysym. [I think X has some stuff on this, but I don't know > how we'd go using it...] > > - it's not easy to encode the position in 8 bits, and darn near > imposible in 7, and end up with something _standard_. Some > keyboards have 34 functions keys for example. And specifing > the position in millimeters is, well, silly. > > So IMHO it's not worth it. [too much pain for too little gain :)] IIRC XFree have some vector files that describes various keyboards. I think 'xkeycaps' uses this data to draw a keyboard layout in a window. So it is possible, though not easy. > I think this requires applications & games to notice VtSwitchedAway > events and act appropriately. For example DOOM would see this event and > think to itself "hey, the user's gone away" and reset it's keyboard > state as 'nothing pressed', it's joystick state to 'centred & no buttons > pressed', etc. [I can just hear Duke saying "Hey, where y'goin' ?" :-)] > > When switched back, it can just ignore KeyRelease & ButtonRelease events > that don't correspond to it's keyboard state (such as the F1-up ALT-up > it would get). Or with Andy's model it will get KeyState, ValState and > PtrState events which would bring it up-to-date. Of course it's possible this way, but not necessary. If DOOM would register certain keys, these get automatically updated. The code doesn't need to re-synchronize, even more it always knows the exact state of the keys. See the point? You lose nothing but win functionality. I don't say to remove any events or signals. DOOM would still receive Vtswitchaway/to, keylabel and symbol events, so Duke may yell "Come back, I wanna fry these aliens" :) > > These apps often want to know about the relative change of keypresses. > > Well you get these for free just by looking at normal events. But not that convenient. How would you code that if you'd only receive events? I'd have a little FIFO. When I want to know about changes I'll be looking at the time stamps. When registering a key, you also register a FIFO that is handled by the OS, so you needn't provide your own routines. > > the function 'IsKeyAvailable()' checks for the presence of a key in > > question. > > Another interesting idea... and doable so long as libGII can read the > keymapping table... but probably not necessary. Any program that used > the 'STOP' key (for example) solely for a particular function wouldn't > be very portable. And remember there's no harm in checking for keys > that aren't there. Not for the program, but for the user. Consider someone is moving his/her .emacs from a SUN to the Linux PC at home. This .emacs puts info-mode on the Help key. This key doesn't exists on PC keyboards, and Emacs cannot even tell the user "Just to let you know, the Help key is not available here". Of course, default configurations should only use portable keys. On the other hand, if you have a SUN keyboard, why not use the special keys there? It's more a userfriendlyness function I have to admit, still IMHO useful and not expensive. (A linear search in the keylabel mapping table is sufficient) Matthias Grimrath From evstack-request@ontv.com Thu Jan 15 12:23:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA09233 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 11:12:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id NAA18070; Thu, 15 Jan 1998 13:33:11 -0500 Resent-Date: Thu, 15 Jan 1998 13:33:11 -0500 Date: Thu, 15 Jan 1998 11:44:21 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xsFYo-0000XXC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980115114251.2376H-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"kjZIP.0.QP4.rNblq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/321 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 14 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > I use a 2.1.78 kernel and my keyboard works, But to get my keyboard working > > > > with 77-78 I had to compile the keyboard-mapping(or what it was called) > > > > into the kernel and not as a module. > > > *grin* Anybody tried to insert it as module ? I'd really be interested in > > > what happens ... > > > > Unresolved symbols: > > show_mem > > ctrl_alt_del > > show_state > > > > *sigh*.... entering this through telnet.... > > Someone forget to EXPORT something? :) > > Probably. Comment out the references and recompile the module. Nothing bad > will happen. These should be changed anyway. The keymap module was not really > intended for being modularized ... I recompiled into the kernel.... XFree86 has no keyboard... (or mouse - but I haven't figured out how to install the sermouse driver... or even where it is yet) But other apps (including svgalib ones) all seem to work. This connected with the lack of raw keyboard access? Perhaps there's a way to emulate it... *grin*. You know, for backwards compatibility. G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 15 12:55:28 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA09447 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 12:55:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.5/8.7.3) id UAA00532; Thu, 15 Jan 1998 20:21:17 GMT Resent-Date: Thu, 15 Jan 1998 20:21:17 GMT Date: Thu, 15 Jan 1998 13:05:09 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: Rewriting display drivers & Bug Report In-Reply-To: <69l2l1$q3$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980115130342.7294B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"s-YO33.0.P7.qzclq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/322 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 15 Jan 1998, Jason McMullan wrote: > Jason McMullan (jmcc@beans.visus.com) wrote: > > Jordan Mendelson (jordy@wserv.com) wrote: > > > Also, I noticed that when booting the recent version of evstack on my 2.1.78 > > > kernel that when init starts up, the screen starts to overwrite itself, this > > > is the same problem I had when i moved the non-evstack ggi source to 2.1.78. > > > Anyone know what's causing it? > > > Whoops! 2 line change! It'll be normal by tomorrow. > > [Replying to myself] Hmm... Now that I look at the code > again, I remember what's up: > > Printk writes _directly_ to the scroll_* interface, > bypassing any loaded (or possibly dead) terminal > stack. > > The XTerm stack has it's own idea of where the > cursor is, and always draws text at absolute > coordinates. > > Both of these are rational decisions, given our model, > and the only solution I see to get back the old printk > behaviour would be to have the XTerm stack query the > cursor position at every write, and respect it. This, > granted, would slow down XTerm. > > I don't think it's worth the effort - any one have any > other ideas? Ummm.... broadcasting cursor-change events somewhere where both can follow? I'd suspect this'd be a good idea - especially for those strange people who are implementing consoles in userspace *grin*.... I'd rather not have my graphic display mucked up by printk. or xterm for that matter. G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 15 15:18:06 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA00442 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 15:18:05 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA05253; Thu, 15 Jan 1998 22:44:52 GMT Resent-Date: Thu, 15 Jan 1998 22:44:52 GMT From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xsx7n-0000XgC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Thu, 15 Jan 1998 22:46:54 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980115114251.2376H-100000@sigil.computersupportcentre.com> from "teunis" at Jan 15, 98 11:44:21 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"-qc-T1.0.bH1.k4flq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/323 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Probably. Comment out the references and recompile the module. Nothing bad > > will happen. These should be changed anyway. The keymap module was not really > > intended for being modularized ... > > I recompiled into the kernel.... > XFree86 has no keyboard... (or mouse - but I haven't figured out how to > install the sermouse driver... or even where it is yet) > But other apps (including svgalib ones) all seem to work. > > This connected with the lack of raw keyboard access? Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. Mediumraw would be easy, because this is in the keycode field ... > Perhaps there's a way to emulate it... *grin*. You know, for backwards > compatibility. There must ... wanna code that ? CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 16:41:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA00538 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 16:41:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA00891; Thu, 15 Jan 1998 19:07:59 -0500 Resent-Date: Thu, 15 Jan 1998 19:07:59 -0500 Message-Id: <m0xszIz-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Rewriting display drivers & Bug Report To: evstack@ontv.com Date: Fri, 16 Jan 1998 11:06:37 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69l2l1$q3$1@grits.visus.com> from "Jason McMullan" at Jan 15, 98 01:23:45 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"iXliC1.0.OD.jIglq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/324 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Jason McMullan (jmcc@beans.visus.com) wrote: > > Jordan Mendelson (jordy@wserv.com) wrote: > > > Also, I noticed that when booting the recent version of evstack > > > on my 2.1.78 kernel that when init starts up, the screen starts > > > to overwrite itself, this is the same problem I had when i moved > > > the non-evstack ggi source to 2.1.78. Anyone know what's causing > > > it? I thought this was a clear-screen problem. When a tty is first open()'d or last close()'d, the display should be cleared, but this clearing just hasn't been implemented yet. Right ? > > Whoops! 2 line change! It'll be normal by tomorrow. > > [Replying to myself] Hmm... Now that I look at the code > again, I remember what's up: > > Printk writes _directly_ to the scroll_* interface, > bypassing any loaded (or possibly dead) terminal > stack. > > The XTerm stack has it's own idea of where the > cursor is, and always draws text at absolute > coordinates. > > Both of these are rational decisions, given our model, > and the only solution I see to get back the old printk > behaviour would be to have the XTerm stack query the > cursor position at every write, and respect it. This, > granted, would slow down XTerm. > > I don't think it's worth the effort - any one have any > other ideas? I also think it's not worth the effort to synchronize the cursors. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 16:47:58 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA00546 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 16:47:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA00980; Thu, 15 Jan 1998 19:14:38 -0500 Resent-Date: Thu, 15 Jan 1998 19:14:38 -0500 Message-Id: <m0xszPi-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 11:13:34 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xsx7n-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 15, 98 10:46:54 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YnLyC3.0.tE.xOglq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/325 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > Mediumraw would be easy, because this is in the keycode field ... Are you sure X isn't happy with keycodes ? They are pretty raw after all, and still 7 bit. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 19:44:06 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA00636 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 19:44:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA02241; Thu, 15 Jan 1998 22:10:15 -0500 Resent-Date: Thu, 15 Jan 1998 22:10:15 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xt10c-0000XgC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 02:55:46 +0100 (MET) In-Reply-To: <m0xszPi-00017IC@ajax> from "Andrew Apted" at Jan 16, 98 11:13:34 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"rhn3q2.0.VY.Mzilq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/326 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > Mediumraw would be easy, because this is in the keycode field ... > Are you sure X isn't happy with keycodes ? They are pretty raw after > all, and still 7 bit. Yep. Have traced it. I might have made a mistake while looking up the ioctl value, but I don't think so. To double check, simply start traditional X with strace, grep out the ioctls and find the KDSKBMODE calls. #define K_RAW 0x00 #define K_XLATE 0x01 #define K_MEDIUMRAW 0x02 #define K_UNICODE 0x03 #define KDGKBMODE 0x4B44 /* gets current keyboard mode */ #define KDSKBMODE 0x4B45 /* sets current keyboard mode */ Cu,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Thu Jan 15 23:36:23 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA00862 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 23:36:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA04327; Fri, 16 Jan 1998 02:02:14 -0500 Resent-Date: Fri, 16 Jan 1998 02:02:14 -0500 Message-Id: <m0xt5mI-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 18:01:18 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xt10c-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 16, 98 02:55:46 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"X2x_Y.0.Y21.ANmlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/327 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > > Mediumraw would be easy, because this is in the keycode field ... > > Are you sure X isn't happy with keycodes ? They are pretty raw after > > all, and still 7 bit. > Yep. Have traced it. I might have made a mistake while looking up the > ioctl value, but I don't think so. To double check, simply start traditional > X with strace, grep out the ioctls and find the KDSKBMODE calls. Oh... Not good... I got the impression that X used MEDIUM_RAW when I saw this in the kernel source: /* * Translation of escaped scancodes to keycodes. * This is now user-settable. * The keycodes 1-88,96-111,119 are fairly standard, and * should probably not be changed - changing might confuse X. * X also interprets scancode 0x5d (KEY_Begin). * * For 1-88 keycode equals scancode. */ I might try feeding it keycodes and see what happens (after all, the E0 XX codes are just IBM specific). Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 15 23:54:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA00874 for <ggi@synergy.foo.net>; Thu, 15 Jan 1998 23:54:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA04459; Fri, 16 Jan 1998 02:21:23 -0500 Resent-Date: Fri, 16 Jan 1998 02:21:23 -0500 Message-Id: <m0xt656-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: no more U() To: evstack@ontv.com Date: Fri, 16 Jan 1998 18:20:43 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"E-0cn2.0.551.Hfmlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/328 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Yes folks, it's really true I've gone and got rid of U [Sorry, could't resist :-D] I've removed the U() macro from the kernel sources and made values like K_ENTER etc. in keyboard.h have the proper value (i.e. 0xf201). The U() macro now does absolutely nothing. > > The xterm has escape codes (I assume) which changes how it handles > > capslock, numlock, and probably other stuff as well. Yech. Will anyone > > miss that ? I don't know, but I know I won't :). > > Argh ! This is mega-sick. Could you try to track them, so we can see if there > is any sense in that codes ? I'd like to see what we kill before we shoot ... For capslock, there are two keysyms that can be put in a keymap: K_CAPS : acts like normal capslock. K_CAPSON : is the sticky version. For numlock, there are also two keysyms that can be put in a keymap: K_BARENUMLOCK : acts like normal numlock K_NUM : depending upon the 'applic_key' flag, either acts like a normal numlock, or sends an xterm-specific escape sequence. And the keypad also behaves differently depending upon this 'applic_key' flag: when off, it's normal (digits or cursor/func), but when on, it sends xterm-specific escape sequences. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 00:16:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA00908 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 00:16:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA04570; Fri, 16 Jan 1998 02:43:15 -0500 Resent-Date: Fri, 16 Jan 1998 02:43:15 -0500 Message-Id: <199801160743.CAA15170@dew.wserv.com> From: "Jordan Mendelson" <jordy@wserv.com> To: "Evstack" <evstack@ontv.com> Subject: Today's Snapshot (1/16/98) Date: Fri, 16 Jan 1998 02:42:27 -0500 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"E7QHP2.0.z61.yzmlq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/329 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Just updated source tree, but the changes to the patch-2.1.77 file break it (error about garbled patch and it craps out on my 2.1.78 kernel). Could you rediff and commit? Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Fri Jan 16 00:25:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA00913 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 00:25:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA04644; Fri, 16 Jan 1998 02:52:16 -0500 Resent-Date: Fri, 16 Jan 1998 02:52:16 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: /dev/graph functional! Date: 16 Jan 1998 07:51:47 GMT Organization: OnTV Pittsburgh, L.P. Lines: 40 Message-ID: <69n3ij$j69$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"-v7EM1.0.481.H6nlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/330 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Here's the scoop on /dev/graph: (- = bad news, + = good news) +) Will properly set _any_ graphics mode your KGI display driver supports! +) MMAP is _fully_ functional! +) libGGI works with /dev/graph _UNMODIFIED_! +) SAK works! +) You can insert/remove a display modules EVEN IF A GRAPHICS APP IS USING IT! (This will require catching SIGWINCH to _fully_ use this capability in libGGI, but we can now write `Does this driver work for you?' apps using GRAPHICS MODE! We can make X servers that you can `upgrade' the display driver WITHOUT LEAVING X!) -) Must be compiled into the kernel. There's some sort of initialization bug when used as a module. -) Font setting does _not_ properly occur on mode switch. -) The console_* code isn't properly setting the mode when you switch-back to a graphics VT -) The `event' reporting feature of /dev/graph is (currently?) removed. We will be using /dev/event in the future - right? Now, I want everyone (that likes to trash their hard drives with Alpha-level code) to get this and FIND THOSE BUGS! Also, do we have anybody that likes writing documentation on the list? I need someone to write up a `KGI change document' that describes how to re-write 0.0.9 drivers as GGI-0.1.0 drivers. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 00:41:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA00996 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 00:41:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA04879; Fri, 16 Jan 1998 03:08:38 -0500 Resent-Date: Fri, 16 Jan 1998 03:08:38 -0500 Message-ID: <001301bd2255$cd705ea0$0c0a0a0a@massacre> From: "David Waite" <davewait@freenet.tlh.fl.us> To: <evstack@ontv.com> Subject: Re: /dev/graph functional! Date: Fri, 16 Jan 1998 03:07:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"kaKMo2.0.kB1.ZLnlq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/331 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > +) You can insert/remove a display modules EVEN IF > A GRAPHICS APP IS USING IT! (This will require > catching SIGWINCH to _fully_ use this capability > in libGGI, but we can now write `Does this driver > work for you?' apps using GRAPHICS MODE! We can > make X servers that you can `upgrade' the display > driver WITHOUT LEAVING X!) > Wait, so if I have two video cards in my computer in a multihead mode, could I move X from one to another? /me imagines a cool 3x3 grid of monitors all switching pictures like those old sliding tile puzzles... > Now, I want everyone (that likes to trash their hard drives >with Alpha-level code) to get this and FIND THOSE BUGS! > <grin> no problem, my harddrive for some reason keeps trashing itself on its own ;) > Also, do we have anybody that likes writing documentation >on the list? I need someone to write up a `KGI change document' >that describes how to re-write 0.0.9 drivers as GGI-0.1.0 >drivers. > I would actually like to do this.. I am not versed in either the changes in evstacks/ggi or in how evstacks works in itself.. right now I'm finishing up an IBM Ramdac/clock driver for 0.0.9, after I get it working there I think some docu writing would be a nice change (better docs woulda made my job a heck of a lot easier) This is great news though.. btw I tried out evstacks last night (on 2.1.79), I must admit that it makes the whole project look more 'polished' as a whole.. I loved how so much of it could be compiled modularly.. the first thing I thought was "wow! this is incredible! I wonder how much of it really is functional?" ;) Anyways, if nobody else is jumping the gun to write the documentation, I'd be happy to do it (although I tend more towards HTML and .ps/.pdf formats, someone else may want to convert it to a normal text format afterwards). -David Waite From evstack-request@ontv.com Fri Jan 16 03:08:21 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA01134 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 03:08:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA05852; Fri, 16 Jan 1998 05:34:57 -0500 Resent-Date: Fri, 16 Jan 1998 05:34:57 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/graph functional! Date: 16 Jan 1998 10:34:15 GMT Organization: OnTV Pittsburgh, L.P. Lines: 59 Distribution: local Message-ID: <69nd37$obs$1@grits.visus.com> References: <69n4ug$k2m$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"ERDEq3.0.tQ1.ZUplq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/332 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com David Waite (davewait@freenet.tlh.fl.us) wrote: > > +) You can insert/remove a display modules EVEN IF > > A GRAPHICS APP IS USING IT! (This will require > > catching SIGWINCH to _fully_ use this capability > > in libGGI, but we can now write `Does this driver > > work for you?' apps using GRAPHICS MODE! We can > > make X servers that you can `upgrade' the display > > driver WITHOUT LEAVING X!) > > > Wait, so if I have two video cards in my computer in a multihead mode, could > I move X from one to another? In a word, yes. libGGI will need a smidgen of support, the X server can't be using DirectBuffer [maybe..] and (in all probablility) the new card must support at LEAST the virtual x/y in the original pixel format, but that's about it. > /me imagines a cool 3x3 grid of monitors all switching pictures like those > old sliding tile puzzles... Neat! > > Also, do we have anybody that likes writing documentation > >on the list? I need someone to write up a `KGI change document' > >that describes how to re-write 0.0.9 drivers as GGI-0.1.0 > >drivers. > > > I would actually like to do this.. I am not versed in either the changes in > evstacks/ggi or in how evstacks works in itself.. right now I'm finishing up > an IBM Ramdac/clock driver for 0.0.9, after I get it working there I think > some docu writing would be a nice change (better docs woulda made my job a > heck of a lot easier) Excellent! If you don't understand _anything_, please ask me - I like good documentation, but the docs I write tend to be pretty terse... > This is great news though.. btw I tried out evstacks last night (on 2.1.79), > I must admit that it makes the whole project look more 'polished' as a > whole.. I loved how so much of it could be compiled modularly.. the first > thing I thought was "wow! this is incredible! I wonder how much of it really > is functional?" ;) Most of it. Hehe... Now that /dev/graph is functional (most of the `bugs' I reported seem to be related to the IBM/VGA driver specifically...) things should proceed at a faster pace... > Anyways, if nobody else is jumping the gun to write the documentation, I'd > be happy to do it (although I tend more towards HTML and .ps/.pdf formats, > someone else may want to convert it to a normal text format afterwards). I know not to look a gift horse in the mouth, but have you looked at the Linux-SGML tools? The format is _very_ similar to HTML, and can be used to automatically generate HTML/ps/TeX/etc documents. Just a thought. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 03:54:02 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA01151 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 03:54:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06246; Fri, 16 Jan 1998 06:20:44 -0500 Resent-Date: Fri, 16 Jan 1998 06:20:44 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtAWB-0000XgC@charon.beck-sw.de> Subject: Re: no more U() To: evstack@ontv.com Date: Fri, 16 Jan 1998 13:04:59 +0100 (MET) In-Reply-To: <m0xt656-00017IC@ajax> from "Andrew Apted" at Jan 16, 98 06:20:43 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"BBWta1.0.yV1.g8qlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/333 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > The xterm has escape codes (I assume) which changes how it handles > > > capslock, numlock, and probably other stuff as well. Yech. Will anyone > > > miss that ? I don't know, but I know I won't :). > > Argh ! This is mega-sick. Could you try to track them, so we can see if there > > is any sense in that codes ? I'd like to see what we kill before we shoot ... > > For capslock, there are two keysyms that can be put in a keymap: > > K_CAPS : acts like normal capslock. > K_CAPSON : is the sticky version. > > For numlock, there are also two keysyms that can be put in a keymap: > > K_BARENUMLOCK : acts like normal numlock > K_NUM : depending upon the 'applic_key' flag, either acts > like a normal numlock, or sends an xterm-specific > escape sequence. Hmm - who send the sequence at last ? Xterm-code I hope ? For such cases, I'd say to the "default thing" in the keymap handler, and if some terminal wants to override the behaviour, it should send "compensation events" to the keymapper and send its emulation events onward. CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 03:54:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA01155 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 03:54:13 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06224; Fri, 16 Jan 1998 06:20:22 -0500 Resent-Date: Fri, 16 Jan 1998 06:20:22 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtATX-0000XgC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 13:02:14 +0100 (MET) In-Reply-To: <m0xt5mI-00017IC@ajax> from "Andrew Apted" at Jan 16, 98 06:01:18 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"H-Pmx2.0.KW1.r8qlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/334 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > Oh... Not good... Hmm - just re-checked: charon:/# strace X 2>bla charon:/# grep "ioctl.*KBMODE" bla | less ioctl(3, KDGKBMODE, 0x81497c0) = 0 ioctl(3, KDSKBMODE, 0) = 0 ioctl(3, KDSKBMODE, 0x1) = 0 With : #define K_RAW 0x00 #define K_XLATE 0x01 #define K_MEDIUMRAW 0x02 #define K_UNICODE 0x03 #define KDGKBMODE 0x4B44 /* gets current keyboard mode */ #define KDSKBMODE 0x4B45 /* sets current keyboard mode */ > I got the impression that X used MEDIUM_RAW when I saw this in the > kernel source: It really should. Everything else is sick. > I might try feeding it keycodes and see what happens (after all, the > E0 XX codes are just IBM specific). Should give at least a bit of keyboard. Better than nothing. We'll probably need a fixed table in an emulation module that does keycode-> E0XX sequence mapping ... sick ... CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 04:01:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA01164 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 04:01:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06351; Fri, 16 Jan 1998 06:28:12 -0500 Resent-Date: Fri, 16 Jan 1998 06:28:12 -0500 Message-Id: <199801161129.GAA13203@beans.visus.com> Subject: Re: Future( Was: GGI_AUTO w/ GGI wrapper for X) To: davewait@freenet.tlh.fl.us (David Waite) Date: Fri, 16 Jan 1998 06:29:17 -0500 (EST) Cc: evstack@ontv.com, linux-ggi@eskimo.com Reply-To: jmcc@ontv.com In-Reply-To: <008901bd2243$065db680$0c0a0a0a@massacre> from "David Waite" at Jan 16, 98 00:53:03 am From: Jason McMullan <jmcc@ontv.com> Content-Type: text Resent-Message-ID: <"hmgIt1.0.ZY1.vFqlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/335 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com 'David Waite wrote with particular insight...' > I would say the next release should be 0.1.0 (or some other similar # > implying a not ready product), and we should at that point have the KGI > /Evstacks stuff in the 2.3 kernel, and a seperate package for libggi/etc. Sounds like what I've been thinking... > I'd say our goal should be to try to have the kgi/evstacks code good enough > to get into the 2.3.xx kernels right away (perhaps semi-stable 2.2.xx > patches before). We should be able to get to that level of stability in ~2 weeks, IF: a) The recoding of the event layer proceeds normally b) Someone can attach the `global keymap' problem (it needs to be 1 per input device, and an instace per VT) c) We can sic someone on the RAW keyboard problem. d) I can kill the few rmaining bugs in /dev/graph, and make the minor patches needed to libGGI. > Libggi and company need to be standardized and out the door as soon as > possible. They can be beta, but they need to be set in stone. libGGI is `alpha' right now - the design SEEMS to be working, but we're just now starting to get developers for it. libGGI will be engraved in stone for Degas. > Same with the > KGI modules.. there needs to be a *solid* standard for this, so that we can > start encouraging people to make KGI drivers for cards (I've heard Daryll > Strauss is interested in making binary drivers for all of the 3Dfx chips, > and heard someone else is interested in a NV1 and Riva 128 driver).. people > won't put effort into writing a driver when the standard keeps changing.. > luckily with evstacks going in, we have a chance of making everything really > close to *right*. I'm waiting for AT LEAST TWO cards to successfuly use the Accel Ping-Pong buffers. Until then, we should consider the KGI driver to be `in flux'. I hate to say that, but I don't want to be burdened by a bad driver standard because we didn't wait a week or two... When we have AT LEAST TWO cards that support Accel Ping-Pong, I'm going to start working with the Documentation Crew here on the list (Willie, you listening?) to create a `KGI DDK' that will contain NON-GPL driver sources (see below), complete documentation (ie, you won't need the sources NON-GPL sources to use it), and the `KGI Binary Driver Spec' - [which will be a .o file, with certain restrictions on what symbols you can expect to be externally defined]. The KGI DDK _must_ be freely downloadable. A printed version produced for sale _must_ include the URL at which to get the downloadable version. [Ie, GPLed documentation]. I don't want to impose any `cost limit' on the printed documentation. Someone, somewhere, has to eat, eh? For the sources, I'm planning to change the Copyright of the IBM/VGA chipset, ramdac, graphic driver, fixed VGA monitor, Multisync VGA monitor, and libGGI vendor/IBM/vga_* code to something like the BSD license, except that `Derived from sources available at http://???' will be the required `emitted copyright'. Anyone object? > P.S. The Evstacks stuff looks *extremely* promising. I haven't really looked > at the code yet, but it made everything feel 'official' and refined, even as > a beta.. it made it all seem like it belonged there. A few people have said that on linux-kernel also... Looks good for us.. It's almost time for `Zeus to spring from the head of Titan, fully formed'... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 04:05:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA01179 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 04:05:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06453; Fri, 16 Jan 1998 06:31:42 -0500 Resent-Date: Fri, 16 Jan 1998 06:31:42 -0500 Message-Id: <m0xt9xx-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/graph functional! To: evstack@ontv.com Date: Fri, 16 Jan 1998 22:29:37 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69n3ij$j69$1@grits.visus.com> from "Jason McMullan" at Jan 16, 98 07:51:47 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KIGd32.0.6a1.6Jqlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/336 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Here's the scoop on /dev/graph: > > (- = bad news, + = good news) > > +) Will properly set _any_ graphics mode your KGI display > driver supports! > +) MMAP is _fully_ functional! > +) libGGI works with /dev/graph _UNMODIFIED_! > +) SAK works! > +) You can insert/remove a display modules EVEN IF > A GRAPHICS APP IS USING IT! (This will require > catching SIGWINCH to _fully_ use this capability > in libGGI, but we can now write `Does this driver > work for you?' apps using GRAPHICS MODE! We can > make X servers that you can `upgrade' the display > driver WITHOUT LEAVING X!) Congrats!! > -) The `event' reporting feature of /dev/graph is > (currently?) removed. We will be using /dev/event > in the future - right? I would say so. I see it working like this: devevent is an evstack device instead of a class. Doing an open("/dev/event") creates an instance stack and attaches it to the appropriate termstack, _before_ the xterm stack so it steals the events. How does that sound ? > Now, I want everyone (that likes to trash their hard drives > with Alpha-level code) to get this and FIND THOSE BUGS! Will do! Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 04:19:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA01212 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 04:19:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06567; Fri, 16 Jan 1998 06:46:19 -0500 Resent-Date: Fri, 16 Jan 1998 06:46:19 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@beans.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/graph functional! Date: 16 Jan 1998 11:45:26 GMT Organization: OnTV Pittsburgh, L.P. Lines: 22 Distribution: local Message-ID: <69nh8m$rj6$1@grits.visus.com> References: <69nglh$rfg$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"Qng-02.0.3c1.IXqlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/337 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > Jason McMullan writes: > > -) The `event' reporting feature of /dev/graph is > > (currently?) removed. We will be using /dev/event > > in the future - right? > I would say so. I see it working like this: devevent is an evstack > device instead of a class. Doing an open("/dev/event") creates an > instance stack and attaches it to the appropriate termstack, _before_ > the xterm stack so it steals the events. How does that sound ? Sounds Ok. Just hit SAK if your program crashes, right ?;^) Seriously, maybe /dev/event should just COPY the events that are coming from input_stack, so that ^C and friends will work. You can always stty the terminal not to display input... We might as well be on the safe side... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 04:31:09 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA01221 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 04:31:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA06670; Fri, 16 Jan 1998 06:57:51 -0500 Resent-Date: Fri, 16 Jan 1998 06:57:51 -0500 Message-Id: <m0xtANn-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 22:56:19 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtATX-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 16, 98 01:02:14 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"d2XKu3.0.ad1.yhqlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/338 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > Hmm - just re-checked: > > charon:/# strace X 2>bla > charon:/# grep "ioctl.*KBMODE" bla | less > ioctl(3, KDGKBMODE, 0x81497c0) = 0 > ioctl(3, KDSKBMODE, 0) = 0 > ioctl(3, KDSKBMODE, 0x1) = 0 > > With : > > #define K_RAW 0x00 > #define K_XLATE 0x01 > #define K_MEDIUMRAW 0x02 > #define K_UNICODE 0x03 > #define KDGKBMODE 0x4B44 /* gets current keyboard mode */ > #define KDSKBMODE 0x4B45 /* sets current keyboard mode */ Drat! > > I got the impression that X used MEDIUM_RAW when I saw this in the > > kernel source: > > It really should. Everything else is sick. > > > I might try feeding it keycodes and see what happens (after all, the > > E0 XX codes are just IBM specific). > > Should give at least a bit of keyboard. Better than nothing. It did work, and most of the keyboard works, including the function keys. What doesn't work is the E0XX keys such as the cursor block. I've looked through all the 'lib/X11/xkb' stuff, and there is NO mention of 'E0' or something like it anywhere. I have this nasty suspicion that XFree has its own E0 table _hardcoded_ in it... > We'll probably need a fixed table in an emulation module that does > keycode-> E0XX sequence mapping ... sick ... It's looking that way... Ouch! Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 04:52:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA01247 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 04:52:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA06934; Fri, 16 Jan 1998 07:18:48 -0500 Resent-Date: Fri, 16 Jan 1998 07:18:48 -0500 Message-Id: <m0xtAhj-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Capslock & Numlock To: evstack@ontv.com Date: Fri, 16 Jan 1998 23:16:55 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtAWB-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 16, 98 01:04:59 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"V1oYI1.0.ih1.M_qlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/339 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > For capslock, there are two keysyms that can be put in a keymap: > > > > K_CAPS : acts like normal capslock. > > K_CAPSON : is the sticky version. > > > > For numlock, there are also two keysyms that can be put in a keymap: > > > > K_BARENUMLOCK : acts like normal numlock > > K_NUM : depending upon the 'applic_key' flag, either acts > > like a normal numlock, or sends an xterm-specific > > escape sequence. > > Hmm - who send the sequence at last ? Xterm-code I hope ? Yes, this capslocking and numlocking is done in xterm.c. > For such cases, I'd say to the "default thing" in the keymap handler, and > if some terminal wants to override the behaviour, it should send > "compensation events" to the keymapper and send its emulation events onward. Capslock can definitely be moved to the VT-specific keymapper (or the global one for those who'd prefer it). As for numlock and the keypad keys, if we assume that keymapping the keypad keys (in the keymapper) only changes the keysym in the event, then the terminal can notice that keys come from the keypad by looking at the _label_ field, and can swallow/override them at will (e.g. to send terminal specific sequences). [also we might exclude numlock, just so that the terminal doesn't haven't to compensate for the numlock led going on/off/on/off...] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 05:19:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA01283 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 05:19:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA07084; Fri, 16 Jan 1998 07:45:01 -0500 Resent-Date: Fri, 16 Jan 1998 07:45:01 -0500 Message-Id: <m0xtB7S-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: /dev/event To: evstack@ontv.com Date: Fri, 16 Jan 1998 23:43:30 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69nh8m$rj6$1@grits.visus.com> from "Jason McMullan" at Jan 16, 98 11:45:26 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RDPWk1.0.Ak1.AOrlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/340 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > > I see it working like this: devevent is an evstack > > device instead of a class. Doing an open("/dev/event") creates an > > instance stack and attaches it to the appropriate termstack, _before_ > > the xterm stack so it steals the events. How does that sound ? > > Sounds Ok. Just hit SAK if your program crashes, right ?;^) Yep. BTW, what is the current (yet-to-be-cast-in-stone :) SAK key ? > Seriously, maybe /dev/event should just COPY the events that are > coming from input_stack, so that ^C and friends will work. You can > always stty the terminal not to display input... We might as well > be on the safe side... Well, how does the graphic mode fit in ? I mean, is it a separate VT with it's own termstack ? Or is it the same VT, but the mode has changed from a text-mode to a graphic-mode, and there is some sleight-of-hand to stop the xterm from scribbling over things ? I know, I should RTFS... If it's the same VT with the same termstack, then we either: steal the events before the xterm gets them (so when we type 'logout' on the graphic app, we don't also type it on the terminal), OR we send an event to the xterm to say "hey, we're in graphics mode now, behave!" and let the terminal code participate in the graphic handling. I'll go read some source... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 09:32:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA01540 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 09:32:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA09071; Fri, 16 Jan 1998 11:58:50 -0500 Resent-Date: Fri, 16 Jan 1998 11:58:50 -0500 Date: Fri, 16 Jan 1998 07:56:39 -0500 (EST) From: MenTaLboY <mental@moonbase.dyn.ml.org> X-Sender: mental@moonbase Reply-To: mentalboy@geocities.com To: EvStack ML <evstack@ontv.com> Subject: Audio and EvStacks Message-ID: <Pine.LNX.3.96.980116062951.3668C-100000@moonbase> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cFW072.0.pC2.t3vlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/341 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I've been playing with some code and thinking long and hard about an EvStack-based audio scheme. Here's basically what I've come up with: + in my concept, audio flow is accomplished through the passing around of tokens, which represent blocks of audio data. + tokens are passed between objects called 'nodes' ... each node having some number of token sources and token sinks associated with it. The path of audio data through the system is determined by how these sources and sinks are connected with one another + sound devices are represented as nodes, each token source on that node being associated with a specific physical input channel, and each token sink being associated with a specific physical output channel. Most current cards would simply have one input and one output, but there are a few bizzare ones on the market with, say, four physical inputs and outputs. + filters, whether implemented in software or hardware, would also be represented as nodes. In this case, the number of sources and sinks would be entirely dependent on the function of the filter. As a token passed through filters in the system, it would accumulate a list of transformations to be applied to it's associated audio block. No actual transformation is done until those transformations are explicitly applied, typically by the code behind a sound device node. This allows transformations on the audio data to be deferred until intelligent optimization decisions can be made by the code that knows about the hardware's capabilities (i.e. does our GUS do hardware mixing? yes? cool. we'll use it to mix these audio blocks, then) + it should be relatively easy to register custom node types (filters), and also custom transform opcodes, to allow some degree of extensibility Now... thoughts on an API... /* use unique integers to identify strings, so we don't have to be comparing and copying string data around all the time */ int gaudio_register_atom(gaudio_atom_t *atom, const char *str); int gaudio_get_string_from_atom(gaudio_atom_t atom, char *str, int *len); int gaudio_get_atom_from_string(gaudio_atom_t *atom, const char *str); int gaudio_unregister_atom(gaudio_atom_t atom); int gaudio_node_create(gaudio_node_t *node, gaudio_atom_t class_name, void *params, size_t param_size); int gaudio_node_destroy(gaudio_node_t node); int gaudio_node_connect(gaudio_node_t source_node, int source_num, gaudio_node_t sink_node, int sink_num); int gaudio_node_pull(gaudio_node_t node, int source_num, bool block); /* indicate to a node that something downstream from that source is starved for data */ int gaudio_node_configure(gaudio_node_t node, gaudio_atom_t option, void *params, size_t param_size); int gaudio_node_issupported(gaudio_node_t node, gaudio_atom_t option); /* internal-type stuff for making custom node classes and transforms */ int gaudio_register_node_class(gaudio_atom_t class_name, gaudio_node_class_def *class_def); int gaudio_unregister_node_class(gaudio_atom_t class_name); int gaudio_register_xform(gaudio_atom_t xform_name, gaudio_xform_def *xform_def); int gaudio_unregister_xform(gaudio_atom_t xform_name); int gaudio_token_create(gaudio_token_t *token); int gaudio_token_getlength(unsigned long *usec, gaudio_token_t token); int gaudio_token_clone(gaudio_token_t *dest, gaudio_token_t src); /* data block is also cloned */ int gaudio_token_destroy(gaudio_token_t token); int gaudio_token_put(gaudio_token_t token, gaudio_node_t node, int sink_num); /* also various functions to manipulate the list of xforms for a token */ int gaudio_token_append_xform(gaudio_token_t token, gaudio_atom_t xform_name, void *params, size_t param_size); /* obtain the block of audio data associated with a token; this could possibly involve mapping the data into the processes' address space */ int gaudio_lock_token(gaudio_data_block *block, gaudio_token_t token); int gaudio_unlock_token(gaudio_token_t token); Now, how does all this relate to EvStacks? The API by itself has nothing to do with EvStacks, but here's how it becomes an EvStack-based audio system: + the system is overseen by a kernel module that maintains the atom database, and a public node and transform class registry. Classes here are public to all processes, and instantiations of such node classes exist as EvStacks (more on this later). New public classes would typically be added by insmod'ing an appropriate module. + classes registered from userspace are private to the process they were registered in, and their instantiations have no EvStack representation. + gaudio_configure and gaudio_issupported for public nodes are accomplished via the EvStack's /proc entry + when a token leaves userspace for an EvStack node, it is decomposed into a sequence of events reflecting the token itself and its transformation list. Any private transformations in the list are rewritten with a pid and 'private' transformation number, so a callback (via an event) can be made later to process the transformation. When going from an EvStack to userspace, the process is reversed. If any private transformations belong to the destination process, they are rewritten back to their original forms. Well... I _tried_ to keep this short... your thoughts? -=MenTaLboY=- From evstack-request@ontv.com Fri Jan 16 09:37:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA01546 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 09:37:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA09434; Fri, 16 Jan 1998 12:04:08 -0500 Resent-Date: Fri, 16 Jan 1998 12:04:08 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtE6z-0000XgC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Fri, 16 Jan 1998 16:55:12 +0100 (MET) In-Reply-To: <m0xtANn-00017IC@ajax> from "Andrew Apted" at Jan 16, 98 10:56:19 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"W5Pyu3.0.0I2.bAvlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/342 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > I might try feeding it keycodes and see what happens (after all, the > > > E0 XX codes are just IBM specific). > > Should give at least a bit of keyboard. Better than nothing. > > It did work, and most of the keyboard works, including the function > keys. What doesn't work is the E0XX keys such as the cursor block. > > I've looked through all the 'lib/X11/xkb' stuff, and there is NO mention > of 'E0' or something like it anywhere. Yes. Internally (i.e. on Xlib level) X uses a linear range of keycodes. > I have this nasty suspicion that XFree has its own E0 table _hardcoded_ > in it... I am pretty sure this is the case. > > We'll probably need a fixed table in an emulation module that does > > keycode-> E0XX sequence mapping ... sick ... > It's looking that way... Ouch! Yep ... they probably did it, as most todays keyboards are IBM style, even on other platforms, so probably most HW lets you get at the raw data from the keyboard controller somehow. Cu, Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 09:38:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA01550 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 09:38:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA09450; Fri, 16 Jan 1998 12:04:23 -0500 Resent-Date: Fri, 16 Jan 1998 12:04:23 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtEJ8-0000XgC@charon.beck-sw.de> Subject: Re: Capslock & Numlock To: evstack@ontv.com Date: Fri, 16 Jan 1998 17:07:45 +0100 (MET) In-Reply-To: <m0xtAhj-00017IC@ajax> from "Andrew Apted" at Jan 16, 98 11:16:55 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"7kG2b2.0.tI2.YBvlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/343 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > As for numlock and the keypad keys, if we assume that keymapping the > keypad keys (in the keymapper) only changes the keysym in the event, > then the terminal can notice that keys come from the keypad by looking > at the _label_ field, and can swallow/override them at will (e.g. to > send terminal specific sequences). Oh - yes .. nice ! CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 14:09:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA01940 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 14:09:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA11662; Fri, 16 Jan 1998 16:35:49 -0500 Resent-Date: Fri, 16 Jan 1998 16:35:49 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/event Date: 16 Jan 1998 21:30:57 GMT Organization: OnTV Pittsburgh, L.P. Lines: 43 Distribution: local Message-ID: <69ojih$mcg$1@grits.visus.com> References: <69nl1s$ut0$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"_Rdjn2.0.6r2.E6zlq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/344 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > Jason McMullan writes: > > > I see it working like this: devevent is an evstack > > > device instead of a class. Doing an open("/dev/event") creates an > > > instance stack and attaches it to the appropriate termstack, _before_ > > > the xterm stack so it steals the events. How does that sound ? > > > > Sounds Ok. Just hit SAK if your program crashes, right ?;^) > Yep. BTW, what is the current (yet-to-be-cast-in-stone :) SAK key ? It's PrintScreen or CTRL-ALT-ESC on the American keyboard... > > Seriously, maybe /dev/event should just COPY the events that are > > coming from input_stack, so that ^C and friends will work. You can > > always stty the terminal not to display input... We might as well > > be on the safe side... > Well, how does the graphic mode fit in ? I mean, is it a separate VT > with it's own termstack ? Or is it the same VT, but the mode has > changed from a text-mode to a graphic-mode, and there is some > sleight-of-hand to stop the xterm from scribbling over things ? I know, > I should RTFS... The graphic mode is on the same VT as the termstack. If render() functions are provided for that graphic mode by the KGI driver, then yes, Xterm can scribble all over your graphics screen. Conversely, we get trivial-to-implement graphical text consoles! > If it's the same VT with the same termstack, then we either: steal the > events before the xterm gets them (so when we type 'logout' on the > graphic app, we don't also type it on the terminal), OR we send an event > to the xterm to say "hey, we're in graphics mode now, behave!" and > let the terminal code participate in the graphic handling. No, we simply close STDIN, and stty the tty into having `invisible' input. All, of course, hidden by libGGI. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 15:16:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02065 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:16:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA12152; Fri, 16 Jan 1998 17:43:14 -0500 Resent-Date: Fri, 16 Jan 1998 17:43:14 -0500 Message-ID: <34BFE0D0.3291595@bitsmart.com> Date: Fri, 16 Jan 1998 23:36:00 +0100 From: "Jonas Borgström" <jonas_b@bitsmart.com> X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Evstack Mailing List <evstack@ontv.com> Subject: Patch fix. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"7kBnu1.0.Nz2.K9-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/345 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, I removed the ksyms part from the 2.1.77 patch to get it to work, I also committed a swedish-keymap and changed the patch script to allow to unpatch the kernel to (Who needs that ? :-D ). I hope I didn't break anything. Should the vga driver work in graphic mode? I only got textmode to work. I needed to use a multisync monitor driver because matrox cards has a nonstandard textmode. Oops I forgot to commit the multisync monitor driver fix. / Jonas Borgström From evstack-request@ontv.com Fri Jan 16 15:23:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02070 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:23:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA12238; Fri, 16 Jan 1998 17:49:42 -0500 Resent-Date: Fri, 16 Jan 1998 17:49:42 -0500 Date: Fri, 16 Jan 1998 15:58:46 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xsx7n-0000XgC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980116155622.485D-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"u6_8Y1.0.h-2.EF-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/346 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 15 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > Probably. Comment out the references and recompile the module. Nothing bad > > > will happen. These should be changed anyway. The keymap module was not really > > > intended for being modularized ... > > > > I recompiled into the kernel.... > > XFree86 has no keyboard... (or mouse - but I haven't figured out how to > > install the sermouse driver... or even where it is yet) > > But other apps (including svgalib ones) all seem to work. > > > > This connected with the lack of raw keyboard access? > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > Mediumraw would be easy, because this is in the keycode field ... > > > Perhaps there's a way to emulate it... *grin*. You know, for backwards > > compatibility. > > There must ... wanna code that ? *thinking*... Any suggestions on how to handle it? Sure I'll code it .... but what additional data is needed? And is it available / emulatable? [aside : this is holding up the 6-console thingy a bit.... but I'll work on getting that operational with medium-raw keyboard for now] Just out of curiousity - what's the difference between "raw" and "mediumraw" keyboard modes? In EvStack that is... I am planning on making those consoles full userspace consoles.... ergo: EvStack! G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 15:24:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02079 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:24:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA12305; Fri, 16 Jan 1998 17:50:50 -0500 Resent-Date: Fri, 16 Jan 1998 17:50:50 -0500 Date: Fri, 16 Jan 1998 16:00:05 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xszPi-00017IC@ajax> Message-ID: <Pine.LNX.3.96.980116155919.485E-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VzK1D.0.M_2.8G-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/347 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 16 Jan 1998, Andrew Apted wrote: > Andreas Beck writes: > > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > > > Mediumraw would be easy, because this is in the keycode field ... > > Are you sure X isn't happy with keycodes ? They are pretty raw after > all, and still 7 bit. Uhh - should I check again with 2.1.79? I tried with 2.1.78 - no keyboard under X. Worked fine outside though... Had to reboot remotely *sigh*. G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 15:30:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02102 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:30:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA12393; Fri, 16 Jan 1998 17:56:55 -0500 Resent-Date: Fri, 16 Jan 1998 17:56:55 -0500 Date: Fri, 16 Jan 1998 16:06:57 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: /dev/graph functional! In-Reply-To: <001301bd2255$cd705ea0$0c0a0a0a@massacre> Message-ID: <Pine.LNX.3.96.980116160254.485F-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"mfEy21.0.213.PM-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/348 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 16 Jan 1998, David Waite wrote: > > +) You can insert/remove a display modules EVEN IF > > A GRAPHICS APP IS USING IT! (This will require > > catching SIGWINCH to _fully_ use this capability > > in libGGI, but we can now write `Does this driver > > work for you?' apps using GRAPHICS MODE! We can > > make X servers that you can `upgrade' the display > > driver WITHOUT LEAVING X!) > > > > Wait, so if I have two video cards in my computer in a multihead mode, could > I move X from one to another? Am looking forward to trying this - I have two videocards in my system (Trio64V+ and ViRGE :) [buggy cards :] > /me imagines a cool 3x3 grid of monitors all switching pictures like those > old sliding tile puzzles... Dang. Now I'm gonna have to get another videocard (and two more monitors). *deep sigh*... (looking fondly at 3DFX-ver2 cards when they appear :) > > Now, I want everyone (that likes to trash their hard drives > >with Alpha-level code) to get this and FIND THOSE BUGS! > > > > <grin> no problem, my harddrive for some reason keeps trashing itself on its > own ;) I've never had a problem - at least not with ext2 partitions :) [I lost my VFAT though a bit ago... no loss as I don't trust VFAT anyways] > > Also, do we have anybody that likes writing documentation > >on the list? I need someone to write up a `KGI change document' > >that describes how to re-write 0.0.9 drivers as GGI-0.1.0 > >drivers. > > > I would actually like to do this.. I am not versed in either the changes in > evstacks/ggi or in how evstacks works in itself.. right now I'm finishing up > an IBM Ramdac/clock driver for 0.0.9, after I get it working there I think > some docu writing would be a nice change (better docs woulda made my job a > heck of a lot easier) I'll start hacking at S3-ViRGE and S3-Trio64V+ support (if noone else beats me to it!).. I have both cards, both sets of books, and have hacked on the drivers before :) > This is great news though.. btw I tried out evstacks last night (on 2.1.79), > I must admit that it makes the whole project look more 'polished' as a > whole.. I loved how so much of it could be compiled modularly.. the first > thing I thought was "wow! this is incredible! I wonder how much of it really > is functional?" ;) > > Anyways, if nobody else is jumping the gun to write the documentation, I'd > be happy to do it (although I tend more towards HTML and .ps/.pdf formats, > someone else may want to convert it to a normal text format afterwards). Works for me! (I have support for reading only HTML, .ps, and .pdf... I'm getting -REALLY- annoyed at those .tex, .doc, ... manuals :P ) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 15:37:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02121 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:37:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA12604; Fri, 16 Jan 1998 18:03:25 -0500 Resent-Date: Fri, 16 Jan 1998 18:03:25 -0500 Date: Fri, 16 Jan 1998 16:13:12 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xtATX-0000XgC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980116160802.485G-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"JttXg1.0.Q43.KS-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/349 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 16 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > Oh... Not good... > Hmm - just re-checked: [clipped strace info] Though I noticed that it switched first into RAW then MEDIUMRAW... was there anything else in between? > > I got the impression that X used MEDIUM_RAW when I saw this in the > > kernel source: > > It really should. Everything else is sick. I use "RAW" for the keyboard-driver in the console kit... is EvStack a solution? I can't allow: Console switches (console-manager handles it) Breakthrough keys such as the alt-sysrq keys in std. kernel Ctrl-Alt-Del ... and other key-combos I can't think of at the moment. ... I also support my own alt-sysrq etc for internal use so... Is this possible with EvStacks? This program has to run in userspace and has to be able to manage the consoles properly. (and hopefully allow IOCTL's, etc :) > > I might try feeding it keycodes and see what happens (after all, the > > E0 XX codes are just IBM specific). > > Should give at least a bit of keyboard. Better than nothing. > > We'll probably need a fixed table in an emulation module that does > keycode-> E0XX sequence mapping ... sick ... But useful for backwards compatibility and future emulations (ie: Windows or DOS emu, ... :) So what'll all the keycode->RAW translations be? I'll be quite happy to help here. (or where can I look? :) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 15:41:21 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02130 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:41:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA12692; Fri, 16 Jan 1998 18:07:46 -0500 Resent-Date: Fri, 16 Jan 1998 18:07:46 -0500 Date: Fri, 16 Jan 1998 16:17:27 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Jason McMullan <jmcc@ontv.com> cc: David Waite <davewait@freenet.tlh.fl.us>, evstack@ontv.com, linux-ggi@eskimo.com Subject: Re: Future( Was: GGI_AUTO w/ GGI wrapper for X) In-Reply-To: <199801161129.GAA13203@beans.visus.com> Message-ID: <Pine.LNX.3.96.980116161423.485H-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"UA9HP.0.d53.KW-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/350 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 16 Jan 1998, Jason McMullan wrote: > 'David Waite wrote with particular insight...' > > I'd say our goal should be to try to have the kgi/evstacks code good enough > > to get into the 2.3.xx kernels right away (perhaps semi-stable 2.2.xx > > patches before). > > We should be able to get to that level of stability in ~2 weeks, IF: > > a) The recoding of the event layer proceeds normally > b) Someone can attach the `global keymap' problem > (it needs to be 1 per input device, and an instace per VT) I can help here as soon as I figure out what's needed :) > c) We can sic someone on the RAW keyboard problem. Sure! *grin* (someone tell me what to do please!) > d) I can kill the few rmaining bugs in /dev/graph, and > make the minor patches needed to libGGI. > > > Libggi and company need to be standardized and out the door as soon as > > possible. They can be beta, but they need to be set in stone. > > libGGI is `alpha' right now - the design SEEMS to be working, but > we're just now starting to get developers for it. libGGI will be > engraved in stone for Degas. Agreed :) > > Same with the > > KGI modules.. there needs to be a *solid* standard for this, so that we can > > start encouraging people to make KGI drivers for cards (I've heard Daryll > > Strauss is interested in making binary drivers for all of the 3Dfx chips, > > and heard someone else is interested in a NV1 and Riva 128 driver).. people > > won't put effort into writing a driver when the standard keeps changing.. > > luckily with evstacks going in, we have a chance of making everything really > > close to *right*. > > I'm waiting for AT LEAST TWO cards to successfuly use the Accel Ping-Pong > buffers. Until then, we should consider the KGI driver to be `in flux'. I > hate to say that, but I don't want to be burdened by a bad driver standard > because we didn't wait a week or two... I can start hacking at ViRGE and Trio64V+ accel support here :) ... once I know -again- how this is supposed to operate... What FM should I RT? *grin* > > P.S. The Evstacks stuff looks *extremely* promising. I haven't really looked > > at the code yet, but it made everything feel 'official' and refined, even as > > a beta.. it made it all seem like it belonged there. > > A few people have said that on linux-kernel also... Looks > good for us.. It's almost time for `Zeus to spring from the > head of Titan, fully formed'... So is the MediaGX code present yet? AFAIK it's public now.... G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 15:43:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA02134 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 15:43:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA12763; Fri, 16 Jan 1998 18:09:56 -0500 Resent-Date: Fri, 16 Jan 1998 18:09:56 -0500 Date: Fri, 16 Jan 1998 16:19:43 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xtANn-00017IC@ajax> Message-ID: <Pine.LNX.3.96.980116161834.485I-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"KskQR1.0.o63.KY-lq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/351 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > I got the impression that X used MEDIUM_RAW when I saw this in the > > > kernel source: > > > > It really should. Everything else is sick. > > > > > I might try feeding it keycodes and see what happens (after all, the > > > E0 XX codes are just IBM specific). > > > > Should give at least a bit of keyboard. Better than nothing. > > It did work, and most of the keyboard works, including the function > keys. What doesn't work is the E0XX keys such as the cursor block. > > I've looked through all the 'lib/X11/xkb' stuff, and there is NO mention > of 'E0' or something like it anywhere. I have this nasty suspicion > that XFree has its own E0 table _hardcoded_ in it... Oh - that's solvable. *thinking*.... I can handle this (I hope). I've got my own hardcoded keyboard driver *grin*.... Though I've never coded with MEDIUMRAW (or EvStacks yet)... > > We'll probably need a fixed table in an emulation module that does > > keycode-> E0XX sequence mapping ... sick ... > > It's looking that way... Ouch! G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 16:08:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA02180 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 16:08:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA12939; Fri, 16 Jan 1998 18:35:29 -0500 Resent-Date: Fri, 16 Jan 1998 18:35:29 -0500 Message-Id: <m0xtLHb-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Sat, 17 Jan 1998 10:34:39 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980116160802.485G-100000@sigil.computersupportcentre.com> from "teunis" at Jan 16, 98 04:13:12 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kFZUy1.0.a93.Ow-lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/352 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > Just out of curiousity - what's the difference between "raw" and > "mediumraw" keyboard modes? In the normal linux kernel, RAW mode is the bytes straight from the keyboard, nothing changed. MEDIUM_RAW mode does a small bit of processing to convert a multi-byte scancode (e.g. 0xE0 0x48 which is cursor up) into a single byte keycode (0x67). Under EvStack we have the nice ggi_key_event instead. > I use "RAW" for the keyboard-driver in the console kit... is EvStack a > solution? Do you really need RAW ? For console code, keysyms are much nicer to use, and they're platform independent. The EvStack xterm code (for example) only uses keysyms. > So what'll all the keycode->RAW translations be? I'll be quite happy to > help here. (or where can I look? :) It's probably just a matter of putting back the 'E0' code which we removed in the keyboard driver [and the 'high_keys' too ...]. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 16:27:00 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA02207 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 16:26:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA13087; Fri, 16 Jan 1998 18:53:27 -0500 Resent-Date: Fri, 16 Jan 1998 18:53:27 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtMTF-0000XgC@charon.beck-sw.de> Subject: 2.1.79 ... testing ... To: evstack@ontv.com (Evstack Mailing List) Date: Sat, 17 Jan 1998 01:50:45 +0100 (MET) Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"7wmV93.0.yB3.nA_lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/353 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks ! O.K. - I recompiled 2.1.79 with evstack ... fine work indeed. Patching went smoothly as did compilation. I had problems with the msdos fs at make-modules stage, but this is very probably not EvStacks fault ... Everything worked well (after I had figured out how *grin*) except : /dev/event didn't seem to report anything. I will browse the code to see what is wrong. I suspect it is simply the default reporting map. Insertion of the vga driver failed with the "couldn't set default mode" error known to come from nonstandard bootup modes (though I had booted simple 80x25). So I have overridden the default_mode=something in the get-reset-mode function which made the driver load, but fail with a divide by 0 immediately after that. Is this a known problem with the /dev/graph being a module or am I missing some patch ? I had updated source around 18:00 MET (17:00 GMT) ... X comes up fine, too, even with mouse via the traditional /dev/mouse. Only keyboard is missing, but I trust in Andrew to have this one fixed soon. I will now go for the ev_rc_* functions. Anyone with a concrete need for it, so I have a test-case ? CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 16:39:24 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA02232 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 16:39:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA13356; Fri, 16 Jan 1998 19:04:50 -0500 Resent-Date: Fri, 16 Jan 1998 19:04:50 -0500 Message-Id: <m0xtLjY-00017IC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: conlinux and raw keyboard To: evstack@ontv.com Date: Sat, 17 Jan 1998 11:03:32 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtE6z-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 16, 98 04:55:12 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"WjEnK1.0.2G3.OL_lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/354 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > I've looked through all the 'lib/X11/xkb' stuff, and there is NO mention > > of 'E0' or something like it anywhere. > > Yes. Internally (i.e. on Xlib level) X uses a linear range of keycodes. Yeah I know, and the values it uses for the cursor keys (for example) and the rest just seem to be magic... And what's funnier is that when it gets a scancode that is one of these magic values, it doesn't work. I guess it has a hardcoded 'highkeys' mapping too ? > > > We'll probably need a fixed table in an emulation module that does > > > keycode-> E0XX sequence mapping ... sick ... > > It's looking that way... Ouch! > > Yep ... they probably did it, as most todays keyboards are IBM style, even > on other platforms, so probably most HW lets you get at the raw data from > the keyboard controller somehow. Okay, but I wonder how they turn this off for platforms which don't have this E0XX stuff -- I guess that this is also a compile-time option... [Anyone got the XFree source ? Bloody hell thats big...] We probably need something like a 'rawterm', which behaves similiarly to a dumbterm or xterm, but sends RAW keyboard to the tty instead. The when an application requests KDSKMODE(RAW) in conlinux, it creates and attaches a rawterm to the termstack, _before_ the xterm so it steals the events from it. Does that sound doable ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 16:46:09 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA02242 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 16:46:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA13438; Fri, 16 Jan 1998 19:12:05 -0500 Resent-Date: Fri, 16 Jan 1998 19:12:05 -0500 Message-ID: <005401bd22db$50431e00$0d00a8c0@bacchus.mardigras> Reply-To: "David Waite" <davewait@freenet.tlh.fl.us> From: "David Waite" <davewait@freenet.tlh.fl.us> To: <evstack@ontv.com> Subject: Re: 2.1.78 boot... Date: Fri, 16 Jan 1998 19:02:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"YkrR-1.0.UH3.RS_lq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/355 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hmm.. I installed 2.1.79 and Evstacks (but alot of it was modular, and I didn't compile modules because I was in a hurry). X started up fine, I don't remember if keyboard worked, but I was able to exit out easy enough. Of course, all this was yesterday.. I don't know with the present snapshot -David Waite -----Original Message----- From: teunis <teunis@mauve.computersupportcentre.com> To: evstack@ontv.com <evstack@ontv.com> Date: Friday, January 16, 1998 5:45 PM Subject: Re: 2.1.78 boot... >On Fri, 16 Jan 1998, Andrew Apted wrote: > >> Andreas Beck writes: >> >> > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. >> > >> > Mediumraw would be easy, because this is in the keycode field ... >> >> Are you sure X isn't happy with keycodes ? They are pretty raw after >> all, and still 7 bit. > >Uhh - should I check again with 2.1.79? > >I tried with 2.1.78 - no keyboard under X. Worked fine outside though... >Had to reboot remotely *sigh*. > >G'day, eh? :) > - Teunis > > From evstack-request@ontv.com Fri Jan 16 17:39:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA02337 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 17:39:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA13913; Fri, 16 Jan 1998 20:06:27 -0500 Resent-Date: Fri, 16 Jan 1998 20:06:27 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtN5D-0000XgC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Sat, 17 Jan 1998 02:29:59 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980116160802.485G-100000@sigil.computersupportcentre.com> from "teunis" at Jan 16, 98 04:13:12 pm Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"ia9ef.0.oO3.PF0mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/356 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > On Fri, 16 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > > > > > Yep. X want full RAW mode, i.e. scancodes as they come from keyboard. > > > Oh... Not good... > > Hmm - just re-checked: > [clipped strace info] > > Though I noticed that it switched first into RAW then MEDIUMRAW... was > there anything else in between? No - It went to RAW, then back to XLATE (which is the normal operation mode: #define K_RAW 0x00 #define K_XLATE 0x01 > > > I got the impression that X used MEDIUM_RAW when I saw this in the > > > kernel source: > I can't allow: > Console switches (console-manager handles it) > Breakthrough keys such as the alt-sysrq keys in std. kernel > Ctrl-Alt-Del In this case you will have to make the console at kernel level. These keys are hardwired on purpose to reduce the possibility of f***ing up the system. If your application has root rights, or can be started from one which has, it could change the keyboard mapping to disallow these keys. But it is in our intention to have these keys working _anytime_ normally. > Is this possible with EvStacks? This program has to run in userspace and > has to be able to manage the consoles properly. (and hopefully allow > IOCTL's, etc :) It is not encouraged and requires the ugly hack mentioned above. But I think SAK,CAD and VT-switching are security critcal and should not be easy to shut off. Not even for root. > > We'll probably need a fixed table in an emulation module that does > > keycode-> E0XX sequence mapping ... sick ... > But useful for backwards compatibility and future emulations (ie: Windows > or DOS emu, ... :) Yes ... > So what'll all the keycode->RAW translations be? I'll be quite happy to > help here. (or where can I look? :) In the keyboard driver. It does the mapping the other way round ... CU,ANdy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 19:05:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02448 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 19:05:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA14576; Fri, 16 Jan 1998 21:32:05 -0500 Resent-Date: Fri, 16 Jan 1998 21:32:05 -0500 Date: Fri, 16 Jan 1998 19:41:51 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xtLHb-00017IC@ajax> Message-ID: <Pine.LNX.3.96.980116194100.8684C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"y6tit2.0.AZ3.yV1mq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/357 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sat, 17 Jan 1998, Andrew Apted wrote: > teunis writes: > > > Just out of curiousity - what's the difference between "raw" and > > "mediumraw" keyboard modes? > > In the normal linux kernel, RAW mode is the bytes straight from the > keyboard, nothing changed. MEDIUM_RAW mode does a small bit of > processing to convert a multi-byte scancode (e.g. 0xE0 0x48 which is > cursor up) into a single byte keycode (0x67). > > Under EvStack we have the nice ggi_key_event instead. > > > I use "RAW" for the keyboard-driver in the console kit... is EvStack a > > solution? > > Do you really need RAW ? > > For console code, keysyms are much nicer to use, and they're platform > independent. The EvStack xterm code (for example) only uses keysyms. I need ggi_key_event *grin*.... > > So what'll all the keycode->RAW translations be? I'll be quite happy to > > help here. (or where can I look? :) > > It's probably just a matter of putting back the 'E0' code which we > removed in the keyboard driver [and the 'high_keys' too ...]. *dang* I don't know much about the mapping. Well, looks like a weekend job :) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 19:20:27 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02475 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 19:20:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA14709; Fri, 16 Jan 1998 21:46:55 -0500 Resent-Date: Fri, 16 Jan 1998 21:46:55 -0500 Date: Fri, 16 Jan 1998 19:56:21 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: becka@rz.uni-duesseldorf.de cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <m0xtN5D-0000XgC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980116195157.8684D-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5Pc6d.0.Gb3.tj1mq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/358 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > > > I got the impression that X used MEDIUM_RAW when I saw this in the > > > > kernel source: > > > I can't allow: > > Console switches (console-manager handles it) > > Breakthrough keys such as the alt-sysrq keys in std. kernel > > Ctrl-Alt-Del > > In this case you will have to make the console at kernel level. NO NO NO! (dang). Is there no way to do this userspace? This is for the 6-consoles-on-the-sides-of-a-cube system.... and I don't think anyone's going to like such in the kernel... > These keys are hardwired on purpose to reduce the possibility of f***ing > up the system. > > If your application has root rights, or can be started from one which has, > it could change the keyboard mapping to disallow these keys. And this will require 'root' access then... which is livable. And if it doesn't have su access it'll just clip those capabilities and still (hopefully) run happily :) > But it is in our intention to have these keys working _anytime_ normally. > > > Is this possible with EvStacks? This program has to run in userspace and > > has to be able to manage the consoles properly. (and hopefully allow > > IOCTL's, etc :) > > It is not encouraged and requires the ugly hack mentioned above. > > But I think SAK,CAD and VT-switching are security critcal and should not > be easy to shut off. Not even for root. It's sometimes necessary... This is designed as a userspace -replacement- for the kernel consoles to allow things like full unicode (and I mean _FULL_ unicode! All 100K+ characters of Chinese included :) > > > We'll probably need a fixed table in an emulation module that does > > > keycode-> E0XX sequence mapping ... sick ... > > But useful for backwards compatibility and future emulations (ie: Windows > > or DOS emu, ... :) > Yes ... That's why I wanna code it :) > > So what'll all the keycode->RAW translations be? I'll be quite happy to > > help here. (or where can I look? :) > In the keyboard driver. It does the mapping the other way round ... Ah - okay. I'll look at it over the next couple of days :) [while I try to get a simple userspace program operational under EvStacks] G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 16 19:43:40 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02507 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 19:43:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA15021; Fri, 16 Jan 1998 22:09:53 -0500 Resent-Date: Fri, 16 Jan 1998 22:09:53 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtO0U-0000XgC@charon.beck-sw.de> Subject: Re: conlinux and raw keyboard To: evstack@ontv.com Date: Sat, 17 Jan 1998 03:29:10 +0100 (MET) In-Reply-To: <m0xtLjY-00017IC@ajax> from "Andrew Apted" at Jan 17, 98 11:03:32 am Reply-To: becka@rz.uni-duesseldorf.de X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"WwPp6.0.7g3.Q32mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/359 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Yeah I know, and the values it uses for the cursor keys (for example) > and the rest just seem to be magic... And what's funnier is that when > it gets a scancode that is one of these magic values, it doesn't work. > I guess it has a hardcoded 'highkeys' mapping too ? Yeah. I suppose so ... > > Yep ... they probably did it, as most todays keyboards are IBM style, even > > on other platforms, so probably most HW lets you get at the raw data from > > the keyboard controller somehow. > Okay, but I wonder how they turn this off for platforms which don't have > this E0XX stuff -- I guess that this is also a compile-time option... Very probably ... > [Anyone got the XFree source ? Bloody hell thats big...] Should be lying around somewhere ... really big thingy ... > We probably need something like a 'rawterm', which behaves similiarly to > a dumbterm or xterm, but sends RAW keyboard to the tty instead. > The when an application requests KDSKMODE(RAW) in conlinux, it creates > and attaches a rawterm to the termstack, _before_ the xterm so it steals > the events from it. > > Does that sound doable ? I would have rather put it in the part that moves keycodes/syms to the usermode. I got to recheck, but I suspect that is in the xterm code ... Well - how about simply writing a special linux-termparser which knows about that sicknesses ... ? Oh - well wouldn't be too nice regarding auto-VT-creation ... grrr ... Yes. Your idea sounds best ... should be integrated with that conlinux compatibility module. CU,Andy -- Andreas Beck | Email : <becka@sunserver1.rz.uni-duesseldorf.de> From evstack-request@ontv.com Fri Jan 16 19:52:11 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA02523 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 19:52:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA15109; Fri, 16 Jan 1998 22:18:32 -0500 Resent-Date: Fri, 16 Jan 1998 22:18:32 -0500 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Sat, 17 Jan 1998 04:17:34 +0100 (MET) From: Stefan Mars <mars@lysator.liu.se> To: evstack@ontv.com Subject: Re: conlinux and raw keyboard In-Reply-To: <m0xtO0U-0000XgC@charon.beck-sw.de> Message-ID: <Pine.GSO.3.96rindlow.980117041446.16363A-100000@tindra.lysator.liu.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1I1Nf2.0.Yh3.bB2mq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/360 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > [Anyone got the XFree source ? Bloody hell thats big...] > Should be lying around somewhere ... really big thingy ... ftp.x.org has them for example, but they are quite huge. If you only want to compile parts of X, like a new server, then you only need the first file though. -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From evstack-request@ontv.com Fri Jan 16 21:55:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA02618 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 21:55:00 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA16046; Sat, 17 Jan 1998 00:21:27 -0500 Resent-Date: Sat, 17 Jan 1998 00:21:27 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: 2.1.78 boot... Date: 17 Jan 1998 05:20:56 GMT Organization: OnTV Pittsburgh, L.P. Lines: 21 Distribution: local Message-ID: <69pf3o$cod$1@grits.visus.com> References: <69peh4$cdk$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"qchZP.0.Bw3.n-3mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/361 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > I can't allow: > Console switches (console-manager handles it) > Breakthrough keys such as the alt-sysrq keys in std. kernel > Ctrl-Alt-Del > ... and other key-combos I can't think of at the moment. > ... I also support my own alt-sysrq etc for internal use so... > Is this possible with EvStacks? This program has to run in userspace and > has to be able to manage the consoles properly. (and hopefully allow > IOCTL's, etc :) You should be able to over-ride these keys as a normal user, EXCEPT FOR SAK. SAK can _never_ be ignored, unless you are root and EXCLICITLY unmap it. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 22:05:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA02627 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 22:05:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA16162; Sat, 17 Jan 1998 00:32:31 -0500 Resent-Date: Sat, 17 Jan 1998 00:32:31 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: 2.1.79 ... testing ... Date: 17 Jan 1998 05:32:07 GMT Organization: OnTV Pittsburgh, L.P. Lines: 24 Distribution: local Message-ID: <69pfon$cod$2@grits.visus.com> References: <69peha$cdo$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"Dr_SL3.0.-x3.G94mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/362 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > Is this a known problem with the /dev/graph being a module or am I missing > some patch ? I had updated source around 18:00 MET (17:00 GMT) ... Currently /dev/graph _won't work_ as a module. If your kernel `make menuconfig' allowed it, it isn't the version that has working /dev/graph. Re-update. (you won't need to re-apply the kernel patch...) > I will now go for the ev_rc_* functions. Anyone with a concrete need for it, > so I have a test-case ? Yes - enhance the keyboard stack to have a CmdChangeHead to change the default head that it sends it's events to. (so when I, say, switch to the hercules display on ALT-F11, I can type also!) and return success or failure. You _really_ want to know that you've been able to switch the keyboard to another display! And, IIRC, you do have a Hercules card in your system? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 16 23:03:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA02644 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 23:03:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA17065; Sat, 17 Jan 1998 01:29:47 -0500 Resent-Date: Sat, 17 Jan 1998 01:29:47 -0500 Message-Id: <m0xtRkE-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: conlinux and raw keyboard To: evstack@ontv.com Date: Sat, 17 Jan 1998 17:28:37 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtO0U-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 17, 98 03:29:10 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kwyuw1.0.6A4.X-4mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/363 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > We probably need something like a 'rawterm', which behaves similiarly to > > a dumbterm or xterm, but sends RAW keyboard to the tty instead. > > The when an application requests KDSKMODE(RAW) in conlinux, it creates > > and attaches a rawterm to the termstack, _before_ the xterm so it steals > > the events from it. > > > > Does that sound doable ? > > I would have rather put it in the part that moves keycodes/syms to the > usermode. I got to recheck, but I suspect that is in the xterm code ... Yep, the xterm code. > Well - how about simply writing a special linux-termparser which knows > about that sicknesses ... ? Oh - well wouldn't be too nice regarding > auto-VT-creation ... grrr ... > > Yes. Your idea sounds best ... should be integrated with that conlinux > compatibility module. Okay I'll look into it some more. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 16 23:17:56 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA02665 for <ggi@synergy.foo.net>; Fri, 16 Jan 1998 23:17:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA17189; Sat, 17 Jan 1998 01:44:25 -0500 Resent-Date: Sat, 17 Jan 1998 01:44:25 -0500 Message-Id: <m0xtRym-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/graph functional! To: evstack@ontv.com Date: Sat, 17 Jan 1998 17:43:39 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69n3ij$j69$1@grits.visus.com> from "Jason McMullan" at Jan 16, 98 07:51:47 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aOLAg3.0.0C4.dC5mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/364 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > +) Will properly set _any_ graphics mode your KGI display > driver supports! > +) MMAP is _fully_ functional! > +) libGGI works with /dev/graph _UNMODIFIED_! It isn't working here. The VGA driver still inserts and removes beautifully, but neither testvid or the libggi demo work. I'm assuming testvid is the lowest common denominator, and when I run this I get a kernel Oops in graph_driver_command +185/3d0 (a NULL pointer dereference). It also changes VT for some reason (possibly always to VT0, despite what /dev/graphXX I give it). I'm invoking it like this: testvid /dev/graph03 320 200 320 200 8 should that work? Using /dev/graphic gives a "No such device" error. I have made all the new devices in /dev. [are /dev/graph[0-9] the old ones ? If so, I'd like to delete 'em]. Any ideas ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 17 00:03:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA02685 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 00:03:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA17849; Sat, 17 Jan 1998 02:30:17 -0500 Resent-Date: Sat, 17 Jan 1998 02:30:17 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/graph functional! Date: 17 Jan 1998 07:29:49 GMT Organization: OnTV Pittsburgh, L.P. Lines: 42 Distribution: local Message-ID: <69pmld$i1b$1@grits.visus.com> References: <69pkb1$gb7$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"3OV9Y.0.NM4.dt5mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/365 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > Jason McMullan writes: > > +) Will properly set _any_ graphics mode your KGI display > > driver supports! > > +) MMAP is _fully_ functional! > > +) libGGI works with /dev/graph _UNMODIFIED_! > It isn't working here. The VGA driver still inserts and removes > beautifully, but neither testvid or the libggi demo work. Did you make sure to compile thge dev/graph module into ther kernel? > I'm assuming testvid is the lowest common denominator, and when I run > this I get a kernel Oops in graph_driver_command +185/3d0 (a NULL > pointer dereference). It also changes VT for some reason (possibly > always to VT0, despite what /dev/graphXX I give it). The `always changes VT' thing is exactly like the 0.0.9 behavior. Hmm... Still trying to find out what I'm not initializing correctly in dev/graph... > I'm invoking it like this: > testvid /dev/graph03 320 200 320 200 8 > should that work? Using /dev/graphic gives a "No such device" error. > I have made all the new devices in /dev. [are /dev/graph[0-9] the old > ones ? If so, I'd like to delete 'em]. That should work IF you have opened a tty on /dev/vty03. (just an `echo hi there >/dev/vty03' will do it.) Yes - ditch the old /dev/* devices. I'm working on getting the `magic open' /dev/graph working again. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 00:16:07 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA02705 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 00:16:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA17955; Sat, 17 Jan 1998 02:42:34 -0500 Resent-Date: Sat, 17 Jan 1998 02:42:34 -0500 Date: Sat, 17 Jan 1998 00:52:48 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <69pf3o$cod$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980117004936.27357A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"9dVOF3.0.1O4.D36mq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/366 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 17 Jan 1998, Jason McMullan wrote: > teunis (teunis@mauve.computersupportcentre.com) wrote: > > I can't allow: > > Console switches (console-manager handles it) > > Breakthrough keys such as the alt-sysrq keys in std. kernel > > Ctrl-Alt-Del > > ... and other key-combos I can't think of at the moment. > > ... I also support my own alt-sysrq etc for internal use so... > > > Is this possible with EvStacks? This program has to run in userspace and > > has to be able to manage the consoles properly. (and hopefully allow > > IOCTL's, etc :) > > You should be able to over-ride these keys as a normal user, EXCEPT FOR SAK. > SAK can _never_ be ignored, unless you are root and EXCLICITLY unmap it. So what's the behaviour of SAK supposed to be? Would there be a reason for me to catch it? there certainly is for all other combos though - this beasty's supposed to be a virtual-console manager in userspace *grin*. Also - any suggestions on configurability options? Should I make a .config file? open an EvStack for external configuration? any other ideas? note: beasty is 6 consoles on the sides of a cube. It would TRUELY be icing on cake if I could run 6 GGI apps - one on each side of the console :) Maybe after this I'll start mucking around with a GGI-based mpg player :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 17 01:51:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA02912 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 01:51:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id EAA19194; Sat, 17 Jan 1998 04:18:09 -0500 Resent-Date: Sat, 17 Jan 1998 04:18:09 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: 2.1.78 boot... Date: 17 Jan 1998 09:17:39 GMT Organization: OnTV Pittsburgh, L.P. Lines: 29 Distribution: local Message-ID: <69psvj$n6b$1@grits.visus.com> References: <69pnrm$j5i$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"_qt0i1.0.Oh4.jS7mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/367 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > On 17 Jan 1998, Jason McMullan wrote: > > SAK can _never_ be ignored, unless you are root and EXCLICITLY unmap it. > So what's the behaviour of SAK supposed to be? > Would there be a reason for me to catch it? SAK kills all processes on the current VT. And no, you _really_ don't want to catch it unless you want the cude to run as root... > Also - any suggestions on configurability options? Should I make a > config file? open an EvStack for external configuration? any other > ideas? A `~/.ggi/evCube' config file would be good.... > note: > beasty is 6 consoles on the sides of a cube. It would TRUELY be icing on > cake if I could run 6 GGI apps - one on each side of the console :) You'd have to write a `display-cube' driver for libGGI - basically, it would perform the rotation/shearing needed an pump the pixels to the Cube. Not too hard. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 05:13:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA03083 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 05:13:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA20393; Sat, 17 Jan 1998 07:39:56 -0500 Resent-Date: Sat, 17 Jan 1998 07:39:56 -0500 Date: Sat, 17 Jan 1998 12:33:06 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xse1v-0000XeC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980117123155.113A-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8nclH3.0.Az4.UPAmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/369 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 15 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > The manual would say up/down is on a/z and this will be the case. Whatever > the keyboard looks like. If you feel uncomfortable with that mapping, > you have to enter config-mode. > > I think this is the best default behaviour we can get. Assumptions about OK > > > With configuration that easy noone would bother too much about a bad > > > default. > > I wouldn't bet on that. > Well - the one who is annoyed about a bad default he can change easily, is > probably annoyed about the colour of his neighbour's house, too ... *grin* Matthias Grimrath From evstack-request@ontv.com Sat Jan 17 05:13:56 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA03087 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 05:13:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA20420; Sat, 17 Jan 1998 07:40:25 -0500 Resent-Date: Sat, 17 Jan 1998 07:40:25 -0500 Date: Sat, 17 Jan 1998 13:34:09 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xsovW-00017DC@ajax> Message-ID: <Pine.LNX.3.96.980117133123.113C-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"m3lJV2.0.ry4.SPAmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/368 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Now that you (Andrew & Andy) seem to implement the keyboard stuff, I think I could write some documentation about this specific part of libGII. You know, that mumbling about abstract keyboards, keylabels and such. Objections? Matthias Grimrath From evstack-request@ontv.com Sat Jan 17 05:14:12 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA03091 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 05:14:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA20428; Sat, 17 Jan 1998 07:40:42 -0500 Resent-Date: Sat, 17 Jan 1998 07:40:42 -0500 Date: Sat, 17 Jan 1998 13:29:35 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> Reply-To: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keyboard API In-Reply-To: <m0xseJJ-0000XeC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980117123322.113B-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jbj2p3.0.Rz4.VPAmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/370 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > code: scan code? If so, I'd say drop it. Apps should use keylabels for > > that purpose. The apps lose nothing but win portability. > > It is a scancode (well, a Linux unified scancode, the thing you get in > mediumraw mode). The app _should_not_ use it. It is reported for backwards > compatibility to old software and wrappers. 'Old' software probably is only interested in the scan code. Instead of merging label,symbol and scan code in one event, I propose to make three of it, because at max only 2 fields (sym and label|scancode) will be used. It's also sensible to separate symbol and label, because keypresses and symbol generation doesn't necessarily happen at the same time. (deadkeys macros, modifiers, etc) This would allow the symbol part of my proposed API too. I hope I have time to explain it soon. > > The actual value of the labels is not important. It's important that the > > label code represents the key NOT a symbol! We should stress that very much > > in the documentation. For example, american keyboards have a '{' key. Such > > a key doesn't exists on a german one. (I have to press AltGr-7). The key > > that generates the scancode of '{' on american keyboards is labeled with > > umlaut u on my german one. So a german and an american keyboard would > > generate different keylabels, though they generate the same scancode. > > Yes, but it is very nice, if you can deduce the symbol printed on the key from > the label. And having unicode values for it seems very reasonable to do this. > > This is very important for configuration purposes, where you surely want to > display what the user chose. Yes, of course :) I only want to stress the logical difference between labels and symbols. I'm sure this difference leads to confusion for new users of GII. > > The processing order should be scan -> label -> sym. Are you saying that? > > More or less yes. However I suggest to do it scan->label and scan->sym > internally, as it saves the hassle of hashing back an array index from the > label to address the symbol tables. > > In the mapping tables external representation (i.e. loadkeys input), it should > be as you suggest. > > Two sections : > 1. code->label mapping > 2. label->sym mapping (with modifiers et al) > > In the kernel code I'd rather like to see the second table unfolded at keymap > download, so it actually does code->sym, as this is much easier. Just perfect. > > 1) Tell the system what kind of keyboard you're using. For example 'echo > > setkeyboardtype german >/proc/evstack/...' This ensures correct keylabel > > codes. > > Would mean huge tables in the kernel. I say this belongs to userspace, i.e. > loadkeys should set section 1 with a big number of bind-calls. Yep > > Scancodes should never be used anymore. There'll only be a backdoor for > > compatibility, and should require root priviledges. > > There is no sense in requiring root priviledges for informative data. Oops, forget about the root privs. I was carried away by the current implementation which disables console switching when in raw mode. This is not true for GGI. > > Of course it's possible this way, but not necessary. If DOOM would > > register certain keys, these get automatically updated. > This requires tables of "registered keys" ... very possible memory leak. The tables are hold in userspace, so no more memory leaks as in other apps. > > The code doesn't need to re-synchronize, even more it always knows > > the exact state of the keys. > > Ahem - you do not propose an application should be able to track keys > pressed/released on a foreign console, do you ? No way! When the app doesn't have the input focus, its registered keys doesn't get updated. > > But not that convenient. How would you code that if you'd only receive > > events? I'd have a little FIFO. When I want to know about changes I'll be > > looking at the time stamps. When registering a key, you also register a > > FIFO that is handled by the OS, so you needn't provide your own routines. > > Sorry I haven't got the original issue ... What should this FIFO do ? OK, I try again. (BTW, FIFO is wrong, it's a ringbuffer) Consider you want to detect double presses of Ctrl. For that to happen, the user has to press down Ctrl, release it, and push it down again. Thus you have to store the last three events. Pseudo code may look like: if (key[EVENT_1].state == down && key[EVENT_2].state == up && key[EVENT_3].state == down && (key[EVENT_3].time - key[EVENT_1].time) < 0.5secs) Another example: I've heard of a program that profiles how a user hacks at the keyboard. (This profile is pretty personal and useful for identifying whether the right person sits a the computer or someone with a stolen password.) It needs to record the changes of any key, i.e. it has to store events and each key has its own history event buffer. What I want to say is whenever an app needs more information than just "this key is up/down", it has to store some kind of history. This history saving can be done quite generic yet efficient, i.e. my proposed registering of ringbuffers. If somethings generic enough, it should go into a lib IMHO, and I think ringbuffers are sufficient in this case for almost all application. We'd also get synchronisation app <-> keyboard almost for free, i.e. the app needn't ignore any key-up events + others hassle I do not know right now :) (I DO NOT say that VtSwitchaway are obsoleted! It's just that you don't need this event for the keyboard anymore in the application area) If you don't like the idea of registering ringbuffers into kernelspace, there is yet the possibility of a 'GetKeyState(labelcode)' system call. libGII may call this function after a VtSwitch event to synchronize the ringbuffers that are now internal to libGGI (and thus userspace). > > Not for the program, but for the user. Consider someone is moving his/her > > .emacs from a SUN to the Linux PC at home. This .emacs puts info-mode on > > the Help key. This key doesn't exists on PC keyboards, and Emacs cannot > > even tell the user "Just to let you know, the Help key is not available > > here". > > I wouldn't like to get flooded with such messages ... Hehe. That's a different story. However, I'd like a command ala 'check-keyboard-bindings' and then emacs would tell me about all impossible key bindings. > BTW: If an app wants to, it can download the keymapping tables (I think we > should allow that, right ? Though no macro information ...) ... Replace 'app' with 'libGGI' and we have same opinion :) I didn't say that there has to be an IsKeyAvailable() ioctl(). After all, it's a library function. Matthias Grimrath From evstack-request@ontv.com Sat Jan 17 05:20:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA03107 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 05:20:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA20526; Sat, 17 Jan 1998 07:46:31 -0500 Resent-Date: Sat, 17 Jan 1998 07:46:31 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtXgO-0000XgC@charon.beck-sw.de> Subject: Re: display-CUBE To: evstack@ontv.com (Evstack Mailing List) Date: Sat, 17 Jan 1998 13:49:04 +0100 (MET) Cc: linux-ggi@eskimo.com (mailing list GGI) In-Reply-To: <69psvj$n6b$1@grits.visus.com> from "Jason McMullan" at Jan 17, 98 09:17:39 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Glfzj1.0.705.4VAmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/371 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > note: > > beasty is 6 consoles on the sides of a cube. It would TRUELY be icing on > > cake if I could run 6 GGI apps - one on each side of the console :) > > You'd have to write a `display-cube' driver for libGGI - basically, > it would perform the rotation/shearing needed an pump the pixels to > the Cube. Not too hard. Yes. A simple implementation would be to have a "display-cube" target, which takes a parameter (the side of the cube) and draws to a shared memory area. Now another application (the cube-renderer) would grab all the shared memory areas and use them as textures. Input could be redirected by named pipes or via some protocol running on part of the shared memory. This would nicely allow (assuming the console is still useable after the cube is there, e.g. under X): bash$ cubeserver bash$ LIBGGI_DISPLAY="display-cube:1" demo 16 200 200 bash$ LIBGGI_DISPLAY="display-cube:2" graphterm etc. ... >From the programming point of view this is bloody simple. Teunis ? Anyone else ? I think it would be a bloody cool exmaple of LibGGI flexibility to be able to redirect the output of apps to the sides of a spinning cube ... CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sat Jan 17 07:02:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA03367 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 07:02:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA21312; Sat, 17 Jan 1998 09:28:28 -0500 Resent-Date: Sat, 17 Jan 1998 09:28:28 -0500 Message-Id: <m0xtZBm-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: conlinux and devevent To: evstack@ontv.com Date: Sun, 18 Jan 1998 01:25:34 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtRkE-00017NC@ajax> from "Andrew Apted" at Jan 17, 98 05:28:37 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"I903H3.0.LC5.X_Bmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/372 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Your's Truly writes: > > > We probably need something like a 'rawterm', which behaves similiarly to > > > a dumbterm or xterm, but sends RAW keyboard to the tty instead. > > > The when an application requests KDSKMODE(RAW) in conlinux, it creates > > > and attaches a rawterm to the termstack, _before_ the xterm so it steals > > > the events from it. [snip ...] > > Yes. Your idea sounds best ... should be integrated with that conlinux > > compatibility module. > > Okay I'll look into it some more. Well after a fair amount of hacking, I got the keyboard working in X. This was just a hack on the xterm.c code, so what I'll do now is implement it properly in conlinux.c. BUT, I need a way to attach the 'conlinux' stack _before_ the xterm stack. [we will probably need this for doing devevent too...]. Plain old "attach 12345678" isn't good enough, it just ends up at the tail. Thus I want to propose extending the "attach" operator with an optional _PRIORITY_ value. When it is not specified, 0 is assumed. Higher priorities mean closer to the front of the list and receiving events sooner. [This is mainly for termstacks, but we should do for inputstacks too for consistency]. Here is the priorities that I have in mind for different stacks: #define STACK_PRIORITY_INPUT 100 #define STACK_PRIORITY_KEYMAP 80 #define STACK_PRIORITY_DEVEVENT 60 #define STACK_PRIORITY_CONLINUX 50 #define STACK_PRIORITY_SELECTION 20 #define STACK_PRIORITY_TERMINAL 10 #define STACK_PRIORITY_NORMAL 0 #define STACK_PRIORITY_OUTPUT -50 Input devices are only at the top for aesthetic reasons. Output devices are at the bottom. Keymapping needs to be done before the terminal, and also before devevent/conlinux. Both conlinux (the RAW emulation stack) and devevent need to be placed before the terminal (to steal the events away from it). Selection also wants to do its magic before the terminal, but not when devevent or conlinux is in-effect (so it comes after them). Well that's it. It will be easy to implement, and solves the "how do I put my stack _there_ ?" problem that's been bugging me for a while. Comments ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 17 09:52:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA03557 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 09:52:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA22496; Sat, 17 Jan 1998 12:18:20 -0500 Resent-Date: Sat, 17 Jan 1998 12:18:20 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtcmf-0000XgC@charon.beck-sw.de> Subject: ev_rc functions ... To: evstack@ontv.com (Evstack Mailing List) Date: Sat, 17 Jan 1998 19:15:52 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"MGjPh1.0.zU5.sUEmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/373 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com O.K. - I added some flesh to the ev_rc functions I added to evstack.c . Please have a look and tell me, if you like them. The wait_queue support is still missing, but that's probably no biggy. I see one security problem with the overall concpet, though: One could in principle try two things to confuse the RC system : 1. Try to be faster with a bogus response from usermode which should come from kernel mode. 2. Try to send responses to events you haven't even seen, as they are e.g. not directed to your head ... Part #2 could be made reasonably difficult by attaching a random "tag" to the RC, so the descriptor and the tag would need to match what would mean you have seen the event which is carrying both the descriptor and the tag. #1 is probably not really fixable, as the exact same thing is what the system is designed for - sending responses from usermode ... I.e. we have to take care that bogus results do not confuse the stack badly. Comments ? CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sat Jan 17 12:19:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA03729 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 12:19:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA23524; Sat, 17 Jan 1998 14:45:30 -0500 Resent-Date: Sat, 17 Jan 1998 14:45:30 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtd1y-0000XgC@charon.beck-sw.de> Subject: Re: conlinux and devevent To: evstack@ontv.com Date: Sat, 17 Jan 1998 19:31:42 +0100 (MET) In-Reply-To: <m0xtZBm-00017NC@ajax> from "Andrew Apted" at Jan 18, 98 01:25:34 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"4_FK-.0.qk5.oeGmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/374 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Well after a fair amount of hacking, I got the keyboard working in X. > This was just a hack on the xterm.c code, so what I'll do now is > implement it properly in conlinux.c. BUT, I need a way to attach the > 'conlinux' stack _before_ the xterm stack. [we will probably need this > for doing devevent too...]. Plain old "attach 12345678" isn't good > enough, it just ends up at the tail. Yep. I like your priority proposal. Far better than the "insert before stack #xxxxxxx" I had in mind quite some time ago. We should document the default priorities somewhere. Insertion policy would be "after the last stack with higher or equal priority" and "if no priority is given, assume 0". Ver nifty. E.g. for debugging, too ... > away from it). Selection also wants to do its magic before the > terminal, but not when devevent or conlinux is in-effect (so it comes > after them). BTW: Where is the selection support ? I though you had coded it ? I've probably overlooked it ... CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sat Jan 17 13:42:11 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA03774 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 13:42:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA24213; Sat, 17 Jan 1998 16:08:07 -0500 Resent-Date: Sat, 17 Jan 1998 16:08:07 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: conlinux and devevent Date: 17 Jan 1998 21:07:26 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Distribution: local Message-ID: <69r6ie$nsr$1@grits.visus.com> References: <69qfis$5on$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"8Fed9.0.lv5.5sHmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/375 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > Well after a fair amount of hacking, I got the keyboard working in X. > This was just a hack on the xterm.c code, so what I'll do now is > implement it properly in conlinux.c. BUT, I need a way to attach the > 'conlinux' stack _before_ the xterm stack. [we will probably need this > for doing devevent too...]. Plain old "attach 12345678" isn't good > enough, it just ends up at the tail. `conlinux' isn't a stack - it DIRECTLY INTERFERES with the console device. See include/ggi/console.h for the definition of a console helper... [Basically, this is NEEDED to provide the icotl() interface (yet another reason we need return-codes, and it'll be a stack when that happens)] -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 13:46:15 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA03778 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 13:46:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA24296; Sat, 17 Jan 1998 16:12:32 -0500 Resent-Date: Sat, 17 Jan 1998 16:12:32 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: ev_rc functions ... Date: 17 Jan 1998 21:12:08 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Distribution: local Message-ID: <69r6r8$nsr$2@grits.visus.com> References: <69qphk$dl9$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"4zjz5.0.3x5.VwHmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/376 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > O.K. - I added some flesh to the ev_rc functions I added to evstack.c . > Please have a look and tell me, if you like them. The wait_queue support is > still missing, but that's probably no biggy. > I see one security problem with the overall concpet, though: > [snip reply-events discussion] Question: What would we lose if events (reply or otherwise) can be sent to another VT IF AND ONLY IF the user is root? This could solve a lot of security questions.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 15:33:47 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA03878 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 15:33:45 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA25109; Sat, 17 Jan 1998 18:00:10 -0500 Resent-Date: Sat, 17 Jan 1998 18:00:10 -0500 Date: Sat, 17 Jan 1998 19:02:17 -0500 (EST) From: MenTaLboY <mental@moonbase.dyn.ml.org> X-Sender: mental@moonbase Reply-To: mentalboy@geocities.com To: EvStack ML <evstack@ontv.com> Subject: Re: rc stuff In-Reply-To: <199801172345.SAA00822@moonbase.dyn.ml.org> Message-ID: <Pine.LNX.3.96.980117185247.866B-100000@moonbase> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"BVBKT2.0.p56.HVJmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/377 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > I see one security problem with the overall concpet, though: > > [snip reply-events discussion] > > Question: What would we lose if events (reply or otherwise) > can be sent to another VT IF AND ONLY IF the user is root? > > This could solve a lot of security questions.... That's kind of an awkward way to partition the EvStack system -- maybe we should generalize this to creating 'partitions' which (some or all) events cannot cross between (based upon criteria such as uid and event type)? i.e. one partition per user's VT cluster, rules require same uid or root to enter? -=MenTaLboY=- P.S. I'm not 100% sure my mail is getting to the list, since this is not the address I'm subscribed by... I have to do it this way, however, since moonbase.dyn.ml.org is my own machine, and thus only connected to the internet sporadically, and so my mail gets dropped at mentalboy@geocities.com ... anyone know how I could set up sendmail to rewrite outgoing headers to have mail from me appear to come from mentalboy@geocities.com ? From evstack-request@ontv.com Sat Jan 17 15:40:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA03890 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 15:40:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA25220; Sat, 17 Jan 1998 18:06:35 -0500 Resent-Date: Sat, 17 Jan 1998 18:06:35 -0500 Message-Id: <m0xthHH-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: conlinux and devevent To: evstack@ontv.com Date: Sun, 18 Jan 1998 10:03:47 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69r6ie$nsr$1@grits.visus.com> from "Jason McMullan" at Jan 17, 98 09:07:26 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jAOnf3.0.T96.XbJmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/378 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > `conlinux' isn't a stack - it DIRECTLY INTERFERES with the console > device. See include/ggi/console.h for the definition of a console helper... Well, in order to emulate raw keyboard mode, we need a way to grab the key events and convert them to scancodes, then call console_vt_stuffc() to send them to the tty. Thus I'm proposing to extend conlinux.c to have it's own stack too, which we can attach the termstack and grab the events. GETTING THE EVENTS is the main thing (also consuming them so we don't confuse the xterm). [And all this just to keep X happy... *sigh*] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 17 15:55:23 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA03901 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 15:55:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA25356; Sat, 17 Jan 1998 18:21:44 -0500 Resent-Date: Sat, 17 Jan 1998 18:21:44 -0500 Message-Id: <m0xthVg-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: conlinux and devevent To: evstack@ontv.com Date: Sun, 18 Jan 1998 10:18:40 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xtd1y-0000XgC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 17, 98 07:31:42 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gCaRl3.0.XB6.YpJmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/379 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > Well after a fair amount of hacking, I got the keyboard working in X. > > This was just a hack on the xterm.c code, so what I'll do now is > > implement it properly in conlinux.c. BUT, I need a way to attach the > > 'conlinux' stack _before_ the xterm stack. [we will probably need this > > for doing devevent too...]. Plain old "attach 12345678" isn't good > > enough, it just ends up at the tail. > > Yep. I like your priority proposal. Far better than the "insert before > stack #xxxxxxx" I had in mind quite some time ago. > > We should document the default priorities somewhere There's the header file... > Insertion policy would be "after the last stack with higher or equal > priority" and "if no priority is given, assume 0". Agreed on both counts. > BTW: Where is the selection support ? I though you had coded it ? > I've probably overlooked it ... The code was just a modification of xterm.c... It's better off in it's own stack, but I still need to sort out some things, like how to use the scroller directly, and how to use the MARK cursor (if at all), and if it should sit above or below the xterm ... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sat Jan 17 16:42:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA03972 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 16:42:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA25775; Sat, 17 Jan 1998 19:08:34 -0500 Resent-Date: Sat, 17 Jan 1998 19:08:34 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xthq0-0000XgC@charon.beck-sw.de> Subject: Re: ev_rc functions ... To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 18 Jan 1998 00:39:40 +0100 (MET) In-Reply-To: <69r6r8$nsr$2@grits.visus.com> from "Jason McMullan" at Jan 17, 98 09:12:08 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"CSAzG2.0.BI6.3VKmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/380 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > O.K. - I added some flesh to the ev_rc functions I added to evstack.c . > > I see one security problem with the overall concept, though: > > [snip reply-events discussion] > > Question: What would we lose if events (reply or otherwise) > can be sent to another VT IF AND ONLY IF the user is root? > > This could solve a lot of security questions.... I'd say this _should_be_the_case. It is no good to be able to either spy or interfere with another VT. /dev/event should get permissions from the corresponding /dev/tty. Only root should be able to access VTs other than his own. (except for VTs owned by the same user). So file permissions should do - right ? CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sat Jan 17 17:24:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA04014 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 17:24:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA25998; Sat, 17 Jan 1998 19:51:06 -0500 Resent-Date: Sat, 17 Jan 1998 19:51:06 -0500 Date: Sat, 17 Jan 1998 18:01:04 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: 2.1.78 boot... In-Reply-To: <69psvj$n6b$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980117175858.1091A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"LwMaU3.0.hL6.N7Lmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/381 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 17 Jan 1998, Jason McMullan wrote: > teunis (teunis@mauve.computersupportcentre.com) wrote: > > On 17 Jan 1998, Jason McMullan wrote: > > > SAK can _never_ be ignored, unless you are root and EXCLICITLY unmap it. > > > So what's the behaviour of SAK supposed to be? > > Would there be a reason for me to catch it? > > SAK kills all processes on the current VT. And no, you _really_ > don't want to catch it unless you want the cude to run as root... Any kind of recovery needed? Or can I assume KGI will take care of everything? (note: AFAIK SAK will kill the cube. No big deal) > > Also - any suggestions on configurability options? Should I make a > > config file? open an EvStack for external configuration? any other > > ideas? > > A `~/.ggi/evCube' config file would be good.... Shall do! > > note: > > beasty is 6 consoles on the sides of a cube. It would TRUELY be icing on > > cake if I could run 6 GGI apps - one on each side of the console :) > > You'd have to write a `display-cube' driver for libGGI - basically, > it would perform the rotation/shearing needed an pump the pixels to > the Cube. Not too hard. Considering I'm writing libGGI3D? *grin*... No prob :) [I'm the one that keeps asking for non-Mesa OpenGL as libGGI3D BTW - I have a complete 3D rendering library and IMHO it's cleaner. It may not be faster but we can use _ANY_ license on it. (I'm considering Berkeley license, but I'll prolly use LGPL)]. G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 17 17:37:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA04053 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 17:37:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA26267; Sat, 17 Jan 1998 20:03:40 -0500 Resent-Date: Sat, 17 Jan 1998 20:03:40 -0500 Date: Sat, 17 Jan 1998 18:13:32 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: andreas.beck@ggi-project.org cc: Evstack Mailing List <evstack@ontv.com>, mailing list GGI <linux-ggi@eskimo.com> Subject: Re: display-CUBE In-Reply-To: <m0xtXgO-0000XgC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980117180255.1091B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4Wbpp3.0.lP6.9JLmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/382 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sat, 17 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > note: > > > beasty is 6 consoles on the sides of a cube. It would TRUELY be icing on > > > cake if I could run 6 GGI apps - one on each side of the console :) > > > > You'd have to write a `display-cube' driver for libGGI - basically, > > it would perform the rotation/shearing needed an pump the pixels to > > the Cube. Not too hard. > > Yes. A simple implementation would be to have a "display-cube" target, > which takes a parameter (the side of the cube) and draws to a shared memory > area. An extension perhaps? :) I already have the graphics library (32BPP ARGB :), I just need to port it to GGI. I've actually taken the time to make it semi-efficient :) Ah - make it a target (with extensions :) > Now another application (the cube-renderer) would grab all the shared memory > areas and use them as textures. Input could be redirected by named pipes or > via some protocol running on part of the shared memory. I've been using unnamed pipes with /dev/pty* coordination. I could use network sockets as well - but I'd rather use an EvStack :) > This would nicely allow (assuming the console is still useable after the > cube is there, e.g. under X): > > bash$ cubeserver > bash$ LIBGGI_DISPLAY="display-cube:1" demo 16 200 200 > bash$ LIBGGI_DISPLAY="display-cube:2" graphterm > etc. ... *g* - in userspace this is basically a telnet session with special capabilities.... I wonder how to autodetect the target? (linux-term though, not xterm) > >From the programming point of view this is bloody simple. Teunis ? > Anyone else ? > > I think it would be a bloody cool exmaple of LibGGI flexibility to > be able to redirect the output of apps to the sides of a spinning > cube ... Shall do! Give me a week (I said 2 last week - I'm not changing my schedual :) BTW - EvStacks works great :) Just checking ggidrv now (VGA, as the S3 driver doesn't yet compile) Okay - I'm getting oops on load/unload (I'll post later if interested). It runs perfectly so far... but the cursor is one place to the left. I can't (yet) get libGGI to compile *sigh*... Header problems. Make that the cursor seems to shift more to the left as you increase your position on the side. But it works :) (loads and unloads too :) SVGAlib works though, but I'm gonna have to attack X probs (keyboard) *sigh*. G'day, eh? :) - Teunis PS : Is there anyway to turn off the debug? It's seriously messing up all my consoles. I'm recompiling now... but it'd be handy if I could track the errors / etc for debugging drivers. I wanna work on S3-ViRGE (my primary card) and S3-Trio64V+ (secondary card) From evstack-request@ontv.com Sat Jan 17 17:54:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA04073 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 17:54:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA26390; Sat, 17 Jan 1998 20:20:46 -0500 Resent-Date: Sat, 17 Jan 1998 20:20:46 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: rc stuff Date: 18 Jan 1998 01:19:50 GMT Organization: OnTV Pittsburgh, L.P. Lines: 34 Distribution: local Message-ID: <69rlbm$3gn$1@grits.visus.com> References: <69rdf5$tfn$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"JxLm81.0.mR6.iYLmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/383 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com MenTaLboY (mental@moonbase.dyn.ml.org) wrote: > > > I see one security problem with the overall concpet, though: > > > [snip reply-events discussion] > > > > Question: What would we lose if events (reply or otherwise) > > can be sent to another VT IF AND ONLY IF the user is root? > > > > This could solve a lot of security questions.... > That's kind of an awkward way to partition the EvStack system -- maybe we > should generalize this to creating 'partitions' which (some or all) events > cannot cross between (based upon criteria such as uid and event type)? i.e. > one partition per user's VT cluster, rules require same uid or root to > enter? This will require some thought... I recommend we go with a simple `hard-line' solution, find out what can't be done, and re-design later. > mentalboy@geocities.com ... anyone know how I could set up sendmail to > rewrite outgoing headers to have mail from me appear to come from > mentalboy@geocities.com ? I'm not sure about sendmail, but my `~/.elm/elmheaders' file has by `From' and `Reply-To' lines... That seems to work for me... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 18:35:43 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA04144 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 18:35:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA26749; Sat, 17 Jan 1998 21:02:06 -0500 Resent-Date: Sat, 17 Jan 1998 21:02:06 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: 2.1.78 boot... Date: 18 Jan 1998 02:01:42 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Distribution: local Message-ID: <69rnq6$5e1$1@grits.visus.com> References: <69rn4t$59d$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"hc7Hv.0.NX6.z9Mmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/384 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > On 17 Jan 1998, Jason McMullan wrote: > > SAK kills all processes on the current VT. And no, you _really_ > > don't want to catch it unless you want the cude to run as root... > Any kind of recovery needed? Or can I assume KGI will take care of > everything? (note: AFAIK SAK will kill the cube. No big deal) SAK takes care of recovery: All processes on VTxx are SIGKILLed, the mode is reset to default mode for that VT's scroller, and init re-start getty on that VT... > [I'm the one that keeps asking for non-Mesa OpenGL as libGGI3D BTW - I > have a complete 3D rendering library and IMHO it's cleaner. It may not be > faster but we can use _ANY_ license on it. (I'm considering Berkeley > license, but I'll prolly use LGPL)]. I've kinda kept out of that debate since I left the care and feeding of libGGI to Andreas, but does your library do full OpenGL compatability? We will need that. Also, Mesa DOES have the advantage that a lot more people are `interested' in maintaining it. I would like to see both your implementation as libGGI3D, and Mesa as libOpenGL. That way, we'll have our own `distrib' of OpenGL we can modify as we see fit, and a `standard' OpenGL that is known to pass the SGI OpenGL compatability tests - you know, the old `speed versus compatability' arguments... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 18:45:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA04151 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 18:45:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA26851; Sat, 17 Jan 1998 21:11:31 -0500 Resent-Date: Sat, 17 Jan 1998 21:11:31 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: ev_rc functions ... Date: 18 Jan 1998 02:11:04 GMT Organization: OnTV Pittsburgh, L.P. Lines: 20 Distribution: local Message-ID: <69robo$5e1$2@grits.visus.com> References: <69rn4s$59c$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"n9zSo3.0.-Y6.kIMmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/385 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > I'd say this _should_be_the_case. It is no good to be able to either spy or > interfere with another VT. /dev/event should get permissions from the > corresponding /dev/tty. Only root should be able to access VTs other > than his own. (except for VTs owned by the same user). [I was prepared with a counter-argument to your `expection', but then realized that std. Unix tty permission allow similar problems.] > So file permissions should do - right ? They will be no less problematic that than what we already have. Who wants to modify login(1)? ;^) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Sat Jan 17 19:42:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA04224 for <ggi@synergy.foo.net>; Sat, 17 Jan 1998 19:42:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA27344; Sat, 17 Jan 1998 22:08:40 -0500 Resent-Date: Sat, 17 Jan 1998 22:08:40 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xtkD7-0000XUC@charon.beck-sw.de> Subject: Re: 2.1.78 boot... To: evstack@ontv.com Date: Sun, 18 Jan 1998 03:11:41 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980117175858.1091A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 17, 98 06:01:04 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"GLJKS1.0.hg6.F8Nmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/386 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > SAK kills all processes on the current VT. And no, you _really_ > > don't want to catch it unless you want the cube to run as root... > Any kind of recovery needed? No. The catch with SAK is that you can't catch it ;-). O.K. - I'll explain a bit more thoroughly why SAK is a good idea and what it does: SAK means Secure Attention Key. This means that it can _always_ be used (thus secure) to get the system's attention. When you press it, you say: No matter what you are doing - kill it off and take me to a logon prompt. This enhaces security in two ways : 1. Even if your terminal is in some unusable state (e.g. a sick line- discipline or stuck in a crashed graphics application), SAK will revive it. 2. You are guaranteed to have all processes attached to the current VT killed off which will cause the system to spawn a new getty. While the 1st thing is obviously good for system stability, the second one enhances logon security. Why ? Because some people like to write "fake logon-screens" i.e. programs which look like the system logon prompt and grab your password, tell you "password incorrect" and then terminate leaving you with a real logon. As typos are common, this method often succeeds ... > Or can I assume KGI will take care of everything? Yep. KGI will kill your cube and reset to default mode. CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sun Jan 18 02:11:00 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA04680 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 02:10:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id EAA30640; Sun, 18 Jan 1998 04:37:18 -0500 Resent-Date: Sun, 18 Jan 1998 04:37:18 -0500 Message-Id: <m0xtr6k-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/graph functional! To: evstack@ontv.com Date: Sun, 18 Jan 1998 20:33:34 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69pmld$i1b$1@grits.visus.com> from "Jason McMullan" at Jan 17, 98 07:29:49 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aB8EN1.0.DU7.pqSmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/387 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Andrew Apted (ajapted@netspace.net.au) wrote: > > > It isn't working here. The VGA driver still inserts and removes > > beautifully, but neither testvid or the libggi demo work. > > Did you make sure to compile thge dev/graph module into ther > kernel? Yep. > > I'm invoking it like this: > > testvid /dev/graph03 320 200 320 200 8 > > should that work? Using /dev/graphic gives a "No such device" error. > > That should work IF you have opened a tty on /dev/vty03. (just > an `echo hi there >/dev/vty03' will do it.) Still no go :-(. The echo on /dev/vty09 shows the following: warning: dev(04:01) tty_count(6) != #fd's(2) in tty_open warning: dev(04:01) tty_count(6) != #fd's(2) in release_dev release_dev: driver.table[1] not tty for (04:01) [similiar output with other vtys] Any ideas ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 18 02:38:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA04712 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 02:38:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA30941; Sun, 18 Jan 1998 05:04:24 -0500 Resent-Date: Sun, 18 Jan 1998 05:04:24 -0500 Message-Id: <m0xtrX4-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Stack priorities To: evstack@ontv.com Date: Sun, 18 Jan 1998 21:00:46 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7cq852.0.sY7.GETmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/388 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi everyone, I have implemented "attach" priorities, here in my local tree, and it's working nicely. I just want to be sure that we're all agreed before I commit it. Jason, is this alright with you ? On another note, having two separate keymaps for two keyboards is _very_ close to working [although I haven't got two keyboards plugged in, so it might be hard to test it :)]. It works by just having an input_stack for each keyboard, and a keymap on each one. The only thing stopping it working *right now* is the fact that the keymap's open call doesn't make a *stack local* instance of the keymap -- easily fixed though! As for the RAW keyboard problem [a.k.a the X problem :-)], I know how to get round it (see my other post), but it does need the attach-with-priority semantics to work... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 18 03:24:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA04762 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 03:24:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA31174; Sun, 18 Jan 1998 05:51:16 -0500 Resent-Date: Sun, 18 Jan 1998 05:51:16 -0500 Message-Id: <199801180950.KAA00660@c125.ryd.student.liu.se> X-Mailer: exmh version 1.6.9 05/05/96 To: mentalboy@geocities.com cc: EvStack ML <evstack@ontv.com> Subject: Re: rc stuff In-reply-to: Your message of "Sat, 17 Jan 1998 19:02:17 EST." <Pine.LNX.3.96.980117185247.866B-100000@moonbase> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 18 Jan 1998 10:50:00 +0100 From: Alexander Larsson <alla@lysator.liu.se> Resent-Message-ID: <"2250o1.0.Zc7.DwTmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/389 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > P.S. I'm not 100% sure my mail is getting to the list, since this is not the > address I'm subscribed by... I have to do it this way, however, since > moonbase.dyn.ml.org is my own machine, and thus only connected to the > internet sporadically, and so my mail gets dropped at > mentalboy@geocities.com ... anyone know how I could set up sendmail to > rewrite outgoing headers to have mail from me appear to come from > mentalboy@geocities.com ? I use Redhat 4.2, this guide is for it. change waht you need for your system. Apply this diff to sendmail.cf (manually probably...) ------------------------------------- --- sendmail.cf.orig Fri Jan 9 16:37:46 1998 +++ sendmail.cf Fri Jan 9 16:51:23 1998 @@ -303,7 +303,10 @@ O DefaultUser=8:12 # list of locations of user database file (null means no lookup) -#O UserDatabaseSpec=/etc/userdb +O UserDatabaseSpec=/etc/userdb.db + +# Define our usrdb file for Pine (and hopefully exmh) rewrites +Kuserdb btree -o /etc/userdb.db # fallback MX host #O FallbackMXhost=fall.back.host.net @@ -636,6 +639,24 @@ # handle locally delivered names R$=L $#local $: @ $1 special local names R$+ $#local $: $1 regular local names + +########################################################################### +### Ruleset 1, rewrite sender header & envelope ### +########################################################################### + +#Thanks to Bjart Kvarme <bjart.kvarme@usit.uio.no>. From FAQ +S1 +R$- < @ $=w . > $* $: $1 < @ $2 . > $3 ?? $1 username@localhost? + +R$+ ?? $+ $: $1 ?? $(userdb $2 : mailname $: @ $) +R$+ ?? @ $@ $1 Not found +R$+ ?? $+ $>3 $2 Found, rewrite + + +#NOTE ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ +# Use Tab Characters Use Tab Characters in these regions +# to make three columns (the line with "mailname" only has 2 columns). + ########################################################################### ### Ruleset 5 -- special rewriting after aliases have been expanded ### --------------------------------------- Put this file as /etc/userdb (note, this is mine you have to change it, but i think you understand the concept.) -------------- #Create db by: makemap btree /etc/userdb.db < /etc/userdb alex:mailname alla@lysator.liu.se anna:mailname annro125@student.liu.se -------------- Then create the binary db as in the comment in userdb above. Restart sendmail by: /etc/rc.d/init.d/sendmail.init stop /etc/rc.d/init.d/sendmail.init start / Alex From evstack-request@ontv.com Sun Jan 18 03:59:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA04783 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 03:59:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA31517; Sun, 18 Jan 1998 06:26:15 -0500 Resent-Date: Sun, 18 Jan 1998 06:26:15 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xttb7-0000XUC@charon.beck-sw.de> Subject: Re: ev_rc functions ... To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 18 Jan 1998 13:13:05 +0100 (MET) In-Reply-To: <69robo$5e1$2@grits.visus.com> from "Jason McMullan" at Jan 18, 98 02:11:04 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Tp-tB3.0.Wh7.xQUmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/390 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > I'd say this _should_be_the_case. It is no good to be able to either spy or > > interfere with another VT. /dev/event should get permissions from the > > corresponding /dev/tty. Only root should be able to access VTs other > > than his own. (except for VTs owned by the same user). > > [I was prepared with a counter-argument to your `expection', but > then realized that std. Unix tty permission allow similar problems.] > > > So file permissions should do - right ? > > They will be no less problematic that than what we already have. > Who wants to modify login(1)? ;^) If nothing else helps, I will do. I got some experience with that (I'm still running a nicely modified login which is once and for all safe against the -froot trick, even if not all the gettys have been modified). I haven't yet tried a PAM system, but if the PAM modules get called with root priviledges still, it should be a piece of cake to write a fake PAM module which gets called after the user has been authenticated (as an additional "authentication" step) which always says "auth ok" and sets permissions on all workplace-specific files to "user.* 600". Would finally shut down that nasty /dev/audio holes ... CU,ANdy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sun Jan 18 04:00:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA04787 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 04:00:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA31547; Sun, 18 Jan 1998 06:26:32 -0500 Resent-Date: Sun, 18 Jan 1998 06:26:32 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xttnU-0000XUC@charon.beck-sw.de> Subject: Re: display-CUBE To: evstack@ontv.com Date: Sun, 18 Jan 1998 13:25:52 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980117180255.1091B-100000@sigil.computersupportcentre.com> from "teunis" at Jan 17, 98 06:13:32 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"ndKNl2.0.1i7.ERUmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/391 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Yes. A simple implementation would be to have a "display-cube" target, > > which takes a parameter (the side of the cube) and draws to a shared memory > > area. > > An extension perhaps? :) > I already have the graphics library (32BPP ARGB :), I just need to port it > to GGI. I've actually taken the time to make it semi-efficient :) > > Ah - make it a target (with extensions :) O.K. - stop - let's make terms clear here and how one would do it. You operate on a 32 bit framebuffer - right ? No fancy accel access - right ? O.K. - so make your 3D library a LibGGI extension. This basically means that it registers its per-visual state with LibGGI at the beginning and gets notified of LibGGI loading display-libs. For the "display-cube" trick one would write yet another LibGGI target as I described in my mail which renders to shmem. Once you've done this the scenario looks like that : Your cube-application registers 6 shmem areas for the "textures" i.e. the sides' contents. It then uses your LibGGI-Extension to draw the cube to a common LibGGI visual (which probably happens to be limited to 32 bit modes, except if you write a stubs_3d.so library which falls back to LibGGI calls). The other applications (that display on the sides of the cube) are set to use the display-cube (or rather display-shmem) target, so they map themselves into the texture areas of the main app. > SVGAlib works though, but I'm gonna have to attack X probs (keyboard) *sigh*. I think Andrew is working on that ... > PS : Is there anyway to turn off the debug? It's seriously messing up all > my consoles. klogd ? CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sun Jan 18 15:07:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA05339 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 15:07:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA03382; Sun, 18 Jan 1998 17:33:22 -0500 Resent-Date: Sun, 18 Jan 1998 17:33:22 -0500 From: guillaum@clipper.ens.fr (Florent Guillaume) Date: Sun, 18 Jan 1998 23:32:03 +0100 (MET) Message-Id: <199801182232.XAA11477@drakkar.ens.fr> To: evstack@ontv.com Subject: SAK Resent-Message-ID: <"JpRmV2.0.Cq.iBemq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/392 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > When you press it [SAK], you say: No matter what you are doing - kill > it off and take me to a logon prompt. Okay, but then how would an application like "xlock" work ? Will it have to be setuid-root and temporarily remove the SAK mapping ? Florent From evstack-request@ontv.com Sun Jan 18 15:43:42 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA05421 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 15:43:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA03775; Sun, 18 Jan 1998 18:09:44 -0500 Resent-Date: Sun, 18 Jan 1998 18:09:44 -0500 Message-Id: <m0xu3ky-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: display-CUBE To: evstack@ontv.com Date: Mon, 19 Jan 1998 10:03:56 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xttnU-0000XUC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 18, 98 01:25:52 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RHTnr.0.Sw.gjemq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/393 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Teunis, how about this for an idea. Use RIGHT alt + function key for your usermode console switching, and keep LEFT alt for normal kernelmode console switching. [This is how my fvwm2 is setup, with four virtual X screens...]. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 18 16:20:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA05452 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 16:20:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA04003; Sun, 18 Jan 1998 18:46:09 -0500 Resent-Date: Sun, 18 Jan 1998 18:46:09 -0500 Date: Sun, 18 Jan 1998 23:29:35 +0100 (MET) From: Matthias Grimrath <m.grimrath@tu-bs.de> To: evstack@ontv.com Subject: Re: keymapping and /proc In-Reply-To: <m0xs5EY-00017HC@ajax> Message-ID: <Pine.LNX.3.96.980118232651.423A-100000@lidschi.wgnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"HuSOc2.0.zz.LGfmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/394 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998, Andrew Apted wrote: > BTW, does anyone know what 'P' means when doing a CVS update ? Yes. It's documented in the info files. Go to node cvs/commands/update/update output/ `P FILE' Like `U', but the CVS server sends a patch instead of an entire file. These two things accomplish the same thing. Matthias Grimrath From evstack-request@ontv.com Sun Jan 18 16:28:00 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA05466 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 16:27:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA04113; Sun, 18 Jan 1998 18:54:09 -0500 Resent-Date: Sun, 18 Jan 1998 18:54:09 -0500 Date: Sun, 18 Jan 1998 19:55:53 -0500 (EST) From: MenTaLboY <mentalboy@geocities.com> X-Sender: mental@moonbase Reply-To: mentalboy@geocities.com To: EvStack ML <evstack@ontv.com> Subject: Re: display-CUBE (fwd) Message-ID: <Pine.LNX.3.96.980118195535.550B-100000@moonbase> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Cauz63.0.V_.LNfmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/395 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com whoops... meant to send to the ML... ---------- Forwarded message ---------- Date: Sun, 18 Jan 1998 19:54:01 -0500 (EST) From: MenTaLboY <mental@moonbase.dyn.ml.org> Reply-To: mentalboy@geocities.com To: ajapted@netspace.net.au Subject: Re: display-CUBE > Teunis, how about this for an idea. Use RIGHT alt + function key for > your usermode console switching, and keep LEFT alt for normal kernelmode > console switching. [This is how my fvwm2 is setup, with four virtual X > screens...]. Aren't we already using right alt for text VTs and left for graphical VTs? -=MenTaLboY=- From evstack-request@ontv.com Sun Jan 18 16:45:09 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA05484 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 16:45:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA04420; Sun, 18 Jan 1998 19:11:20 -0500 Resent-Date: Sun, 18 Jan 1998 19:11:20 -0500 Message-Id: <m0xu4jZ-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: keymapping and /proc To: evstack@ontv.com Date: Mon, 19 Jan 1998 11:06:33 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980118232651.423A-100000@lidschi.wgnet> from "Matthias Grimrath" at Jan 18, 98 11:29:35 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"gVEe23.0.W41.Ydfmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/396 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Matthias Grimrath writes: > On Tue, 13 Jan 1998, Andrew Apted wrote: > > > BTW, does anyone know what 'P' means when doing a CVS update ? > > Yes. It's documented in the info files. > > Go to node cvs/commands/update/update output/ > > `P FILE' > Like `U', but the CVS server sends a patch instead of an entire > file. These two things accomplish the same thing. Ahh thanks. It's not mentioned in my cvs info files (cvs version 1.9), I guess it's been updated... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 18 18:29:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA05555 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 18:29:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA05187; Sun, 18 Jan 1998 20:56:02 -0500 Resent-Date: Sun, 18 Jan 1998 20:56:02 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xu6QZ-0000XUC@charon.beck-sw.de> Subject: Re: SAK To: evstack@ontv.com Date: Mon, 19 Jan 1998 02:55:02 +0100 (MET) In-Reply-To: <199801182232.XAA11477@drakkar.ens.fr> from "Florent Guillaume" at Jan 18, 98 11:32:03 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"0wXUF.0.vF1.2Ahmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/397 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > When you press it [SAK], you say: No matter what you are doing - kill > > it off and take me to a logon prompt. > Okay, but then how would an application like "xlock" work ? Will it > have to be setuid-root and temporarily remove the SAK mapping ? Yes. Just like NT or solaris does : You can unlock the screen with the user- or with the root password. Any such app which potentially blocks access to the machine should have such a backdoor for priviledged users. Many sysadmins at universities or other institutions, where many people have access to the same pool also use hacked versions, which allow ordinary users to terminate xlocks that haven been active for excessive amounts of time. This requires you to log in at the xlock which will then take down the locked session and let you log on. This is much nicer than having to press STOP-A and reboot the machine this way ... CU, Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sun Jan 18 18:30:19 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA05559 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 18:30:18 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA05203; Sun, 18 Jan 1998 20:56:30 -0500 Resent-Date: Sun, 18 Jan 1998 20:56:30 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xu7JF-0000XUC@charon.beck-sw.de> Subject: Re: Standard key/mouse UI To: bri@forcade.calyx.net (Brian Julin) Date: Mon, 19 Jan 1998 03:51:33 +0100 (MET) Cc: evstack@ontv.com (Evstack Mailing List) In-Reply-To: <Pine.BSF.3.91.980118170554.5118B-100000@forcade.calyx.net> from "Brian Julin" at Jan 18, 98 07:01:59 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"gCLuS1.0.7G1.3Ahmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/398 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > I was more worried that the mapping of the keys would disperse > them about the foreign keyboard in a less than useful fashion, > or force multi-key strokes when single key strokes are desireable. > Some sort of physical UNICODE layout mapping file rated by convenience > and handedness would be necessary, then the internationalized app > would do something like: > > if (key == keystrokes(12, 1, handedness)) { /* blah */ } > > ... meaning the twelfth most convenient single keystroke (including > shifts) dependent on left-right handedness. (A commonly used keystroke > to set handedness would be nice, too.) Hmm - this would be very hard to express in the documentation - wouldn't it ? And preferences might vary. I'd really say go for full configurability. > Heck I'd even prefer VC selection to be keybased. I only want > mouse when it is needed, and then I don't want to have to reach across > the keyboard with my free hand to hit a letter on the other side, > nor do I like popup menus unless the application is complex enough > to merit them and does really good context sensing. I think being > able to hold down the mouse button and then hit a key which is under > my free hand to execute some function would be the most usable way > (effectively gives you about 40-50 mouse buttons counting shifts, less > if using just the keyboard though) -- funny how few UIs do this. > I think apple does to some extent. I suspect because many people are very centered on handling only _one_ device ... I do not care - if you want to be an at least descent action-game player, you need to be able to handle two controls at the same time ... But I have seen many people which get that centered on using the mouse that something like shift-clicking is already something difficult and strange for them ... CU,ANdy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Sun Jan 18 21:03:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA05889 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 21:03:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA06259; Sun, 18 Jan 1998 23:29:28 -0500 Resent-Date: Sun, 18 Jan 1998 23:29:28 -0500 Message-Id: <m0xu8ki-00017NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: display-CUBE (fwd) To: evstack@ontv.com Date: Mon, 19 Jan 1998 15:24:00 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980118195535.550B-100000@moonbase> from "MenTaLboY" at Jan 18, 98 07:55:53 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KaaWD3.0.DX1.cOjmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/399 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com MenTaLboY writes: > > Teunis, how about this for an idea. Use RIGHT alt + function key for > > your usermode console switching, and keep LEFT alt for normal kernelmode > > console switching. [This is how my fvwm2 is setup, with four virtual X > > screens...]. > > Aren't we already using right alt for text VTs and left for graphical VTs? I'm pretty sure that for EvStack/Degas we're going back to using just left-ALT for VT switches. [suits me, fwiw] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 18 21:47:23 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA05939 for <ggi@synergy.foo.net>; Sun, 18 Jan 1998 21:47:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA06693; Mon, 19 Jan 1998 00:13:19 -0500 Resent-Date: Mon, 19 Jan 1998 00:13:19 -0500 Message-ID: <007f01bd2498$a1d10160$0c0a0a0a@massacre> From: "David Waite" <mass@ufl.edu> To: "Evstack Mailing List" <evstack@ontv.com> Subject: FYI and asking for topics and information for evstack documentation Date: Mon, 19 Jan 1998 00:10:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"HyL5_2.0.4e1.L2kmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/400 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com first off my email address is now mass@ufl.edu, my old provider has proven to me that they are not capable of administering a machine (long story) Second, I am now thinking about writing some general programming info for evstack (and maybe some for ggi). Any ideas for topics? I have heard 'What the heck is EvStacks?' and 'How to convert ggi-0.0.9 drivers to ggi-0.1.0' -David Waite From evstack-request@ontv.com Mon Jan 19 07:14:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA06721 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 07:14:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA13654; Mon, 19 Jan 1998 09:40:15 -0500 Resent-Date: Mon, 19 Jan 1998 09:40:15 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/graph functional! Date: 19 Jan 1998 14:39:00 GMT Organization: OnTV Pittsburgh, L.P. Lines: 34 Distribution: local Message-ID: <69voi4$4n6$1@grits.visus.com> References: <69siv5$mkb$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"L-OET2.0.XK3.xLsmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/401 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > Jason McMullan writes: > > Andrew Apted (ajapted@netspace.net.au) wrote: > > > > > It isn't working here. The VGA driver still inserts and removes > > > beautifully, but neither testvid or the libggi demo work. > > > > Did you make sure to compile thge dev/graph module into ther > > kernel? > Yep. Blech... There's some un-initialized (or buffer over-run, or whatever), but it doesn't tickle my system... Couldn't make it Oops all weekend... Do you get Oops? > Still no go :-(. The echo on /dev/vty09 shows the following: > warning: dev(04:01) tty_count(6) != #fd's(2) in tty_open > warning: dev(04:01) tty_count(6) != #fd's(2) in release_dev > release_dev: driver.table[1] not tty for (04:01) > > [similiar output with other vtys] Argh! Argh! Argh!.... Can you uuencode & email me your kernel? I'll try to find a machine I can run it on.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 07:20:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA06736 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 07:20:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA13756; Mon, 19 Jan 1998 09:46:17 -0500 Resent-Date: Mon, 19 Jan 1998 09:46:17 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: SAK Date: 19 Jan 1998 14:45:53 GMT Organization: OnTV Pittsburgh, L.P. Lines: 16 Distribution: local Message-ID: <69vov1$4n6$2@grits.visus.com> References: <69u0c8$r7t$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"9Osk63.0.MM3.JSsmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/402 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Florent Guillaume (guillaum@clipper.ens.fr) wrote: > > When you press it [SAK], you say: No matter what you are doing - kill > > it off and take me to a logon prompt. > Okay, but then how would an application like "xlock" work ? Will it > have to be setuid-root and temporarily remove the SAK mapping ? No. Under that case you imply that you're running under XDM (otherwise XLock is kinda useless), and since XDM needs to be setuid root for other things.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 07:22:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA06743 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 07:22:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA13825; Mon, 19 Jan 1998 09:48:08 -0500 Resent-Date: Mon, 19 Jan 1998 09:48:08 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Stack priorities Date: 19 Jan 1998 14:47:26 GMT Organization: OnTV Pittsburgh, L.P. Lines: 23 Distribution: local Message-ID: <69vp1u$4n6$3@grits.visus.com> References: <69ske2$nag$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"n3mft3.0.RN3.nTsmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/403 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > I have implemented "attach" priorities, here in my local tree, and it's > working nicely. I just want to be sure that we're all agreed before I > commit it. Jason, is this alright with you ? Go for it. > On another note, having two separate keymaps for two keyboards is _very_ > close to working [although I haven't got two keyboards plugged in, so it > might be hard to test it :)]. It works by just having an input_stack for > each keyboard, and a keymap on each one. The only thing stopping it > working *right now* is the fact that the keymap's open call doesn't > make a *stack local* instance of the keymap -- easily fixed though! Does ANYONE have info on how to hook a PS2 keyboard to the PS2 mouse port & get data from it??? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 10:47:49 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA07100 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 10:47:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA15892; Mon, 19 Jan 1998 13:13:15 -0500 Resent-Date: Mon, 19 Jan 1998 13:13:15 -0500 Sender: core@tron.mirus.fr Message-ID: <34C3954E.3CC5DB7D@mirus.fr> Date: Mon, 19 Jan 1998 19:02:54 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: First blood Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ge-i71.0.Vt3.dSvmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/404 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello, I finally tried the current evstack kernel today. Okay, first, good news: it boots. :) The machine I tested is : * Cyrix Media GX 120 mhz * Cyrix CX5510 companion chip * Linux kernel 2.1.79 * French keymap I'm sorry, I didn't follow the mailing list at all before, I was too busy with the GX driver and other things.. :) So sorry if these are known 'features', but I noticed : Boot time : * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. Is it on purpose, or does it provoke a double or triple CPU fault by accident? :) * I have lots of "cannot bind [key here] to [function code here]" when booting. I'll try to debug that. * I can't page up/down the console with shift + pgup/pgdown. Not implemented or more serious buggie? I will test it on my home system (P133, Intel Triton II motherboard, Mystique 220 rev 2 board) home tonight, and on a 200 Mhz MediaGXm/5520 board tomorrow. Insmodding the driver (VGA-everything) : * Cursor is not displayed at the right position The line is "/home/core/ggi-evstack/driver#" and it's under the "v" instead of being after the "#". NOTE: The MediaGX has no textmode and is even emulating VGA in software. It might not be completely EvStack-related - though I never seen it emulate the cursor wrong with previous KGI VGA driver. * There is a "newline" code problem or something; All driver messages appear on the same line (noticed that too during boottime with some registration messages) and they are overwritten by the prompt when the driver has been insmodded. Trying libggi programs : None will want to set a graphical mode; either with current Dali-branch libggi, or recompiling libggi from the EvStack branch (and after copying missing files from the dali branch :). I will try to hunt all of the problems above. Congrats for making it even BOOT :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org/~ggi - Netnation project: open soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Mon Jan 19 11:08:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA07158 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 11:08:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA16112; Mon, 19 Jan 1998 13:34:44 -0500 Resent-Date: Mon, 19 Jan 1998 13:34:44 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: First blood Date: 19 Jan 1998 18:33:07 GMT Organization: OnTV Pittsburgh, L.P. Lines: 85 Distribution: local Message-ID: <6a0693$fqm$1@grits.visus.com> References: <6a05gu$fnd$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"nfIWK3.0.Cx3.Mnvmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/405 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > I finally tried the current evstack kernel today. Okay, first, > good news: it boots. :) The machine I tested is : Yeah! > * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. > Is it on purpose, or does it provoke a double or triple CPU fault > by accident? :) Oops - blame me. I'll have it fixed by tomorrow. > * I have lots of "cannot bind [key here] to [function code here]" when > booting. I'll try to debug that. That's because `conlinux' doesn't yet support keymap re-binding with the old loadkeys() ioctls. > * I can't page up/down the console with shift + pgup/pgdown. Not > implemented or more serious buggie? Not implemented. Needs to be put in the `kgiscroll' module. (ie, when finished you can set the graphics mode to `720x350[720x700]' and you have 25 lines of backscroll) > I will test it on my home system (P133, Intel Triton II motherboard, > Mystique 220 rev 2 board) home tonight, and on a 200 Mhz MediaGXm/5520 > board tomorrow. Spiff. > Insmodding the driver (VGA-everything) : > * Cursor is not displayed at the right position > The line is "/home/core/ggi-evstack/driver#" and it's under the "v" > instead of being after the "#". Known problem. Still trying to track it down. The `oops' that some people were getting is a higher priority, but I haven't been able to replicate it.. yet... > NOTE: The MediaGX has no textmode and is even emulating VGA in > software. It might not be completely EvStack-related - though I > never seen it emulate the cursor wrong with previous KGI VGA driver. Nope - problem with out code. > * There is a "newline" code problem or something; All driver messages > appear on the same line (noticed that too during boottime with > some registration messages) and they are overwritten by the prompt > when the driver has been insmodded. Known `problem' - due to the isolation between the Xterm and the scoller driver, and the fact that: a) We didn't want printk() to rely on the existence of a terminal driver and b) we don't want the xterm terminal driver to have to poll for the current drawing cursor position after each printk. I'll have the `printk console' as a LILO: and compile-time settable option (hopefully) by Wednesday. Right now, if you have a Hercules card handy, just enabling the MONO boot display support will divert all the printk()s to the Herc. > Trying libggi programs : > None will want to set a graphical mode; either with current Dali-branch > libggi, or recompiling libggi from the EvStack branch (and after > copying missing files from the dali branch :). I feel so lonely..... > I will try to hunt all of the problems above. Congrats for making it > even BOOT :) At least we have that... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 11:55:02 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA07227 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 11:55:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA16632; Mon, 19 Jan 1998 14:20:55 -0500 Resent-Date: Mon, 19 Jan 1998 14:20:55 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xuMzr-0000XUC@charon.beck-sw.de> Subject: Re: Stack priorities To: evstack@ontv.com (Evstack Mailing List) Date: Mon, 19 Jan 1998 20:36:35 +0100 (MET) In-Reply-To: <69vp1u$4n6$3@grits.visus.com> from "Jason McMullan" at Jan 19, 98 02:47:26 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"tAbq1.0.H34.cSwmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/406 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Does ANYONE have info on how to hook a PS2 keyboard to the > PS2 mouse port & get data from it??? I have once occasionally swapped ports for mouse and keyboard on my Alpha. This resulted in the mouse producing keyboard input. I assume it should be as simple as taking the data coming from the mouse port, not interpreting it as mouse, but as keyboard protocol. If someone has the HW (I don't have a PS/2 port) he could simply take the PS2 mouse driver and rip out the mouse protocol and let it rather send raw data events which can easily be dumped for investigation ... CU,ANdy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Mon Jan 19 12:50:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA07260 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 12:50:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id PAA17287; Mon, 19 Jan 1998 15:16:07 -0500 Resent-Date: Mon, 19 Jan 1998 15:16:07 -0500 Date: Mon, 19 Jan 1998 13:25:13 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: andreas.beck@ggi-project.org cc: evstack@ontv.com Subject: Re: display-CUBE In-Reply-To: <m0xttnU-0000XUC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980119130736.1982C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"sUDq_3.0.9D4.RGxmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/408 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Sun, 18 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > > Yes. A simple implementation would be to have a "display-cube" target, > > > which takes a parameter (the side of the cube) and draws to a shared memory > > > area. > > > > An extension perhaps? :) > > I already have the graphics library (32BPP ARGB :), I just need to port it > > to GGI. I've actually taken the time to make it semi-efficient :) > > > > Ah - make it a target (with extensions :) > > O.K. - stop - let's make terms clear here and how one would do it. > > You operate on a 32 bit framebuffer - right ? No fancy accel access - right ? Wrong (I hope) - the 3D library (like libGGI) is designed to hook into accels. That makes it a target, right? There's also an internal extension that does rendering onto a 32BPP texture - to make texturemapping fun :) > O.K. - so make your 3D library a LibGGI extension. This basically means that > it registers its per-visual state with LibGGI at the beginning and gets notified > of LibGGI loading display-libs. > > For the "display-cube" trick one would write yet another LibGGI target as > I described in my mail which renders to shmem. Yep :) > Once you've done this the scenario looks like that : > > Your cube-application registers 6 shmem areas for the "textures" i.e. the sides' > contents. It then uses your LibGGI-Extension to draw the cube to a common LibGGI > visual (which probably happens to be limited to 32 bit modes, except if you > write a stubs_3d.so library which falls back to LibGGI calls). Nope - the libGGI-extension is used on the shmem sections. The 3D library is like libGGI - it goes directly to the hardware. I _HAVE_ a 3D-accelerator - and can test it! ... but noone thinks that 3D accel calls should exist in libGGI. Ergo a new library. I would guess the Mesa-fan people are doing the same thing. ... so I hope I'm using the terminology correctly. (whoops - I may have done some wrong ones) use: TARGET = the 3D/accel support. EXTENSION = hooks to libGGI to allow the 3D/accel support proper operation (perhaps it's just an extension? You imply as much. It would make sense). TARGET = display-shmem (-> internal 32bpp frame) (aside: I use the multithreading clone() to handle shmem currently as I've found sysv shmem to be a pain... but I can use that too - any suggestions?) EXTENSION = 3Dlib-tiein for display-shmem to allow 3D rendering on the shmem target *grin* [yep - run the cube on a face of the cube... hope yer computer's fast enough to do this :] That covers it? (yep - the 3D-lib's already starting to be capable of extensions... perhaps I should check how libGGI handles it so I can make the two compatible :) > The other applications (that display on the sides of the cube) are set to use the > display-cube (or rather display-shmem) target, so they map themselves into the > texture areas of the main app. *grin* - yep :) > > SVGAlib works though, but I'm gonna have to attack X probs (keyboard) *sigh*. > > I think Andrew is working on that ... GOOD! 'cause I'm still learning how this system works :) > > PS : Is there anyway to turn off the debug? It's seriously messing up all > > my consoles. > klogd ? Oh? What flags / etc do I use? (I've never used klogd). G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 19 12:58:28 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA07272 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 12:58:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id PAA17418; Mon, 19 Jan 1998 15:24:16 -0500 Resent-Date: Mon, 19 Jan 1998 15:24:16 -0500 Date: Mon, 19 Jan 1998 13:33:38 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: display-CUBE (fwd) In-Reply-To: <m0xu8ki-00017NC@ajax> Message-ID: <Pine.LNX.3.96.980119133010.1982D-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Tia7E3.0.QF4.KOxmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/409 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Mon, 19 Jan 1998, Andrew Apted wrote: > MenTaLboY writes: > > > > Teunis, how about this for an idea. Use RIGHT alt + function key for > > > your usermode console switching, and keep LEFT alt for normal kernelmode > > > console switching. [This is how my fvwm2 is setup, with four virtual X > > > screens...]. > > > > Aren't we already using right alt for text VTs and left for graphical VTs? > > I'm pretty sure that for EvStack/Degas we're going back to using just > left-ALT for VT switches. [suits me, fwiw] Doesn't using both "ALT"'s in this way make playing, say, 'doom' a pain? *grin* Okay - I'll default to this pattern, but use the squigley-pattern by default on my own computer. (and the blocky-thingy with pointer on it for pulling down menus :) (aside: yes, I have a microsoft natural keyboard. It's comfortable and nice but I haven't the foggiest what those keys are supposed to do... I don't run microsoft software) So can you tell the left and right squiggley keys apart? There's only one of those blocky-thingy keys though. G'day, eh? :) - Teunis PS: actually I think I do know what those funny keys are for.... but I don't know what use they'd be under Linux... From evstack-request@ontv.com Mon Jan 19 13:06:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA07241 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 12:19:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA16837; Mon, 19 Jan 1998 14:43:13 -0500 Resent-Date: Mon, 19 Jan 1998 14:43:13 -0500 Date: Mon, 19 Jan 1998 12:52:09 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: 2.1.78 boot... (whoops - quick licensing q with long preclude) In-Reply-To: <69rnq6$5e1$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980119124203.1982B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"O6FXN.0.R64.enwmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/407 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 18 Jan 1998, Jason McMullan wrote: > > [I'm the one that keeps asking for non-Mesa OpenGL as libGGI3D BTW - I > > have a complete 3D rendering library and IMHO it's cleaner. It may not be > > faster but we can use _ANY_ license on it. (I'm considering Berkeley > > license, but I'll prolly use LGPL)]. > > I've kinda kept out of that debate since I left the care and > feeding of libGGI to Andreas, but does your library do full > OpenGL compatability? We will need that. Also, Mesa DOES > have the advantage that a lot more people are `interested' > in maintaining it. *g* - Pretty soon here.... > I would like to see both your implementation as libGGI3D, > and Mesa as libOpenGL. That way, we'll have our own `distrib' > of OpenGL we can modify as we see fit, and a `standard' OpenGL > that is known to pass the SGI OpenGL compatability tests - > you know, the old `speed versus compatability' arguments... There's another person doing Mesa as libGGI3D... Or other people. If anyone sends in anything I'll help cover that as well - but I'm more interested in using my own code *g* (so call me biased :) So what license would be best? Berkeley? (I kinda like this one :) LGPL? (this one has advantages too) I don't do GPL as I happen to like the idea of commercial companies (like myself :) being able to use it... And I hate living on the street (been there, done that). Ahh - Mesa is LGPL.... Cool :) [that's good - I've been working under the misassertion that it was using a commercial license or the GPL] Okay - maybe I'll look at porting it too.... 'twould save me a lot of time I guess. G'day, eh? :) - Teunis PS : I'm posting this 'cause I want to see the licensing issue answered. The rest of it is just commentary and random meandering - a general discussion on 3D in this list would be a bad idea IMHO. GGI was bad enough (but I never learn my lessons *slap with wet haddock*) From evstack-request@ontv.com Mon Jan 19 14:15:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07384 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:15:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA18098; Mon, 19 Jan 1998 16:41:16 -0500 Resent-Date: Mon, 19 Jan 1998 16:41:16 -0500 Date: Mon, 19 Jan 1998 14:50:16 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: linux-ggi@eskimo.com cc: EvStack list <evstack@ontv.com> Subject: Re: i18n (internationalization) In-Reply-To: <Pine.OSF.3.95.980117163229.3270A-100000@shangrila.ecn.ou.edu> Message-ID: <Pine.LNX.3.96.980119143716.343A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"fIErd2.0.6Q4.UWymq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/410 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com (crossposting to EvStack as people there might want to think about this :) [it'll explain better why userspace consoles are necessary] On Sat, 17 Jan 1998, Hugh Mcdonald Bright wrote: > Ok. Let's say i have a document that uses the JIS X 0208 character set > and this character set is encoded using EUC-JP > > How am i going to display this file on my ggi console? > > right now i can use a program called "kon" that talks directly to the > vga hardware. Oh - thanks for reminding me :) I have the source for that beasty (v2.2). It'd be even easier to port to GGI than my console-manager (mostly 'cause the kon source is much smaller :) Okay - I'll see if I can get kon-GGI working this week too then :) Though kon _SHOULD_ work with the current EvStack-GGI system... (testing... yep! kon works just fine :) Kon probably won't work with 0.0.9 though... but it's hard to say. (checking if it works under GGI driver... yep - it works with the VGA driver anyways :) Though kon under GGI will be a _LOT_ slower. kon on my old 486-50 used to match speeds with normal text consoles. (aside: on VGA kon runs at 640x480x4bpp. On (if supported) S3 systems it can run at 640x480x16bpp. The code is fully accelerated and supports Japanese hardware as well... I mentioned it a while ago as something to look at for ideas - but never actually got to checking it) Also: for those who don't know, kon is a graphical console with support for Japanese text fonts (~8000 characters). This issue came up a long time ago and noone's talked about it since. That crazy 6-consoles-on-the-side-of-a-cube project is actually the beginning of an implementation of userspace consoles for this kind of problem. Say you're using a chinese console with a complete ISO-10646 current font set... you wouldn't want to have to use this in the kernel. ... the current ISO-10646 font for Chinese characters is ~130000 characters (at least) IIRC. G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 19 14:51:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07451 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:51:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA18762; Mon, 19 Jan 1998 17:17:08 -0500 Resent-Date: Mon, 19 Jan 1998 17:17:08 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: evstack & monitor driver errors Date: 19 Jan 1998 22:15:43 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Distribution: local Message-ID: <6a0jaf$pv8$1@grits.visus.com> References: <6a0id9$qbe$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"iogBt1.0.1a4.02zmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/414 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jordan Mendelson (jordy@wserv.com) wrote: > Well, I just patched my kernel (2.1.80 pre4), and I'm having an odd > problem insmodding the vga driver. Here is what's in my syslog (sorry hand > typed, so some stuff ommited): > check_mode: clock ok. > check_mode: ramdac ok. > check_mode: chipset ok. > check_mode: graphics ok. > timelist.c:252: timing limits violated, hfreq = 31157, vfreq = 69, dclk = > 28322000 Hmm.. That's with the VGA monosync driver, right? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 14:53:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07455 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:53:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA18827; Mon, 19 Jan 1998 17:19:48 -0500 Resent-Date: Mon, 19 Jan 1998 17:19:48 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Repatching source for kernel. Date: 19 Jan 1998 22:18:31 GMT Organization: OnTV Pittsburgh, L.P. Lines: 21 Distribution: local Message-ID: <6a0jfn$pv8$2@grits.visus.com> References: <6a0imp$qhv$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"3_Hio.0.Zb4.f4zmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/415 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > I redownload ggi-evstack almost every day right now.... is there a safe > way to insert it into my kernel source or do I have to rm the old source, > reunpack linux-2.1.79, and repatch _EVERY_ time? The `kernel patches' don't often change - the drivers/console/ and include/ggi/ trees do. Just symlink those into where you drop your source. > Oh - is 2.1.79 yet supported by the "make kernel" bit? I have to manually > patch AFAIK which has been a pain. Should be. If not, just fix the Makefile... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 19 15:00:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA07464 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 15:00:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA18930; Mon, 19 Jan 1998 17:26:35 -0500 Resent-Date: Mon, 19 Jan 1998 17:26:35 -0500 Date: Mon, 19 Jan 1998 15:35:48 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Re: Repatching source for kernel. In-Reply-To: <Pine.LNX.3.96.980119150740.1445C-100000@sigil.computersupportcentre.com> Message-ID: <Pine.LNX.3.96.980119153429.2912A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"vMLKo1.0.8d4.yAzmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/416 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Silly me (replying to my own post)... I'd assume patch-* (for whatever kernel) would get a modern version if it changes... And it turns out the driver/* stuff was linked to the GGI source-branch *whoops* - so no problem. (a sure senility sign of - replying to your own message with a semi-usable reply :) On Mon, 19 Jan 1998, teunis wrote: > I redownload ggi-evstack almost every day right now.... is there a safe > way to insert it into my kernel source or do I have to rm the old source, > reunpack linux-2.1.79, and repatch _EVERY_ time? > > Oh - is 2.1.79 yet supported by the "make kernel" bit? I have to manually > patch AFAIK which has been a pain. > > Any ideas? > > G'day, eh? :) > - Teunis > From evstack-request@ontv.com Mon Jan 19 15:06:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07442 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:36:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA18569; Mon, 19 Jan 1998 17:00:42 -0500 Resent-Date: Mon, 19 Jan 1998 17:00:42 -0500 Date: Mon, 19 Jan 1998 15:09:59 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Repatching source for kernel. Message-ID: <Pine.LNX.3.96.980119150740.1445C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"buqe9.0.aV4.noymq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/413 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I redownload ggi-evstack almost every day right now.... is there a safe way to insert it into my kernel source or do I have to rm the old source, reunpack linux-2.1.79, and repatch _EVERY_ time? Oh - is 2.1.79 yet supported by the "make kernel" bit? I have to manually patch AFAIK which has been a pain. Any ideas? G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 19 15:06:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07432 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:27:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA18235; Mon, 19 Jan 1998 16:52:49 -0500 Resent-Date: Mon, 19 Jan 1998 16:52:49 -0500 Date: Mon, 19 Jan 1998 16:50:48 -0500 (EST) From: Jordan Mendelson <jordy@wserv.com> To: evstack@ontv.com Subject: evstack & monitor driver errors Message-ID: <Pine.LNX.3.96.980119164737.6414A-100000@snappy.wserv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"23iWr2.0.ES4.Jgymq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/411 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Well, I just patched my kernel (2.1.80 pre4), and I'm having an odd problem insmodding the vga driver. Here is what's in my syslog (sorry hand typed, so some stuff ommited): check_mode: clock ok. check_mode: ramdac ok. check_mode: chipset ok. check_mode: graphics ok. timelist.c:252: timing limits violated, hfreq = 31157, vfreq = 69, dclk = 28322000 And then the driver unloads itself. Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Mon Jan 19 15:06:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA07440 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 14:32:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA18330; Mon, 19 Jan 1998 16:57:45 -0500 Resent-Date: Mon, 19 Jan 1998 16:57:45 -0500 Date: Mon, 19 Jan 1998 15:06:37 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: linux-ggi@eskimo.com cc: EvStack list <evstack@ontv.com> Subject: Re: i18n (internationalization) In-Reply-To: <Pine.LNX.3.96.980119143716.343A-100000@sigil.computersupportcentre.com> Message-ID: <Pine.LNX.3.96.980119145834.1445B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"r3uhP2.0.iT4.2mymq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/412 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Mon, 19 Jan 1998, teunis wrote: > > right now i can use a program called "kon" that talks directly to the > > vga hardware. > [clip] > Though kon _SHOULD_ work with the current EvStack-GGI system... > (testing... yep! kon works just fine :) > Kon probably won't work with 0.0.9 though... but it's hard to say. > (checking if it works under GGI driver... yep - it works with the VGA > driver anyways :) ... it also successfully switches consoles... okay, getting my 3D-cube operational just got a LOT easier :) [I'm gonna cheat for graphics driver until GGI is completely operational on my S3-ViRGE under EvStacks] Note: running 'kon' is a great way of not receiving all of those annoying debug messages under an EvStack/GGI system :) If anyone can't find the source (it's on one of the Japanese archives), I can email it to them... though my source might be old. IIRC it's also in SRPM format on redhat though. Sorry to pester y'all with this though... G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 19 15:08:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA07495 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 15:08:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA19066; Mon, 19 Jan 1998 17:34:41 -0500 Resent-Date: Mon, 19 Jan 1998 17:34:41 -0500 Date: Mon, 19 Jan 1998 15:43:38 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Problems compiling libGGI - any ideas? Message-ID: <Pine.LNX.3.96.980119153725.2912B-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-175199511-885249818=:2912" Resent-Message-ID: <"2GWKw.0.Nf4.eIzmq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/417 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-175199511-885249818=:2912 Content-Type: TEXT/PLAIN; charset=US-ASCII I've got a couple of problems compiling libGGI under EvStacks... ... uh - any ideas? I configured for all targets and am running an EvStack/GGI version of sometime in the last 2 hours.. (~3:30MST pickup time) I use glibc-2.0.5c if anyone cares (and either egcs-1.0 (patched a little) or gcc-2.7.2.1) Should I download the current 0.0.9 GGI and use that libGGI instead? G'day, eh? :) - Teunis ---1463800064-175199511-885249818=:2912 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="err.list" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980119154338.2912C@sigil.computersupportcentre.com> Content-Description: Z2NjIC1mUElDIC1PMiAtZnVucm9sbC1sb29wcyAtZm9taXQtZnJhbWUtcG9p bnRlciAtbTQ4NiAtbWFsaWduLWZ1bmN0aW9ucz0yIC1tYWxpZ24tbG9vcHM9 MiAtbWFsaWduLWp1bXBzPTIgLXBpcGUgLXBlZGFudGljICAgLUkvdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZSAgLVdhbGwg LVdzdHJpY3QtcHJvdG90eXBlcyAtZyAtRERFQlVHIC1ER0dJQ09ORkZJTEU9 XCJUYUcxL2V0Yy9nZ2kvbGliZ2dpLmNvbmZcIiAtYyAtbyBpbml0Lm8gaW5p dC5jDQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL3Vzci9pbmNsdWRlL2dnaS9n Z2kuaDoxNDIsDQogICAgICAgICAgICAgICAgIGZyb20gL3VzcjIvc3JjL0NW Uy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaS5o OjMwLA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3IyL3NyYy9DVlMvZ2dp LWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6NiwNCiAg ICAgICAgICAgICAgICAgZnJvbSBpbml0LmM6MTE2Og0KL3Vzci9pbmNsdWRl L2dnaS9ldmVudHMuaDo1NDogd2FybmluZzogQU5TSSBDIHJlc3RyaWN0cyBl bnVtZXJhdG9yIHZhbHVlcyB0byByYW5nZSBvZiBgaW50Jw0KL3Vzci9pbmNs dWRlL2dnaS9ldmVudHMuaDozMjQ6IHdhcm5pbmc6IEFOU0kgZG9lcyBub3Qg cGVybWl0IHRoZSBrZXl3b3JkIGBpbmxpbmUnDQovdXNyL2luY2x1ZGUvZ2dp L2V2ZW50cy5oOjM2Mjogd2FybmluZzogQU5TSSBkb2VzIG5vdCBwZXJtaXQg dGhlIGtleXdvcmQgYGlubGluZScNCi91c3IvaW5jbHVkZS9nZ2kvZXZlbnRz Lmg6MzY3OiB3YXJuaW5nOiBBTlNJIGRvZXMgbm90IHBlcm1pdCB0aGUga2V5 d29yZCBgaW5saW5lJw0KL3Vzci9pbmNsdWRlL2dnaS9ldmVudHMuaDozODQ6 IHdhcm5pbmc6IEFOU0kgZG9lcyBub3QgcGVybWl0IHRoZSBrZXl3b3JkIGBp bmxpbmUnDQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL3VzcjIvc3JjL0NWUy9n Z2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaS5oOjQ4 LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6NiwNCiAgICAg ICAgICAgICAgICAgZnJvbSBpbml0LmM6MTE2Og0KL3VzcjIvc3JjL0NWUy9n Z2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaV9kYi5o OjEyMTogcGFyc2UgZXJyb3IgYmVmb3JlIGB1aW50bCcNCi91c3IyL3NyYy9D VlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lf ZGIuaDoxMjE6IHdhcm5pbmc6IG5vIHNlbWljb2xvbiBhdCBlbmQgb2Ygc3Ry dWN0IG9yIHVuaW9uDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTM4OiBwYXJzZSBlcnJv ciBiZWZvcmUgYH0nDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTM4OiB3YXJuaW5nOiB0 eXBlIGRlZmF1bHRzIHRvIGBpbnQnIGluIGRlY2xhcmF0aW9uIG9mIGBnZ2lf cGl4ZWxsaW5lYXJidWZmZXInDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNr L2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTM4OiBBTlNJ IEMgZm9yYmlkcyBkYXRhIGRlZmluaXRpb24gd2l0aCBubyB0eXBlIG9yIHN0 b3JhZ2UgY2xhc3MNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xp YmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNjU6IHBhcnNlIGVycm9y IGJlZm9yZSBgZ2dpX3BpeGVsbGluZWFyYnVmZmVyJw0KL3VzcjIvc3JjL0NW Uy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaV9k Yi5oOjE2NTogd2FybmluZzogbm8gc2VtaWNvbG9uIGF0IGVuZCBvZiBzdHJ1 Y3Qgb3IgdW5pb24NCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xp YmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNjU6IHdhcm5pbmc6IG5v IHNlbWljb2xvbiBhdCBlbmQgb2Ygc3RydWN0IG9yIHVuaW9uDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGli Z2dpX2RiLmg6MTY2OiB3YXJuaW5nOiB0eXBlIGRlZmF1bHRzIHRvIGBpbnQn IGluIGRlY2xhcmF0aW9uIG9mIGBidWZmZXInDQovdXNyMi9zcmMvQ1ZTL2dn aS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6 MTY2OiBBTlNJIEMgZm9yYmlkcyBkYXRhIGRlZmluaXRpb24gd2l0aCBubyB0 eXBlIG9yIHN0b3JhZ2UgY2xhc3MNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3Rh Y2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNjg6IHBh cnNlIGVycm9yIGJlZm9yZSBgfScNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3Rh Y2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNjg6IHdh cm5pbmc6IHR5cGUgZGVmYXVsdHMgdG8gYGludCcgaW4gZGVjbGFyYXRpb24g b2YgYGdnaV9kaXJlY3RidWZmZXInDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0 YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTY4OiBB TlNJIEMgZm9yYmlkcyBkYXRhIGRlZmluaXRpb24gd2l0aCBubyB0eXBlIG9y IHN0b3JhZ2UgY2xhc3MNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGli L2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNzQ6IHBhcnNlIGVy cm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGli L2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNzQ6IHdhcm5pbmc6 IHR5cGUgZGVmYXVsdHMgdG8gYGludCcgaW4gZGVjbGFyYXRpb24gb2YgYGdn aV9kaXJlY3RidWZmZXJfdCcNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2sv bGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxNzQ6IEFOU0kg QyBmb3JiaWRzIGRhdGEgZGVmaW5pdGlvbiB3aXRoIG5vIHR5cGUgb3Igc3Rv cmFnZSBjbGFzcw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGli Z2dpL2luY2x1ZGUvZ2dpL2xpYmdnaV9kYi5oOjE3ODogcGFyc2UgZXJyb3Ig YmVmb3JlIGBnZ2lfZGlyZWN0YnVmZmVyX3QnDQovdXNyMi9zcmMvQ1ZTL2dn aS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6 MTc4OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHBy b3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dp L2luY2x1ZGUvZ2dpL2xpYmdnaV9kYi5oOjE4MDogcGFyc2UgZXJyb3IgYmVm b3JlIGBidWYnDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJn Z2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTgwOiB3YXJuaW5nOiBmdW5j dGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3Jj L0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdn aV9kYi5oOjE4MjogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3Jj L0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdn aV9kYi5oOjE4MjogcGFyc2UgZXJyb3IgYmVmb3JlIGBidWYnDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGli Z2dpX2RiLmg6MTgyOiB3YXJuaW5nOiB0eXBlIGRlZmF1bHRzIHRvIGBpbnQn IGluIGRlY2xhcmF0aW9uIG9mIGBnZ2lEQkdldFBMQicNCi91c3IyL3NyYy9D VlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2lf ZGIuaDoxODI6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0 IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpX2RiLmg6MTgyOiBBTlNJIEMgZm9y YmlkcyBkYXRhIGRlZmluaXRpb24gd2l0aCBubyB0eXBlIG9yIHN0b3JhZ2Ug Y2xhc3MNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9p bmNsdWRlL2dnaS9saWJnZ2lfZGIuaDoxODQ6IHBhcnNlIGVycm9yIGJlZm9y ZSBgZ2dpX3BpeGVsbGluZWFyYnVmZmVyJw0KL3VzcjIvc3JjL0NWUy9nZ2kt ZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaV9kYi5oOjE4 Njogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90 b3R5cGUNCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAvdXNyMi9zcmMvQ1ZTL2dn aS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9pbnRlcm5hbC5oOjYsDQog ICAgICAgICAgICAgICAgIGZyb20gaW5pdC5jOjExNjoNCi91c3IyL3NyYy9D VlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2ku aDo3NTogcGFyc2UgZXJyb3IgYmVmb3JlIGBnZ2lfZGlyZWN0YnVmZmVyJw0K L3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUv Z2dpL2xpYmdnaS5oOjc1OiB3YXJuaW5nOiBubyBzZW1pY29sb24gYXQgZW5k IG9mIHN0cnVjdCBvciB1bmlvbg0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFj ay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaS5oOjc3OiBwYXJzZSBl cnJvciBiZWZvcmUgYH0nDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xp Yi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dpLmg6Nzc6IHdhcm5pbmc6IHR5 cGUgZGVmYXVsdHMgdG8gYGludCcgaW4gZGVjbGFyYXRpb24gb2YgYGdnaV9p bmZvJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvZ2dpL2xpYmdnaS5oOjc3OiBBTlNJIEMgZm9yYmlkcyBkYXRhIGRl ZmluaXRpb24gd2l0aCBubyB0eXBlIG9yIHN0b3JhZ2UgY2xhc3MNCi91c3Iy L3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9s aWJnZ2kuaDo5OTogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3Jj L0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdn aS5oOjk5OiB3YXJuaW5nOiB0eXBlIGRlZmF1bHRzIHRvIGBpbnQnIGluIGRl Y2xhcmF0aW9uIG9mIGBnZ2lHZXRJbmZvJw0KL3VzcjIvc3JjL0NWUy9nZ2kt ZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaS5oOjk5OiBB TlNJIEMgZm9yYmlkcyBkYXRhIGRlZmluaXRpb24gd2l0aCBubyB0eXBlIG9y IHN0b3JhZ2UgY2xhc3MNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGli L2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2kuaDoyMjY6IHdhcm5pbmc6IEFO U0kgZG9lcyBub3QgcGVybWl0IHRoZSBrZXl3b3JkIGBpbmxpbmUnDQovdXNy Mi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kv bGliZ2dpLmg6MjMzOiB3YXJuaW5nOiBBTlNJIGRvZXMgbm90IHBlcm1pdCB0 aGUga2V5d29yZCBgaW5saW5lJw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC91 c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2lu dGVybmFsLmg6OSwNCiAgICAgICAgICAgICAgICAgZnJvbSBpbml0LmM6MTE2 Og0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1 ZGUvc3RydWN0cy5oOjU5OiBwYXJzZSBlcnJvciBiZWZvcmUgYGdnaV9nYycN Ci91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRl L3N0cnVjdHMuaDo1OTogd2FybmluZzogbm8gc2VtaWNvbG9uIGF0IGVuZCBv ZiBzdHJ1Y3Qgb3IgdW5pb24NCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2sv bGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDo3MjogY29uZmxpY3Rpbmcg dHlwZXMgZm9yIGBzaXplJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9s aWIvbGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaV9kYi5oOjEyNzogcHJldmlv dXMgZGVjbGFyYXRpb24gb2YgYHNpemUnDQovdXNyMi9zcmMvQ1ZTL2dnaS1l dnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6NzU6IHBhcnNl IGVycm9yIGJlZm9yZSBgfScNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2sv bGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDo3NTogd2FybmluZzogdHlw ZSBkZWZhdWx0cyB0byBgaW50JyBpbiBkZWNsYXJhdGlvbiBvZiBgZ2dpX3Zp c3VhbCcNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9p bmNsdWRlL3N0cnVjdHMuaDo3NTogQU5TSSBDIGZvcmJpZHMgZGF0YSBkZWZp bml0aW9uIHdpdGggbm8gdHlwZSBvciBzdG9yYWdlIGNsYXNzDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3Rz Lmg6Nzk6IHBhcnNlIGVycm9yIGJlZm9yZSBgZ2dpX3Zpc3VhbCcNCi91c3Iy L3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVj dHMuaDo3OTogd2FybmluZzogbm8gc2VtaWNvbG9uIGF0IGVuZCBvZiBzdHJ1 Y3Qgb3IgdW5pb24NCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xp YmdnaS9pbmNsdWRlL3N0cnVjdHMuaDo4MTogcGFyc2UgZXJyb3IgYmVmb3Jl IGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvc3RydWN0cy5oOjgxOiB3YXJuaW5nOiB0eXBlIGRlZmF1bHRzIHRv IGBpbnQnIGluIGRlY2xhcmF0aW9uIG9mIGB2aXN1YWwnDQovdXNyMi9zcmMv Q1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6 ODE6IEFOU0kgQyBmb3JiaWRzIGRhdGEgZGVmaW5pdGlvbiB3aXRoIG5vIHR5 cGUgb3Igc3RvcmFnZSBjbGFzcw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFj ay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjgyOiBwYXJzZSBlcnJv ciBiZWZvcmUgYH0nDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6ODI6IHdhcm5pbmc6IHR5cGUgZGVm YXVsdHMgdG8gYGludCcgaW4gZGVjbGFyYXRpb24gb2YgYGdnaV9mb2N1cycN Ci91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRl L3N0cnVjdHMuaDo4MjogQU5TSSBDIGZvcmJpZHMgZGF0YSBkZWZpbml0aW9u IHdpdGggbm8gdHlwZSBvciBzdG9yYWdlIGNsYXNzDQovdXNyMi9zcmMvQ1ZT L2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTE0 OiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1l dnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTE0OiB3YXJu aW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0K L3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUv c3RydWN0cy5oOjExNzogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIv c3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0 cy5oOjExNzogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3Qg YSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xp YmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoxMjM6IHBhcnNlIGVycm9yIGJlZm9y ZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9p bmNsdWRlL3N0cnVjdHMuaDoxMjM6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xh cmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1l dnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTI1OiBwYXJz ZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNr L2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTI1OiB3YXJuaW5nOiBm dW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIv c3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0 cy5oOjEyNzogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NW Uy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjEy Nzogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90 b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9p bmNsdWRlL3N0cnVjdHMuaDoxMzM6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicN Ci91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRl L3N0cnVjdHMuaDoxMzU6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9u IGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNr L2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTM3OiBwYXJzZSBlcnJv ciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTM3OiB3YXJuaW5nOiBmdW5jdGlv biBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NW Uy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE1 NDogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2kt ZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE1NDogd2Fy bmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUN Ci91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRl L3N0cnVjdHMuaDoxNTY6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3Iy L3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVj dHMuaDoxNTY6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0 IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MTU4OiBwYXJzZSBlcnJvciBiZWZv cmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kv aW5jbHVkZS9zdHJ1Y3RzLmg6MTU4OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNs YXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2kt ZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE2MDogcGFy c2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFj ay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE2MDogd2FybmluZzog ZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3Iy L3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVj dHMuaDoxNjI6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9D VlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDox NjI6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJv dG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kv aW5jbHVkZS9zdHJ1Y3RzLmg6MTY0OiBwYXJzZSBlcnJvciBiZWZvcmUgYCon DQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVk ZS9zdHJ1Y3RzLmg6MTY0OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlv biBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFj ay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE3MDogcGFyc2UgZXJy b3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIv bGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE3Mjogd2FybmluZzogZnVuY3Rp b24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9D VlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDox NzU6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dp LWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoxNzc6IHdh cm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBl DQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVk ZS9zdHJ1Y3RzLmg6MTgwOiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNy Mi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1 Y3RzLmg6MTgwOiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24n dCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIv bGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjE4MzogcGFyc2UgZXJyb3IgYmVm b3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dp L2luY2x1ZGUvc3RydWN0cy5oOjE4Mzogd2FybmluZzogZnVuY3Rpb24gZGVj bGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dp LWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyMDE6IHBh cnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3Rh Y2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyMDE6IHdhcm5pbmc6 IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNy Mi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1 Y3RzLmg6MjAzOiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMv Q1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6 MjAzOiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHBy b3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dp L2luY2x1ZGUvc3RydWN0cy5oOjIwNTogcGFyc2UgZXJyb3IgYmVmb3JlIGAq Jw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1 ZGUvc3RydWN0cy5oOjIwNTogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRp b24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3Rh Y2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyMDY6IHBhcnNlIGVy cm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGli L2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyMDY6IHdhcm5pbmc6IGZ1bmN0 aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMv Q1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6 MjE2OiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dn aS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjE2OiB3 YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlw ZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1 ZGUvc3RydWN0cy5oOjIxNzogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3Vz cjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3Ry dWN0cy5oOjIxNzogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNu J3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGli L2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyMTg6IHBhcnNlIGVycm9yIGJl Zm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdn aS9pbmNsdWRlL3N0cnVjdHMuaDoyMTg6IHdhcm5pbmc6IGZ1bmN0aW9uIGRl Y2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dn aS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjI2OiBw YXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0 YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjI2OiB3YXJuaW5n OiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3Vz cjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3Ry dWN0cy5oOjIyODogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3Jj L0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5o OjIyODogd2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBw cm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdn aS9pbmNsdWRlL3N0cnVjdHMuaDoyMjk6IHBhcnNlIGVycm9yIGJlZm9yZSBg KicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNs dWRlL3N0cnVjdHMuaDoyMjk6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0 aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0 YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjM0OiBwYXJzZSBl cnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xp Yi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjM0OiB3YXJuaW5nOiBmdW5j dGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3Jj L0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5o OjIzNTogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9n Z2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjIzNTog d2FybmluZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5 cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNs dWRlL3N0cnVjdHMuaDoyMzY6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91 c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0 cnVjdHMuaDoyMzY6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlz bid0IGEgcHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xp Yi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjQxOiBwYXJzZSBlcnJvciBi ZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJn Z2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjQxOiB3YXJuaW5nOiBmdW5jdGlvbiBk ZWNsYXJhdGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9n Z2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjI0Mzog cGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZz dGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjI0Mzogd2Fybmlu ZzogZnVuY3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91 c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0 cnVjdHMuaDoyNDQ6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3Ny Yy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMu aDoyNDQ6IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEg cHJvdG90eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJn Z2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjQ1OiBwYXJzZSBlcnJvciBiZWZvcmUg YConDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5j bHVkZS9zdHJ1Y3RzLmg6MjQ1OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJh dGlvbiBpc24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZz dGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjI0NzogcGFyc2Ug ZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9s aWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjI0Nzogd2FybmluZzogZnVu Y3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3Ny Yy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMu aDoyNDg6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMv Z2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyNDg6 IHdhcm5pbmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90 eXBlDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5j bHVkZS9zdHJ1Y3RzLmg6MjQ5OiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQov dXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9z dHJ1Y3RzLmg6MjQ5OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBp c24ndCBhIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9s aWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOjI1MTogcGFyc2UgZXJyb3Ig YmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGli Z2dpL2luY2x1ZGUvc3RydWN0cy5oOjI1MTogd2FybmluZzogZnVuY3Rpb24g ZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMv Z2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyNTY6 IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyNTY6IHdhcm5p bmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQov dXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9z dHJ1Y3RzLmg6MjU3OiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3Rz Lmg6MjU3OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBh IHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGli Z2dpL2luY2x1ZGUvc3RydWN0cy5oOjI1ODogcGFyc2UgZXJyb3IgYmVmb3Jl IGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvc3RydWN0cy5oOjI1ODogd2FybmluZzogZnVuY3Rpb24gZGVjbGFy YXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyNTk6IHBhcnNl IGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2sv bGliL2xpYmdnaS9pbmNsdWRlL3N0cnVjdHMuaDoyNTk6IHdhcm5pbmc6IGZ1 bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3Rz Lmg6MjYwOiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZT L2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6MjYx OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3Rv dHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvc3RydWN0cy5oOjI2ODogcGFyc2UgZXJyb3IgYmVmb3JlIGBfZ2dp Rm9jdXMnDQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kv aW5jbHVkZS9zdHJ1Y3RzLmg6MjY4OiB3YXJuaW5nOiB0eXBlIGRlZmF1bHRz IHRvIGBpbnQnIGluIGRlY2xhcmF0aW9uIG9mIGBfZ2dpRm9jdXMnDQovdXNy Mi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9zdHJ1 Y3RzLmg6MjY4OiBBTlNJIEMgZm9yYmlkcyBkYXRhIGRlZmluaXRpb24gd2l0 aCBubyB0eXBlIG9yIHN0b3JhZ2UgY2xhc3MNCkluIGZpbGUgaW5jbHVkZWQg ZnJvbSBpbml0LmM6MTE2Og0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9s aWIvbGliZ2dpL2luY2x1ZGUvaW50ZXJuYWwuaDozMjogcGFyc2UgZXJyb3Ig YmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGli Z2dpL2luY2x1ZGUvaW50ZXJuYWwuaDozMjogd2FybmluZzogZnVuY3Rpb24g ZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMv Z2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6MzM6 IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6MzM6IHdhcm5p bmc6IGZ1bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQov dXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9p bnRlcm5hbC5oOjM1OiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9pbnRlcm5h bC5oOjM1OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBh IHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGli Z2dpL2luY2x1ZGUvaW50ZXJuYWwuaDozNjogcGFyc2UgZXJyb3IgYmVmb3Jl IGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvaW50ZXJuYWwuaDozNjogd2FybmluZzogZnVuY3Rpb24gZGVjbGFy YXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCi91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6Mzk6IHBhcnNl IGVycm9yIGJlZm9yZSBgKicNCi91c3IyL3NyYy9DVlMvZ2dpLWV2c3RhY2sv bGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFsLmg6Mzk6IHdhcm5pbmc6IGZ1 bmN0aW9uIGRlY2xhcmF0aW9uIGlzbid0IGEgcHJvdG90eXBlDQovdXNyMi9z cmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9pbnRlcm5h bC5oOjQyOiBwYXJzZSBlcnJvciBiZWZvcmUgYConDQovdXNyMi9zcmMvQ1ZT L2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9pbnRlcm5hbC5oOjQy OiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNsYXJhdGlvbiBpc24ndCBhIHByb3Rv dHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2lu Y2x1ZGUvaW50ZXJuYWwuaDo0NDogcGFyc2UgZXJyb3IgYmVmb3JlIGAqJw0K L3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUv aW50ZXJuYWwuaDo0NDogd2FybmluZzogdHlwZSBkZWZhdWx0cyB0byBgaW50 JyBpbiBkZWNsYXJhdGlvbiBvZiBgX2dnaU5ld1Zpc3VhbCcNCi91c3IyL3Ny Yy9DVlMvZ2dpLWV2c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2ludGVybmFs Lmg6NDQ6IEFOU0kgQyBmb3JiaWRzIGRhdGEgZGVmaW5pdGlvbiB3aXRoIG5v IHR5cGUgb3Igc3RvcmFnZSBjbGFzcw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZz dGFjay9saWIvbGliZ2dpL2luY2x1ZGUvaW50ZXJuYWwuaDo0NTogcGFyc2Ug ZXJyb3IgYmVmb3JlIGAqJw0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9s aWIvbGliZ2dpL2luY2x1ZGUvaW50ZXJuYWwuaDo0NTogd2FybmluZzogZnVu Y3Rpb24gZGVjbGFyYXRpb24gaXNuJ3QgYSBwcm90b3R5cGUNCmluaXQuYzox MjE6IHBhcnNlIGVycm9yIGJlZm9yZSBgX2dnaUZvY3VzJw0KaW5pdC5jOjEy MTogd2FybmluZzogdHlwZSBkZWZhdWx0cyB0byBgaW50JyBpbiBkZWNsYXJh dGlvbiBvZiBgX2dnaUZvY3VzJw0KaW5pdC5jOjEyMTogQU5TSSBDIGZvcmJp ZHMgZGF0YSBkZWZpbml0aW9uIHdpdGggbm8gdHlwZSBvciBzdG9yYWdlIGNs YXNzDQppbml0LmM6IEluIGZ1bmN0aW9uIGBnZ2lJbml0JzoNCmluaXQuYzox Mzg6IHJlcXVlc3QgZm9yIG1lbWJlciBgdmlzdWFscycgaW4gc29tZXRoaW5n IG5vdCBhIHN0cnVjdHVyZSBvciB1bmlvbg0KaW5pdC5jOjEzOTogcmVxdWVz dCBmb3IgbWVtYmVyIGB2aXN1YWwnIGluIHNvbWV0aGluZyBub3QgYSBzdHJ1 Y3R1cmUgb3IgdW5pb24NCmluaXQuYzoxNDA6IHJlcXVlc3QgZm9yIG1lbWJl ciBgZm9jdXMnIGluIHNvbWV0aGluZyBub3QgYSBzdHJ1Y3R1cmUgb3IgdW5p b24NCmluaXQuYzogSW4gZnVuY3Rpb24gYGdnaUV4aXQnOg0KaW5pdC5jOjIw ODogcmVxdWVzdCBmb3IgbWVtYmVyIGB2aXN1YWwnIGluIHNvbWV0aGluZyBu b3QgYSBzdHJ1Y3R1cmUgb3IgdW5pb24NCmluaXQuYzoyMDk6IHJlcXVlc3Qg Zm9yIG1lbWJlciBgdmlzdWFsJyBpbiBzb21ldGhpbmcgbm90IGEgc3RydWN0 dXJlIG9yIHVuaW9uDQppbml0LmM6IEF0IHRvcCBsZXZlbDoNCmluaXQuYzoy MzQ6IHBhcnNlIGVycm9yIGJlZm9yZSBgKicNCmluaXQuYzoyMzU6IHdhcm5p bmc6IHJldHVybi10eXBlIGRlZmF1bHRzIHRvIGBpbnQnDQppbml0LmM6MjM1 OiBjb25mbGljdGluZyB0eXBlcyBmb3IgYGdnaU9wZW4nDQovdXNyMi9zcmMv Q1ZTL2dnaS1ldnN0YWNrL2xpYi9saWJnZ2kvaW5jbHVkZS9nZ2kvbGliZ2dp Lmg6OTI6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mIGBnZ2lPcGVuJw0KaW5p dC5jOiBJbiBmdW5jdGlvbiBgZ2dpT3Blbic6DQppbml0LmM6MjM3OiBgdmlz JyB1bmRlY2xhcmVkIChmaXJzdCB1c2UgdGhpcyBmdW5jdGlvbikNCmluaXQu YzoyMzc6IChFYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBpcyByZXBvcnRl ZCBvbmx5IG9uY2UNCmluaXQuYzoyMzc6IGZvciBlYWNoIGZ1bmN0aW9uIGl0 IGFwcGVhcnMgaW4uKQ0KaW5pdC5jOjIzNzogd2FybmluZzogc3RhdGVtZW50 IHdpdGggbm8gZWZmZWN0DQppbml0LmM6MjM4OiBwYXJzZSBlcnJvciBiZWZv cmUgYGNoYXInDQppbml0LmM6MjQ2OiBgY3AnIHVuZGVjbGFyZWQgKGZpcnN0 IHVzZSB0aGlzIGZ1bmN0aW9uKQ0KaW5pdC5jOjI1MzogYHN0cicgdW5kZWNs YXJlZCAoZmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24pDQppbml0LmM6MjcwOiBg YnVmZicgdW5kZWNsYXJlZCAoZmlyc3QgdXNlIHRoaXMgZnVuY3Rpb24pDQpp bml0LmM6Mjc3OiByZXF1ZXN0IGZvciBtZW1iZXIgYHZpc3VhbCcgaW4gc29t ZXRoaW5nIG5vdCBhIHN0cnVjdHVyZSBvciB1bmlvbg0KaW5pdC5jOjI3ODog cmVxdWVzdCBmb3IgbWVtYmVyIGB2aXN1YWwnIGluIHNvbWV0aGluZyBub3Qg YSBzdHJ1Y3R1cmUgb3IgdW5pb24NCmluaXQuYzoyODQ6IHdhcm5pbmc6IGNv bnRyb2wgcmVhY2hlcyBlbmQgb2Ygbm9uLXZvaWQgZnVuY3Rpb24NCmluaXQu YzogQXQgdG9wIGxldmVsOg0KaW5pdC5jOjI5MTogcGFyc2UgZXJyb3IgYmVm b3JlIGAqJw0KaW5pdC5jOiBJbiBmdW5jdGlvbiBgZ2dpQ2xvc2UnOg0KaW5p dC5jOjI5MjogbnVtYmVyIG9mIGFyZ3VtZW50cyBkb2Vzbid0IG1hdGNoIHBy b3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIvbGliZ2dp L2luY2x1ZGUvZ2dpL2xpYmdnaS5oOjkzOiBwcm90b3R5cGUgZGVjbGFyYXRp b24NCmluaXQuYzoyOTM6IGB2aXMnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSB0 aGlzIGZ1bmN0aW9uKQ0KaW5pdC5jOjI5MzogYHB2aXMnIHVuZGVjbGFyZWQg KGZpcnN0IHVzZSB0aGlzIGZ1bmN0aW9uKQ0KaW5pdC5jOjI5Mzogd2Fybmlu ZzogbGVmdC1oYW5kIG9wZXJhbmQgb2YgY29tbWEgZXhwcmVzc2lvbiBoYXMg bm8gZWZmZWN0DQppbml0LmM6MjkzOiB3YXJuaW5nOiBzdGF0ZW1lbnQgd2l0 aCBubyBlZmZlY3QNCmluaXQuYzoyOTk6IHJlcXVlc3QgZm9yIG1lbWJlciBg dmlzdWFsJyBpbiBzb21ldGhpbmcgbm90IGEgc3RydWN0dXJlIG9yIHVuaW9u DQppbml0LmM6Mjk5OiB3YXJuaW5nOiBsZWZ0LWhhbmQgb3BlcmFuZCBvZiBj b21tYSBleHByZXNzaW9uIGhhcyBubyBlZmZlY3QNCmluaXQuYzoyOTk6IHdh cm5pbmc6IHN0YXRlbWVudCB3aXRoIG5vIGVmZmVjdA0KaW5pdC5jOjMwOTog cmVxdWVzdCBmb3IgbWVtYmVyIGB2aXN1YWwnIGluIHNvbWV0aGluZyBub3Qg YSBzdHJ1Y3R1cmUgb3IgdW5pb24NCmluaXQuYzozMTM6IHJlcXVlc3QgZm9y IG1lbWJlciBgZm9jdXMnIGluIHNvbWV0aGluZyBub3QgYSBzdHJ1Y3R1cmUg b3IgdW5pb24NCmluaXQuYzozMTQ6IHJlcXVlc3QgZm9yIG1lbWJlciBgZm9j dXMnIGluIHNvbWV0aGluZyBub3QgYSBzdHJ1Y3R1cmUgb3IgdW5pb24NCmlu aXQuYzogQXQgdG9wIGxldmVsOg0KaW5pdC5jOjMyNzogcGFyc2UgZXJyb3Ig YmVmb3JlIGAqJw0KaW5pdC5jOiBJbiBmdW5jdGlvbiBgZ2dpU2V0Rm9jdXMn Og0KaW5pdC5jOjMyODogbnVtYmVyIG9mIGFyZ3VtZW50cyBkb2Vzbid0IG1h dGNoIHByb3RvdHlwZQ0KL3VzcjIvc3JjL0NWUy9nZ2ktZXZzdGFjay9saWIv bGliZ2dpL2luY2x1ZGUvZ2dpL2xpYmdnaS5oOjk0OiBwcm90b3R5cGUgZGVj bGFyYXRpb24NCmluaXQuYzozMjk6IGB2aXMnIHVuZGVjbGFyZWQgKGZpcnN0 IHVzZSB0aGlzIGZ1bmN0aW9uKQ0KaW5pdC5jOjMyOTogd2FybmluZzogc3Rh dGVtZW50IHdpdGggbm8gZWZmZWN0DQppbml0LmM6MzM1OiByZXF1ZXN0IGZv ciBtZW1iZXIgYHZpc3VhbCcgaW4gc29tZXRoaW5nIG5vdCBhIHN0cnVjdHVy ZSBvciB1bmlvbg0KaW5pdC5jOjM0MjogcmVxdWVzdCBmb3IgbWVtYmVyIGBm b2N1cycgaW4gc29tZXRoaW5nIG5vdCBhIHN0cnVjdHVyZSBvciB1bmlvbg0K aW5pdC5jOiBBdCB0b3AgbGV2ZWw6DQppbml0LmM6MzQ5OiBwYXJzZSBlcnJv ciBiZWZvcmUgYConDQppbml0LmM6MzUwOiB3YXJuaW5nOiByZXR1cm4tdHlw ZSBkZWZhdWx0cyB0byBgaW50Jw0KaW5pdC5jOjM1MDogY29uZmxpY3Rpbmcg dHlwZXMgZm9yIGBnZ2lHZXRGb2N1cycNCi91c3IyL3NyYy9DVlMvZ2dpLWV2 c3RhY2svbGliL2xpYmdnaS9pbmNsdWRlL2dnaS9saWJnZ2kuaDo5NTogcHJl dmlvdXMgZGVjbGFyYXRpb24gb2YgYGdnaUdldEZvY3VzJw0KaW5pdC5jOiBJ biBmdW5jdGlvbiBgZ2dpR2V0Rm9jdXMnOg0KaW5pdC5jOjM1MTogcmVxdWVz dCBmb3IgbWVtYmVyIGBmb2N1cycgaW4gc29tZXRoaW5nIG5vdCBhIHN0cnVj dHVyZSBvciB1bmlvbg0KaW5pdC5jOjM1Mjogd2FybmluZzogY29udHJvbCBy ZWFjaGVzIGVuZCBvZiBub24tdm9pZCBmdW5jdGlvbg0KL3VzcjIvc3JjL0NW Uy9nZ2ktZXZzdGFjay9saWIvbGliZ2dpL2luY2x1ZGUvc3RydWN0cy5oOiBB dCB0b3AgbGV2ZWw6DQovdXNyMi9zcmMvQ1ZTL2dnaS1ldnN0YWNrL2xpYi9s aWJnZ2kvaW5jbHVkZS9zdHJ1Y3RzLmg6NzE6IHN0b3JhZ2Ugc2l6ZSBvZiBg aW5mbycgaXNuJ3Qga25vd24NCm1ha2U6ICoqKiBbaW5pdC5vXSBFcnJvciAx DQo= ---1463800064-175199511-885249818=:2912-- From evstack-request@ontv.com Mon Jan 19 15:37:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA07540 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 15:37:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA19404; Mon, 19 Jan 1998 18:03:04 -0500 Resent-Date: Mon, 19 Jan 1998 18:03:04 -0500 To: evstack@ontv.com Subject: Can't get current evstack to work... Date: Mon, 19 Jan 1998 22:41:55 +0100 Reply-To: Daniel.Egger@t-online.de X-Mailer: KMail [version 0.5.1] MIME-Version: 1.0 Message-Id: <98011922575501.00172@z2.n2480.f898.fidonet.org> X-Sender: 0844189307-0001@t-online.de From: Daniel.Egger@t-online.de (Daniel Egger) Resent-Message-ID: <"qt6yK2.0.Vk4.Rjzmq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/418 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com -----BEGIN PGP SIGNED MESSAGE----- Hiho! I just tried to compile the current evstack. The "official" ggi version isn't compileable due to the fact that I'm running linux 2.1.80pre4 and the patch for 2.1.71 doesn't apply for this version. So I decided to try out the CVS version: The patch for 2.1.77 applied without problems.... The kernel rebootet causing a large number of unsuccessful keyboard bindings. Only one console works. I tried to compile the drivers but TrioV64+ failed to compile so I used vga. Insmoding this driver causes an unusable console because of the mispointing cursor and a holy bunch of characters on the screen. But (I wondered) the other consoles are useable again. So I tried to compile the libraries but no one was compileable due to typos/thinkos in the header files?!? My system is an i486 linux/libc5 system with gcc 2.7.0.13 or/and current egcs. If you need more detailed information (official bug-report-form?) I'll do my very best to help you getting this thing work.... - -- Servus, Daniel -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBNMPMYmEdw1sxhJOZAQFDOgP/dzLd7siKeiF3fLseaRH5NIxzB7JX2GeX KvTm8EmDU8yJbecZfdkPgzVquMgPRr2ToSTWG9Cy5Td9k3F76UTtAQ3nh81P+4Tn doUCsyRCGtLxpJ+5pH4HBQHMDiyOVIUCyMcmnBz7vKDNTJdgpYiV0lw5AayMfv6c bzGriD8nL1Q= =TZnZ -----END PGP SIGNATURE----- From evstack-request@ontv.com Mon Jan 19 16:23:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA07633 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 16:23:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA19768; Mon, 19 Jan 1998 18:48:37 -0500 Resent-Date: Mon, 19 Jan 1998 18:48:37 -0500 Date: Mon, 19 Jan 1998 18:48:00 -0500 (EST) From: Jordan Mendelson <jordy@wserv.com> To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: evstack & monitor driver errors In-Reply-To: <6a0jaf$pv8$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980119184722.12820A-100000@snappy.wserv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"UJJui3.0.Dq4._N-mq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/419 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 19 Jan 1998, Jason McMullan wrote: > > check_mode: chipset ok. > > check_mode: graphics ok. > > timelist.c:252: timing limits violated, hfreq = 31157, vfreq = 69, dclk = > > 28322000 > > Hmm.. That's with the VGA monosync driver, right? That's with timelist monitor defs (hence the name, timelist.c :), however the same thing happens with the monosync driver. Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Mon Jan 19 17:03:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA07696 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 17:03:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA20196; Mon, 19 Jan 1998 19:28:38 -0500 Resent-Date: Mon, 19 Jan 1998 19:28:38 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xuQUF-0000XUC@charon.beck-sw.de> Subject: Re: First blood To: evstack@ontv.com (Evstack Mailing List) Date: Tue, 20 Jan 1998 00:20:11 +0100 (MET) In-Reply-To: <34C3954E.3CC5DB7D@mirus.fr> from "Emmanuel Marty" at Jan 19, 98 07:02:54 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"WJ6Zk2.0.uw4.Oz-mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/420 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. > Is it on purpose, or does it provoke a double or triple CPU fault > by accident? :) Hmm - haven't checked ... but is anyone else experiencing that CMOS erased problem ? I had it several times when shutting down _cleanly_. Just going to runlevel 1 unmounting all fs and pressing reset works fine ... > * Cursor is not displayed at the right position > The line is "/home/core/ggi-evstack/driver#" and it's under the "v" > instead of being after the "#". Yes. See the same here. Strangely it does not happen at the very left of each scanline ... > NOTE: The MediaGX has no textmode and is even emulating VGA in > software. It might not be completely EvStack-related - though I > never seen it emulate the cursor wrong with previous KGI VGA driver. No - it happens with other cards as well. CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Mon Jan 19 17:43:35 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA07736 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 17:43:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA20577; Mon, 19 Jan 1998 20:09:06 -0500 Resent-Date: Mon, 19 Jan 1998 20:09:06 -0500 Date: Mon, 19 Jan 1998 18:18:18 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: Alan Cox <alan@lxorguk.ukuu.org.uk> cc: evstack@ontv.com, becka@rz.uni-duesseldorf.de Subject: Re: [Feature Wish] GGI in Linux 2.3 In-Reply-To: <m0xs3To-0005FzC@lightning.swansea.linux.org.uk> Message-ID: <Pine.LNX.3.96.980113104451.806A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"rPbeI3.0.k05.PZ_mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/421 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 13 Jan 1998, Alan Cox wrote: > > Is there a particular max-size for a font? My current code goes from 0x0 > > (useless) to 16x16 without a problem.... (I just limited to 16x16 because > > it made more sense for VGA-font compatibility.. though I suppose 8x16 is > > more usable as a limit. VGA hardware is capable of as low as 6x8 font > > quality AFAIK - though 8x8 could be the real limit) [if that helps for > > debugging such font-sizes that is] > > Unless there is a good reason for not doing it supporting large fonts > isnt a bad thing. Running 320x200 with 32x32 fonts is a common thing for > the partially sighted. (Along with running X11 via Xmag all the time) Okay - shall do :) [I'll start scanning into the code tonight.... I'll use BDF format for fonts for now :] (either that or minix format or something... perhaps linux native? :) Should I support >32-bit wide fonts? An advantage with 32-bits is that they can be completely encoded into an integer for bit-testing. (suppose I could do bigger - but I'd split the code into several subroutines then...) > > commercial support from Cyrix for the Media/GX chips :] > > Got any source code out of them yet ;) Yep - through NDA so it's not well-documented... *checking* It's not in CVS yet though. Apparently working perfectly - but I don't know *yet* where to get it. It was announced mid to late decembre-ish that Cyrix finally okayed the code *grin*.... so it SHOULD be available... somewhere G'day, eh? :) - Teunis (yes - finally trying to follow up on older messages) From evstack-request@ontv.com Mon Jan 19 18:03:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA07762 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 18:03:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA20749; Mon, 19 Jan 1998 20:29:09 -0500 Resent-Date: Mon, 19 Jan 1998 20:29:09 -0500 Message-Id: <m0xuSQ8-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/graph functional! To: evstack@ontv.com Date: Tue, 20 Jan 1998 12:24:04 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <69voi4$4n6$1@grits.visus.com> from "Jason McMullan" at Jan 19, 98 02:39:00 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"40qN03.0.c35.Rs_mq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/422 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Blech... There's some un-initialized (or buffer over-run, or > whatever), but it doesn't tickle my system... Couldn't > make it Oops all weekend... Do you get Oops? Yeah, a NULL pointer dereference in graph_driver_command(), pretty sure it's in DRIVER_SETGRAPHMODE... > > Still no go :-(. The echo on /dev/vty09 shows the following: > > > warning: dev(04:01) tty_count(6) != #fd's(2) in tty_open > > warning: dev(04:01) tty_count(6) != #fd's(2) in release_dev > > release_dev: driver.table[1] not tty for (04:01) > > > > [similiar output with other vtys] > > Argh! Argh! Argh!.... Can you uuencode & email me your kernel? > I'll try to find a machine I can run it on.... I just noticed something: bash> dir /dev/vtyFF crw-rw---- 1 root users 120, 0 Jan 8 21:36 /dev/vtyFF bash> dir /dev/graphFF crw-rw---- 1 root users 121, 0 Jan 8 21:36 /dev/graphFF bash> dir /dev/eventFF crw-rw---- 1 root users 122, 0 Jan 8 21:36 /dev/eventFF All the minors are 0 ! Same for each XX ending. Did I get a dud copy of the script, or is the script broken ? I'll try fixing it by hand and see if testvid works then... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 19 18:17:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA07777 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 18:17:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA20876; Mon, 19 Jan 1998 20:42:12 -0500 Resent-Date: Mon, 19 Jan 1998 20:42:12 -0500 Message-Id: <m0xuScn-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Raw keyboard fixed ! To: evstack@ontv.com Date: Tue, 20 Jan 1998 12:37:09 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sYq28.0.Z55.K20nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/423 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, I've just committed the RAW and MEDIUMRAW keyboard emulation stuff to the repository. X should work as normal, as well as SVGAlib apps (only tested sdoom so far). Included is the stack priority stuff. Everyone please do 'cvs update' and try it out! Jason, what's the deal with the kernel patches ? I modified tty_io.c to get /dev/console to work properly, so should I send you the new version, or is updating patches/Linux/patch-2.1.77 (which is what I've done) good enough ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 19 19:44:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA07885 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 19:44:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA21648; Mon, 19 Jan 1998 22:09:36 -0500 Resent-Date: Mon, 19 Jan 1998 22:09:36 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xuTCh-0000XWC@charon.beck-sw.de> Subject: Re: Repatching source for kernel. To: evstack@ontv.com Date: Tue, 20 Jan 1998 03:14:15 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980119150740.1445C-100000@sigil.computersupportcentre.com> from "teunis" at Jan 19, 98 03:09:59 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"M_jGK2.0.eH5.GK1nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/424 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > I redownload ggi-evstack almost every day right now.... is there a safe > way to insert it into my kernel source or do I have to rm the old source, > reunpack linux-2.1.79, and repatch _EVERY_ time? If I have seen it right, the script nicely symlinks thinks in a developer- convenient way. Only if the patch itself changes the above should be necessary ... > Oh - is 2.1.79 yet supported by the "make kernel" bit? I have to manually > patch AFAIK which has been a pain. Worked like a charm for me ... strange ... CU,andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Mon Jan 19 20:04:58 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA07923 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 20:04:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA21828; Mon, 19 Jan 1998 22:30:41 -0500 Resent-Date: Mon, 19 Jan 1998 22:30:41 -0500 Date: Mon, 19 Jan 1998 20:40:05 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: *G* - the playing continues Message-ID: <Pine.LNX.3.96.980119203126.567I-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"FodE03.0.VK5.Fe1nq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/425 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Mouse finally works :) [now how do I use it? mc -x works...] Are there such a thing as EvStack demo-code? (ie: I can't find any) ... I'd like to start working on the 6-consoles-ona-cube - but without libGGI (it still won't compile) or a clue about how to talk to EvStacks I'm gonna be out on a limb *sigh*.... ... just found utils/EvTest - I guess I have somewhere to start :) Console 6 eventually oopses out, killing that console completely. No consoles above 6 seem to work (I use console 8 to track /var/log/messages normally) ... it might have something to do with mpeg-3 player though as that's what's been running every time. (it works fine in non-GGI though) This normal? I can post the oopses if anyone wants :) [they get logged nicely] G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 19 20:27:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA07958 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 20:27:10 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA21957; Mon, 19 Jan 1998 22:52:55 -0500 Resent-Date: Mon, 19 Jan 1998 22:52:55 -0500 Date: Mon, 19 Jan 1998 22:52:21 -0500 (EST) From: Jordan Mendelson <jordy@wserv.com> To: Evstack Mailing List <evstack@ontv.com> Subject: Re: First blood In-Reply-To: <m0xuQUF-0000XUC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980119225127.19901B-100000@snappy.wserv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"-fTla.0.YM5.3z1nq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/426 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 20 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. > > Is it on purpose, or does it provoke a double or triple CPU fault > > by accident? :) I might add that my tab key for completion under ncftp is broken as well, I haven't checked but under bash as well. Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Mon Jan 19 23:18:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA08161 for <ggi@synergy.foo.net>; Mon, 19 Jan 1998 23:18:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA23532; Tue, 20 Jan 1998 01:44:04 -0500 Resent-Date: Tue, 20 Jan 1998 01:44:04 -0500 Message-Id: <m0xuXLw-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Raw keyboard fixed ! (addendum) To: evstack@ontv.com Date: Tue, 20 Jan 1998 17:40:04 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xuScn-00017OC@ajax> from "Andrew Apted" at Jan 20, 98 12:37:09 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ntP-4.0.Fl5.FU4nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/427 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Your's truly writes: > I've just committed the RAW and MEDIUMRAW keyboard emulation stuff to > the repository. X should work as normal, as well as SVGAlib apps (only > tested sdoom so far). Included is the stack priority stuff. Everyone > please do 'cvs update' and try it out! Note that you'll need to REPATCH the kernel as well... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 20 02:17:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA08466 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 02:17:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id EAA24441; Tue, 20 Jan 1998 04:43:47 -0500 Resent-Date: Tue, 20 Jan 1998 04:43:47 -0500 Sender: core@tron.mirus.fr Message-ID: <34C46F05.BE3CCF69@mirus.fr> Date: Tue, 20 Jan 1998 10:31:50 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: how to get /dev/graph to work Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FpwlK3.0.Ez5.V57nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/428 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello, I have investigated that problem that Andy and I have, not being able to set any graphic mode. First, MAKEDEV.ggi doesn't create /dev/graphic, do you need to : cd /dev rm -f graphic mknod -c --mode=0660 graphic c 121 0 or the KGI target is not happy. Once I did this, if you tried to open ("/dev/graphic", O_RDWR), i got -1 as fd and errno 19 (No such device). Examining syslog shown : Jan 20 09:34:20 surfnet modprobe: can't locate module char-major-121 Aha. Obviously, kernel 2.1.79 that i'm running, needs something new to be defined or it makes up a module name like this, instead of devgraph. So, well, you can get it to work by doing : cd /lib/modules/2.1.79/misc ln -s devgraph.o char-major-121.o depmod -a Then if you insmod the VGA driver and try to run a demo, it works (woo!) I'll investigate what is missing and fix it, but just wanted to let you know how you can get it to run (no, Jason is not insane, it does work on his system :)) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Tue Jan 20 02:37:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA08505 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 02:37:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA24667; Tue, 20 Jan 1998 05:03:16 -0500 Resent-Date: Tue, 20 Jan 1998 05:03:16 -0500 Sender: core@tron.mirus.fr Message-ID: <34C47386.3F6331FB@mirus.fr> Date: Tue, 20 Jan 1998 10:51:02 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com, andreas.beck@ggi-project.org Subject: how to get /dev/graph to work (bis) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RICuw3.0.r06.UN7nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/429 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi again, I'm not too familiar with modules.. Seems to be a 'normal' behavior (see my previous post) with misc modules. Edit /etc/conf.modules and add "alias char-major-121 devgraph", redo depmod -a. Then graphic modes will, to a certain extent, work. i.e. running "demo", the 320x200x8 mode is set successfully and you have the "press a key to begin tests.." message, but it doesn't do anything else, and if you exit w/ ESC, the textmode is completely messed. I'll investigate that too... ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Tue Jan 20 03:10:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA08551 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 03:10:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA24807; Tue, 20 Jan 1998 05:36:20 -0500 Resent-Date: Tue, 20 Jan 1998 05:36:20 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xubwL-0000XWC@charon.beck-sw.de> Subject: Re: display-CUBE To: evstack@ontv.com Date: Tue, 20 Jan 1998 12:33:57 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980119130736.1982C-100000@sigil.computersupportcentre.com> from "teunis" at Jan 19, 98 01:25:13 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"8yJ0l3.0.336.Ut7nq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/430 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > That covers it? (yep - the 3D-lib's already starting to be capable of > extensions... perhaps I should check how libGGI handles it so I can make > the two compatible :) Yes. I commited LibGGI2d frame tonight. Have a look. It would be nice, if your lib would use the same frame and use the native LibGGI extension mechanism. > > > PS : Is there anyway to turn off the debug? It's seriously messing up all > > > my consoles. > > klogd ? > > Oh? What flags / etc do I use? (I've never used klogd). -c n Sets the default log level of console messages to n. CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Tue Jan 20 08:15:23 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08895 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:15:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27075; Tue, 20 Jan 1998 10:40:57 -0500 Resent-Date: Tue, 20 Jan 1998 10:40:57 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Can't get current evstack to work... Date: 20 Jan 1998 15:38:07 GMT Organization: OnTV Pittsburgh, L.P. Lines: 39 Distribution: local Message-ID: <6a2gcv$ac1$1@grits.visus.com> References: <6a0mgk$ttc$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"8Cflf3.0.Jb6.GJCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/431 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Daniel Egger (Daniel.Egger@t-online.de) wrote: > So I decided to try out the CVS version: > The patch for 2.1.77 applied without problems.... > The kernel rebootet causing a large number of unsuccessful keyboard bindings. > Only one console works. Odd.. But then again, I usually boot to a minimal floppy root to test evstack... I don't trust it. [And I wrote the darned thing] > I tried to compile the drivers but TrioV64+ failed to compile so I used vga. Known problem. Only VGA and Hercules have been worked on. > Insmoding this driver causes an unusable console because of the mispointing > cursor and a holy bunch of characters on the screen. Known bug. Being worked on. > But (I wondered) the other consoles are useable again. > So I tried to compile the libraries but no one was compileable due to > typos/thinkos in the header files?!? > My system is an i486 linux/libc5 system with gcc 2.7.0.13 or/and current egcs. Hmmm.. Could you email the list a sample of the compiler warnings? > If you need more detailed information (official bug-report-form?) I'll do > my very best to help you getting this thing work.... Thanks! The EvStack code is NOT even in Alpha yet. We're still amazed when our machines don't spontaneously combust. (Quick! Put the magic smoke back in!) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 08:15:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08902 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:15:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27106; Tue, 20 Jan 1998 10:41:28 -0500 Resent-Date: Tue, 20 Jan 1998 10:41:28 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: First blood Date: 20 Jan 1998 15:40:22 GMT Organization: OnTV Pittsburgh, L.P. Lines: 20 Distribution: local Message-ID: <6a2gh6$ac1$2@grits.visus.com> References: <6a0rft$1t5$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"ECfJF3.0.Rc6.MLCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/432 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. > > Is it on purpose, or does it provoke a double or triple CPU fault > > by accident? :) > Hmm - haven't checked ... but is anyone else experiencing that > CMOS erased problem ? I had it several times when shutting down _cleanly_. Nope. Not me. And _I_ usually only run a `minimal' system when testing kernels... I don't even run init, just /bin/sh... [and I recommend you all do the same! :^) ] -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 08:17:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08916 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:17:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27181; Tue, 20 Jan 1998 10:42:41 -0500 Resent-Date: Tue, 20 Jan 1998 10:42:41 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: how to get /dev/graph to work Date: 20 Jan 1998 15:41:50 GMT Organization: OnTV Pittsburgh, L.P. Lines: 13 Distribution: local Message-ID: <6a2gju$ac1$3@grits.visus.com> References: <6a1s0m$plt$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"eT47r.0.nd6.lMCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/433 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > Then if you insmod the VGA driver and try to run a demo, it works (woo!) > I'll investigate what is missing and fix it, but just wanted to let > you know how you can get it to run (no, Jason is not insane, it does > work on his system :)) Heresy! I'm crazier than a march hare! I dare you to show otherwise! ;^) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 08:18:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08922 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:18:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27253; Tue, 20 Jan 1998 10:44:34 -0500 Resent-Date: Tue, 20 Jan 1998 10:44:34 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Problems compiling libGGI - any ideas? Date: 20 Jan 1998 15:43:40 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Distribution: local Message-ID: <6a2gnc$ac1$4@grits.visus.com> References: <6a0lb1$ss5$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"lpBFJ1.0.Bf6.YOCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/434 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > I've got a couple of problems compiling libGGI under EvStacks... > .. uh - any ideas? > I configured for all targets and am running an EvStack/GGI version of > sometime in the last 2 hours.. (~3:30MST pickup time) > I use glibc-2.0.5c if anyone cares (and either egcs-1.0 (patched a little) > or gcc-2.7.2.1) > Should I download the current 0.0.9 GGI and use that libGGI instead? Yes - the libGGI in the EvStack dist is really stale... NOBODY SHOULD USE IT. It was fine a few months ago... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 08:22:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08931 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:22:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27344; Tue, 20 Jan 1998 10:47:43 -0500 Resent-Date: Tue, 20 Jan 1998 10:47:43 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Raw keyboard fixed ! Date: 20 Jan 1998 15:46:39 GMT Organization: OnTV Pittsburgh, L.P. Lines: 27 Distribution: local Message-ID: <6a2gsv$ac1$5@grits.visus.com> References: <6a0vsj$5l2$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"JmzgJ2.0.dg6.GRCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/435 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > I've just committed the RAW and MEDIUMRAW keyboard emulation stuff to > the repository. X should work as normal, as well as SVGAlib apps (only > tested sdoom so far). Included is the stack priority stuff. Everyone > please do 'cvs update' and try it out! Woo hoo! Compatability! So, tell us, how does the RAW and MEDIUMRAW stuff work? [as I'm CVSing the latest and greatest...] > Jason, what's the deal with the kernel patches ? I modified tty_io.c to > get /dev/console to work properly, so should I send you the new version, > or is updating patches/Linux/patch-2.1.77 (which is what I've done) good > enough ? Updating the patches is good enough. Idea: When anyone makes changes to the Kernel Patch (as opposed to the files that are symlinked in), please announce it on the list because 90% of the time we don't need to re-apply it.. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 08:30:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08957 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:30:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA27491; Tue, 20 Jan 1998 10:56:28 -0500 Resent-Date: Tue, 20 Jan 1998 10:56:28 -0500 Sender: core@tron.mirus.fr Message-ID: <34C4C671.4A62E6E9@mirus.fr> Date: Tue, 20 Jan 1998 16:44:49 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: got the MediaGX driver to work.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-XOym2.0.ti6.HZCnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/436 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello, This is just to inform you that I got the mediaGX chipset driver, ICS 5342 prog pll driver (and hence pll.inc :) and ICS 5342 RAMDAC driver to compile and run on EvStack. I seem to have a problem with graphic modes and I need to implement graphic console textops, but my impression is that everything is _much_ saner and coherent than before. The level of difficulty of porting a Dali driver to EvStack is reasonable, it's mostly removing fb_ things, setting up the ops structure, moving most mode root fields into the tm substructure, modifying the kgim_???_command parameters.. It's reasonable. :) When I'm done with the GX driver, I'll publish some documentation about how to convert a driver (I took notes already, I need to make them readable and to ask for your opinion before it's put in the docs). I suppose the merge in two weeks or so, will involve merging most of the dali tree (most of the includes, all drivers except VGA and MediaGX, libggi, etc) with the evstack sources.. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Tue Jan 20 08:53:51 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA08978 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 08:53:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA27843; Tue, 20 Jan 1998 11:19:33 -0500 Resent-Date: Tue, 20 Jan 1998 11:19:33 -0500 Date: Tue, 20 Jan 1998 09:29:30 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: um... why I can't patch kernel Message-ID: <Pine.LNX.3.96.980120092749.2373C-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-1302491926-885313770=:2373" Resent-Message-ID: <"rcBCD.0.Ro6.VvCnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/437 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-1302491926-885313770=:2373 Content-Type: TEXT/PLAIN; charset=US-ASCII Can anyone explain why I get this instead of a working option? (it's why I can't patch/unpatch automatically my kernel) [sorry to spam y'all with this but I'm trying to find (potential?) problems for newbies (like myself :)] G'day, eh? :) - Teunis ---1463800064-1302491926-885313770=:2373 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980120092930.2373D@sigil.computersupportcentre.com> Content-Description: S0VSTkVMU1JDID0gDQpkaWFsb2cgdmVyc2lvbiAwLjMsIGJ5IFNhdmlvIExh bSAobGFtODM2QGNzLmN1aGsuaGspLg0KICBwYXRjaGVkIHRvIHZlcnNpb24g MC40IGJ5IFN0dWFydCBIZXJiZXJ0IChTLkhlcmJlcnRAc2hlZi5hYy51aykN Cg0KKiBEaXNwbGF5IGRpYWxvZyBib3hlcyBmcm9tIHNoZWxsIHNjcmlwdHMg Kg0KDQpVc2FnZTogZGlhbG9nIC0tY2xlYXINCiAgICAgICBkaWFsb2cgWy0t dGl0bGUgPHRpdGxlPl0gWy0tYmFja3RpdGxlIDxiYWNrdGl0bGU+IF0gWy0t Y2xlYXJdIDxCb3ggb3B0aW9ucz4NCg0KQm94IG9wdGlvbnM6DQoNCiAgLS15 ZXNubyAgICAgPHRleHQ+IDxoZWlnaHQ+IDx3aWR0aD4NCiAgLS1tc2dib3gg ICAgPHRleHQ+IDxoZWlnaHQ+IDx3aWR0aD4NCiAgLS1pbmZvYm94ICAgPHRl eHQ+IDxoZWlnaHQ+IDx3aWR0aD4NCiAgLS1pbnB1dGJveCAgPHRleHQ+IDxo ZWlnaHQ+IDx3aWR0aD4NCiAgLS10ZXh0Ym94ICAgPGZpbGU+IDxoZWlnaHQ+ IDx3aWR0aD4NCiAgLS1tZW51ICAgICAgPHRleHQ+IDxoZWlnaHQ+IDx3aWR0 aD4gPG1lbnUgaGVpZ2h0PiA8dGFnMT4gPGl0ZW0xPi4uLg0KICAtLWNoZWNr bGlzdCA8dGV4dD4gPGhlaWdodD4gPHdpZHRoPiA8bGlzdCBoZWlnaHQ+IDx0 YWcxPiA8aXRlbTE+IDxzdGF0dXMxPi4uLi8qDQogIC0tcmFkaW9saXN0IDx0 ZXh0PiA8aGVpZ2h0PiA8d2lkdGg+IDxsaXN0IGhlaWdodD4gPHRhZzE+IDxp dGVtMT4gPHN0YXR1czE+Li4uKi8NCg== ---1463800064-1302491926-885313770=:2373-- From evstack-request@ontv.com Tue Jan 20 11:44:07 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA09220 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 11:44:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA29467; Tue, 20 Jan 1998 14:09:02 -0500 Resent-Date: Tue, 20 Jan 1998 14:09:02 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: got the MediaGX driver to work.. Date: 20 Jan 1998 19:07:29 GMT Organization: OnTV Pittsburgh, L.P. Lines: 42 Distribution: local Message-ID: <6a2slh$kjc$1@grits.visus.com> References: <6a2hma$bpg$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"7f9Bl3.0.aB7.YNFnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/438 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > This is just to inform you that I got the mediaGX chipset driver, > ICS 5342 prog pll driver (and hence pll.inc :) and ICS 5342 RAMDAC > driver to compile and run on EvStack. Yeah! Someone (other than I) with a success report! > I seem to have a problem > with graphic modes and I need to implement graphic console textops, > but my impression is that everything is _much_ saner and coherent > than before. Yep - with the new system, I _expect_ the display to be a write-only, graphical text mode. TEXT16 is the exception in this model, not the rule. [and easy exception, I must say..] > The level of difficulty of porting a Dali driver to > EvStack is reasonable, it's mostly removing fb_ things, setting > up the ops structure, moving most mode root fields into the tm > substructure, modifying the kgim_???_command parameters.. It's > reasonable. :) When I'm done with the GX driver, I'll publish some > documentation about how to convert a driver (I took notes already, > I need to make them readable and to ask for your opinion before > it's put in the docs). Can't wait! Do you have the same cursor problem in your driver as VGA? Is your kgi_mode.textop field set properly after switching back from a `graphics' (ha!) mode? > I suppose the merge in two weeks or so, will involve merging most > of the dali tree (most of the includes, all drivers except VGA > and MediaGX, libggi, etc) with the evstack sources.. Vice versa. We will be moving the EvStack stuff into the DEGAS tree. Do a `cvs checkout degas' to see what I mean.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Tue Jan 20 13:08:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA09329 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 13:08:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id PAA30239; Tue, 20 Jan 1998 15:33:42 -0500 Resent-Date: Tue, 20 Jan 1998 15:33:42 -0500 Sender: duff@salsa.visus.com Message-ID: <34C509D6.3BE3CB90@cip.informatik.uni-erlangen.de> Date: Tue, 20 Jan 1998 21:32:22 +0100 From: Andreas Vogler <asvogler@cip.informatik.uni-erlangen.de> X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.78 i586) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: um... why I can't patch kernel References: <Pine.LNX.3.96.980120092749.2373C-200000@sigil.computersupportcentre.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_daYT1.0._N7.cdGnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/439 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis wrote: > > Can anyone explain why I get this instead of a working option? > (it's why I can't patch/unpatch automatically my kernel) > [sorry to spam y'all with this but I'm trying to find (potential?) > problems for newbies (like myself :)] > KERNELSRC = > dialog version 0.3, by Savio Lam (lam836@cs.cuhk.hk). > patched to version 0.4 by Stuart Herbert (S.Herbert@shef.ac.uk) > > * Display dialog boxes from shell scripts * > > [...] This problem happens if you are using a version of dialog which doesn't support an initial value for input fields. Try using a more recent version of 'dialog' or edit this file by hand: KERNELSRC = /usr/src/linux or whereever your kernel may be Andreas -- / \ "All that we see or seem \ / / \ is but a dream within a dream" E.A. Poe \ / From evstack-request@ontv.com Tue Jan 20 14:56:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA09455 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 14:56:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA31312; Tue, 20 Jan 1998 17:21:37 -0500 Resent-Date: Tue, 20 Jan 1998 17:21:37 -0500 Date: Tue, 20 Jan 1998 15:31:29 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: Can't get current evstack to work... In-Reply-To: <6a2gcv$ac1$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980120152751.747A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"bPscc.0.le7.uCInq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/440 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 20 Jan 1998, Jason McMullan wrote: > Daniel Egger (Daniel.Egger@t-online.de) wrote: > > > I tried to compile the drivers but TrioV64+ failed to compile so I used vga. > > Known problem. Only VGA and Hercules have been worked on. Any advice on where to start with this? Or any other drivers? *grin* > > But (I wondered) the other consoles are useable again. > > So I tried to compile the libraries but no one was compileable due to > > typos/thinkos in the header files?!? > > My system is an i486 linux/libc5 system with gcc 2.7.0.13 or/and current egcs. > > Hmmm.. Could you email the list a sample of the compiler warnings? libGGI in the evstack kit doesn't compile. I downloaded the CVS ggi (standard) and that libGGI compiles just fine. When are the two going to be remerged? (not to beat a dead horse or anything) > > If you need more detailed information (official bug-report-form?) I'll do > > my very best to help you getting this thing work.... > > Thanks! The EvStack code is NOT even in Alpha yet. We're still amazed > when our machines don't spontaneously combust. (Quick! Put the magic > smoke back in!) *waving fan at magic smoke* Runs nicely here... Oh - the new keyboard code works just peachy-keen under X... Now if only I knew how to setup X to handle the evstack serialmouse driver.... (I had X setup for "gpm" before 'cause it made life easier :) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 20 14:58:38 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA09463 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 14:58:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA31387; Tue, 20 Jan 1998 17:23:49 -0500 Resent-Date: Tue, 20 Jan 1998 17:23:49 -0500 Date: Tue, 20 Jan 1998 15:33:51 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: First bloo In-Reply-To: <6a2gh6$ac1$2@grits.visus.com> Message-ID: <Pine.LNX.3.96.980120153144.747B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"BNv5K1.0.mf7.6FInq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/441 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 20 Jan 1998, Jason McMullan wrote: > becka@rz.uni-duesseldorf.de wrote: > > > > * CTRL-ALT-DEL reboots the machine right away, it doesn't shutdown. > > > Is it on purpose, or does it provoke a double or triple CPU fault > > > by accident? :) > > > Hmm - haven't checked ... but is anyone else experiencing that > > CMOS erased problem ? I had it several times when shutting down _cleanly_. > > Nope. Not me. And _I_ usually only run a `minimal' system when > testing kernels... I don't even run init, just /bin/sh... > > [and I recommend you all do the same! :^) ] *pthpthpthptht* *grin* Some of us _LIKE_ chancing our luck with alpha software :) ['sides, I've had no probs with any other hardware... just yer GGI/EvStack basics + the new sound-drivers] G'day, eh? :) - Teunis (running a heavily loaded [usually] system under EvStacks/GGI :) From evstack-request@ontv.com Tue Jan 20 15:18:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA09513 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 15:18:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA31554; Tue, 20 Jan 1998 17:43:59 -0500 Resent-Date: Tue, 20 Jan 1998 17:43:59 -0500 Date: Tue, 20 Jan 1998 15:53:44 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: um... why I can't patch kernel In-Reply-To: <34C509D6.3BE3CB90@cip.informatik.uni-erlangen.de> Message-ID: <Pine.LNX.3.96.980120153817.747C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"LqD273.0.Ri7.oXInq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/442 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 20 Jan 1998, Andreas Vogler wrote: > teunis wrote: > > > > Can anyone explain why I get this instead of a working option? > > (it's why I can't patch/unpatch automatically my kernel) > > [sorry to spam y'all with this but I'm trying to find (potential?) > > problems for newbies (like myself :)] > > > KERNELSRC = > > dialog version 0.3, by Savio Lam (lam836@cs.cuhk.hk). > > patched to version 0.4 by Stuart Herbert (S.Herbert@shef.ac.uk) > > > > * Display dialog boxes from shell scripts * > > > > > [...] > > This problem happens if you are using a version of dialog which doesn't > support an initial value for input fields. Try using a more recent > version of 'dialog' or edit this file by hand: This must go into REQUIRED_SOURCE (or whatever). This has had me burned for a while 'cause I couldn't figure it out... (so I did manual workarounds *sigh*) dialog is available from where? *hunting* Haven't found it... Just dl'ing latest RPM-version then. If you require files _PLEASE_ try to give the most common source.. (sunsite.unc.edu, redhat.com, ftp.funet.fi, and ftp.cdrom.com are all handy repositories... the only problem with them is that they are _BIG_) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 20 15:42:58 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA09538 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 15:42:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA31919; Tue, 20 Jan 1998 18:08:39 -0500 Resent-Date: Tue, 20 Jan 1998 18:08:39 -0500 Message-Id: <3.0.32.19980121000556.00c07bc0@tron.mirus.fr> X-Sender: core@tron.mirus.fr X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 Jan 1998 00:06:00 +0100 To: jmcc@ontv.com From: Emmanuel Marty <core@mirus.fr> Subject: Re: got the MediaGX driver to work.. Cc: evstack@ontv.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"2J4Fv1.0.Co7.zuInq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/443 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan wrote: >Emmanuel Marty (core@mirus.fr) wrote: >> This is just to inform you that I got the mediaGX chipset driver, >> ICS 5342 prog pll driver (and hence pll.inc :) and ICS 5342 RAMDAC >> driver to compile and run on EvStack. > > Yeah! Someone (other than I) with a success report! Hehe.. Well, getting EvStack to boot was already a success, I think. >> I seem to have a problem >> with graphic modes and I need to implement graphic console textops, >> but my impression is that everything is _much_ saner and coherent >> than before. > > Yep - with the new system, I _expect_ the display to be a >write-only, graphical text mode. TEXT16 is the exception in >this model, not the rule. [and easy exception, I must say..] Yes, I saw your efforts to handle text and graphics just the same way. The right thing to do, indeed. >> When I'm done with the GX driver, I'll publish some >> documentation about how to convert a driver (I took notes already, >> I need to make them readable and to ask for your opinion before >> it's put in the docs). > > Can't wait! Do you have the same cursor problem in your >driver as VGA? Is your kgi_mode.textop field set properly >after switching back from a `graphics' (ha!) mode? Easy, easy :) What works right now is insmodding/rmmodding the module, and setting modes. i.e., the most annoying part ; dclk and ramdac mode setting, horizontal/vertical total etc computation worked right away, and i was very happy of that. right now, i get a synced picture in the right mode with the right colors, displaying text. i don't have tackled graphical text rendering yet, so i don't have a cursor or a single char rendered.. it will run tomorrow most probably, i'll tell you how it is going, and fix what has to be fixed if the cursor is wrongly positioned with my driver too. >> I suppose the merge in two weeks or so, will involve merging most >> of the dali tree (most of the includes, all drivers except VGA >> and MediaGX, libggi, etc) with the evstack sources.. > > Vice versa. We will be moving the EvStack stuff into the >DEGAS tree. Do a `cvs checkout degas' to see what I mean.... "Did that, got the t-shirt" (that phrase just cracked me up Andy :). That's what I meant.. :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Tue Jan 20 15:49:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA09547 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 15:49:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA32007; Tue, 20 Jan 1998 18:15:00 -0500 Resent-Date: Tue, 20 Jan 1998 18:15:00 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xunlx-0000XWC@charon.beck-sw.de> Subject: You are not alone ... To: evstack@ontv.com (Evstack Mailing List) Date: Wed, 21 Jan 1998 01:12:01 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"RaJTJ.0.Zp7.B_Inq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/444 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com HI Jason ! YOU ARE NOT ALONE ! I finally managed to get graphics on EvStack, too. demo.c got to the point where it should start drawing inside its clipping rectangle. I assume it blocks on non-available input ... Switching away causes a corrupted font and usuabale console, but at least it does something ... ! I do not know what finally fixed it, I just did a complete repatch/ recompile. As a nice side-effect the CMOS-erased problem seems to be gone, too. So I can now head for ev_rc_* stuff again and whatever else strikes me ... Hercules support works nicely, too. CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Tue Jan 20 15:56:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA09578 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 15:56:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA32094; Tue, 20 Jan 1998 18:21:13 -0500 Resent-Date: Tue, 20 Jan 1998 18:21:13 -0500 Message-Id: <m0xumss-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Raw keyboard fixed ! To: evstack@ontv.com Date: Wed, 21 Jan 1998 10:15:06 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <6a2gsv$ac1$5@grits.visus.com> from "Jason McMullan" at Jan 20, 98 03:46:39 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KGG_T1.0.0r7.q4Jnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/445 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan writes: > Andrew Apted (ajapted@netspace.net.au) wrote: > > > I've just committed the RAW and MEDIUMRAW keyboard emulation stuff to > > the repository. X should work as normal, as well as SVGAlib apps (only > > tested sdoom so far). Included is the stack priority stuff. Everyone > > please do 'cvs update' and try it out! > > Woo hoo! Compatability! So, tell us, how does the RAW and MEDIUMRAW > stuff work? [as I'm CVSing the latest and greatest...] All the gory details are in conlinux.c :-), but here's a summary: When going from normal keyboard to RAW/MEDIUMRAW mode (in the linux ioctl KDSKBMODE, it creates and attaches a 'conlinux' stack to the corresponding termstack. This stack gets the key events, converts to scancodes if in RAW mode (no conversion needed in MEDIUMRAW mode), and then console_vt_stuffc()s them to the tty. When going back to XLATE mode, the conlinux stack is removed and destroyed, and the xterm stack can get the key events once again. > > Jason, what's the deal with the kernel patches ? > > Updating the patches is good enough. Ok. > Idea: When anyone makes changes to the Kernel Patch (as opposed > to the files that are symlinked in), please announce it > on the list because 90% of the time we don't need to > re-apply it.. Good idea. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 20 20:02:02 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09800 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 20:02:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA01328; Tue, 20 Jan 1998 22:27:30 -0500 Resent-Date: Tue, 20 Jan 1998 22:27:30 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xunuD-0000XWC@charon.beck-sw.de> Subject: Re: Can't get current evstack to work... To: evstack@ontv.com Date: Wed, 21 Jan 1998 01:20:33 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980120152751.747A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 20, 98 03:31:29 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"35hBJ3.0.fJ.jhMnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/446 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Runs nicely here... Oh - the new keyboard code works just peachy-keen > under X... Now if only I knew how to setup X to handle the evstack > serialmouse driver.... > (I had X setup for "gpm" before 'cause it made life easier :) You can simply set X to use /dev/mouse and the right protocol and then _not_ load the serialmouse driver (or at least not activate the line-discipline using setmouse). CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Tue Jan 20 20:02:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09803 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 20:02:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA01336; Tue, 20 Jan 1998 22:27:35 -0500 Resent-Date: Tue, 20 Jan 1998 22:27:35 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xuonY-0000XWC@charon.beck-sw.de> Subject: Re: 2.1.78 & prink() questions To: tbcx@dds.nl (Erlend Hoel) Date: Wed, 21 Jan 1998 02:17:44 +0100 (MET) Cc: evstack@ontv.com (Evstack Mailing List) In-Reply-To: <Pine.LNX.3.96.980120220742.2540C-100000@tightan.freenet.org> from "Erlend Hoel" at Jan 20, 98 10:33:31 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"ojf4A1.0.sJ.khMnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/447 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > As you can see, I am still way behind on cathing up on the list - my > problem is that mostly everything interests me, which results in my > wanting to read it all - and thus on those days when 150+ mails roll in... Yeah ... know that feeling ... > I don't mail the list with this, but instead ask you privately. Feel free to do this ... worst thing that could happen is I forward to the list ;-) > Is there no official agreement or plan to include GGI in Linux? Not yet. But we are heading towards an inclusion of EvStack in LInux 2.3.x. However we do not advertise with that yet, because we want to be sure we can hold what we promise ... > Why does there seem to be so much bad blood between Linux kernel > developers and GGI developers (which I, no matter how things turn, > will always consider partial Linux kernel developers in my heart, > with "partial" being where it is because GGI is so much more than > just Linux)? ;-) I suspect this is something that has to do with a few simple things : 1. We break existing applications (lots of them, all graphics apps) with the KGI code as in 0.0.9. Fortunately EvStack fixes that (I have designed it for this sole purpose ...). If I were Linus I wouldn't have let the old patch in, too. If X breaks on most people's systems, this is no good. 2. The old code doesn't look nice and is hard to understand. Again EvStack fixes that and I hope if all kernel devel people understand the patch at the very first glance, chances are better we get positive votes. 3. Backward compatibility. The new EvStack kernel allows to turn the KGI support on and off. 4. Psychological reasons. Linux is deemed as _the_ authority. And if he thinks kernel graphics are a bad idea, many will say so, just because he does. > Nobody ever said that we - and I don't even know how to explain who I feel > that "we" are, but it's some community of which I feel that I, and you, > and many with us, are part of - had to beat Microsoft, but computers will > forever loose a lot of their appeal, if not all, to me if I wake up one > day and can only use software on my box that has been created by the > minions of Bill Gates. He's trying to sell his software by pointing out > how divided and in contradiction the Un*x world is, and the part I hate > most is that he is mostly right! And now I have the impression that the > Linux community isn't the tightly soldered bunch I have always felt... I hope we will soon be again. I have a creeping suspicion about some mighty people working on becoming Billiboy for Linux and due to commercial interests they seem to actively hinder GGI development, because we would break into their market. I will not name them openly, but I suppose you and they know who I mean ... > Can you tell me anything that would help me understand why things are as > they are with the Linux <-> GGI issue? I have enourmous faith in both > Linux and GGI, and I know that GGI has grown beyond the need for Linux in > order to "make it", but I would find it an uncomprehensible tragedy if in > GGI ended up not being the option - the only option! - for the Linux > community that I think it should be. Well - even if we never get into the Linux kernel, GPL always allows us to continue. Well yes, I say FreeBSD would support us with all and everything, yes, _I_ might consider abandoning Linux and porting it. [ Don't worry, it will always be available for Linux I think ... ] > As always, many thanks for all you are doing! I hope you realize that the > enourmous quantity of work I know you put into GGI is very appreciated - > if not yet by the people you would want, then by many who remain silent in > their appreciation (and anticipation :) Thanks ... I actually do not care too much who appreciates our work. I do it, because I like what I do. But yes, it keeps me going, if some people tell me at times that what I am doing is right ... CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Tue Jan 20 20:29:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09819 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 20:29:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA01589; Tue, 20 Jan 1998 22:55:19 -0500 Resent-Date: Tue, 20 Jan 1998 22:55:19 -0500 Date: Tue, 20 Jan 1998 21:05:26 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: mouse and X? Message-ID: <Pine.LNX.3.96.980120210413.385D-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TdDXq1.0.FO.z5Nnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/448 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com So I have a serial mouse. How do I get it working under XFree86? I have not (yet) found info on this... Just curious is all... EvStack-native stuff seems to work fine :) [as does 'mc -x'] G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 20 20:40:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09827 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 20:40:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA01807; Tue, 20 Jan 1998 23:05:41 -0500 Resent-Date: Tue, 20 Jan 1998 23:05:41 -0500 Message-Id: <m0xurKd-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: mouse and X? To: evstack@ontv.com Date: Wed, 21 Jan 1998 15:00:03 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980120210413.385D-100000@sigil.computersupportcentre.com> from "teunis" at Jan 20, 98 09:05:26 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YsLbd1.0.kR.ZFNnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/449 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > So I have a serial mouse. How do I get it working under XFree86? > I have not (yet) found info on this... Just edit /etc/XF86Config and take a peek at the Pointer section. The gunk below is from mine. :) Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ <gunk> # ********************************************************************** # Pointer section # ********************************************************************** Section "Pointer" Protocol "Microsoft" Device "/dev/mouse" # When using XQUEUE, comment out the above two lines, and uncomment # the following line. # Protocol "Xqueue" # Baudrate and SampleRate are only for some Logitech mice # BaudRate 9600 # SampleRate 150 # Emulate3Buttons is an option for 2-button Microsoft mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) # Emulate3Buttons # Emulate3Timeout 50 # ChordMiddle is an option for some 3-button Logitech mice # ChordMiddle # ClearDTR # ClearRTS EndSection </gunk> From evstack-request@ontv.com Tue Jan 20 20:48:16 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09832 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 20:48:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA01910; Tue, 20 Jan 1998 23:13:46 -0500 Resent-Date: Tue, 20 Jan 1998 23:13:46 -0500 Message-Id: <m0xurRz-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: MAKEDEV.ggi To: evstack@ontv.com Date: Wed, 21 Jan 1998 15:07:39 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"enUv73.0.FT.cMNnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/450 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I've found the source of (at least some of) my woes. Old versions of mknod do not understand hex! Thus all the minors of the devices created by MAKEDEV.ggi were 0... This was version 3.12, upgrading to 3.16 has fixed the problem. We should add this to our ever-growing list of Required Software... Any ideas where to put this info ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 20 23:52:09 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA09903 for <ggi@synergy.foo.net>; Tue, 20 Jan 1998 23:52:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA04040; Wed, 21 Jan 1998 02:14:39 -0500 Resent-Date: Wed, 21 Jan 1998 02:14:39 -0500 Message-ID: <003801bd263c$17ead0c0$0c0a0a0a@massacre> From: "David Waite" <mass@ufl.edu> To: <evstack@ontv.com> Subject: Re: Can't get current evstack to work... Date: Wed, 21 Jan 1998 02:13:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"CAEAc3.0.g-.21Qnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/451 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com -----Original Message----- From: teunis <teunis@mauve.computersupportcentre.com> >On 20 Jan 1998, Jason McMullan wrote: > >> Daniel Egger (Daniel.Egger@t-online.de) wrote: >> >> > I tried to compile the drivers but TrioV64+ failed to compile so I used vga. >> >> Known problem. Only VGA and Hercules have been worked on. > >Any advice on where to start with this? >Or any other drivers? *grin* > Yeah.. I am taking a break from coding my IBM RGB52x Ramdac and clock drivers, because there is some bug that is driving me nuts, and I can't stand to think about it anymore :P Right now, I'm thinking I won't code anything more for GGI/KGI until EvStacks is in the tree (well, this also is because my root filesystem crashed. /usr/src is a symbolic link onto /.src/, and for some reason this directory and /var/log/ keep having major filesystem corruption. I have actually considered making one huge (200 Meg would be enough?) file, and using loopback so I just make a new file when it crabs out. But I am interested in doing documentation, and this little brief sanity check would be a good chance for me to do it. So if anyone wants anything covered, let me know... I will probably make it a HTML document, targeting lynx. Right now I'm trying to get the full evstacks tree though, so I can look at what is included. Is it a set of patches on the kernel, or replacement files? I'm trying to stay out of linux for at least a week (which means no patch command). =) Right now I am unable to download it, but I guarantee it is a problem with my ISP and not with the site that the evstacks snapshot is on. (They don't understand that other networks can't find a 10.10.23.48 or similar IP) >Runs nicely here... Oh - the new keyboard code works just peachy-keen >under X... Now if only I knew how to setup X to handle the evstack >serialmouse driver.... > >(I had X setup for "gpm" before 'cause it made life easier :) > Will gpm work with EvStacks? What is neccessary to get this working? This would be one grand thing to get working, either that or putting mouse support into bash *evil grin*. It is the one thing that is keeping a lot of people I know from using ggi (they aren't interested in developing, but they have matrox cards and the GGI support is rapidly surpassing the normal X and svgalib support.=)) -David Waite From evstack-request@ontv.com Wed Jan 21 02:46:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA10179 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 02:46:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA05038; Wed, 21 Jan 1998 05:11:01 -0500 Resent-Date: Wed, 21 Jan 1998 05:11:01 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xuy1G-0000XWC@charon.beck-sw.de> Subject: Re: Can't get current evstack to work... To: evstack@ontv.com Date: Wed, 21 Jan 1998 12:08:30 +0100 (MET) In-Reply-To: <003801bd263c$17ead0c0$0c0a0a0a@massacre> from "David Waite" at Jan 21, 98 02:13:23 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"mLlpf.0.AE1.wbSnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/452 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > But I am interested in doing documentation, and this little brief sanity > check would be a good chance for me to do it. So if anyone wants anything > covered, let me know... Hmm - maybe you could check my old documentation in lib/libggi/demos/.evstack and give it a major servicing interval ? Most other things on EvStack are not yet "set in stone", so your docs might get outdated very fast. But a FAQ would be nice. What is EvStack ? How Does it work ? What kernel(s) does it run on ? Will it break anything ? > Is it a set of patches on the kernel, or replacement files? Both. It does slight patches and adds much. You can en-/disable it at make config time. > Right now I am unable to download it, but I guarantee it is a problem with > my ISP and not with the site that the evstacks snapshot is on. (They don't > understand that other networks can't find a 10.10.23.48 or similar IP) ??? Don't say they assign that IP to your host ... ! They should be shot if they do ... > >(I had X setup for "gpm" before 'cause it made life easier :) > Will gpm work with EvStacks? What is neccessary to get this working? Haven't tried, I assume it will miss the "selection" ioctls. But it has been reported to run in some kind of "xterm mode" even under normal GGI ... > This would be one grand thing to get working, either that or putting mouse > support into bash *evil grin*. We will have selection support natively, soon. CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Wed Jan 21 04:13:34 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA10258 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 04:13:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA05538; Wed, 21 Jan 1998 06:39:13 -0500 Resent-Date: Wed, 21 Jan 1998 06:39:13 -0500 Message-Id: <m0xuyOL-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Raw keyboard fixed ! (AGAIN!) To: evstack@ontv.com Date: Wed, 21 Jan 1998 22:32:21 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xuXLw-00017OC@ajax> from "Andrew Apted" at Jan 20, 98 05:40:04 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=%#%record%#% Resent-Message-ID: <"WsNke2.0.1M1.ztTnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/453 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com --%#%record%#% Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 793 Your's truly writes: > > I've just committed the RAW and MEDIUMRAW keyboard emulation stuff to > > the repository. X should work as normal, as well as SVGAlib apps (only > > tested sdoom so far). Included is the stack priority stuff. Everyone > > please do 'cvs update' and try it out! > > Note that you'll need to REPATCH the kernel as well... Sorry folks, I forgot to commit the changes to the patch file -- Doh! It should be there now, but if you just want to fix up your current kernel sources, all you need to do is : cd /usr/src/linux/drivers/char patch < blah where 'blah' is the attached message. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ --%#%record%#% Content-Type: text/plain Content-Name: /tmp/blah Content-Length: 625 Content-Transfer-Encoding: base64 ZGlmZiAtdSB0dHlfaW8ubm9ybWFsIHR0eV9pby5jID4gL3RtcC9kaWZmCi0tLSB0dHlfaW8u bm9ybWFsCVdlZCBKYW4gMjEgMTk6MTk6MTEgMTk5OAorKysgdHR5X2lvLmMJV2VkIEphbiAy MSAxOToyMDo1MyAxOTk4CkBAIC0xMTk3LDcgKzExOTcsMTMgQEAKICNpZmRlZiBDT05GSUdf VlQKIAlpZiAoZGV2aWNlID09IENPTlNPTEVfREVWKSB7CiAjaWZkZWYgQ09ORklHX0dHSQot CQlpbnQgZmdfY29uc29sZT1NS19DT05TT0xFX0lEKDAsMCk7CS8qIEZJWEZJWCAqLworCQlp bnQgY3Vycl92dCA9IGNvbnNvbGVfaGVhZF9nZXRfbWFwcGVkX3Z0KDApOworCQlpbnQgZmdf Y29uc29sZTsKKwkJCisJCWlmIChjdXJyX3Z0IDwgMCkgeworCQkJY3Vycl92dD0wOworCQl9 CisJCWZnX2NvbnNvbGU9TUtfQ09OU09MRV9JRCgwLCBjdXJyX3Z0KTsKICNlbHNlCiAJCWV4 dGVybiBpbnQgZmdfY29uc29sZTsKICNlbmRpZgo= --%#%record%#% --%#%record%#%-- From evstack-request@ontv.com Wed Jan 21 07:13:34 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA10459 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 07:13:33 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA06866; Wed, 21 Jan 1998 09:38:56 -0500 Resent-Date: Wed, 21 Jan 1998 09:38:56 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: MAKEDEV.ggi Date: 21 Jan 1998 14:37:14 GMT Organization: OnTV Pittsburgh, L.P. Lines: 19 Distribution: local Message-ID: <6a516q$8bm$1@grits.visus.com> References: <6a3t1t$ft7$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"GdtER3.0.Cg1.8WWnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/454 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > I've found the source of (at least some of) my woes. Old versions of > mknod do not understand hex! Thus all the minors of the devices created > by MAKEDEV.ggi were 0... Oops... Anyone want to try to fix the MAKEDEV.ggi? > This was version 3.12, upgrading to 3.16 has fixed the problem. We > should add this to our ever-growing list of Required Software... > Any ideas where to put this info ? Top level of the tree, as `REQUIRED_SOFTWARE'? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 21 07:16:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA10469 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 07:16:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA06924; Wed, 21 Jan 1998 09:41:44 -0500 Resent-Date: Wed, 21 Jan 1998 09:41:44 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Raw keyboard fixed ! Date: 21 Jan 1998 14:38:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 21 Distribution: local Message-ID: <6a519v$8bm$2@grits.visus.com> References: <6a3boo$1k9$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"vcroa3.0.vg1.iXWnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/455 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted (ajapted@netspace.net.au) wrote: > When going from normal keyboard to RAW/MEDIUMRAW mode (in the linux > ioctl KDSKBMODE, it creates and attaches a 'conlinux' stack to the > corresponding termstack. This stack gets the key events, converts to > scancodes if in RAW mode (no conversion needed in MEDIUMRAW mode), and > then console_vt_stuffc()s them to the tty. > When going back to XLATE mode, the conlinux stack is removed and > destroyed, and the xterm stack can get the key events once again. Nice, clean, simple. Exactly what EvStacks should do! I commend your efforts! Can't wait to try it! [Haven't had time to get on my devel machine since Monday...] -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 21 09:55:12 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA10626 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 09:55:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA08663; Wed, 21 Jan 1998 12:20:34 -0500 Resent-Date: Wed, 21 Jan 1998 12:20:34 -0500 Date: Wed, 21 Jan 1998 10:29:38 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: evstack@ontv.com Subject: Re: mouse and X? In-Reply-To: <m0xurKd-00017OC@ajax> Message-ID: <Pine.LNX.3.96.980121094508.4485C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"2ZxxT2.0.m62.2uYnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/456 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 21 Jan 1998, Andrew Apted wrote: > teunis writes: > > > So I have a serial mouse. How do I get it working under XFree86? > > I have not (yet) found info on this... > > Just edit /etc/XF86Config and take a peek at the Pointer section. > The gunk below is from mine. :) Okay - time to start looking at a mouse-emulator for EvStacks :) I'm too used to GPM. (I reprogrammed my system to use gpm for _ALL_ mouse-action... Got tired of having the mouse reprogrammed every time I switched consoles...) ... of course, gpm sometimes loses track of the "selection" buffer... Isn't this kind of problem supposed to be "Fixed By EvStacks (tm)"? :) hmmm *thinking*... I'll see what I can do today about that - perhaps a mouse-systems emulator into the mouse EvStack :) Any thoughts? I wanna do EvStack _AND_ XFree86 at same time! G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 21 10:02:53 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA10639 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 10:02:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA08795; Wed, 21 Jan 1998 12:28:19 -0500 Resent-Date: Wed, 21 Jan 1998 12:28:19 -0500 Date: Wed, 21 Jan 1998 10:37:31 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: EvStack list <evstack@ontv.com> Subject: S3 ViRGE driver Message-ID: <Pine.LNX.3.96.980121102940.4485E-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"peecP.0.g82.O_Ynq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/457 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Just playing with porting S3-ViRGE to EvStacks kernel :) [why not - it's my primary display :] ... perhaps the "oopses" seen are related to VGA driver? Has anyone not using the VGA driver seen them? Okay - KGIM_PRIVATE(...) seems to be wrong... I replaced it with: #define KGIM_PRIVATE(dpy, subsystem) \ (((struct kgim_private *) dpy->driver_data)->subsystem) (include/ggi/module.h) Is this right? Or do I have to fix something in the driver? mode->[|d|l]clk, mode->flags are now in mode->tm.* (a grin to anyone who understands this :) [I assume a *grin* to everyone :] .. but still looking... Anything else? I know I'm missing something but can't remember what... G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 21 11:06:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34] (may be forged)) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA10684 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 11:05:58 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA09440; Wed, 21 Jan 1998 13:30:02 -0500 Resent-Date: Wed, 21 Jan 1998 13:30:02 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: S3 ViRGE driver Date: 21 Jan 1998 18:27:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 21 Distribution: local Message-ID: <6a5enb$ivc$1@grits.visus.com> References: <6a5bkh$h3p$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"e48P4.0.dI2.UuZnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/458 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > Okay - KGIM_PRIVATE(...) seems to be wrong... > I replaced it with: > #define KGIM_PRIVATE(dpy, subsystem) \ > (((struct kgim_private *) dpy->driver_data)->subsystem) Should be: (((struct kgim_private *) dpy->mode.mode_data)->subsystem) > mode->[|d|l]clk, mode->flags are now in mode->tm.* > (a grin to anyone who understands this :) > [I assume a *grin* to everyone :] Just moved all the `timing' into into a struct... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 21 12:09:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA10774 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 12:09:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA10090; Wed, 21 Jan 1998 14:34:20 -0500 Resent-Date: Wed, 21 Jan 1998 14:34:20 -0500 Date: Wed, 21 Jan 1998 12:41:44 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: *sigh* - demos anyone? Message-ID: <Pine.LNX.3.96.980121123639.4485I-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"mIbaS.0.1T2.Wranq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/459 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Anyone have a short demo? Perhaps one that reads the keyboard and prints something? I can't get the userspace code in the utils/.. area to work... and don't know enough about EvStacks to really get started. (I understand the concepts... but not the reality yet). Any reccomendations on what kernel source to start with? G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 21 12:21:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA10779 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 12:21:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA10228; Wed, 21 Jan 1998 14:46:11 -0500 Resent-Date: Wed, 21 Jan 1998 14:46:11 -0500 Date: Wed, 21 Jan 1998 12:54:36 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: S3 ViRGE driver In-Reply-To: <6a5enb$ivc$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980121125002.7340A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"xbrow2.0.9V2.o_anq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/460 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 21 Jan 1998, Jason McMullan wrote: > teunis (teunis@mauve.computersupportcentre.com) wrote: > > Okay - KGIM_PRIVATE(...) seems to be wrong... > > I replaced it with: > > #define KGIM_PRIVATE(dpy, subsystem) \ > > (((struct kgim_private *) dpy->driver_data)->subsystem) > > Should be: > (((struct kgim_private *) dpy->mode.mode_data)->subsystem) Can someone fix this in the CVS then? > > mode->[|d|l]clk, mode->flags are now in mode->tm.* > > (a grin to anyone who understands this :) > > [I assume a *grin* to everyone :] > > Just moved all the `timing' into into a struct... Are there any other things I should be watching for? G'day, eh? :) - Teunis [attached a simple patch just on the principle of the thing :] *** include/ggi/module.h~ Wed Jan 21 12:51:34 1998 --- include/ggi/module.h Wed Jan 21 12:51:23 1998 *************** *** 99,105 **** }; #define KGIM_PRIVATE(dpy, subsystem) \ ! (((struct kgim_private *) dpy->mode_data)->subsystem) struct kgim_options_pci { --- 99,105 ---- }; #define KGIM_PRIVATE(dpy, subsystem) \ ! (((struct kgim_private *) dpy->mode.mode_data)->subsystem) struct kgim_options_pci { From evstack-request@ontv.com Wed Jan 21 14:02:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA10952 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 14:01:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA11313; Wed, 21 Jan 1998 16:27:01 -0500 Resent-Date: Wed, 21 Jan 1998 16:27:01 -0500 To: EvStack list <evstack@ontv.com> Subject: Patches for Trio.... Date: Wed, 21 Jan 1998 22:02:41 +0100 Reply-To: Daniel.Egger@t-online.de X-Mailer: KMail [version 0.5.1] MIME-Version: 1.0 Message-Id: <98012122035501.03734@z2.n2480.f898.fidonet.org> Content-Type: Multipart/Mixed; boundary="Boundary-=_JkFOBteVfYVBTiRtXQCQARYovhHH" X-Sender: 0844189307-0001@t-online.de From: Daniel.Egger@t-online.de (Daniel Egger) Resent-Message-ID: <"XR7182.0.Am2.sUcnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/461 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com --Boundary-=_JkFOBteVfYVBTiRtXQCQARYovhHH Content-Type: text/plain Content-Transfer-Encoding: 7bit Hiho! I hope these are right.... <to be contiuned> Servus, Daniel --Boundary-=_JkFOBteVfYVBTiRtXQCQARYovhHH Content-Type: text/x-c; name="triopatch" Content-Transfer-Encoding: base64 KioqIGRyaXZlci9yYW1kYWMvUzMvdHJpbzY0LmMJU3VuIEphbiAxMSAwNTowNTowMyAxOTk4Ci0t LSAuLi90cmlvNjQuYwlXZWQgSmFuIDIxIDIxOjUxOjMyIDE5OTgKKioqKioqKioqKioqKioqCioq KiAxMjQsMTMwICoqKioKICAJCQkgICAgZW51bSBrZ2lfdG1fY21kIGNtZCkKICB7CiAgCWludCBk aXY7CiEgCWludCBuZXdjbG9jayA9IG1vZGUtPmRjbGs7CiAgCXN0cnVjdCBrZ2lfcmFtZGFjICpk YWMgPSBkcHktPmNhcmQtPnJhbWRhYzsKICAJCiAgCXN3aXRjaChtb2RlLT5yZXF1ZXN0LmdyYXBo dHlwZSkgCi0tLSAxMjQsMTMwIC0tLS0KICAJCQkgICAgZW51bSBrZ2lfdG1fY21kIGNtZCkKICB7 CiAgCWludCBkaXY7CiEgCWludCBuZXdjbG9jayA9IG1vZGUtPnRtLmRjbGs7CiAgCXN0cnVjdCBr Z2lfcmFtZGFjICpkYWMgPSBkcHktPmNhcmQtPnJhbWRhYzsKICAJCiAgCXN3aXRjaChtb2RlLT5y ZXF1ZXN0LmdyYXBodHlwZSkgCioqKioqKioqKioqKioqKgoqKiogMTY3LDE4NSAqKioqCiAgCXsK ICAJCQogIAljYXNlIENNRF9QUk9QT1NFOgohIAkJbW9kZS0+bGNsay5tdWwgPSAxOwohIAkJbW9k ZS0+Y2xrLm11bCA9IDE7IAohIAkJbW9kZS0+Y2xrLmRpdiA9IDE7CiEgCQltb2RlLT5sY2xrLmRp diA9IGRpdjsKISAJCURFQlVHMSgiJWk6JWkgbXVsdGlwbGV4IG1vZGUiLCBtb2RlLT5sY2xrLmRp diwgbW9kZS0+bGNsay5tdWwpOwohIAkJbW9kZS0+ZmxhZ3MgJj0gfkZMX0RBQ18yWENMT0NLOwoh IAkJbW9kZS0+ZmxhZ3MgfD0gRkxfREFDXzhCSVQ7CiAgCQlpZiAoKG1vZGUtPnJlcXVlc3QuZ3Jh cGh0eXBlID09IEdUXzMyQklUKSB8fCAKICAJCSAgICAobW9kZS0+cmVxdWVzdC5ncmFwaHR5cGUg PT0gR1RfMTVCSVQpIHx8CiAgCQkgICAgKG1vZGUtPnJlcXVlc3QuZ3JhcGh0eXBlID09IEdUXzE2 QklUKSkgCiAgCQl7CiAgCQkJCiEgCQkJbW9kZS0+ZmxhZ3MgfD0gRkxfREFDX0dBTU1BOwogIAkJ CQogIAkJfQogIAkJCi0tLSAxNjcsMTg1IC0tLS0KICAJewogIAkJCiAgCWNhc2UgQ01EX1BST1BP U0U6CiEgCQltb2RlLT50bS5sY2xrLm11bCA9IDE7CiEgCQltb2RlLT50bS5jbGsubXVsID0gMTsg CiEgCQltb2RlLT50bS5jbGsuZGl2ID0gMTsKISAJCW1vZGUtPnRtLmxjbGsuZGl2ID0gZGl2Owoh IAkJREVCVUcxKCIlaTolaSBtdWx0aXBsZXggbW9kZSIsIG1vZGUtPnRtLmxjbGsuZGl2LCBtb2Rl LT50bS5sY2xrLm11bCk7CiEgCQltb2RlLT50bS5mbGFncyAmPSB+RkxfREFDXzJYQ0xPQ0s7CiEg CQltb2RlLT50bS5mbGFncyB8PSBGTF9EQUNfOEJJVDsKICAJCWlmICgobW9kZS0+cmVxdWVzdC5n cmFwaHR5cGUgPT0gR1RfMzJCSVQpIHx8IAogIAkJICAgIChtb2RlLT5yZXF1ZXN0LmdyYXBodHlw ZSA9PSBHVF8xNUJJVCkgfHwKICAJCSAgICAobW9kZS0+cmVxdWVzdC5ncmFwaHR5cGUgPT0gR1Rf MTZCSVQpKSAKICAJCXsKICAJCQkKISAJCQltb2RlLT50bS5mbGFncyB8PSBGTF9EQUNfR0FNTUE7 CiAgCQkJCiAgCQl9CiAgCQkKKioqKioqKioqKioqKioqCioqKiAyMTAsMjE2ICoqKioKICAJCX0K ICAJCQogIAkJREVCVUcxKCJEQ0xLID0gJWkiLCBuZXdjbG9jayk7CiEgCQltb2RlLT5kY2xrID0g bmV3Y2xvY2s7CiAgCQlyZXR1cm4gRU9LOwogIAkJCiAgCWNhc2UgQ01EX1JBSVNFOgotLS0gMjEw LDIxNiAtLS0tCiAgCQl9CiAgCQkKICAJCURFQlVHMSgiRENMSyA9ICVpIiwgbmV3Y2xvY2spOwoh IAkJbW9kZS0+dG0uZGNsayA9IG5ld2Nsb2NrOwogIAkJcmV0dXJuIEVPSzsKICAJCQogIAljYXNl IENNRF9SQUlTRToKKioqKioqKioqKioqKioqCioqKiAyMzYsMjYyICoqKioKICAJCQluZXdjbG9j ayA9IGRhYy0+bm9ybWFsLm1pbjsKICAJCX0KICAJCQohIAkJbW9kZS0+ZGNsayA9IG5ld2Nsb2Nr OwogIAkJcmV0dXJuIEVPSzsKICAJCQogIAljYXNlIENNRF9DSEVDSzoKICAJCQohIAkJaWYgKCht b2RlLT5sY2xrLm11bCAhPSAxKSB8fCAobW9kZS0+bGNsay5kaXYgIT0gZGl2KSB8fAohIAkJICAg IChtb2RlLT5jbGsubXVsICE9IDEpIHx8IChtb2RlLT5jbGsuZGl2ICE9IDEpKSAKICAJCXsKICAJ CQkKICAJCQlyZXR1cm4gLUUoUkFNREFDLCBVTktOT1dOKTsKICAJCX0KICAJCQohIAkJaWYgKCht b2RlLT5kY2xrIDwgZGFjLT5ub3JtYWwubWluKSB8fAohIAkJICAgIChtb2RlLT5kY2xrIDwgZGFj LT5jbG9ja1ttb2RlLT5yZXF1ZXN0LmdyYXBodHlwZV0ubWluKSkKICAJCXsKICAJCQkKICAJCQly ZXR1cm4gLUUoUkFNREFDLCBVTktOT1dOKTsKICAJCX0KICAJCQohIAkJaWYgKChtb2RlLT5kY2xr ID4gZGFjLT5ub3JtYWwubWF4KSB8fAohIAkJICAgIChtb2RlLT5kY2xrID4gZGFjLT5jbG9ja1tt b2RlLT5yZXF1ZXN0LmdyYXBodHlwZV0ubWF4KSkKICAJCXsKICAJCQkKICAJCQlyZXR1cm4gLUUo UkFNREFDLCBVTktOT1dOKTsKLS0tIDIzNiwyNjIgLS0tLQogIAkJCW5ld2Nsb2NrID0gZGFjLT5u b3JtYWwubWluOwogIAkJfQogIAkJCiEgCQltb2RlLT50bS5kY2xrID0gbmV3Y2xvY2s7CiAgCQly ZXR1cm4gRU9LOwogIAkJCiAgCWNhc2UgQ01EX0NIRUNLOgogIAkJCiEgCQlpZiAoKG1vZGUtPnRt LmxjbGsubXVsICE9IDEpIHx8IChtb2RlLT50bS5sY2xrLmRpdiAhPSBkaXYpIHx8CiEgCQkgICAg KG1vZGUtPnRtLmNsay5tdWwgIT0gMSkgfHwgKG1vZGUtPnRtLmNsay5kaXYgIT0gMSkpIAogIAkJ ewogIAkJCQogIAkJCXJldHVybiAtRShSQU1EQUMsIFVOS05PV04pOwogIAkJfQogIAkJCiEgCQlp ZiAoKG1vZGUtPnRtLmRjbGsgPCBkYWMtPm5vcm1hbC5taW4pIHx8CiEgCQkgICAgKG1vZGUtPnRt LmRjbGsgPCBkYWMtPmNsb2NrW21vZGUtPnJlcXVlc3QuZ3JhcGh0eXBlXS5taW4pKQogIAkJewog IAkJCQogIAkJCXJldHVybiAtRShSQU1EQUMsIFVOS05PV04pOwogIAkJfQogIAkJCiEgCQlpZiAo KG1vZGUtPnRtLmRjbGsgPiBkYWMtPm5vcm1hbC5tYXgpIHx8CiEgCQkgICAgKG1vZGUtPnRtLmRj bGsgPiBkYWMtPmNsb2NrW21vZGUtPnJlcXVlc3QuZ3JhcGh0eXBlXS5tYXgpKQogIAkJewogIAkJ CQogIAkJCXJldHVybiAtRShSQU1EQUMsIFVOS05PV04pOwoqKioqKioqKioqKioqKioKKioqIDMx MSwzMjkgKioqKgogIAl9CiAgfQogIAohIGludCBrZ2ltX3JhbWRhY19jb21tYW5kKHN0cnVjdCBr Z2lfZ3JhcGhpYyAqZ3JhcGgsIGdnaV91aW50IGNtZCwgZ2dpX3VpbnQgYXJnKSAKICB7CiAgCS8q IFRoaXMgbWF5IHNldDoKICAJICogLSBIYXJkd2FyZSBjdXJzb3IKICAJICogLSBDTFVUIChvciBn YW1tYSBjb3JyZWN0aW9uIHRhYmxlKQogIAkgKi8KICAJCiAgCWdnaV9jbHV0IGNsdXQ7CiAgCiAg CXN3aXRjaCAoY21kKSAKICAJeyAKICAJCQohIAljYXNlIFJBTURBQ19HRVRJTkZPOgogIAkJZ3Jh cGgtPmlvX3JlcyA9ICZyYW1kYWM7CiAgCQlyZXR1cm4gRU9LOwogIAkJCi0tLSAzMTEsMzMxIC0t LS0KICAJfQogIH0KICAKISBpbnQga2dpbV9yYW1kYWNfY29tbWFuZChzdHJ1Y3Qga2dpX2Rpc3Bs YXkgKmRweSwgZ2dpX3VpbnQgY21kLCBsb25nIGFyZykgCiAgewogIAkvKiBUaGlzIG1heSBzZXQ6 CiAgCSAqIC0gSGFyZHdhcmUgY3Vyc29yCiAgCSAqIC0gQ0xVVCAob3IgZ2FtbWEgY29ycmVjdGlv biB0YWJsZSkKICAJICovCiAgCQorIAlpbnQgZXJyOwogIAlnZ2lfY2x1dCBjbHV0OworIAlnZ2lf Y29sb3IgZGF0YVsyNTZdOwogIAogIAlzd2l0Y2ggKGNtZCkgCiAgCXsgCiAgCQkKISAvKgljYXNl IFJBTURBQ19HRVRJTkZPOgogIAkJZ3JhcGgtPmlvX3JlcyA9ICZyYW1kYWM7CiAgCQlyZXR1cm4g RU9LOwogIAkJCioqKioqKioqKioqKioqKgoqKiogMzM5LDM1NyAqKioqCiAgCQkJCiAgCQkJcmV0 dXJuIC1FUEVSTTsKICAJCX0KISAJCQogIAljYXNlIFJBTURBQ19TRVRDTFVUOgogIAkJY2x1dC5z aXplID0gMjU2OwohIAkJY2x1dC5kYXRhID0gKGdnaV9jb2xvciAqKShncmFwaC0+aW9fYnVmKTsK ISAJCWRhY19zZXRfY2x1dChncmFwaC0+ZGV2LmRweSwgJmNsdXQsIDAsIDI1Nik7CiAgCQlyZXR1 cm4gRU9LOwogIAkJCiAgCWNhc2UgUkFNREFDX0dFVENMVVQ6CiAgCQljbHV0LnNpemUgPSAyNTY7 CiEgCQljbHV0LmRhdGEgPSAoZ2dpX2NvbG9yICopKGdyYXBoLT5pb19idWYpOwohIAkJZ3JhcGgt PmlvX3JlcyA9IGdyYXBoLT5pb19idWY7CiEgCQlkYWNfZ2V0X2NsdXQoZ3JhcGgtPmRldi5kcHks ICZjbHV0LCAwLCAyNTYpOwohIAkJcmV0dXJuIEVPSzsKICAJfQogIAlyZXR1cm4gLUUoUkFNREFD LE5PU1VQX0FMV0FZU19DQU5UKTsgIC8qIFRoZSBkcml2ZXIgY2FuJ3QgZG8gdGhpcyAqLwogIH0K LS0tIDM0MSwzNjggLS0tLQogIAkJCQogIAkJCXJldHVybiAtRVBFUk07CiAgCQl9CiEgKi8JCQog IAljYXNlIFJBTURBQ19TRVRDTFVUOgorIAkJZXJyID0gdXNlcl9jb3B5X2Zyb20oZGF0YSwoZ2dp X2NvbG9yICopYXJnLAorIAkJCQkJc2l6ZW9mKGdnaV9jb2xvcikqMjU2KTsKKyAJCWlmIChlcnIp CisgCQkJcmV0dXJuIGVycjsJCQkKICAJCWNsdXQuc2l6ZSA9IDI1NjsKISAJCWNsdXQuZGF0YSA9 IGRhdGE7CiEgCQlkYWNfc2V0X2NsdXQoZHB5LCAmY2x1dCwgMCwgMjU2KTsKICAJCXJldHVybiBF T0s7CiAgCQkKICAJY2FzZSBSQU1EQUNfR0VUQ0xVVDoKKyAJCWVyciA9IHVzZXJfdmVyaWZ5KFVT RVJfV1JJVEUsKGdnaV9jb2xvciAqKWFyZywKKyAJCQkJc2l6ZW9mKGdnaV9jb2xvcikqMjU2KTsK KyAJCWlmIChlcnIpCisgCQkJcmV0dXJuIGVycjsJCQkKICAJCWNsdXQuc2l6ZSA9IDI1NjsKISAJ CWNsdXQuZGF0YSA9IGRhdGE7CiEgCQlkYWNfZ2V0X2NsdXQoZHB5LCAmY2x1dCwgMCwgMjU2KTsK ISAJCWVyciA9IHVzZXJfY29weV90bygoZ2dpX2NvbG9yICopYXJnLGRhdGEsCiEgCQkJCXNpemVv ZihnZ2lfY29sb3IpKjI1Nik7CiEgCQlyZXR1cm4gZXJyOwogIAl9CiAgCXJldHVybiAtRShSQU1E QUMsTk9TVVBfQUxXQVlTX0NBTlQpOyAgLyogVGhlIGRyaXZlciBjYW4ndCBkbyB0aGlzICovCiAg fQoAAA== --Boundary-=_JkFOBteVfYVBTiRtXQCQARYovhHH Content-Type: text/x-c; name="modulepatch" Content-Transfer-Encoding: base64 KioqIGluY2x1ZGUvZ2dpL21vZHVsZS5oCVN1biBKYW4gMTEgMDU6MDU6MDMgMTk5OAotLS0gLi4v bW9kdWxlLmgJV2VkIEphbiAyMSAyMTo1MjowMiAxOTk4CioqKioqKioqKioqKioqKgoqKiogOTks MTA1ICoqKioKICB9OwogIAogICNkZWZpbmUJS0dJTV9QUklWQVRFKGRweSwgc3Vic3lzdGVtKSBc CiEgCSgoKHN0cnVjdCBrZ2ltX3ByaXZhdGUgKikgZHB5LT5tb2RlX2RhdGEpLT5zdWJzeXN0ZW0p CiAgCiAgc3RydWN0IGtnaW1fb3B0aW9uc19wY2kgCiAgewotLS0gOTksMTA1IC0tLS0KICB9Owog IAogICNkZWZpbmUJS0dJTV9QUklWQVRFKGRweSwgc3Vic3lzdGVtKSBcCiEgCSgoKHN0cnVjdCBr Z2ltX3ByaXZhdGUgKikgZHB5LT5tb2RlLm1vZGVfZGF0YSktPnN1YnN5c3RlbSkKICAKICBzdHJ1 Y3Qga2dpbV9vcHRpb25zX3BjaSAKICB7CgAA --Boundary-=_JkFOBteVfYVBTiRtXQCQARYovhHH-- From evstack-request@ontv.com Wed Jan 21 15:23:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA11056 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 15:23:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA12096; Wed, 21 Jan 1998 17:48:22 -0500 Resent-Date: Wed, 21 Jan 1998 17:48:22 -0500 To: EvStack list <evstack@ontv.com> Subject: Patch for pll.h Date: Wed, 21 Jan 1998 23:43:00 +0100 Reply-To: Daniel.Egger@t-online.de X-Mailer: KMail [version 0.5.1] MIME-Version: 1.0 Message-Id: <98012123445704.03734@z2.n2480.f898.fidonet.org> X-Sender: 0844189307-0001@t-online.de From: Daniel.Egger@t-online.de (Daniel Egger) Resent-Message-ID: <"H8zxr.0.Qy2.Vhdnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/462 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hiho! Here's another patch which should make at least one of the clockchips compileable again... Are there outstandng patches for TrioV64 support? -- Servus, Daniel From evstack-request@ontv.com Wed Jan 21 19:12:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11307 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 19:12:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA13910; Wed, 21 Jan 1998 21:34:24 -0500 Resent-Date: Wed, 21 Jan 1998 21:34:24 -0500 Message-Id: <m0xvCMN-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: mouse and X? To: evstack@ontv.com Date: Thu, 22 Jan 1998 13:27:15 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980121094508.4485C-100000@sigil.computersupportcentre.com> from "teunis" at Jan 21, 98 10:29:38 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YQb7G2.0.gO3.V_gnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/463 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > Okay - time to start looking at a mouse-emulator for EvStacks :) > > I'm too used to GPM. (I reprogrammed my system to use gpm for _ALL_ > mouse-action... Got tired of having the mouse reprogrammed every time I > switched consoles...) ..... > hmmm *thinking*... I'll see what I can do today about that - perhaps a > mouse-systems emulator into the mouse EvStack :) I recommend having a userspace program that receives the mouse events through /dev/event, grabs the evPtrRelative events, converts them to mouse-systems protocol, and stuffs them onto a *FIFO*. You'll need to wait until we have the devevent code fully sorted out though... [The other way is a kernel device driver that emulates a mouse-systems mouse (e.g. mknod /dev/mouse -c XXX YYY).] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 21 19:24:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11314 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 19:24:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA14062; Wed, 21 Jan 1998 21:49:25 -0500 Resent-Date: Wed, 21 Jan 1998 21:49:25 -0500 Message-Id: <m0xvCbR-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: *sigh* - demos anyone? To: evstack@ontv.com Date: Thu, 22 Jan 1998 13:42:49 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980121123639.4485I-100000@sigil.computersupportcentre.com> from "teunis" at Jan 21, 98 12:41:44 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"B1Cve1.0.7R3.nDhnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/464 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > I can't get the userspace code in the utils/.. area to work... and don't > know enough about EvStacks to really get started. Does util/stacktree work ? Does util/setmouse work ? [this is in the main CVS tree, the EvUtil stuff is obsolete] > Any reccomendations on what kernel source to start with? Let's see: /usr/include/ggi/evstack.h -- the core structures /usr/src/linux/drivers/console/dumbterm.c -- an example terminal $GGIHOME/driver/input/mouse/mouseaccel.c -- an example parser Hope that helps. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 21 19:45:21 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11341 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 19:45:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA14391; Wed, 21 Jan 1998 22:07:17 -0500 Resent-Date: Wed, 21 Jan 1998 22:07:17 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvBEv-0000XWC@charon.beck-sw.de> Subject: Hmm RAW key stuff semiworking here ... To: evstack@ontv.com (Evstack Mailing List) Date: Thu, 22 Jan 1998 02:15:29 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"H_0Lq.0.MW3.mUhnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/465 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi ! I just try Andrew's patch and - it does something, but I am not sure, if all is well ... After inserting the conlinux module, I started the X server and I still could not type. Doe sthe code make any assumptions on which VT the X server should come up or something like it ? OTOH I issued kbd_mode -u and it resulted in an unsuable concole just like it should ... However I did not see any weird chars appearing what usually happens when you do that. VT switching still works (how about SAK BTW ?) Hmm ... just to report it ... CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Wed Jan 21 22:02:28 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA11451 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 22:02:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA15352; Thu, 22 Jan 1998 00:24:45 -0500 Resent-Date: Thu, 22 Jan 1998 00:24:45 -0500 Date: Wed, 21 Jan 1998 22:34:04 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: *sigh* - demos anyone? In-Reply-To: <m0xvCbR-00017OC@ajax> Message-ID: <Pine.LNX.3.96.980121222358.2915B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"L9rE73.0.Ql3.YVjnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/466 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 22 Jan 1998, Andrew Apted wrote: > teunis writes: > > > I can't get the userspace code in the utils/.. area to work... and don't > > know enough about EvStacks to really get started. > > Does util/stacktree work ? yes.... is it enough? > Does util/setmouse work ? yes but I haven't the foggiest how this one works... util/EvTest does not work for me though.... I'll check that again later. > [this is in the main CVS tree, the EvUtil stuff is obsolete] No prob :) > > Any reccomendations on what kernel source to start with? > > Let's see: > /usr/include/ggi/evstack.h -- the core structures > /usr/src/linux/drivers/console/dumbterm.c -- an example terminal > $GGIHOME/driver/input/mouse/mouseaccel.c -- an example parser Yes actually - quite a bit :) There are so many sources and I don't know where to start... This is a great help (so far :) G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 21 22:06:49 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA11455 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 22:06:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA15424; Thu, 22 Jan 1998 00:28:35 -0500 Resent-Date: Thu, 22 Jan 1998 00:28:35 -0500 Date: Wed, 21 Jan 1998 22:38:42 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: evstack@ontv.com Subject: Re: mouse and X? In-Reply-To: <m0xvCMN-00017OC@ajax> Message-ID: <Pine.LNX.3.96.980121222207.2915A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Ajk3N3.0.Tm3.TZjnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/467 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 22 Jan 1998, Andrew Apted wrote: > teunis writes: > > > Okay - time to start looking at a mouse-emulator for EvStacks :) > > > > I'm too used to GPM. (I reprogrammed my system to use gpm for _ALL_ > > mouse-action... Got tired of having the mouse reprogrammed every time I > > switched consoles...) > ..... > > hmmm *thinking*... I'll see what I can do today about that - perhaps a > > mouse-systems emulator into the mouse EvStack :) > > I recommend having a userspace program that receives the mouse events > through /dev/event, grabs the evPtrRelative events, converts them to > mouse-systems protocol, and stuffs them onto a *FIFO*. I don't know how to read /dev/event from userspace.... hmmm... Is there any kind of basic description? Preferably text or postscript or html? :) > You'll need to wait until we have the devevent code fully sorted out > though... Oh? Ah - the request/reply type protocols et al... ... luckily a mouse tends to be one-directional :) > [The other way is a kernel device driver that emulates a mouse-systems > mouse (e.g. mknod /dev/mouse -c XXX YYY).] That is how I am planning on doing it... I think I've figured enough of the kernel to pull it off... Except what major/minor/route to use... G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 21 22:59:53 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA11594 for <ggi@synergy.foo.net>; Wed, 21 Jan 1998 22:59:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA16632; Thu, 22 Jan 1998 01:21:50 -0500 Resent-Date: Thu, 22 Jan 1998 01:21:50 -0500 Message-Id: <m0xvFvd-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Hmm RAW key stuff semiworking here ... To: evstack@ontv.com Date: Thu, 22 Jan 1998 17:15:53 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xvBEv-0000XWC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 22, 98 02:15:29 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nKdc63.0.K34.SLknq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/468 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > After inserting the conlinux module, I started the X server and I still > could not type. Doe sthe code make any assumptions on which VT the X server > should come up or something like it ? Hmmmm. No, no assumption. I was going to suggest running stacktree in X -- might be a bit hard though ;-). And you won't see the conlinux stack if you switch to a normal VC because X disables RAW mode on the switch away... If you can get the 'stacktree -l' output while X is running, as in : sleep 15; stacktree -l > blah / on one VC xinit / on another VC you should see a 'conlinux' stack on the termstack that X is using. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ PS: does 'semiworking' mean 'doesn't blow the computer up' ? :-) From evstack-request@ontv.com Thu Jan 22 01:13:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA11810 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 01:13:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA17507; Thu, 22 Jan 1998 03:39:06 -0500 Resent-Date: Thu, 22 Jan 1998 03:39:06 -0500 Date: Thu, 22 Jan 1998 01:49:09 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: S3 ViRGE progress... Message-ID: <Pine.LNX.3.96.980122013941.5091A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1QmwI2.0.1H4.rLmnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/469 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com *grin* Well - I've got the Trio64 ramdac driver compiling. (incidentally - anyone know what drivers the ViRGE uses other than chipset/virge?) chipset/S3/virge is just about finished : text_operations is wildly different and as the S3/MMIO cards have a different memory layout the new functions (render, copybox) are fun :) [still working on this] : also the new memory-management has not yet been merged. clock/prog/s3idac compiles :) graphic/S3/generic needs lotsa work Yep - I'm using this mailing list as a notepad :) [figure someone can use the running commentary] I'll toss up the .diffs (or even just the whole source :) once this beasty's operational (or tomorrow if anyone asks :) G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 22 02:47:50 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA11906 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 02:47:49 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA18130; Thu, 22 Jan 1998 05:13:21 -0500 Resent-Date: Thu, 22 Jan 1998 05:13:21 -0500 X-Authentication-Warning: tindra.lysator.liu.se: mars owned process doing -bs Date: Thu, 22 Jan 1998 11:12:08 +0100 (MET) From: Stefan Mars <mars@lysator.liu.se> To: teunis <teunis@mauve.computersupportcentre.com> cc: EvStack list <evstack@ontv.com> Subject: Re: S3 ViRGE progress... In-Reply-To: <Pine.LNX.3.96.980122013941.5091A-100000@sigil.computersupportcentre.com> Message-ID: <Pine.GSO.3.96rindlow.980122110913.3477B-100000@tindra.lysator.liu.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cyAxe1.0.iQ4.-jnnq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/470 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 22 Jan 1998, teunis wrote: > *grin* > Well - I've got the Trio64 ramdac driver compiling. > (incidentally - anyone know what drivers the ViRGE uses other than > chipset/virge?) Yep, the Trio64 ramdac drivee :) If you haven't done it yet, then I will rehack that driver slightly so that it can do it's own detection of chip and chipversion. That's the only way to tell if you have a 135MHz or a 220MHz chip.. > chipset/S3/virge is just about finished : text_operations is wildly > different and as the S3/MMIO cards have a different memory layout the new > functions (render, copybox) are fun :) > [still working on this] > : also the new memory-management has not yet been merged. Due to my exams I am afraid I haven't followed this discussion as much as I should have been doing. Teunis, are you talking EvStack only, or are you also talking KGI? If so, then I would be happy to get those diffs to see what you are doing to the driver? > clock/prog/s3idac compiles :) > > graphic/S3/generic needs lotsa work > > Yep - I'm using this mailing list as a notepad :) > [figure someone can use the running commentary] > > I'll toss up the .diffs (or even just the whole source :) once this > beasty's operational (or tomorrow if anyone asks :) > > G'day, eh? :) > - Teunis > > -Stefan /-----------------------------------------------------------------------------\ | Stefan Mars |Student, Applied physics & Electrical engineering | | Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology | | S-584 36 Linkoping | | | Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 | |-----------------------------------------------------------------------------| | Maintainer of The THX Home Cinema Buyers Guide, located at | | http://www.lysator.liu.se/%7Emars/thxguide.html | \--------------------- PGP key available through finger ----------------------/ From evstack-request@ontv.com Thu Jan 22 06:59:23 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA00500 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 06:59:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA19796; Thu, 22 Jan 1998 09:24:01 -0500 Resent-Date: Thu, 22 Jan 1998 09:24:01 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvOPI-0000XWC@charon.beck-sw.de> Subject: Re: Hmm RAW key stuff semiworking here ... To: evstack@ontv.com Date: Thu, 22 Jan 1998 16:19:04 +0100 (MET) In-Reply-To: <m0xvFvd-00017OC@ajax> from "Andrew Apted" at Jan 22, 98 05:15:53 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Evnru1.0.Pq4.xMrnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/471 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > After inserting the conlinux module, I started the X server and I still > > could not type. Doe sthe code make any assumptions on which VT the X server > > should come up or something like it ? > sleep 15; stacktree -l > blah / on one VC > xinit / on another VC Will try that ... > PS: does 'semiworking' mean 'doesn't blow the computer up' ? :-) ROTFL ! CU, Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Thu Jan 22 07:34:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA00568 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 07:34:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA20123; Thu, 22 Jan 1998 09:59:54 -0500 Resent-Date: Thu, 22 Jan 1998 09:59:54 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: S3 ViRGE progress... Date: 22 Jan 1998 14:58:23 GMT Organization: OnTV Pittsburgh, L.P. Lines: 16 Distribution: local Message-ID: <6a7mqf$c0j$1@grits.visus.com> References: <6a70uo$rap$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"BbKQt1.0.av4.wvrnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/472 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > chipset/S3/virge is just about finished : text_operations is wildly > different and as the S3/MMIO cards have a different memory layout the new > functions (render, copybox) are fun :) > [still working on this] > : also the new memory-management has not yet been merged. Remeber, the whole textop structure is OPTIONAL in GT_TEXT16... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 22 07:51:24 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA00581 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 07:51:23 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA20433; Thu, 22 Jan 1998 10:16:14 -0500 Resent-Date: Thu, 22 Jan 1998 10:16:14 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: MMAP Problems... Date: 22 Jan 1998 15:14:15 GMT Organization: OnTV Pittsburgh, L.P. Lines: 58 Message-ID: <6a7no7$c0j$2@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"S4DH_1.0.R-4.o8snq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/473 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com The is a design issue at hand... THE PROBLEM ----------- Assume application A opens /dev/graph and mmap()s some pages from the framebuffer. Then it gets switched away. Those mmaped pages are invalid during the switch away. Then it gets switched back. The question is: What happens to the old mmap()ings on switch-to? SOLUTIONS --------- I) Try to match the `dev-graph' copy of the MMIO regions with the kgi_mode's idea of MMIO regions. a) Error prone if the head has been changed b) Do we need `stamps' on the MMIO region lists? II) Ditch the old mappings, and let libGGI re-arbitrate the mode. a) Doesn't do `The Right Thing' - mmap()ed pages aren't suppost to fly out from under you.. b) programs that directly from /dev/graph become much more complicated. III) `Lock' the VT and prevent VT switching while mmap()ed regions are alloacted. Exception: SAK. The VTSwitch event is send to the app when a VT switch is requested. a) Similar to the semantics of drive partitioning - while a partition is open, you can't frob with the partition table. b) SAK works as expected. c) libGGI will handle mode arbitration on VT switch d) Less kernel code SYNOPSIS -------- I think permitting VT switching while MMIO regions are open is a lost cause. Since we have a TRUE Secure Attention Key (SAK), this is not a big loss. libGGI can handle most VT switching cases, ALT-Fx are released to app developers to handle, etc. Also, should there be a `force-VT-switch' which sends a SIGKILL to the mmap()ing process, and VT switches. ALT-ALT-Fx? YOUR THOUGHTS HERE: ------------------- -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 22 10:18:48 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA00803 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 10:18:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA21987; Thu, 22 Jan 1998 12:43:17 -0500 Resent-Date: Thu, 22 Jan 1998 12:43:17 -0500 Date: Thu, 22 Jan 1998 10:51:47 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: S3 ViRGE progress... In-Reply-To: <6a7mqf$c0j$1@grits.visus.com> Message-ID: <Pine.LNX.3.96.980122105055.6351D-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Pqd0n3.0.JM5.XIunq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/475 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On 22 Jan 1998, Jason McMullan wrote: > teunis (teunis@mauve.computersupportcentre.com) wrote: > > > chipset/S3/virge is just about finished : text_operations is wildly > > different and as the S3/MMIO cards have a different memory layout the new > > functions (render, copybox) are fun :) > > [still working on this] > > : also the new memory-management has not yet been merged. > > Remeber, the whole textop structure is OPTIONAL in GT_TEXT16... Unless you have a non-standard memory layout for text... A _GREAT_ example is the S3 chipsets' MMIO textmode - where it's 8 bytes per character and only the first two are safe to set. G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 22 10:19:58 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA00808 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 10:19:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA21951; Thu, 22 Jan 1998 12:41:38 -0500 Resent-Date: Thu, 22 Jan 1998 12:41:38 -0500 Date: Thu, 22 Jan 1998 10:50:31 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Stefan Mars <mars@lysator.liu.se> cc: EvStack list <evstack@ontv.com> Subject: Re: S3 ViRGE progress... In-Reply-To: <Pine.GSO.3.96rindlow.980122110913.3477B-100000@tindra.lysator.liu.se> Message-ID: <Pine.LNX.3.96.980122103940.6351C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"DIrmm3.0.WL5.QHunq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/474 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 22 Jan 1998, Stefan Mars wrote: > On Thu, 22 Jan 1998, teunis wrote: > > > *grin* > > Well - I've got the Trio64 ramdac driver compiling. > > (incidentally - anyone know what drivers the ViRGE uses other than > > chipset/virge?) > > Yep, the Trio64 ramdac drivee :) If you haven't done it yet, then I will > rehack that driver slightly so that it can do it's own detection of chip > and chipversion. That's the only way to tell if you have a 135MHz or a > 220MHz chip.. Oh? I can toss ya the source I've got so far (but I haven't tested it yet) ... Would you just probe for chip-version? Trio64V+ == 135 Mhz, yes? (I canna remember at the moment) ViRGE == 135..270 mhz range but Trio64 et al are different speeds yet again (but compatible clocks IIRC) > > chipset/S3/virge is just about finished : text_operations is wildly > > different and as the S3/MMIO cards have a different memory layout the new > > functions (render, copybox) are fun :) > > [still working on this] > > : also the new memory-management has not yet been merged. > > Due to my exams I am afraid I haven't followed this discussion as much as > I should have been doing. Teunis, are you talking EvStack only, or are you > also talking KGI? If so, then I would be happy to get those diffs to see > what you are doing to the driver? KGI + EvStack only.... *sigh* I can toss ya the diffs from the standard GGI drivers if you want though.. (but give me a bit - busy day...) G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 22 10:25:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA00814 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 10:25:20 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA22169; Thu, 22 Jan 1998 12:47:36 -0500 Resent-Date: Thu, 22 Jan 1998 12:47:36 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvRbt-0000XVC@charon.beck-sw.de> Subject: ConLinux and rawkeys ... To: evstack@ontv.com (Evstack Mailing List) Date: Thu, 22 Jan 1998 19:44:17 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"706vw2.0.hO5.YNunq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/477 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi ! Just tested what you suggested Andrew. Yes the conlinux stack gets attached and it seems to steal away the events, too, but it seems as if it doesn't send anything to the tty. I can manually detach the stack and kill processes on the console in question to revive it. But it looks like nothing gets sent to the tty. BTW: I just had that damned CMOS erased problem again ... we should track it. It is annoying. CU,ANdy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Thu Jan 22 10:25:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA00818 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 10:25:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA22170; Thu, 22 Jan 1998 12:47:37 -0500 Resent-Date: Thu, 22 Jan 1998 12:47:37 -0500 Date: Thu, 22 Jan 1998 10:57:15 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: jmcc@ontv.com cc: evstack@ontv.com Subject: Re: MMAP Problems... In-Reply-To: <6a7no7$c0j$2@grits.visus.com> Message-ID: <Pine.LNX.3.96.980122105455.6351E-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"GVjzE.0.BP5.iNunq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/478 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com If ya want the full text - ref the original.. I'm gonna clip :) On 22 Jan 1998, Jason McMullan wrote: > III) `Lock' the VT and prevent VT switching while mmap()ed > regions are alloacted. Exception: SAK. The VTSwitch > event is send to the app when a VT switch is requested. > a) Similar to the semantics of drive partitioning - > while a partition is open, you can't frob with > the partition table. > b) SAK works as expected. > c) libGGI will handle mode arbitration on VT switch > d) Less kernel code This looks to be the right one by me :) > SYNOPSIS > -------- > > I think permitting VT switching while MMIO regions are open > is a lost cause. Since we have a TRUE Secure Attention Key (SAK), > this is not a big loss. libGGI can handle most VT switching cases, > ALT-Fx are released to app developers to handle, etc. > > Also, should there be a `force-VT-switch' which sends a SIGKILL > to the mmap()ing process, and VT switches. ALT-ALT-Fx? Hm? ... it might be an idea... but make it an emergency key-combo just slightly less important than SAK (it isn't as final :) > YOUR THOUGHTS HERE: > ------------------- Agreed - and (III) seems to be what you're implying. G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 22 10:25:42 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA00822 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 10:25:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA22177; Thu, 22 Jan 1998 12:47:45 -0500 Resent-Date: Thu, 22 Jan 1998 12:47:45 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvQu5-0000XVC@charon.beck-sw.de> Subject: Re: MMAP Problems... To: evstack@ontv.com (Evstack Mailing List) Date: Thu, 22 Jan 1998 18:59:00 +0100 (MET) In-Reply-To: <6a7no7$c0j$2@grits.visus.com> from "Jason McMullan" at Jan 22, 98 03:14:15 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"8UsTv2.0.PO5.RNunq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/476 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > THE PROBLEM > ----------- > > Assume application A opens /dev/graph and mmap()s some > pages from the framebuffer. Then it gets switched away. > Those mmaped pages are invalid during the switch away. Then > it gets switched back. > > The question is: What happens to the old mmap()ings > on switch-to? This is handles by the nopage exception. At switchaway the pages get unmapped and any access gets the application a signal. On switch-to, the pages get mapped back at the next nopage exception. > I) Try to match the `dev-graph' copy of the MMIO regions > with the kgi_mode's idea of MMIO regions. > a) Error prone if the head has been changed > b) Do we need `stamps' on the MMIO region lists? If the head has been changed (i.e. the application moved to another card), it will usually have to re-negotiate the mode anyway. Thus I'd go for a twofold process: Normally try to make the switch transparent to the app as much as possible. But it things like a Head-switch come in between, tell the App it should renegotiate the mode or unpredictable results occur. "Good" apps would do so, simple ones ignore the request and eventually are not capable of being moved between heads. > II) Ditch the old mappings, and let libGGI re-arbitrate > the mode. > a) Doesn't do `The Right Thing' - mmap()ed > pages aren't suppost to fly out from under you.. > b) programs that directly from /dev/graph become > much more complicated. Yep. Thus hybrid scheme. > > III) `Lock' the VT and prevent VT switching while mmap()ed > regions are alloacted. Exception: SAK. No. Bad. Would throw away a lot of the extra "stability" we head for. O.K. Details : Switchaway : - send SIGTSTP or WINCH. Wait for reply from userspace (thus "locking" as you suggested). - If callback comes, unmap all ressources. Further acces gets SIGSEGV. - If callback doesn't come until the user gets impatient and hits the switchaway key again, unmap all ressources as above, send SIGSTOP. Switchto : - send SIGWINCH (and evetually SIGCONT ...) and remap all ressources. Or the best approximation. The app is expected to query the capabilities of the new visual and adapt to it. However it may skip this, what leads to unpredictable behaviour on cross-hardware switchtos (i.e. program being moved to another head). This results in applications being able to switch to/from different rendering algorithms at runtime cleanly (callback). If application doesn't hear you, STOP it freezing its state. At switchto time, the app again gets notified. It can either blindly assume it has been in some kind of frozen state (sigSTOPed or it had swapped it drawing funcs) and gets back to the same state as before later (which prevents cross-head movement, except where heads are compatible) or it can fully analyze the "got focus again" message and try to renegotiate its setup allowing for moveable apps. Should make everyone happy and is not too complicated I think ... -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Thu Jan 22 11:48:48 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA00922 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 11:48:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA23124; Thu, 22 Jan 1998 14:14:04 -0500 Resent-Date: Thu, 22 Jan 1998 14:14:04 -0500 To: EvStack list <evstack@ontv.com> Subject: Network problems? Date: Thu, 22 Jan 1998 20:07:10 +0100 Reply-To: Daniel.Egger@t-online.de X-Mailer: KMail [version 0.5.1] MIME-Version: 1.0 Message-Id: <98012220083502.07270@z2.n2480.f898.fidonet.org> X-Sender: 0844189307-0001@t-online.de From: Daniel.Egger@t-online.de (Daniel Egger) Resent-Message-ID: <"ct9ya.0.je5.Qevnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/479 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hiho! Didn't my patches reach you or is it just such an kind of shit that neither one replies nor the source got into CVS? -- Servus, Daniel From evstack-request@ontv.com Thu Jan 22 12:01:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA00935 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 12:01:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA23292; Thu, 22 Jan 1998 14:26:17 -0500 Resent-Date: Thu, 22 Jan 1998 14:26:17 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: MMAP Problems... Date: 22 Jan 1998 19:24:58 GMT Organization: OnTV Pittsburgh, L.P. Lines: 76 Distribution: local Message-ID: <6a86ea$nr0$1@grits.visus.com> References: <6a8160$ku2$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"xzZiz.0.Bh5.rpvnq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/480 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > The question is: What happens to the old mmap()ings > > on switch-to? > This is handles by the nopage exception. > At switchaway the pages get unmapped and any access gets the > application a signal. > On switch-to, the pages get mapped back at the next nopage exception. This I understood. The crux of the problem is `I loaded a different display driver - what happened to my mmap()s???' > If the head has been changed (i.e. the application moved to another card), > it will usually have to re-negotiate the mode anyway. > > Thus I'd go for a twofold process: > > Normally try to make the switch transparent to the app as much as possible. > > But it things like a Head-switch come in between, tell the App it should > renegotiate the mode or unpredictable results occur. > > "Good" apps would do so, simple ones ignore the request and eventually > are not capable of being moved between heads. This is where we diverge. I want as LITTLE code in the kernel as possible, and this isn't it. I'm even thinking of simplifying /dev/graph to one-per-head, only one open() per device. Would move as much of this mess as possible into user-land. [See below for more reasoning...] > > III) `Lock' the VT and prevent VT switching while mmap()ed > > regions are alloacted. Exception: SAK. > No. Bad. Would throw away a lot of the extra "stability" we head for. Not at all. VT switching is NOT essential to security/stability. SAK is. I used to be `the other way around', but trying to get mmap() working across VT switches is a PITA. It causes messy, exception-riddled, ill-understood code - the last thing we want in a kernel patch. > O.K. Details : > [snip snip] > Should make everyone happy and is not too complicated I think ... This isn't complicated - from a user-land perspective. Getting the kernel to believe in it is a different matter. [I _still_ shudder over the current mode-arbitration scheme...] Anyhow, my reasoning - and a compromise: I think `Plan III' - Ie, open/mmap on /dev/graph[headid] `locks' the display driver and VT - is the EASIEST to implement in kernel space and is EASILY the most `verifibly correct'. SAK will still `Do The Right Thing' - which is a massive improvement over the current kernel code. It's still even possible to have a `forced VT switch' that kills the /dev/graph process with SIGSEGV first [and then SIGKILL on the second try]. Also, Plan III requires no `SIGTSTP/SIGCONT' signal pair to `help' apps VT-switch. SIGWINCH isn't even required, unless of course you're running a text (ncurses) based app. The fewer signals we `eat' from applications, the better. Here is the compromise: My /dev/graph will do `Plan III', HOWEVER, I am _perfectly_ willing to replace it in the future with someone else's /dev/graph driver that fully supports Andrea's spec. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 22 16:33:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA01309 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 16:33:34 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA25591; Thu, 22 Jan 1998 18:58:22 -0500 Resent-Date: Thu, 22 Jan 1998 18:58:22 -0500 Message-Id: <199801222357.AAA28170@zafir.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: evstack@ontv.com Subject: Re: MMAP Problems... In-reply-to: Your message of "22 Jan 1998 19:24:58 GMT." <6a86ea$nr0$1@grits.visus.com> Mime-Version: 1.0 Content-Type: text/plain Date: Fri, 23 Jan 1998 00:57:13 +0100 From: Marcus Sundberg <e94_msu@elixir.e.kth.se> Resent-Message-ID: <"gxnnC2.0.AF6.Ppznq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/481 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Anyhow, my reasoning - and a compromise: > > I think `Plan III' - Ie, open/mmap on /dev/graph[headid] > `locks' the display driver and VT - is the EASIEST to implement > in kernel space and is EASILY the most `verifibly correct'. SAK > will still `Do The Right Thing' - which is a massive improvement > over the current kernel code. It's still even possible to have > a `forced VT switch' that kills the /dev/graph process with > SIGSEGV first [and then SIGKILL on the second try]. > > Also, Plan III requires no `SIGTSTP/SIGCONT' signal pair > to `help' apps VT-switch. SIGWINCH isn't even required, unless > of course you're running a text (ncurses) based app. The fewer > signals we `eat' from applications, the better. My first reaction about alternative III was "NOOOO WAAAY!" One of the reasons I want GGI is allways being able to do a VT switch, without worrying about any running apps, and without killing apps. What I think you're also forgetting is that GGI is supposed to be portable, apps should definitely not need to care about any Linux console specific things like VT switching. If you think Andy's way bloat the kernel too much, I was going to propose a subset of that: At VT swicth send the app a SIGWINCH, and any access to graphics before switchback will cause a SIGSEGV. Let the app itself be responsible for checking what actually happened at the SIGWINCH and doing the right thing without any actions needed from the kernel. This is what SIGWINCH is for, and apps need to handle it anyway because they might be running in a windowing system that supports changing resolution and/or display depth on the fly. > Here is the compromise: My /dev/graph will do `Plan III', > HOWEVER, I am _perfectly_ willing to replace it in the future > with someone else's /dev/graph driver that fully supports > Andrea's spec. This sounds fair enough. //Marcus From evstack-request@ontv.com Thu Jan 22 19:42:59 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA01583 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 19:42:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA27241; Thu, 22 Jan 1998 22:07:36 -0500 Resent-Date: Thu, 22 Jan 1998 22:07:36 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvZAV-0000XVC@charon.beck-sw.de> Subject: Re: MMAP Problems... To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 23 Jan 1998 03:48:31 +0100 (MET) In-Reply-To: <6a86ea$nr0$1@grits.visus.com> from "Jason McMullan" at Jan 22, 98 07:24:58 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"pl-Bt1.0.3f6.7b0oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/482 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > This is handled by the nopage exception. > > At switchaway the pages get unmapped and any access gets the > > application a signal. > > On switch-to, the pages get mapped back at the next nopage exception. > This I understood. The crux of the problem is `I loaded a > different display driver - what happened to my mmap()s???' I'd say just map the new equivalent mmap in (or inhibit driver unloading as long as it is "in-use", though I think this isn't a good idea). If this gets you a foobared display, because the app ignores the "please renegotiate mode" hint, the app is too stupid and thus deserves no better. > This is where we diverge. I want as LITTLE code in the kernel > as possible, and this isn't it. I'm even thinking of simplifying > /dev/graph to one-per-head, only one open() per device. Would > move as much of this mess as possible into user-land. You mean the app is requested to close down its graphics part on SIGWINCH so that the device is freed for another app ? Hmm - don't really like that. I assume it will make life difficult for wrappers etc, but ... > Not at all. VT switching is NOT essential to security/stability. > SAK is. I used to be `the other way around', but trying to get > mmap() working across VT switches is a PITA. Sorry what is PITA ? I know it as a greek speciality made up from a piece of flat round bread filled with some salad, tzatziki (a garlic containing souce) and some flesh ... > It causes messy, exception-riddled, ill-understood code - the > last thing we want in a kernel patch. Do you really think it would be that hard ? I'd say we have half the thing already in the conlinux driver. We go to VT_PROCESS mode and send a signal when VT switching is requested. We need to do that anyway for compatibility. Now we need one more variable in the VT info struct that says "switch requested". If it is unset, set it, proceed normal and wait for VT being released by ioctl (resetting said variable) the switch. If it is set, send SIGSTOP, effectively freezing the app. On siwtch to check the variable again. If it is set, the app has been frozen => send SIGCONT. Anyway send SIGWINCH (or whatever the app requested at setting VT_PROCESS). Thus I say on the kernel side we need +1 variable and +2 trivial if cases. > I think `Plan III' - Ie, open/mmap on /dev/graph[headid] > `locks' the display driver and VT - is the EASIEST to implement > in kernel space and is EASILY the most `verifibly correct'. Well yes, I basically say nothing else. Go to VT_PROCESS, but allow for a "forced switch" which just halts the application. Such applications are to be considered bad, and if they fault on switching back, well - that's life. Normally nothing bad will happen, only when you have done weird things like moving the VT to another head, you will encounter strange behaviour or a segfault or something with such apps. > Also, Plan III requires no `SIGTSTP/SIGCONT' signal pair > to `help' apps VT-switch. SIGWINCH isn't even required, unless > of course you're running a text (ncurses) based app. The fewer > signals we `eat' from applications, the better. If we use VT-PROCESS mode, we do nothing new. SIGSTOP/CONT are free, because they cannot be catched. (SIGCONT might be catchable, but ...) > Here is the compromise: My /dev/graph will do `Plan III', > HOWEVER, I am _perfectly_ willing to replace it in the future > with someone else's /dev/graph driver that fully supports > Andrea's spec. O.K. - I'll look into it, when I find some time. Get something done for now. No matter if I like it. First get it working, then get it nice. CU,ANdy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Thu Jan 22 21:29:52 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA01765 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 21:29:51 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA27931; Thu, 22 Jan 1998 23:52:01 -0500 Resent-Date: Thu, 22 Jan 1998 23:52:01 -0500 Message-Id: <m0xvazJ-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: MMAP Problems... To: evstack@ontv.com Date: Fri, 23 Jan 1998 15:45:05 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xvZAV-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 23, 98 03:48:31 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"izG7R3.0.wp6.672oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/483 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > The crux of the problem is `I loaded a > > different display driver - what happened to my mmap()s???' > > I'd say just map the new equivalent mmap in (or inhibit driver unloading > as long as it is "in-use", though I think this isn't a good idea). I say inhibit driver unloading. When some process has /dev/graphXX open, the module should be unloadable (i.e. marked as in-use by MOD_INC_USE_COUNT). This is simply because graphic consoles cannot be handled by a boot driver. Text consoles are different, regardless of whether they are on a text mode or a graphic mode, they CAN migrate to a boot driver, the only caveat is that they need to handle forcible resizing... > Sorry what is PITA ? Pain In The A***. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 22 21:52:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id VAA01813 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 21:52:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA28466; Fri, 23 Jan 1998 00:17:57 -0500 Resent-Date: Fri, 23 Jan 1998 00:17:57 -0500 Message-Id: <m0xvbOQ-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: ConLinux and rawkeys ... To: evstack@ontv.com Date: Fri, 23 Jan 1998 16:11:02 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xvRbt-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 22, 98 07:44:17 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Nk5zP2.0.9y6.OV2oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/484 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > Just tested what you suggested Andrew. Yes the conlinux stack gets attached > and it seems to steal away the events, too, but it seems as if it doesn't > send anything to the tty. > > I can manually detach the stack and kill processes on the console in question > to revive it. But it looks like nothing gets sent to the tty. Bleedin' hell... Do the keys 1 2 3 4 do anything when you start the X server _without_ insmodding conlinux ? [in particular: n m , .] If you like, send me an strace of X starting up (with conlinux installed), and I'll take a look... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 22 23:25:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA01890 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 23:25:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA29088; Fri, 23 Jan 1998 01:47:30 -0500 Resent-Date: Fri, 23 Jan 1998 01:47:30 -0500 Date: Thu, 22 Jan 1998 23:57:55 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: console speed Message-ID: <Pine.LNX.3.96.980122234713.9197A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"hwzLa2.0.-57.Yp3oq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/485 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Just out of curiousity - is the current console speed slow for any particular reason? I'm now editing this message in kon (userspace Japanese graphical console) because it's display speed is faster than EvStack/kernel :) hmm... maybe look at this a little later.. I'm still rewriting the textmode operations (and interoperations) for the ViRGE driver... .. I don't suppose anyone out there's got some data on the kgiscroll or console manager do they? ... if not I'll continue RTFM :) G'day, eh? :) - Teunis PS: I'm just about finished render(..) and copybox(...)... Are those two functions enough for rendering? .. I'm tempted to accelerate copybox *grin*... From evstack-request@ontv.com Thu Jan 22 23:34:42 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id XAA01905 for <ggi@synergy.foo.net>; Thu, 22 Jan 1998 23:34:41 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id BAA29182; Fri, 23 Jan 1998 01:57:03 -0500 Resent-Date: Fri, 23 Jan 1998 01:57:03 -0500 Message-ID: <00dc01bd27cb$faa98560$0c0a0a0a@massacre> From: "David Waite" <mass@ufl.edu> To: <evstack@ontv.com> Subject: Re: console speed Date: Fri, 23 Jan 1998 01:56:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-Message-ID: <"cswCf2.0.U77.cy3oq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/486 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com -----Original Message----- From: teunis <teunis@mauve.computersupportcentre.com> >... if not I'll continue RTFM :) Isn't it more like RTFC now? Or UTSL? (Read the Forgotten Code) (Use The Source Luke) I'll look more at WTFM tonight for a few minutes, then start on it this weekend. -David Waite From evstack-request@ontv.com Fri Jan 23 01:30:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA02119 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 01:30:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA29930; Fri, 23 Jan 1998 03:55:30 -0500 Resent-Date: Fri, 23 Jan 1998 03:55:30 -0500 Message-ID: <34C8D8A8.3DD1@ggi-project.org> Date: Fri, 23 Jan 1998 18:51:36 +0100 From: Jonas Borgström <jonas@ggi-project.org> X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: evstack@ontv.com Subject: Kernel selection(gpm) support. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"J2Epl.0.4J7.Ph5oq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/487 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, I have an almost working selection module for evstack. Gpm and other libgpm programs works now, I just need to clean up the code before I release it. -- ___________________________________________________ ///////////////// Jonas Borgström \\\\\\\\\\\\\\\\\ |----------- E-Mail: jonas@ggi-project.org ----------| |-- The GGI Project: http://www.de.ggi-project.org --| \___________________________________________________/ From evstack-request@ontv.com Fri Jan 23 02:42:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA02219 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 02:42:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA30556; Fri, 23 Jan 1998 05:04:57 -0500 Resent-Date: Fri, 23 Jan 1998 05:04:57 -0500 Message-Id: <m0xvfrn-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: ConLinux and rawkeys ... To: evstack@ontv.com Date: Fri, 23 Jan 1998 20:57:39 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xvbOQ-00017OC@ajax> from "Andrew Apted" at Jan 23, 98 04:11:02 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"eqSWj2.0.tS7.Si6oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/488 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Your's truly writes: > Do the keys 1 2 3 4 do anything when you start the X server _without_ > insmodding conlinux ? [in particular: n m , .] Yet another braino. :-/ I meant running X without the conlinux stack attached... When I get a chance, I'll put some debugging stuff in there, so we can get some idea of what's going on... or not going on... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 23 02:47:15 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA02224 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 02:47:14 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA30642; Fri, 23 Jan 1998 05:12:39 -0500 Resent-Date: Fri, 23 Jan 1998 05:12:39 -0500 Message-Id: <m0xvfzO-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: console speed To: evstack@ontv.com Date: Fri, 23 Jan 1998 21:05:30 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980122234713.9197A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 22, 98 11:57:55 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"OyiP81.0.HU7.ip6oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/489 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > Just out of curiousity - is the current console speed slow for any > particular reason? Just that the speed-up code using (IIRC) an internal set-origin in kgiscroll.c for fast scrolling hasn't been implemented yet. > I'm now editing this message in kon (userspace Japanese graphical console) > because it's display speed is faster than EvStack/kernel :) Ouch. :) Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 23 02:55:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA02232 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 02:55:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA30721; Fri, 23 Jan 1998 05:20:36 -0500 Resent-Date: Fri, 23 Jan 1998 05:20:36 -0500 Message-Id: <m0xvg7C-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Kernel selection(gpm) support. To: evstack@ontv.com Date: Fri, 23 Jan 1998 21:13:33 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <34C8D8A8.3DD1@ggi-project.org> from "Jonas Borgström" at Jan 23, 98 06:51:36 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lJ_kJ2.0.WV7.Fx6oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/490 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jonas Borgström writes: > I have an almost working selection module for evstack. Gpm and other libgpm > programs works now, I just need to clean up the code before I release it. I'd like to hear more about it. In particular, the way it fits in which the scroller and the termstack. [I had some selection code working a while back, but it needed some rethinking...] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 23 05:11:51 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA02382 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 05:11:50 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA31614; Fri, 23 Jan 1998 07:37:17 -0500 Resent-Date: Fri, 23 Jan 1998 07:37:17 -0500 Message-ID: <34C90C74.20A7@ggi-project.org> Date: Fri, 23 Jan 1998 22:32:36 +0100 From: Jonas Borgström <jonas@ggi-project.org> X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: Kernel selection(gpm) support. References: <m0xvg7C-00017OC@ajax> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"4TQt11.0.Dj7.Fw8oq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/491 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andrew Apted wrote: > I'd like to hear more about it. In particular, the way it fits in which > the scroller and the termstack. [I had some selection code working a > while back, but it needed some rethinking...] The module is based on the conlinux code. I'm using: scoll_set_cursor(CURSOR_MARK_START); and scroll_set_cursor(CURSOR_MARK_END); It works but it's flickering when you select the whole screen and then move the mouse, it rerenders the screen after every movement. I'll need to figure out a way to get the selection to disappear when the screen scrolls, but I think it's not to hard to do. I can send you my code on monday(I only have internet access from the school now). -- ___________________________________________________ ///////////////// Jonas Borgström \\\\\\\\\\\\\\\\\ |----------- E-Mail: jonas@ggi-project.org ----------| |-- The GGI Project: http://www.de.ggi-project.org --| \___________________________________________________/ From evstack-request@ontv.com Fri Jan 23 06:22:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA02426 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 06:22:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id IAA32220; Fri, 23 Jan 1998 08:47:38 -0500 Resent-Date: Fri, 23 Jan 1998 08:47:38 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xvioG-0000XVC@charon.beck-sw.de> Subject: Re: ConLinux and rawkeys ... To: evstack@ontv.com Date: Fri, 23 Jan 1998 14:06:12 +0100 (MET) In-Reply-To: <m0xvfrn-00017OC@ajax> from "Andrew Apted" at Jan 23, 98 08:57:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"kYYsS.0.hs7.Dy9oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/492 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Do the keys 1 2 3 4 do anything when you start the X server _without_ > > insmodding conlinux ? [in particular: n m , .] > > Yet another braino. :-/ I meant running X without the conlinux stack > attached... ? I.e. insmod conlinux, start X, but kill off the conlinux stack - right ? > When I get a chance, I'll put some debugging stuff in there, so we can > get some idea of what's going on... or not going on... O.K. - I will try some strace tests ... CU,Andy -- Andreas Beck | Email : <andreas.beck@ggi-project.org> From evstack-request@ontv.com Fri Jan 23 06:39:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA02457 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 06:39:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA32496; Fri, 23 Jan 1998 09:04:04 -0500 Resent-Date: Fri, 23 Jan 1998 09:04:04 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: console speed Date: 23 Jan 1998 14:02:58 GMT Organization: OnTV Pittsburgh, L.P. Lines: 25 Distribution: local Message-ID: <6aa7ui$be2$1@grits.visus.com> References: <6a9ese$r8o$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"IJhx01.0.8x7.1CAoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/493 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis (teunis@mauve.computersupportcentre.com) wrote: > Just out of curiousity - is the current console speed slow for any > particular reason? > I'm now editing this message in kon (userspace Japanese graphical console) > because it's display speed is faster than EvStack/kernel :) Yes - console-scroll-kgi doesn't use a `ring buffer' for text mode - you know, splitline/set_origin... I'll fix this as soon as I get /dev/graph working with IBM/VGA. > PS: I'm just about finished render(..) and copybox(...)... > Are those two functions enough for rendering? > .. I'm tempted to accelerate copybox *grin*... They're all that's required. (actually, only render() is required - copybox can be emulated) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 23 06:41:34 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA02466 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 06:41:33 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA32565; Fri, 23 Jan 1998 09:07:00 -0500 Resent-Date: Fri, 23 Jan 1998 09:07:00 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Kernel selection(gpm) support. Date: 23 Jan 1998 14:06:31 GMT Organization: OnTV Pittsburgh, L.P. Lines: 27 Distribution: local Message-ID: <6aa857$be2$2@grits.visus.com> References: <6aa3co$7v9$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"6Tlj21.0.Dy7.HFAoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/494 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jonas Borgström (jonas@ggi-project.org) wrote: > The module is based on the conlinux code. I'm using: > scoll_set_cursor(CURSOR_MARK_START); > and > scroll_set_cursor(CURSOR_MARK_END); > It works but it's flickering when you select the whole screen and then move > the mouse, it rerenders the screen after every movement. Actually, that's a bug in kgiscroll. What it SHOULD do is either a) Zap the whole danged mark area on any call to scroll_scroll() or b) Move the endpoints of the mark area depending on the scroll_scroll() > I'll need to figure out a way to get the selection to disappear when the > screen scrolls, but I think it's not to hard to do. Fix kgiscroll, and fix it for all time. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 23 06:52:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA02476 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 06:52:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA32704; Fri, 23 Jan 1998 09:17:58 -0500 Resent-Date: Fri, 23 Jan 1998 09:17:58 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: MMAP Problems... Date: 23 Jan 1998 14:17:06 GMT Organization: OnTV Pittsburgh, L.P. Lines: 36 Distribution: local Message-ID: <6aa8p2$be2$3@grits.visus.com> References: <6a8mrs$7uj$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"h-gYD.0.R-7.CPAoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/495 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Marcus Sundberg (e94_msu@elixir.e.kth.se) wrote: > My first reaction about alternative III was "NOOOO WAAAY!" > One of the reasons I want GGI is allways being able to do a VT > switch, without worrying about any running apps, and without > killing apps. From the user-perception, this is what happend. If I try to VT switch once, the kernel send a `CmdVTReqSwitch' to the app. If I try again and the VT is STILL locked, a SIGSEGV is sent to the app. If THAT didn't work, a SIGKILL is sent to the app. > What I think you're also forgetting is that GGI is supposed to > be portable, apps should definitely not need to care about any > Linux console specific things like VT switching. Exactly. Which is why the app will get events like `CmdLostFocus' and `CmdGotFocus' [which can be ignored and are pretty generic], and the KGI target of libGGI will handle the `CmdVTReqSwitch' events. Of course, my concept of `apps' is libGGI apps. People who go directly to /dev/graph* are expected to deal with that mess. > If you think Andy's way bloat the kernel too much, I was going > to propose a subset of that: The problem is not of setting modes or of signaling apps - it's of mmap()ed memory areas that we can't (currently) be sure will even EXIST on switch-away, or that might be WILDLY DIFFERENT on switch-to. That these mapping will change under a program's feet is `The Wrong Thing To Do' -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 23 07:11:53 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA02494 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 07:11:52 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA00120; Fri, 23 Jan 1998 09:35:23 -0500 Resent-Date: Fri, 23 Jan 1998 09:35:23 -0500 Sender: torgeir@salsa.visus.com Message-ID: <34C8B7EF.5CD7BD16@vertech.no> Date: Fri, 23 Jan 1998 15:31:59 +0000 From: Torgeir Veimo <torgeir.veimo@vertech.no> Organization: Vertech AS X-Mailer: Mozilla 4.04j2 [en] (X11; I; Linux 2.0.31 i686) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: Kernel selection(gpm) support. References: <6aa3co$7v9$1@grits.visus.com> <6aa857$be2$2@grits.visus.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"k4e-K.0.61.ZfAoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/496 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan wrote: > > Jonas Borgström (jonas@ggi-project.org) wrote: > > I'll need to figure out a way to get the selection to disappear when the > > screen scrolls, but I think it's not to hard to do. > > Fix kgiscroll, and fix it for all time. I find it rather handy to be able to scroll and select at the same time, as I do in netscape. (But I haven't tried this is a console window though.) -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From evstack-request@ontv.com Fri Jan 23 10:47:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA02744 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 10:47:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA02382; Fri, 23 Jan 1998 13:12:12 -0500 Resent-Date: Fri, 23 Jan 1998 13:12:12 -0500 Date: Fri, 23 Jan 1998 11:22:03 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: console speed In-Reply-To: <m0xvfzO-00017OC@ajax> Message-ID: <Pine.LNX.3.96.980123111830.10997C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Aq7F82.0.Va.oqDoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/497 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 23 Jan 1998, Andrew Apted wrote: > teunis writes: > > > Just out of curiousity - is the current console speed slow for any > > particular reason? > > Just that the speed-up code using (IIRC) an internal set-origin in > kgiscroll.c for fast scrolling hasn't been implemented yet. Okay - that explains a lot... so what's needed? At a guess the prototypes are already present in text_operations. > > I'm now editing this message in kon (userspace Japanese graphical console) > > because it's display speed is faster than EvStack/kernel :) > > Ouch. :) Tells ya something about a fast 16-colour program though, doesn't it? :) (the code's only slightly slower than normal linux console... and it supports full Japanese character-set too :) When's the console getting scrollback BTW? ... and when will the keyboard-repeat-rate be programmable? *sigh*... I'm going to look at implementing a basic kernel-based EGA-style console for inclusion as either a GGI-module-piece or an actual kernel module in the next couple of weeks after I get this cubic puzzle out :) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 23 12:32:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA02816 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 12:31:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA03233; Fri, 23 Jan 1998 14:56:40 -0500 Resent-Date: Fri, 23 Jan 1998 14:56:40 -0500 Date: Fri, 23 Jan 1998 13:06:11 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: S3 ViRGE driver Message-ID: <Pine.LNX.3.96.980123130214.11355B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Ar-C23.0.jn.TMFoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/498 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Okay - I've got the driver compiling (without acceleration - that code still needs work)... But it's crashing very early - at KGIM_PRIVATE(dpy,chipset)=private... it seems as though dpy->mode.mode_data (void* -> struct kgim_private*) has not been initialized anywhere so ya get a NULL pointer reference. So where should I set this up? I'm patching the ViRGE to set it up but IMHO it should be in the kernel-driver... G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 23 14:03:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA02960 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 14:03:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA04343; Fri, 23 Jan 1998 16:27:56 -0500 Resent-Date: Fri, 23 Jan 1998 16:27:56 -0500 Message-ID: <19980123152600.55644@3e8.com> Date: Fri, 23 Jan 1998 15:26:00 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Docs for porting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Deities: e38 Resent-Message-ID: <"hd6bs2.0.Y11.WhGoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/499 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I need some documentation or direction on what changes need to be made to a display driver to port it to EvStack, so I can port my own driver. Of course I plan to read the EvStack source and ported driver sources anyway, but if even a small amount of reading material, porting caveats, etc. is available it'd be great. (Emmanuel Marty is supposed to be writing a guide, but he must have gotten his info from somewhere.) Then, once I decide that kernels greater than 2.1.59 won't cripple my system, I will begin the port. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Fri Jan 23 14:22:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA02994 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 14:22:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA04588; Fri, 23 Jan 1998 16:47:00 -0500 Resent-Date: Fri, 23 Jan 1998 16:47:00 -0500 Date: Fri, 23 Jan 1998 14:56:18 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Re: S3 ViRGE driver In-Reply-To: <Pine.LNX.3.96.980123130214.11355B-100000@sigil.computersupportcentre.com> Message-ID: <Pine.LNX.3.96.980123145516.11641A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4mXs11.0.Y51.WzGoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/500 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 23 Jan 1998, teunis wrote: > Okay - I've got the driver compiling (without acceleration - that code > still needs work)... > > But it's crashing very early - at KGIM_PRIVATE(dpy,chipset)=private... > > it seems as though dpy->mode.mode_data (void* -> struct kgim_private*) > has not been initialized anywhere so ya get a NULL pointer reference. > > So where should I set this up? I'm patching the ViRGE to set it up but > IMHO it should be in the kernel-driver... Further info : the VGA driver does _NOT_ use this structure. It now has the MMAP info and other pieces... it's very important to fix! So how shall I begin? :) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 23 17:02:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA03272 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 17:02:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA06270; Fri, 23 Jan 1998 19:27:34 -0500 Resent-Date: Fri, 23 Jan 1998 19:27:34 -0500 Date: Fri, 23 Jan 1998 17:37:24 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com Reply-To: teunis <teunis@mauve.computersupportcentre.com> To: EvStack list <evstack@ontv.com> Subject: i386 (GGI/kernel) update [IMPORTANT TO PEOPLE PORTING DRIVERS] Message-ID: <Pine.LNX.3.96.980123172250.449A-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-2127642792-885602244=:449" Resent-Message-ID: <"gwdF33.0.AV1.uKJoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/501 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-2127642792-885602244=:449 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's an updated i386.c (sorry can't patch - don't have original anymore) ... that fixes KGIM_PRIVATE... and particularily KGIM_OPTIONS. This might explain the faults on loading ggidrv.o.... checking :) Nope - there's still a NULL pointer reference somewhere *sigh*. On the flip side, ViRGE now compiles and inserts (and crashes *grr* - but only the display... you can still hit keys and reboot safely and all :) G'day, eh? :) - Teunis Figure I'd post to everyone so SOMEONE can fix the beasty... It's not that large (11K)... ---1463800064-2127642792-885602244=:449 Content-Type: TEXT/plain; name="i386.c" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980123173724.449B@sigil.computersupportcentre.com> Content-Description: LyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoqKglLR0kga2Vy bmVsIGRyaXZlcg0KKiogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoqKg0KKioJQ29weXJpZ2h0IChDKSAxOTk1LTE5OTcgYnkgDQoqKg0KKioJ QW5kcmVhcyBCZWNrLA0KKioJU3RlZmZlbiBTZWVnZXIsDQoqKg0KKioJVGhp cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli dXRlIGl0IGFuZC9vciBtb2RpZnkNCioqCWl0IHVuZGVyIHRoZSB0ZXJtcyBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVk IGJ5DQoqKgl0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIg dmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRpb24pDQoqKglhbnkgbGF0ZXIg dmVyc2lvbi4NCioqDQoqKglZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBj b3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KKioJYWxv bmcgd2l0aCB0aGlzIHByb2dyYW07IHNlZSB0aGUgZmlsZSBDT1BZSU5HLiAg SWYgbm90LCB3cml0ZSB0bw0KKioJdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbiwgNjc1IE1hc3MgQXZlLCBDYW1icmlkZ2UsIE1BIDAyMTM5LCBVU0Eu DQoqKg0KKiogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoqKiAN CioqCSRMb2c6IGkzODYuYyx2ICQNCioqCVJldmlzaW9uIDEuMTkuMi43ICAx OTk4LzAxLzE0IDA1OjUzOjEwICBlenJlYw0KKioJTWlub3I6IENhdmVhdCBF bXB0b3IhIGxhdGVzdCBzdHVmZiBmcm9tIEphc29uIQ0KKioJICAgICAgIHNo b3VsZCBwYXRjaCBMaW51eCAyLjEuNzctMi4xLjc5DQoqKgkNCioqCVJldmlz aW9uIDEuMTkuMi42ICAxOTk4LzAxLzA0IDE5OjMzOjA1ICBlenJlYw0KKioJ TWlub3I6IFRoaXMgaXMgdGhlIDIuMS43N2EgUmVsZWFzZQ0KKioJDQoqKglS ZXZpc2lvbiAxLjE5LjIuNSAgMTk5OC8wMS8wNCAwMzozNzo1MSAgZXpyZWMN CioqCU1pbm9yOiBIZXJjdWxlcyBhbmQgVkdBIGRyaXZlcnMgbm93IHdvcmsg Zm9yIG1vZGUtc3dpdGNoaW5nDQoqKgkgICAgICAgYW5kIEdUX1RFWFQxNiBt b2RlLiBEZXYtZ3JhcGggc3RpbGwgZG9uJ3Qgd29yayAtIG11bHRpaGVhZCBk b2VzLg0KKioJDQoqKglSZXZpc2lvbiAxLjE5LjIuNCAgMTk5Ny8xMi8xNyAx NDozODowMyAgZXpyZWMNCioqCU1lcmdlZCB3aXRoIERlYzEzIHJldmlzaW9u IG9mIHRoZSBtYWlsIHRyZWUsIGFuZCBtb2RpZmllZCB0aGUNCioqCWtnaV9t b2RlL2tnaV9kaXNwbGF5IHN0cnVjdHMuIFNlZSBrZ2kuaCBmb3IgbW9yZSBk ZXRhaWxzLg0KKioJDQoqKglSZXZpc2lvbiAxLjIyICAxOTk3LzEyLzE0IDIx OjU2OjEyICBiZWNrYQ0KKioJdWludC9zaW50IG5hbWVzcGFjZSBmaXhlZCAu Li4gcGxlYXNlIHRlc3QgLi4uDQoqKgkNCioqCVJldmlzaW9uIDEuMjEgIDE5 OTcvMTIvMDQgMTA6Mjk6MzEgIHNlZWdlcg0KKioJRml4IGluIFBDSSBleHBv cnQgbWFjcm9zLg0KKioJDQoqKglSZXZpc2lvbiAxLjIwICAxOTk3LzEyLzAz IDE1OjQxOjU0ICBzZWVnZXINCioqCUFkZGVkIFBDSSBtb2R1bGUgcGFyYW1l dGVycw0KKioJDQoqKglSZXZpc2lvbiAxLjE4ICAxOTk3LzExLzA4IDE1OjEy OjQ3ICBiZWNrYQ0KKioJTmFtZXNwYWNlIGNsZWFudXAgLi4uIHByb2JhYmx5 IGJyb2tlIGFsbCBhbmQgZXZlcnl0aGluZyAuLi4NCioqDQoqKiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiovDQoNCiNpbmNsdWRlIDxnZ2kv bWFpbnRhaW5lcnMuaD4NCiNkZWZpbmUJTUFJTlRBSU5FUglTdGVmZmVuX1Nl ZWdlcg0KI2RlZmluZSBEUklWRVJfTkFNRQkiaTM4NiINCiNkZWZpbmUgRFJJ VkVSX1JFVgkiJFJldmlzaW9uOiAxLjE5LjIuNyAkIg0KDQojaW5jbHVkZSA8 bGludXgvY29uZmlnLmg+DQojaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPg0K I2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KI2luY2x1ZGUgPGxpbnV4L2tl cm5lbC5oPg0KI2luY2x1ZGUgPGxpbnV4L21tLmg+DQoNCiNpbmNsdWRlIDxn Z2kvbW9kdWxlLmg+DQojaW5jbHVkZSA8Z2dpL2dnaV9jb21tYW5kcy5oPg0K I2luY2x1ZGUgPGdnaS9jb25zb2xlLmg+DQojaW5jbHVkZSAiY29uZmlnLmgi DQoNCiNpbmNsdWRlIDxhc20vaW8uaD4NCg0KI2lmIERFQlVHX0xFVkVMID4g Mg0Kc3RhdGljIHZvaWQgcHJpbnRrX21vZGUgKHN0cnVjdCBrZ2lfbW9kZSAq bW9kZSwgY2hhciAqbXNnKQ0Kew0KCSNkZWZpbmUgTShYKQltb2RlLT50bS5Y DQoJI2RlZmluZSBSKFgpCW1vZGUtPnJlcXVlc3QuWA0KCSNkZWZpbmUgVChY KQlNKFgud2lkdGgpLCBNKFguYmxhbmtzdGFydCksIE0oWC5zeW5jc3RhcnQp LFwNCgkJCU0oWC5zeW5jZW5kKSwgTShYLmJsYW5rZW5kKSwgTShYLnRvdGFs KSwgTShYLnBvbGFyaXR5KQ0KDQoJcHJpbnRrKG1zZyk7DQoJcHJpbnRrKCJt b2RlID0ge1xue1xuLyogZnJhbWVzICAgICovICAlaSxcbi8qIHZpc2libGUg Ki9cdHsgJWksICVpfSxcbiIsDQoJCQlSKGZyYW1lcyksIFIodmlzaWJsZS54 KSxSKHZpc2libGUueSkpOw0KCXByaW50aygiLyogdmlydHVhbCAgICovICB7 ICVpLCAlaX0sXG4iLFIodmlydC54KSxSKHZpcnQueSkpOw0KCXByaW50aygi Lyogc2l6ZSBbbW1dICovICB7ICVpLCAlaX0sXG4iLFIoc2l6ZS54KSxSKHNp emUueSkpOw0KCXByaW50aygiLyogZ3JhcGhtb2RlICovICAweCV4LFxuIiwg UihncmFwaHR5cGUpKTsNCglwcmludGsoIi8qIHRleHRncmlkICAqLyAgeyAl aSwgJWl9fSxcbiIsIFIodGV4dC54KSxSKHRleHQueSkpOw0KCXByaW50aygi LyogeCB0aW1pbmcgICovICB7ICVpLCAlaSwgJWksICVpLCAlaSwgJWksICVp fSxcbiIsIFQoeCkpOw0KCXByaW50aygiLyogeSB0aW1pbmcgICovICB7ICVp LCAlaSwgJWksICVpLCAlaSwgJWksICVpfSxcbiIsIFQoeSkpOw0KCXByaW50 aygiLyogbWFnbmlmeSAgICovICB7ICVpLCAlaX0sXG4iLCBNKG1hZ25pZnku eCksIE0obWFnbmlmeS55KSk7DQoJcHJpbnRrKCIvKiBmbGFncyAgICAgKi8g ICV4LFxuIiwgTShmbGFncykpOw0KCXByaW50aygiLyogZGNsayAgICAgICov ICAlaSxcbiIsIE0oZGNsaykpOw0KCXByaW50aygiLyogY2xrICAgICAgICov ICB7ICVpLCAlaX0sXG4iLCBNKGNsay5tdWwpLCBNKGNsay5kaXYpKTsNCglw cmludGsoIi8qIGxjbGsgICAgICAqLyAgeyAlaSwgJWl9XG59XG4iLCBNKGxj bGsubXVsKSwgTShsY2xrLmRpdikpOw0KDQoJI3VuZGVmIE0NCgkjdW5kZWYg Ug0KCSN1bmRlZiBUDQp9DQojZW5kaWYgLyogI2lmIERFQlVHX0xFVkVMID4g MiAqLw0KDQpzdGF0aWMgc3RydWN0IGtnaV9jYXJkIGNhcmQgPSANCnsNCglD T05GSUdfQ0FSRF9NQU5VRkFDVCwJCQkvKiBDYXJkIG1hbnVmYWN0dXJlcgkq Lw0KCUNPTkZJR19DQVJEX01PREVMLAkJCS8qIENhcmQgbW9kZWwJCSovDQoJ Q09ORklHX0NBUkRfTU9ERVMsCQkJLyogQWxsb3dlZCBtb2RlcwkqLw0KCTAs DQoJeyBDT05GSUdfQ0FSRF9NQVhfWCwgQ09ORklHX0NBUkRfTUFYX1kgfSwv KiBVc2VyIGxpbWl0cwkJKi8NCg0KCU5VTEwsCS8qIGNhcmQgY29tcG9uZW50 IGluZm8gc3RydWN0cywgdGhlc2UgYXJlIG5vdCBrbm93biB5ZXQJKi8NCglO VUxMLAkvKiBhbmQgZ2V0IGZpbGxlZCBpbiBkdXJpbmcgaW5pdGl0YWxpemF0 aW9uCQkqLw0KCU5VTEwsDQoJTlVMTCwNCgl7IH0JLyogV2UgdXNlIHRoZSBj YXJkJ3MgYGRlZmF1bHQgbW9kZScgKi8NCn07DQoNCiNkZWZpbmUJa2dpbV9z ZXRfbW9kZQlrZ2ltX2NoaXBzZXRfc2V0X21vZGUNCg0Kc3RhdGljIGludCBr Z2ltX2NoZWNrX21vZGUoc3RydWN0IGtnaV9kaXNwbGF5ICpkcHksIHN0cnVj dCBrZ2lfbW9kZSAqbW9kZSwgDQoJCQkgICBlbnVtIGtnaV90bV9jbWQgY21k KQ0Kew0KCWludCBjbnQgPSAxMDsNCg0KCWlmIChjbWQgPT0gQ01EX1BST1BP U0UpIHsNCg0KCQltZW1zZXQoJihtb2RlLT5yZXF1ZXN0KSArIDEsIDAsIA0K CQkgICAgICAgc2l6ZW9mKCptb2RlKSAtIHNpemVvZihtb2RlLT5yZXF1ZXN0 KSk7DQoJfQ0KDQoJd2hpbGUgKGNudC0tICYmICEoY21kID09IENNRF9SRUFE WSkpIHsNCg0KCQlyZWdpc3RlciBpbnQgZXJyOw0KCQlERUJVRzIoImNoZWNr X21vZGU6Y21kPSVpOyBjbnQ9JWkiLCBjbWQsIGNudCk7DQoNCgkJaWYgKChl cnIgPSBrZ2ltX2Nsb2NrX2NoZWNrX21vZGUgKGRweSwgbW9kZSwgY21kKSkp IHsNCg0KCQkJcmV0dXJuIGVycjsNCgkJfQ0KCQkNCgkJREVCVUcyKCJjaGVj a19tb2RlOiBjbG9jayBvay4iKTsNCg0KCQlpZiAoKGVyciA9IGtnaW1fcmFt ZGFjX2NoZWNrX21vZGUoZHB5LCBtb2RlLCBjbWQpKSkgew0KDQoJCQlyZXR1 cm4gZXJyOw0KCQl9DQoJCQ0KCQlERUJVRzIoImNoZWNrX21vZGU6IHJhbWRh YyBvay4iKTsNCg0KCQlpZiAoKGVyciA9IGtnaW1fY2hpcHNldF9jaGVja19t b2RlKGRweSwgbW9kZSwgY21kKSkpIHsNCg0KCQkJcmV0dXJuIGVycjsNCgkJ fQ0KCQkNCgkJREVCVUcyKCJjaGVja19tb2RlOiBjaGlwc2V0IG9rLiIpOw0K IA0KCQlpZiAoY21kID09IENNRF9MT1dFUiB8fCBjbWQgPT0gQ01EX1JBSVNF KSB7DQoNCgkJCWlmICgoZXJyID0ga2dpbV9jbG9ja19jaGVja19tb2RlKGRw eSwgbW9kZSwgY21kKSkpIA0KCQkJew0KDQoJCQkJcmV0dXJuIGVycjsNCgkJ CX0NCgkJCURFQlVHMigiMm5kIGNsb2NrIGNoZWNrIG9rLiIpOw0KCQl9DQoN CgkJaWYgKChlcnIgPSBrZ2ltX2dyYXBoaWNzX2NoZWNrX21vZGUoZHB5LCBt b2RlLCBjbWQpKSkgew0KDQoJCQlyZXR1cm4gZXJyOw0KCQl9DQoJCQ0KCQlE RUJVRzIoImNoZWNrX21vZGU6IGdyYXBoaWNzIG9rLiIpOw0KIA0KCQlpZiAo KGVyciA9IGtnaW1fbW9uaXRvcl9jaGVja19tb2RlKGRweSwgbW9kZSwgJmNt ZCkpKSB7DQoNCgkJCXJldHVybiBlcnI7DQoJCX0NCgkJDQoJCURFQlVHMigi Y2hlY2tfbW9kZTogbW9uaXRvciBvay4iKTsNCg0KCQkjaWYgREVCVUdfTEVW RUwgPiAyDQoJCQlwcmludGtfbW9kZShtb2RlLCAibW9kZTpcbiIpOw0KCQkj ZW5kaWYNCgl9DQoNCgkjaWYgREVCVUdfTEVWRUwgPiAyDQoJVFJBQ0UocHJp bnRrX21vZGUobW9kZSwgIm1vZGUgb2s6XG4iKSk7DQoJI2VuZGlmDQogDQoJ cmV0dXJuICgrK2NudCkgPyBFT0sgOiAtRShEUklWRVIsIFVOS05PV04pOw0K fQ0KDQpzdGF0aWMgdm9pZCBrZ2ltX3Jlc2V0KHN0cnVjdCBrZ2lfZGlzcGxh eSAqZHB5KQ0Kew0KCWtnaW1fY2hpcHNldF9zZXRfbW9kZShkcHksICYoZHB5 LT5jYXJkLT5wcmVzZXQpKTsNCgkvKglmcmFtZSBhbmQgb3JpZ2luIGFyZSBz ZXQgdG8gemVybyBhbmQgc3BsaXRsaW5lIGlzIHNldCB0bw0KCSoqCWRweS0+ Y2FyZC0+cmVzZXQtPnJlcXVlc3QudmlzaWJsZS55IGJ5IHRoZSBjaGlwc2V0 IGRyaXZlcg0KCSoqCWR1cmluZyBkcHktPnNldF9tb2RlLiBUaHVzIG5vIG5l ZWQgdG8gcmVzZXQgdGhlbSBhZ2Fpbi4NCgkqLw0KfQ0KDQovKgltb2R1bGUg bG9hZGluZw0KKi8NCg0KZ2dpX3VpbnQgcGNpYnVzID0gLTEsIHBjaWRldiA9 IC0xLCBwY2lmbiA9IDA7DQpnZ2lfdWludCBwY2liYXNlMCA9IDAsIHBjaWJh c2UxID0gMCwgcGNpYmFzZTIgPSAwLCBwY2liYXNlMyA9IDAsIHBjaWJhc2U0 ID0gMDsNCnN0cnVjdCBrZ2ltX29wdGlvbnNfcGNpIG9wdGlvbnNfcGNpOw0K DQpnZ2lfdWludCBsYXdfYmFzZSA9IDAsIGRpc3BsYXkgPSAwOw0KDQojaWZk ZWYgTU9EVUxFX1BBUk0NCiNpZiBNQVhfTlJfRElTUExBWVMgIT0gMTYNCgkj d2FybmluZyBNQVhfTlJfRElTUExBWVMgY2hhbmdlZCwgdXBkYXRlIHRoaXMg Y29kZQ0KI2VuZGlmDQpNT0RVTEVfUEFSTShkaXNwbGF5LCAiMC0iIF9fTU9E VUxFX1NUUklORygxNikgImkiKTsNCg0KTU9EVUxFX1BBUk0obGF3X2Jhc2Us ICIxLSIgX19NT0RVTEVfU1RSSU5HKDQyOTQ5NjcyOTUpICJpIik7DQoNCk1P RFVMRV9QQVJNKHBjaWJ1cywgIjAtIiBfX01PRFVMRV9TVFJJTkcoMjU1KSAi aSIpOw0KTU9EVUxFX1BBUk0ocGNpZGV2LCAiMC0iIF9fTU9EVUxFX1NUUklO RygyNTUpICJpIik7DQpNT0RVTEVfUEFSTShwY2liYXNlMCwgIjEtIiBfX01P RFVMRV9TVFJJTkcoNDI5NDk2Mjk1KSAiaSIpOw0KTU9EVUxFX1BBUk0ocGNp YmFzZTEsICIxLSIgX19NT0RVTEVfU1RSSU5HKDQyOTQ5NjI5NSkgImkiKTsN Ck1PRFVMRV9QQVJNKHBjaWJhc2UyLCAiMS0iIF9fTU9EVUxFX1NUUklORyg0 Mjk0OTYyOTUpICJpIik7DQpNT0RVTEVfUEFSTShwY2liYXNlMywgIjEtIiBf X01PRFVMRV9TVFJJTkcoNDI5NDk2Mjk1KSAiaSIpOw0KTU9EVUxFX1BBUk0o cGNpYmFzZTQsICIxLSIgX19NT0RVTEVfU1RSSU5HKDQyOTQ5NjI5NSkgImki KTsNCiNlbmRpZg0KDQpzdHJ1Y3Qga2dpbV9vcHRpb25zX21pc2Mgb3B0aW9u c19taXNjOw0KDQpzdGF0aWMgc3RydWN0IGtnaW1fb3B0aW9ucyBvcHRpb25z ID0NCnsNCgkmb3B0aW9uc19taXNjLA0KCSZvcHRpb25zX3BjaQ0KfTsNCg0K c3RhdGljIGlubGluZSB2b2lkIGdldF9vcHRpb25zKHZvaWQpDQp7DQoJaWYg KChwY2lidXMgIT0gLTEpICYmIChwY2lkZXYgIT0gLTEpKSB7DQoNCgkJb3B0 aW9uc19wY2kuZGV2ID0gUENJQ0ZHX1ZBRERSKHBjaWJ1cywgcGNpZGV2LCBw Y2lmbik7DQoJCW9wdGlvbnNfcGNpLmJhc2UwID0gcGNpYmFzZTA7DQoJCW9w dGlvbnNfcGNpLmJhc2UxID0gcGNpYmFzZTE7DQoJCW9wdGlvbnNfcGNpLmJh c2UyID0gcGNpYmFzZTI7DQoJCW9wdGlvbnNfcGNpLmJhc2UzID0gcGNpYmFz ZTM7DQoJCW9wdGlvbnNfcGNpLmJhc2U0ID0gcGNpYmFzZTQ7DQoNCgl9IGVs c2Ugew0KDQoJCW1lbXNldCgmb3B0aW9uc19wY2ksIDAsIHNpemVvZihvcHRp b25zX3BjaSkpOw0KCQlvcHRpb25zX3BjaS5kZXYgPSBQQ0lDRkdfTlVMTDsN Cgl9DQoNCglvcHRpb25zX21pc2MubGF3X2Jhc2UgPSBsYXdfYmFzZTsNCglv cHRpb25zX21pc2MuZGlzcGxheSA9IGRpc3BsYXk7DQp9Ow0KDQpzdGF0aWMg c3RydWN0IGtnaW1fcHJpdmF0ZSBtb2R1bGVfcHJpdmF0ZSA9DQp7DQoJJm9w dGlvbnMsDQoJTlVMTCwNCn07DQoNCnN0YXRpYyBnZ2lfbW9kZSBrZ2ltX2Rl ZmF1bHRfbW9kZTsNCg0Kc3RydWN0IGtnaV9kaXNwbGF5IG15X2Rpc3BsYXkg PSANCnsNCgktMSwJCQkJLyogaWQgbnVtYmVyCQkJKi8NCgkwLAkJCQkvKiBy ZWZjbnQJCQkqLw0KCTB4RkZGRkZGRkYsCQkJLyogY29uZmxpY3RfdGV4dAkJ Ki8NCgkweEZGRkZGRkZGLAkJCS8qIGNvbmZsaWN0X2dyYXBoCQkqLw0KCTB4 RkZGRkZGRkYsCQkJLyogY29uZmxpY3Rfc2V0dXAJCSovDQoNCgkmbW9kdWxl X3ByaXZhdGUsCQkvKiBkcml2ZXJfZGF0YQkJCSovDQoNCgkJCQkJLyogdGhl c2UgYXJlIHNldCBieSB0aGUgZHJpdmVyCSovDQoNCglOVUxMLAkJCQkvKiBl bmFibGUoc3RydWN0IGtnaV9kaXNwbGF5ICopCSovDQoJTlVMTCwJCQkJLyog ZGlzYWJsZShzdHJ1Y3Qga2dpX2Rpc3BsYXkgKikqLw0KCWtnaW1fcmVzZXQs CQkJLyogcmVzZXQoc3RydWN0IGtnaV9kaXNwbGF5ICopCSovDQoNCgl7CQkJ CS8qIGlvY3RsIG1ldGhvZHMJCSovDQoJCU5VTEwsDQoJCWtnaW1fbW9uaXRv cl9jb21tYW5kLA0KCQlrZ2ltX3JhbWRhY19jb21tYW5kLA0KCQlrZ2ltX2Ns b2NrX2NvbW1hbmQsDQoJCWtnaW1fY2hpcHNldF9jb21tYW5kLA0KCQlrZ2lt X2dyYXBoaWNzX2NvbW1hbmQsDQoJCU5VTEwsDQoJCU5VTEwNCgl9LA0KCSZj YXJkLAkJCQkvKiBoYXJkd2FyZSBpbmZvCQkqLw0KCWtnaW1fY2hlY2tfbW9k ZSwJCS8qIGNoZWNrX21vZGUoKQkJCSovDQoJa2dpbV9zZXRfbW9kZSwJCQkv KiBzZXRfbW9kZSgpCS0+IGNoaXBzZXQJKi8NCg0KCXsgfSwJCQkJLyogY3Vy cmVudCBtb2RlCQkJKi8NCgkma2dpbV9kZWZhdWx0X21vZGUsCQkvKiBkZWZh dWx0IG1vZGUgb2YgZGlzcGxheQkqLw0KfTsNCg0Kc3RhdGljIGludCBwcmVw YXJlX2Rpc3BsYXlfc3RydWN0KHN0cnVjdCBrZ2lfZGlzcGxheSAqZHB5KQ0K ICB7DQogIGlmIChkcHktPm1vZGUubW9kZV9kYXRhID09IE5VTEwpDQogICAg IHsNCiAgICAgZHB5LT5tb2RlLm1vZGVfZGF0YSA9IGtnaV9tYWxsb2Nfc21h bGwoc2l6ZW9mKHN0cnVjdCBrZ2ltX3ByaXZhdGUpLA0KCQkJCQkgICAgR0ZQ X0tFUk5FTCk7DQogICAgIGlmIChkcHktPm1vZGUubW9kZV9kYXRhID09IE5V TEwpDQoJew0KCUVSUk9SKCJFUlJPUjogZGlzcGxheSdzIHByaXZhdGUgbW9k ZSBkYXRhIGZhaWxlZCBhbGxvY2F0aW9uISIpOw0KCXJldHVybiAtRU5PTUVN Ow0KCX07DQogICAgIH07DQoNCiAgS0dJTV9QUklWQVRFKGRweSwgZHJpdmVy KSAgID0gJm9wdGlvbnM7DQogIEtHSU1fUFJJVkFURShkcHksIG1vbml0b3Ip ICA9IE5VTEw7DQogIEtHSU1fUFJJVkFURShkcHksIGNoaXBzZXQpICA9IE5V TEw7DQogIEtHSU1fUFJJVkFURShkcHksIHJhbWRhYykgICA9IE5VTEw7DQog IEtHSU1fUFJJVkFURShkcHksIGNsb2NrKSAgICA9IE5VTEw7DQogIEtHSU1f UFJJVkFURShkcHksIGdyYXBoaWNzKSA9IE5VTEw7DQoNCiAgcmV0dXJuIEVP SzsNCiAgfTsNCg0KaW50IGluaXRfbW9kdWxlKHZvaWQpDQp7DQoJLyoJTk9U RTogVGhlIHZhcmlvdXMgP19pbml0KCkgZnVuY3Rpb25zIGhhdmUgdG8gcHJp bnRrIHRoZSByZWFzb24NCgkqKglmb3IgZmFpbGluZyB0aGVtc2VsZiAtLSBq dXN0IGluIGNhc2UgdGhleSBmYWlsLg0KCSovDQoJaW50IGVycjsNCg0KCWdl dF9vcHRpb25zKCk7DQoNCgkvKiBpbml0aWFsaXplcyB0aGUgZGlzcGxheSBl bnZpcm9ubWVudCBwcml2YXRlIGRhdGEgKi8NCglpZiAoKGVyciA9IHByZXBh cmVfZGlzcGxheV9zdHJ1Y3QoJm15X2Rpc3BsYXkpKSkNCgkgICB7IHJldHVy biBlcnI7IH07DQoNCgkvKglUaGUgY2hpcHNldCBwcm92aWRlcyBJL08gZnVu Y3Rpb25zIGZvciBhbGwgb3RoZXIgcGFydHMsIHRodXMgd2UNCgkqKgloYXZl IHRvIGluaXQgaXQgZmlyc3QuDQoJKi8NCg0KCWlmICgoZXJyID0ga2dpbV9j aGlwc2V0X2luaXQoJmNhcmQsICZteV9kaXNwbGF5KSkpIHsNCg0KCQlyZXR1 cm4gZXJyOw0KCX0NCg0KCS8qCU5vdyB0aGF0IHRoZSBjaGlwc2V0IGlzIG9r LCB3ZSB0cnkgdG8gaW5pdCB0aGUgbW9uaXRvciBkcml2ZXIuDQoJKioJaWYg dGhpcyBmYWlscywgd2UgaGF2ZSB0byBkZWluaXRpYWxpemVlIHRoZSBjaGlw c2V0Lg0KCSovDQoJaWYgKChlcnIgPSBrZ2ltX21vbml0b3JfaW5pdCgmY2Fy ZCwgJm15X2Rpc3BsYXkpKSkgew0KDQoJCWtnaW1fY2hpcHNldF9kb25lKCZt eV9kaXNwbGF5KTsNCgkJcmV0dXJuIGVycjsNCgl9DQoNCgkvKglOb3cgd2Ug Z28gZm9yIHRoZSBEQUMuIElmIGl0IGZhaWxzLCB3ZSBoYXZlIHRvIGRlaW5p dGlhbGl6ZQ0KCSoqCXRoZSBzdWJzeXN0ZW1zIGFscmVhZHkgZmlyZWQgdXAu DQoJKi8NCglpZiAoKGVyciA9IGtnaW1fcmFtZGFjX2luaXQoJmNhcmQsICZt eV9kaXNwbGF5KSkpIHsNCg0KCQlrZ2ltX21vbml0b3JfZG9uZSgmbXlfZGlz cGxheSk7DQoJCWtnaW1fY2hpcHNldF9kb25lKCZteV9kaXNwbGF5KTsNCgkJ cmV0dXJuIC1FSU87DQoJfQ0KDQoJLyoJTm93IHRoZSBjbG9jayBkcml2ZXIu IElmIHRoaXMgZmFpbHMsIC4uLg0KCSovDQoJaWYgKChlcnIgPSBrZ2ltX2Ns b2NrX2luaXQoJmNhcmQsICZteV9kaXNwbGF5KSkpIHsNCg0KCQlrZ2ltX3Jh bWRhY19kb25lKCZteV9kaXNwbGF5KTsNCgkJa2dpbV9tb25pdG9yX2RvbmUo Jm15X2Rpc3BsYXkpOw0KCQlrZ2ltX2NoaXBzZXRfZG9uZSgmbXlfZGlzcGxh eSk7DQoJCXJldHVybiAtRUlPOw0KCX0NCg0KCS8qCUxhc3QgaXMgdGhlIGFj Y2VsIGRyaXZlci4gSWYgdGhpcyBmYWlscywgLi4uDQoJKi8NCglpZiAoKGVy ciA9IGtnaW1fZ3JhcGhpY3NfaW5pdCgmY2FyZCwgJm15X2Rpc3BsYXkpKSkg ew0KDQoJCWtnaW1fY2xvY2tfZG9uZSgmbXlfZGlzcGxheSk7DQoJCWtnaW1f cmFtZGFjX2RvbmUoJm15X2Rpc3BsYXkpOw0KCQlrZ2ltX21vbml0b3JfZG9u ZSgmbXlfZGlzcGxheSk7DQoJCWtnaW1fY2hpcHNldF9kb25lKCZteV9kaXNw bGF5KTsNCgkJcmV0dXJuIC1FSU87DQoJfQ0KDQoJLyoJV2UgcmVxdWlyZSB0 aGF0IHRoZSBjYXJkIGNhbiBiZSByZXNldCBwcm9wZXJseSwgdGh1cw0KCSoq CXRoZSBwcmVzZXQgbW9kZSBtdXN0IGJlIGFjY2VwdGVkIGJ5IHRoZSBkcml2 ZXJzLg0KCSoqCUp1c3QgaW4gY2FzZSAuLi4gKEV2ZXIgaGVhcmQgb2YgTXVy cGh5cyBMYXc/IHwtKQ0KCSovDQoJaWYgKGtnaW1fY2hlY2tfbW9kZSgmbXlf ZGlzcGxheSwgJmNhcmQucHJlc2V0LCBDTURfQ0hFQ0spKSB7DQoJDQoJCUVS Uk9SKCJjaGVja19tb2RlKCkgZmFpbGVkIHdpdGggcHJlc2V0IG1vZGUuIik7 DQoJCWtnaW1fZ3JhcGhpY3NfZG9uZSgmbXlfZGlzcGxheSk7DQoJCWtnaW1f Y2xvY2tfZG9uZSgmbXlfZGlzcGxheSk7DQoJCWtnaW1fcmFtZGFjX2RvbmUo Jm15X2Rpc3BsYXkpOw0KCQlrZ2ltX21vbml0b3JfZG9uZSgmbXlfZGlzcGxh eSk7DQoJCWtnaW1fY2hpcHNldF9kb25lKCZteV9kaXNwbGF5KTsNCgkJcmV0 dXJuIC1FSU87DQoJfQ0KDQoJLyoJTm93IHNldCB0aGUgaW5pdGlhbCBkaXNw bGF5IG1vZGUgYW5kIG90aGVyIHN0YXRlLiBXZSBrbm93DQoJKioJdGhlIG1v ZGUgY2hlY2sgY2FuJ3QgZmFpbCBiZWNhdXNlIGlmIGl0IGRvZXMsIHdlIHNo b3VsZCBuZXZlcg0KCSoqCWhhdmUgZ290dGVuIGhlcmUuDQoJKi8NCgltZW1j cHkobXlfZGlzcGxheS5kZWZtb2RlLCAmY2FyZC5wcmVzZXQucmVxdWVzdCwg c2l6ZW9mKGdnaV9tb2RlKSk7DQoJbWVtY3B5KCZteV9kaXNwbGF5Lm1vZGUu cmVxdWVzdCwgbXlfZGlzcGxheS5kZWZtb2RlLCBzaXplb2YoZ2dpX21vZGUp KTsNCglrZ2ltX2NoZWNrX21vZGUoJm15X2Rpc3BsYXksICZteV9kaXNwbGF5 Lm1vZGUsIENNRF9QUk9QT1NFKTsNCglrZ2ltX2NoaXBzZXRfc2V0X21vZGUo Jm15X2Rpc3BsYXksICZteV9kaXNwbGF5Lm1vZGUpOw0KCWtnaW1fcmVzZXQo Jm15X2Rpc3BsYXkpOw0KDQoJLyoJT2suIEhhcmR3YXJlIGlzIHVwIGFuZCBy dW5uaW5nIG5vdywgc28gd2UgY2FuIHRyeSB0byByZWdpc3Rlcg0KCSoqCWl0 LiA8ZGlzcGxheT4gaG9sZHMgdGhlIGJvb3QgZGlzcGxheSB0byByZXBsYWNl IG9yIC0xIGlmIHRoZQ0KCSoqCWRpc3BsYXkgaGFzIG5vdCBiZWVuIHJlZ2lz dGVyZWQuIElmIHJlZ2lzdHJhdGlvbiBmYWlscywgd2UNCgkqKglyZXNldCB0 aGUgaGFyZHdhcmUgYW5kIHNodXRkb3duIHByb3Blcmx5Lg0KCSovDQoJaWYg KChlcnIgPSBrZ2lfcmVnaXN0ZXJfZGlzcGxheShkaXNwbGF5LCAmbXlfZGlz cGxheSkpIDwgMCkgew0KDQoJCUVSUk9SKCJmYWlsZWQgdG8gcmVnaXN0ZXIg YXMgZGlzcGxheSAlaSIsIGRpc3BsYXkpOw0KCQlrZ2ltX3Jlc2V0KCZteV9k aXNwbGF5KTsNCg0KCQlrZ2ltX2dyYXBoaWNzX2RvbmUoJm15X2Rpc3BsYXkp Ow0KCQlrZ2ltX2Nsb2NrX2RvbmUoJm15X2Rpc3BsYXkpOw0KCQlrZ2ltX3Jh bWRhY19kb25lKCZteV9kaXNwbGF5KTsNCgkJa2dpbV9tb25pdG9yX2RvbmUo Jm15X2Rpc3BsYXkpOw0KCQlrZ2ltX2NoaXBzZXRfZG9uZSgmbXlfZGlzcGxh eSk7DQoJCXJldHVybiAtRUlPOw0KCX0gZWxzZSB7DQoJCWRpc3BsYXkgPSBl cnI7DQoJfQ0KDQoJLyoJQW5kIG5vdy4uLi4gRkxZIEJBQlksIEZMWSAhDQoJ Ki8NCglERUJVRzEoIiVzICVzIGRyaXZlciBsb2FkZWQgYXMgZGlzcGxheSAl aS4iLA0KCSAgICAgICBjYXJkLm1hbnVmYWN0LCBjYXJkLm1vZGVsLCBteV9k aXNwbGF5LmlkKTsNCglyZXR1cm4gRU9LOw0KfQ0KDQp2b2lkIGNsZWFudXBf bW9kdWxlICh2b2lkKQ0Kew0KCWlmIChNT0RfSU5fVVNFKSB7DQoNCgkJREVC VUcxKCJNb2R1bGUgdXNlIGNvdW50IGlzIG5vdCAwLiIpOw0KCX0NCg0KCWtn aV91bnJlZ2lzdGVyX2Rpc3BsYXkoZGlzcGxheSk7CQ0KICAgICAgDQoJa2dp bV9yZXNldCgmbXlfZGlzcGxheSk7DQoNCglrZ2ltX2dyYXBoaWNzX2RvbmUo Jm15X2Rpc3BsYXkpOw0KCWtnaW1fY2xvY2tfZG9uZSgmbXlfZGlzcGxheSk7 DQoJa2dpbV9yYW1kYWNfZG9uZSgmbXlfZGlzcGxheSk7DQoJa2dpbV9tb25p dG9yX2RvbmUoJm15X2Rpc3BsYXkpOw0KCWtnaW1fY2hpcHNldF9kb25lKCZt eV9kaXNwbGF5KTsNCg0KCURFQlVHMSgiJXMgJXMgZHJpdmVyIHJlbW92ZWQu IiwgY2FyZC5tYW51ZmFjdCwgY2FyZC5tb2RlbCk7DQp9DQo= ---1463800064-2127642792-885602244=:449-- From evstack-request@ontv.com Fri Jan 23 17:21:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA03295 for <ggi@synergy.foo.net>; Fri, 23 Jan 1998 17:21:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA06522; Fri, 23 Jan 1998 19:46:13 -0500 Resent-Date: Fri, 23 Jan 1998 19:46:13 -0500 Date: Fri, 23 Jan 1998 17:56:35 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Trio64V+ Message-ID: <Pine.LNX.3.96.980123175515.1095A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gu1nh1.0.Gb1.rcJoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/502 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com One of the nice side-effects of the ViRGE work is that it's basically the same as Trio64V+... I have a Trio64V+ driver compiling (unaccelerated) but it errors on insert with "Device or resource busy"... ... more later... when it's finished I'll send the drivers in :) G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 24 06:12:47 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA04138 for <ggi@synergy.foo.net>; Sat, 24 Jan 1998 06:12:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id IAA12264; Sat, 24 Jan 1998 08:37:53 -0500 Resent-Date: Sat, 24 Jan 1998 08:37:53 -0500 Date: Sat, 24 Jan 1998 14:33:17 +0100 (CET) From: Emmanuel Marty <core@netnation.org> X-Sender: core@core.staff.netnation.org To: evstack@ontv.com Subject: Teunis fixes commited & sorry for being quiet Message-ID: <Pine.LNX.3.96.980124142745.2261A-100000@core.staff.netnation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lXXwx2.0.5_2.cvUoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/503 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello all, Sorry for being quiet for a couple of days, I was away in London for work thursday, and friday I spent most of the day mounting and setting up a new peecee for me.. :) I now have an AGP/USB bi-Pentium II board w/ (sigh :) one PII @ 233 mhz, 80 mb of SDRAM and all my previous boards (i.e. I still display through my PCI mystique, I'll get an AGP board when there is a decent one so that I can add tested support into GGI :) I reinstalled my system from Debian-HAMM so I run a glibc2 system aswell now. I have committed Teunis' fixes to driver/kernel/i386.c ; I was having sigbus problems with KGIM_PRIVATE access when porting the MediaGX driver wednesday, I hope it fixes them .. If yes then by monday-tuesday we'll have a fully functional GX driver under EvStack. I'll port the Matrox drivers too if noone objects. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Sat Jan 24 06:14:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA04144 for <ggi@synergy.foo.net>; Sat, 24 Jan 1998 06:14:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id IAA12334; Sat, 24 Jan 1998 08:39:51 -0500 Resent-Date: Sat, 24 Jan 1998 08:39:51 -0500 Date: Sat, 24 Jan 1998 14:35:12 +0100 (CET) From: Emmanuel Marty <core@mirus.fr> X-Sender: core@core.staff.netnation.org To: evstack@ontv.com Subject: Teunis fixes commited & sorry for being quiet (fwd) Message-ID: <Pine.LNX.3.96.980124143449.2261C-100000@core.staff.netnation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"BZGGD3.0.403.JxUoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/504 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello all, Sorry for being quiet for a couple of days, I was away in London for work thursday, and friday I spent most of the day mounting and setting up a new peecee for me.. :) I now have an AGP/USB bi-Pentium II board w/ (sigh :) one PII @ 233 mhz, 80 mb of SDRAM and all my previous boards (i.e. I still display through my PCI mystique, I'll get an AGP board when there is a decent one so that I can add tested support into GGI :) I reinstalled my system from Debian-HAMM so I run a glibc2 system aswell now. I have committed Teunis' fixes to driver/kernel/i386.c ; I was having sigbus problems with KGIM_PRIVATE access when porting the MediaGX driver wednesday, I hope it fixes them .. If yes then by monday-tuesday we'll have a fully functional GX driver under EvStack. I'll port the Matrox drivers too if noone objects. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: open real soon ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Sun Jan 25 00:23:24 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA04941 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 00:23:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id CAA20965; Sun, 25 Jan 1998 02:48:20 -0500 Resent-Date: Sun, 25 Jan 1998 02:48:20 -0500 Message-Id: <m0xwMgp-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: ConLinux and rawkeys To: evstack@ontv.com Date: Sun, 25 Jan 1998 18:41:11 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xvioG-0000XVC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 23, 98 02:06:12 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0WI782.0.975.gukoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/505 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > > Do the keys 1 2 3 4 do anything when you start the X server _without_ > > > insmodding conlinux ? [in particular: n m , .] > > > > Yet another braino. :-/ I meant running X without the conlinux stack > > attached... > > ? I.e. insmod conlinux, start X, but kill off the conlinux stack - right ? Yeah, but it's probably easier to edit conlinux.c, find the do_set_kbmode() function, and put a 'return 0' right at the beginning. This means that the xterm sends chars to the tty (no conlinux stack), so pressing '1' sends 0x49 which is the keycode for 'n'. If that works, then there's something wrong with the conlinux stack. If it doesn't and there is still no keyboard at all, well... > > When I get a chance, I'll put some debugging stuff in there, so we can > > get some idea of what's going on... or not going on... > > O.K. - I will try some strace tests ... Could you also post the GGI bits of your .config ? Maybe there's some weird interaction there... [I've already tried compiling conlinux as a module -- it still works here (unfortunately)] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 25 00:39:33 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA05029 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 00:39:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA21227; Sun, 25 Jan 1998 03:04:38 -0500 Resent-Date: Sun, 25 Jan 1998 03:04:38 -0500 Message-Id: <m0xwMwm-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Kernel selection(gpm) support. To: evstack@ontv.com Date: Sun, 25 Jan 1998 18:57:40 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <34C90C74.20A7@ggi-project.org> from "Jonas Borgström" at Jan 23, 98 10:32:36 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"M-9iS2.0.CB5.28loq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/506 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jonas Borgström writes: > The module is based on the conlinux code. I'm using: > scoll_set_cursor(CURSOR_MARK_START); > and > scroll_set_cursor(CURSOR_MARK_END); > > It works but it's flickering when you select the whole screen and then move > the mouse, it rerenders the screen after every movement. Oh.. yes :-) Since the mark cursor is just undone and redone in _kgiscroll_render() like the other cursors, it gets redrawn on every little change, including the pointer cursor... Fixing this may not be easy. But it may suffice to send the 'damaged area' (which is in c,r,cw,rw) to the kgiscroll_XXX_mark() routines and just skip the outside area. > I'll need to figure out a way to get the selection to disappear when the > screen scrolls, but I think it's not to hard to do. I'd say update the mark positions in the kgiscroll_scroll() function. E.G. when scrolling up one line, move the mark cursors up one line too, clipping them to the screen. > I can send you my code on monday(I only have internet access from the school > now). Great. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 25 03:23:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA05297 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 03:23:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA22299; Sun, 25 Jan 1998 05:48:56 -0500 Resent-Date: Sun, 25 Jan 1998 05:48:56 -0500 Message-Id: <m0xwPVj-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Kgiscroll To: evstack@ontv.com Date: Sun, 25 Jan 1998 21:41:55 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BmY5n2.0.wR5.-Xnoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/507 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi, Currently kgiscroll is capable of writing chars in any four directions, which is a Good Thing, but this complicates things like the selection cursor and the yet-to-be-implemented ring buffer. I've had this idea to treat the scroll buffer as always left to right, top to bottom, and then in _render() do a conversion to the actual drawing direction when we copy from scrollbuf -> framebuf. The drawing directions would need to be extended from 4 to 8 to specify the perpendicular direction, such as: #define KGI_SCROLL_DRAW_RIGHT_DOWN 0 #define KGI_SCROLL_DRAW_LEFT_UP 1 #define KGI_SCROLL_DRAW_DOWN_LEFT 2 #define KGI_SCROLL_DRAW_UP_RIGHT 3 #define KGI_SCROLL_DRAW_RIGHT_UP 4 #define KGI_SCROLL_DRAW_LEFT_DOWN 5 #define KGI_SCROLL_DRAW_DOWN_RIGHT 6 #define KGI_SCROLL_DRAW_UP_LEFT 7 Thus for up/down drawing directions, you automatically get scrollback going left and right. The mark cursor becomes easier to implement, as does the ring buffer, but cursor positioning becomes a bit more complicated... Comments ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Sun Jan 25 10:23:40 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA05657 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 10:23:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA25699; Sun, 25 Jan 1998 12:48:35 -0500 Resent-Date: Sun, 25 Jan 1998 12:48:35 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xwX53-0000XYC@charon.beck-sw.de> Subject: X and sorry ... To: evstack@ontv.com (Evstack Mailing List) Date: Sun, 25 Jan 1998 19:46:53 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"x0Jd43.0.zG6.4htoq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/508 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks ! First of all I'm sorry for posting that over-long strace ... I just neraly fell off my chair when I looked at the size of the file I blindly included ... Please accept my apologies ... I though It would be around 50k or something ... I just cross-checked it with regular X. But I can't find the problem ... This is really sick. Both dumps are quite identical, except that traditional X gets the mouse on FD=12 and X-on-EvStack gets it on 4, but I assume there are other changed in the kernel which caused that. ConLinux and the "normal" console send both the same chars ... weird ... CU, Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Sun Jan 25 14:29:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA05875 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 14:29:29 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA27470; Sun, 25 Jan 1998 16:53:37 -0500 Resent-Date: Sun, 25 Jan 1998 16:53:37 -0500 Date: Sun, 25 Jan 1998 15:03:38 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: that i386 update Message-ID: <Pine.LNX.3.96.980125150146.3023A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7MzvS3.0.ii6.MGxoq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/509 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com It includes a VERY tiny memory leek (as I don't free the mode local data)... Easy enough to fix but all of a sudden I'm getting oopses from the vga driver if I stick a 'kgi_free_small(mydisplay.mode.mode_data);' at the end of the free_driver... .. that and apparently the memory address is invalid. Possibly a VGA driver bug? I don't know (yet)... G'day, eh? :) - Teunis From evstack-request@ontv.com Sun Jan 25 19:48:50 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA06137 for <ggi@synergy.foo.net>; Sun, 25 Jan 1998 19:48:49 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA29908; Sun, 25 Jan 1998 22:13:41 -0500 Resent-Date: Sun, 25 Jan 1998 22:13:41 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xwdsv-0000WvC@charon.beck-sw.de> Subject: X and conlinux To: evstack@ontv.com (Evstack Mailing List) Date: Mon, 26 Jan 1998 03:02:49 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Ab3QO1.0.YI7.jx_oq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/510 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi ! Seems like the list-processor has deleted my my overly large mail regarding X and conlinux/RAWMODE. This is good, as it save you downloading that huge beast. The content boiled down to : I don't understand anything anymore now. The strace of X showed, that X _IS_ receiving RAW Key events. And the conlinux stack works properly. HOWEVER X does not work. I see it read() keystrokes form the keyboard and the codes sent are identical with what it gets under a normal kernel, but it does not seem to pass them on to the clients ... Weird !!! ??? !!! Any ideas ? -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Mon Jan 26 07:35:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA07010 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 07:35:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA03016; Mon, 26 Jan 1998 09:57:11 -0500 Resent-Date: Mon, 26 Jan 1998 09:57:11 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: X and conlinux Date: 26 Jan 1998 14:53:39 GMT Organization: OnTV Pittsburgh, L.P. Lines: 12 Distribution: local Message-ID: <6ai81j$ol9$1@grits.visus.com> References: <6ah6rg$ted$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"ypaR.0.3k.JDApq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/511 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > Seems like the list-processor has deleted my my overly large mail regarding > X and conlinux/RAWMODE. Well, it put it in MY mailbox - I am the list admin... No worries, we've got a big mail-spool here. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Mon Jan 26 12:24:42 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA07344 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 12:24:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA05644; Mon, 26 Jan 1998 14:46:56 -0500 Resent-Date: Mon, 26 Jan 1998 14:46:56 -0500 Date: Mon, 26 Jan 1998 12:51:36 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: andreas.beck@ggi-project.org cc: Evstack Mailing List <evstack@ontv.com> Subject: Re: X and conlinux In-Reply-To: <m0xwdsv-0000WvC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980126125025.324B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"QlPz7.0.qM1.EREpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/512 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Mon, 26 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > Hi ! > > Seems like the list-processor has deleted my my overly large mail regarding > X and conlinux/RAWMODE. > > This is good, as it save you downloading that huge beast. > > The content boiled down to : > > I don't understand anything anymore now. The strace of X showed, that > X _IS_ receiving RAW Key events. And the conlinux stack works properly. > > HOWEVER X does not work. > > I see it read() keystrokes form the keyboard and the codes sent are identical > with what it gets under a normal kernel, but it does not seem to pass them on > to the clients ... Weird !!! ??? !!! > > Any ideas ? Just FWIW - beyond constantly requiring me to make new consoles (/dev/tty13 et al) X works perfectly for me :) Even mouse unless I install mouse driver - I really must finish that translation module *grin*... (though that console problem is irritating *sigh*) G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 26 16:53:52 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA07762 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 16:53:51 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA08066; Mon, 26 Jan 1998 19:17:34 -0500 Resent-Date: Mon, 26 Jan 1998 19:17:34 -0500 Date: Mon, 26 Jan 1998 17:27:29 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: mice... *grr* Message-ID: <Pine.LNX.3.96.980126172558.530A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Mnw9L1.0.Yz1.WTIpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/513 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Is there any way to unbind a mouse-stack? It is most frustrating to work with when not setup as the right kind of mouse *sigh*.... (that and mouseman mice need proper reset capability... is there a reset command? Otherwise the mouse becomes wedged if you, say, unplug it from the serial port...) G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 26 17:05:31 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA07790 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 17:05:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA08219; Mon, 26 Jan 1998 19:30:13 -0500 Resent-Date: Mon, 26 Jan 1998 19:30:13 -0500 Message-Id: <m0xwykp-00017OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: mice... *grr* To: evstack@ontv.com Date: Tue, 27 Jan 1998 11:19:51 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980126172558.530A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 26, 98 05:27:29 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kb6XE3.0.s_1.RfIpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/514 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > Is there any way to unbind a mouse-stack? Just kill the setmouse program, as in "killall setmouse". > It is most frustrating to work with when not setup as the right kind of > mouse *sigh*.... (that and mouseman mice need proper reset capability... > is there a reset command? Otherwise the mouse becomes wedged if you, > say, unplug it from the serial port...) Does the mouseman driver in serialmouse.c actually work ? and all three buttons ? I rewrote it, but couldn't test it... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Mon Jan 26 17:48:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA07837 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 17:48:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA08724; Mon, 26 Jan 1998 20:12:57 -0500 Resent-Date: Mon, 26 Jan 1998 20:12:57 -0500 Date: Mon, 26 Jan 1998 18:22:59 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: mice... *grr* In-Reply-To: <m0xwykp-00017OC@ajax> Message-ID: <Pine.LNX.3.96.980126181734.854A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"dR-0M.0.l72.OHJpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/515 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Tue, 27 Jan 1998, Andrew Apted wrote: > teunis writes: > > > Is there any way to unbind a mouse-stack? > > Just kill the setmouse program, as in "killall setmouse". Ahh... Okay - stick this in the docs SVP? :) > > It is most frustrating to work with when not setup as the right kind of > > mouse *sigh*.... (that and mouseman mice need proper reset capability... > > is there a reset command? Otherwise the mouse becomes wedged if you, > > say, unplug it from the serial port...) > > Does the mouseman driver in serialmouse.c actually work ? and all > three buttons ? I rewrote it, but couldn't test it... Tiny little square in one corner with mc -x... Mind you, microsoft protocol does that too... Don't know if all three buttons work yet.... but they seem to. Cool, eh? :) How would I test? (or look for source to build a test? :) [yes - I'm not up to RTFS today... it's big and hard to read.. 'sides, I'm busy working through the Mesa sources at the moment :] G'day, eh? :) - Teunis From evstack-request@ontv.com Mon Jan 26 19:48:24 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA07898 for <ggi@synergy.foo.net>; Mon, 26 Jan 1998 19:48:22 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA09658; Mon, 26 Jan 1998 22:12:24 -0500 Resent-Date: Mon, 26 Jan 1998 22:12:24 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xx024-0000WvC@charon.beck-sw.de> Subject: Re: mice... *grr* To: evstack@ontv.com Date: Tue, 27 Jan 1998 02:41:44 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980126172558.530A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 26, 98 05:27:29 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"boZxC.0.OM2.c1Lpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/516 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Is there any way to unbind a mouse-stack? >From what you write on, I assume it is busy ... ;-) > It is most frustrating to work with when not setup as the right kind of > mouse *sigh*.... (that and mouseman mice need proper reset capability... > is there a reset command? Otherwise the mouse becomes wedged if you, > say, unplug it from the serial port...) You should be simply able to kill the setmouse "daemon" and start it again. CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Tue Jan 27 02:39:28 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id CAA08462 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 02:39:27 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id FAA13308; Tue, 27 Jan 1998 05:04:09 -0500 Resent-Date: Tue, 27 Jan 1998 05:04:09 -0500 Message-Id: <m0xx7h9-00012OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: X and conlinux To: evstack@ontv.com Date: Tue, 27 Jan 1998 20:52:39 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xwdsv-0000WvC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 26, 98 03:02:49 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uKg8d.0.PF3.83Rpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/517 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > The content boiled down to : > > I don't understand anything anymore now. The strace of X showed, that > X _IS_ receiving RAW Key events. And the conlinux stack works properly. > > HOWEVER X does not work. > > I see it read() keystrokes form the keyboard and the codes sent are identical > with what it gets under a normal kernel, but it does not seem to pass them on > to the clients ... Weird !!! ??? !!! Yes, very strange... > Any ideas ? Only one. I've noticed that my X reads the kernel keymapping using the linux KDGKBENT ioctl. This isn't implemented in conlinux, it just returns -EINVAL, and seems to have no effect on my X, but maybe it messes up your X ?? The easiest way to test this is to just disable it in the normal kernel source (drivers/char/vt.c) ... [the harder way is to actually implement the ioctl in conlinux.c -- ouch!] Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Tue Jan 27 03:49:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA08571 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 03:49:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA13685; Tue, 27 Jan 1998 06:13:50 -0500 Resent-Date: Tue, 27 Jan 1998 06:13:50 -0500 Message-ID: <34CE3E66.54F2@ggi-project.org> Date: Tue, 27 Jan 1998 21:07:02 +0100 From: Jonas Borgström <jonas@ggi-project.org> X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: mice... *grr* References: <Pine.LNX.3.96.980126181734.854A-100000@sigil.computersupportcentre.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"NPZ3I1.0.BL3.92Spq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/518 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis wrote: > Tiny little square in one corner with mc -x... Mind you, microsoft > protocol does that too...I had the same problem with my ps2 mouse, but try to start mc -x in another vc, then it worked for me, strange! -- ___________________________________________________ ///////////////// Jonas Borgström \\\\\\\\\\\\\\\\\ |----------- E-Mail: jonas@ggi-project.org ----------| |--- The GGI Project: http://www.ggi-project.org ----| \___________________________________________________/ From evstack-request@ontv.com Tue Jan 27 05:06:54 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA08651 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 05:06:53 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA14264; Tue, 27 Jan 1998 07:31:35 -0500 Resent-Date: Tue, 27 Jan 1998 07:31:35 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxARk-0000WvC@charon.beck-sw.de> Subject: Re: X and conlinux To: evstack@ontv.com Date: Tue, 27 Jan 1998 13:48:56 +0100 (MET) In-Reply-To: <m0xx7h9-00012OC@ajax> from "Andrew Apted" at Jan 27, 98 08:52:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"_QmLo.0.xT3.FDTpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/520 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Any ideas ? > > Only one. I've noticed that my X reads the kernel keymapping using the > linux KDGKBENT ioctl. This isn't implemented in conlinux, it just > returns -EINVAL, and seems to have no effect on my X, but maybe it > messes up your X ?? That could be it ... Yeah ! Most common installations do not make use of that feature, but overload the mapping table anyway ... IIRC I did not do this, because the normal system works like a charm ... ouch. Will try. > The easiest way to test this is to just disable it in the normal kernel > source (drivers/char/vt.c) ... > [the harder way is to actually implement the ioctl in conlinux.c -- ouch!] I'll try the "mediumhard" way of getting XFree to read a keymapping table. If it proves to be it, we'll probably have to implement it ... well -we should do so anyway ... THANKS FOR THAT HINT ! CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Tue Jan 27 05:07:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA08655 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 05:07:31 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA14275; Tue, 27 Jan 1998 07:31:49 -0500 Resent-Date: Tue, 27 Jan 1998 07:31:49 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxB3U-0000WvC@charon.beck-sw.de> Subject: X PROBLEM SOLVED ! [hey Macarena ...] To: evstack@ontv.com (Evstack Mailing List) Date: Tue, 27 Jan 1998 14:27:56 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"qC9Z9.0.gT3.BDTpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/519 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com ANDREW ! THANKS ! I have Xfree running fine now ... your idea hit the nail on the head as we say here ... My X starting scripts do not call Xmodmap in any way, because X normally reads the mappings from kernel just fine. I have now manually called Xmodmap under EvStack kernel and it worked ! Modifiers were dead, but I suppose this is due to a wrong modmap. I'll simply dump one from the normal kernel. Hope this fixes that last glitch. /ME is jumping around in joy again ... Cu, Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Tue Jan 27 10:51:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA09117 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 10:51:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA17815; Tue, 27 Jan 1998 13:15:29 -0500 Resent-Date: Tue, 27 Jan 1998 13:15:29 -0500 Date: Tue, 27 Jan 1998 11:23:54 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: mice again... about that mouse cursor Message-ID: <Pine.LNX.3.96.980127112100.5750C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"eLvZX1.0.bL4.NEYpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/521 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Okay - figured out why the mouse is trapped in a little box in the upperleft corner of the screen (sorta)... It's _ONLY_ the mouse cursor behaving this way (mc -x); mc behaves as if the mouse were all over the screen as normal.... I don't know how to test the mouse buttons (yet) because I don't know how mc is supposed to behave... but so far so good :) How does "setmouse" work anyways? It's not intuitively obvious to me from the source... (and what does it do?) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 27 16:00:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA09393 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 16:00:34 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA20985; Tue, 27 Jan 1998 18:24:41 -0500 Resent-Date: Tue, 27 Jan 1998 18:24:41 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxKf9-0000WvC@charon.beck-sw.de> Subject: Re: mice again... about that mouse cursor To: evstack@ontv.com Date: Wed, 28 Jan 1998 00:43:26 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980127112100.5750C-100000@sigil.computersupportcentre.com> from "teunis" at Jan 27, 98 11:23:54 am Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"xPcOV2.0.675.Amcpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/522 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > How does "setmouse" work anyways? It's not intuitively obvious to me from > the source... (and what does it do?) It opens the device you give to it, sets the moden attributes like speed, RTC/CTS, number of bits, start/stopbits, ... and then it changes the "line-discipline". This line-discipline is some kind of "behaviour" for a port. It is used to have network drivers on a port normally (SLIP etc.). The normal line discipline is being a terminal, but others can be set. We register a mouse discipline in the nmouse module (right ? guessing here ...) and select it in the setmouse utility. When the setmouse utility is killed, it frees the line again. CU,ANdy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Tue Jan 27 17:19:35 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA09502 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 17:19:34 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA21671; Tue, 27 Jan 1998 19:43:18 -0500 Resent-Date: Tue, 27 Jan 1998 19:43:18 -0500 Date: Tue, 27 Jan 1998 17:53:04 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: andreas.beck@ggi-project.org cc: evstack@ontv.com Subject: Re: mice again... about that mouse cursor In-Reply-To: <m0xxKf9-0000WvC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980127175122.6985A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"YdtNQ1.0.4I5.Lxdpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/523 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 28 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > How does "setmouse" work anyways? It's not intuitively obvious to me from > > the source... (and what does it do?) > [clip] > The normal line discipline is being a terminal, but others can be set. > We register a mouse discipline in the nmouse module (right ? guessing here > ...) and select it in the setmouse utility. When the setmouse utility > is killed, it frees the line again. So - does this transform /dev/cua1 (as an example) to a mouse interface? Or an evstack-addition? (and where?) Or a new device? Or console gets new events (mouse ones)? (X style I guess... Though I don't know how this one would work and if this is how it works _PLEASE_ explain! :) G'day, eh? :) - Teunis From evstack-request@ontv.com Tue Jan 27 20:45:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA09726 for <ggi@synergy.foo.net>; Tue, 27 Jan 1998 20:45:54 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA23534; Tue, 27 Jan 1998 23:10:10 -0500 Resent-Date: Tue, 27 Jan 1998 23:10:10 -0500 Message-Id: <m0xxOf4-00012RC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: mice again... about that mouse cursor To: evstack@ontv.com Date: Wed, 28 Jan 1998 14:59:38 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980127175122.6985A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 27, 98 05:53:04 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"g87S92.0.0l5.nzgpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/524 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis writes: > So - does this transform /dev/cua1 (as an example) to a mouse interface? Yes, it causes the N_MOUSE line discipline to be responsible for the handling of incoming bytes from the serial driver. Under EvStack the N_MOUSE handling code is in 'drivers/console/nmouse.c'. This is a manager for serial protocols, like mouseman or spaceorb. All it really does is just pass on the mouse packets to registered parser functions. It is setmouse that tells the nmouse manager which parser to send the raw data from a serial port to. The serialmouse code registers a parser function for each type of mouse (mousesys, mouseman, ...). These parser functions then convert raw mouse packets into GGI mouse events and send them to the input_stack [i.e. the same place that the keyboard sends GGI key events to]. Now the xterm code gets the mouse events and converts them into xterm-ish escape codes (e.g. for midnight commander). And when the devevent code is fully operational, it will grab the mouse events and send them to libGGI, which will send them to the application. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 28 03:51:19 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA10177 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 03:51:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA27724; Wed, 28 Jan 1998 06:14:06 -0500 Resent-Date: Wed, 28 Jan 1998 06:14:06 -0500 Sender: core@tron.mirus.fr Message-ID: <34CF0F9D.98057426@mirus.fr> Date: Wed, 28 Jan 1998 11:59:41 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: KGIM_PRIVATE fixed ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7MLsI.0.cm6.cAnpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/525 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello all, I have just commited changes that fix the problems Teunis mentioned with KGIM_PRIVATE (i.e. the mode_data pointer becoming NULL magically sometimes). In driver/kernel/linux/i386.c, kgim_check_mode() does : if (cmd == CMD_PROPOSE) { memset(&(mode->request) + 1, 0, sizeof(*mode) - sizeof(mode->request)); This dangerous memset clears the whole mode structure besides the request data, so the *mode_data goes NULL aswell. I have replaced it by the longer and safer : memset(&mode->tm, 0, sizeof (struct kgi_tm)); memset(&mode->fb, 0, sizeof (struct kgi_fb)); mode->textop = NULL; mode->mmio = NULL; mode->accel = NULL; Other changes : I declared kgi_tm and kgi_fb as public structures from the kgi_mode structure (recommited kgi.h) so that they can be used here, and in chipset drivers too (when memcpying the default mode into the display and card, in order to avoid the same problem with killing fields in the mode structure you aren't supposed to touch) I fixed the KGIM_PRIVATE macro in module.h as Jason mentioned - the change hadn't been done, so I did it. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Wed Jan 28 03:55:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA10181 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 03:55:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA27798; Wed, 28 Jan 1998 06:19:52 -0500 Resent-Date: Wed, 28 Jan 1998 06:19:52 -0500 Sender: core@tron.mirus.fr Message-ID: <34CF117A.E35CF58B@mirus.fr> Date: Wed, 28 Jan 1998 12:07:38 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: pll.inc and ICS ramdac driver ported Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GnSBH1.0.on6.bGnpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/526 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com As part of the porting work of the MediaGX driver to EvStack, I have ported pll.inc (the base of most clock/prog drivers, allows most of them to compile now) and the ICS ramdac drivers (ramdac/ICS) to EvStack. They have been tested to run successfully on the new kernel. This should remove most clock-driver porting work, and ease porting the ET4000 drivers, since they use the ICS ramdac. Hopefully, if I don't have to fight more bugs related to KGIM_PRIVATE stuff, I should be able to produce a paper about how to port drivers, sometime soon - stay tuned. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Wed Jan 28 04:04:48 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA10201 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 04:04:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA27893; Wed, 28 Jan 1998 06:29:13 -0500 Resent-Date: Wed, 28 Jan 1998 06:29:13 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxWaF-0000WvC@charon.beck-sw.de> Subject: Re: mice again... about that mouse cursor To: evstack@ontv.com Date: Wed, 28 Jan 1998 13:27:10 +0100 (MET) In-Reply-To: <Pine.LNX.3.96.980127175122.6985A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 27, 98 05:53:04 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"IMZjt.0.Hp6.1Pnpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/527 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > The normal line discipline is being a terminal, but others can be set. > > We register a mouse discipline in the nmouse module (right ? guessing here > > ...) and select it in the setmouse utility. When the setmouse utility > > is killed, it frees the line again. > > So - does this transform /dev/cua1 (as an example) to a mouse interface? > Or an evstack-addition? (and where?) Both. /dev/cua1 is still there, but it has some kind of "terminal emulation", i.e. the nmouse code or "mouse" line discipline attached. this makes it not spit out characters anymore, but forward them to the line-discipline handlers. These handlers forward the chars to the mouse parsers (serialmouse or spaceorb) which in turn have generated an input EvStack to which they send their interpreted results. > Or console gets new events (mouse ones)? Well - the Console stack code gets new events. As the default console is xterm, it can make these events visible as Xterm-mouse sequences. I suppose what you want to do is having an "emulated" mouse on some file to be able to do the GPM-trick of always having a mousesystems mouse on some pipe - right ? For this you should try to get /dev/event working (shouldn't be hard - maybe I try later today) and attach such a device to the input stack. You will then be forwarded selected events (which ones are controlled by an ioctl, please look at the devevent source for details). You select the mouse-type events and the build up mousesystems packets from them. CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Wed Jan 28 06:54:47 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA10346 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 06:54:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA29167; Wed, 28 Jan 1998 09:19:07 -0500 Resent-Date: Wed, 28 Jan 1998 09:19:07 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxYaM-0000WvC@charon.beck-sw.de> Subject: /dev/event _is_ working ... To: evstack@ontv.com (Evstack Mailing List) Date: Wed, 28 Jan 1998 15:35:25 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"VdLyz1.0.t67.-tppq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/528 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks ! As Teunis wants to write a GPM-like mouse-emulator on a pipe, I thought I'd check /dev/event code. It works just fine. I have added ioctl facility to allow for selecting the eventmasks so you can select which events you want to hear. Moreover I added some demo code in the utility directory. They way to get this working is : insmod devevent.o echo create >/proc/sys/evstack/class/devevent ll /proc/sys/evstack/stack [find out the name of the created stack] echo + [deveventstack] >some-termstack from then on, you can start the deveventdump program as deveventdump </dev/event0 (the minor is announced on stack creation). It should be fairly trivial to derive a "mouse-simulator" from the deveventdump source and GPM sources. You simply receive mouse events, convert them back to some serial mouse protocol and stuff it to a pipe. CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Wed Jan 28 07:15:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA10377 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 07:15:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA29384; Wed, 28 Jan 1998 09:38:56 -0500 Resent-Date: Wed, 28 Jan 1998 09:38:56 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: pll.inc and ICS ramdac driver ported Date: 28 Jan 1998 14:37:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 31 Distribution: local Message-ID: <6anfs3$shj$1@grits.visus.com> References: <6an4ig$jvn$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"hphXr1.0.NA7.WAqpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/529 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > As part of the porting work of the MediaGX driver to EvStack, > I have ported pll.inc (the base of most clock/prog drivers, > allows most of them to compile now) and the ICS ramdac drivers > (ramdac/ICS) to EvStack. They have been tested to run > successfully on the new kernel. This should remove most > clock-driver porting work, and ease porting the ET4000 drivers, > since they use the ICS ramdac. > Hopefully, if I don't have to fight more bugs related to KGIM_PRIVATE > stuff, I should be able to produce a paper about how to port drivers, > sometime soon - stay tuned. Although most of my new changes (which I hope to haev working & committed by this weekend) don't affect driver writers (ie, a couple of changes to kgi_display to clean it up - all the changes of which reside in kernel/linux/i386.c), one thing that does change is that *_set_mode() now returns an error code. That way, if some state changes between the kernel checking the mode and setting the mode, it can be notified. Like, for instance, your mode check is buggy and generated a mode that can't be set.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 28 10:10:45 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA10594 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 10:10:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA31287; Wed, 28 Jan 1998 12:34:47 -0500 Resent-Date: Wed, 28 Jan 1998 12:34:47 -0500 Date: Wed, 28 Jan 1998 12:36:47 -0500 (EST) From: David Waite <davewait@freenet.tlh.fl.us> To: evstack@ontv.com Subject: Re: pll.inc and ICS ramdac driver ported In-Reply-To: <6anfs3$shj$1@grits.visus.com> Message-ID: <Pine.OSF.3.96.980128123014.17863C-100000@fn3.freenet.tlh.fl.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"AGrgI1.0.yd7._kspq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/530 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Although most of my new changes (which I hope to haev working > & committed by this weekend) don't affect driver writers > (ie, a couple of changes to kgi_display to clean it up - > all the changes of which reside in kernel/linux/i386.c), > one thing that does change is that *_set_mode() now > returns an error code. > > That way, if some state changes between the kernel checking > the mode and setting the mode, it can be notified. Like, > for instance, your mode check is buggy and generated a mode > that can't be set.... I may be translating my ramdac/clock driver (which doesn't use the pll.* files) and the S3 964/968 drivers soon. I was surprised last night to find a very large envelope with a dew databooks in it on my doorstep last night- and S3 never even wrote me back saying they would send them ;) Does the graphics function that sets the modes cache the current mode? Hopefully nobody retains mode information in say, a private memory location, would it be possible just to cache all the data of the current mode and perhaps the last 8 used? This'd make mode switching through terminals and in graphics programs very fast.. Do people still want me to work on writing documentation on changes needed for EvStack? Now that I have every databook on my card (*grin*) I guess I can figure out the changes from the ground up.. but if someone else is already working on such a document, I can just work on editing/refining it and work on documenting other features. One thing I figured out about GGI recently is that it is in *desperate* need of documentation and of advertising. It is getting to be a very very cool project, but outsiders still don't know much about it, many think it is only kernel-level stuff. We need some writers and some advertising folk in here ;) -David Waite From evstack-request@ontv.com Wed Jan 28 10:48:32 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA10682 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 10:48:30 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA31800; Wed, 28 Jan 1998 13:10:17 -0500 Resent-Date: Wed, 28 Jan 1998 13:10:17 -0500 Sender: core@tron.mirus.fr Message-ID: <34CF7131.8C92EEB0@mirus.fr> Date: Wed, 28 Jan 1998 18:56:01 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Modification in driver API ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ZAy_z1.0.tl7.jFtpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/531 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hello, moving the chipset private data from display to mode would, I think, require that chipset register access functions (DAC_out8, etc) are given a pointer to the mode rather than the display. if it doesn't matter for VGA which doesn't make use of it at all, it does matter for other driver such as mediaGX caching register mmio pointers there, for example. i did all the necessary changes in the includes, then all necessary drivers for compiling VGA and mediaGX and it still works fine.. with those changes i can go further with the porting. should i commit them, or is someone against the change (requires more porting work, but i think it's necessary.. if it isn't, then it isn't logical and private data should stay in the kgi_display) please everyone comment this. should i commit the changes? ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Wed Jan 28 12:35:30 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA10866 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 12:35:28 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA00133; Wed, 28 Jan 1998 14:59:42 -0500 Resent-Date: Wed, 28 Jan 1998 14:59:42 -0500 Sender: torgeir@salsa.visus.com Message-ID: <34CF9B28.3DAE900C@vertech.no> Date: Wed, 28 Jan 1998 20:55:04 +0000 From: Torgeir Veimo <torgeir.veimo@vertech.no> Organization: Vertech AS X-Mailer: Mozilla 4.04j2 [en] (X11; I; Linux 2.0.31 i686) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: pll.inc and ICS ramdac driver ported References: <Pine.OSF.3.96.980128123014.17863C-100000@fn3.freenet.tlh.fl.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KENi91.0.L1.Ssupq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/532 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com David Waite wrote: > > Do people still want me to work on writing documentation on changes needed > for EvStack? YES! It is allways better to have too much documentation that too little... -- Torgeir Veimo, Vertech AS, email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755 From evstack-request@ontv.com Wed Jan 28 13:58:10 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id NAA11101 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 13:58:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA01064; Wed, 28 Jan 1998 16:22:18 -0500 Resent-Date: Wed, 28 Jan 1998 16:22:18 -0500 Date: Wed, 28 Jan 1998 14:31:19 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Emmanuel Marty <core@mirus.fr> cc: evstack@ontv.com Subject: Re: Modification in driver API ? In-Reply-To: <34CF7131.8C92EEB0@mirus.fr> Message-ID: <Pine.LNX.3.96.980128142911.8253A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"tj1Sd3.0.mF.74wpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/533 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 28 Jan 1998, Emmanuel Marty wrote: > Hello, > > moving the chipset private data from display to mode would, I think, > require that chipset register access functions (DAC_out8, etc) are > given a pointer to the mode rather than the display. if it doesn't > matter for VGA which doesn't make use of it at all, it does matter > for other driver such as mediaGX caching register mmio pointers > there, for example. i did all the necessary changes in the includes, > then all necessary drivers for compiling VGA and mediaGX and it > still works fine.. with those changes i can go further with the > porting. should i commit them, or is someone against the change > (requires more porting work, but i think it's necessary.. if it > isn't, then it isn't logical and private data should stay in > the kgi_display) > > please everyone comment this. should i commit the changes? hmmmm... ... thinking... IMHO - no, the display structure is appropriate for I/O and memory mapping... though perhaps a "local" block in the mode structure could be helpful. Private mode-related display info should be in kgi_mode.. private card-related info should be in... kgi_card? Hmm.... Maybe go ahead and stick it into mode. I can't think of any other logical way of doing it. And there should be _SOME_ private data in kgi_mode.... G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 28 14:00:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA11110 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 14:00:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id QAA01144; Wed, 28 Jan 1998 16:24:50 -0500 Resent-Date: Wed, 28 Jan 1998 16:24:50 -0500 Date: Wed, 28 Jan 1998 14:34:39 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: andreas.beck@ggi-project.org cc: Evstack Mailing List <evstack@ontv.com> Subject: Re: /dev/event _is_ working ... In-Reply-To: <m0xxYaM-0000WvC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980128143342.8253B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4HJxI1.0.9H.D7wpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/534 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 28 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > Hi folks ! > > As Teunis wants to write a GPM-like mouse-emulator on a pipe, I > thought I'd check /dev/event code. Hai! :) Okay - checking this afternoon. If all goes well, I'll post a simple gpm-replacement (sorta) later today or tomorrow (or the day after if things stay really busy)... Thanks and G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 28 15:06:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA11210 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 15:06:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA01881; Wed, 28 Jan 1998 17:28:48 -0500 Resent-Date: Wed, 28 Jan 1998 17:28:48 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: pll.inc and ICS ramdac driver ported Date: 28 Jan 1998 22:27:59 GMT Organization: OnTV Pittsburgh, L.P. Lines: 30 Distribution: local Message-ID: <6aobdf$ino$1@grits.visus.com> References: <6anqhk$5nq$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"NDSRZ.0.pS.A3xpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/535 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com David Waite (davewait@freenet.tlh.fl.us) wrote: > Does the graphics function that sets the modes cache the current mode? > Hopefully nobody retains mode information in say, a private memory > location, would it be possible just to cache all the data of the current > mode and perhaps the last 8 used? This'd make mode switching through > terminals and in graphics programs very fast.. See my post to Emmanuel about this self-same topic. What it boils down to is that in my latest foray into /dev/graph, I've come up with a solution that allows one to: a) `Lock down' a display driver b) check_mode a bunch of modes to use on that display c) and set_mode with confidence. d) When you're done, unlock the driver. This also solves the problem with not being able to keep track of MMAP regions between driver remove-add cycles. Looks like I'll be going back to Andreas' model for /dev/graph (SIGWINCH et al.), since the features that I needed to add to the VT-locked version facilitated the easy construction of Andreas' version... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Wed Jan 28 15:21:16 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA11237 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 15:21:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA02029; Wed, 28 Jan 1998 17:45:22 -0500 Resent-Date: Wed, 28 Jan 1998 17:45:22 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxgDr-0000XYC@charon.beck-sw.de> Subject: Re: Boot problem ... To: evstack@ontv.com (Evstack Mailing List) Date: Wed, 28 Jan 1998 23:44:43 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"oRRh42.0.4V.1Jxpq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/536 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > From: Marcus Sundberg <e94_msu@elixir.e.kth.se> > > > > BTW I tried EvStack on 2.1.78 yesterday, but the kernel would just hang > > > while booting. Could you please mail me the kernel .config you used to > > > get EvStack working? > > > > Where did it hang ? You did enable the keymapper module, did you ? > > I found the problem after another test, You see, I've got this nasty > habit of compiling in stuff in the kernel that I actually don't > need... :) And it seems that the MDA/Hercules driver gets very upset > when it can't find any card, this is the output I got when booting > with MDA enabled: > > kgi_arch_init: 1 displays detected > Can't bind to VT 0x10 > Unable to handle kernel paging request > > and then it prints the register stuff and stops. > > After removing MDA/Hercules support the kernel booted just fine. Ouch ... Anyone knows how to fix that easily. A default kernel _should_ be configured with both drivers and work on single-headed systems as well as on headless ones, too ... CU,ANdy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Wed Jan 28 16:58:41 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA11373 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 16:58:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA02919; Wed, 28 Jan 1998 19:22:34 -0500 Resent-Date: Wed, 28 Jan 1998 19:22:34 -0500 Message-ID: <19980128182112.19082@3e8.com> Date: Wed, 28 Jan 1998 18:21:12 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Compile errors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Deities: e38 Resent-Message-ID: <"Vooqm3.0.yi.Xjypq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/537 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com OK, since I can't figure out what's going on, I'm going to ask some stupid questions now. Is libggi supposed to work with EvStack right now? The CVS snapshot I got today failed libggi compilation with several errors: (a) line 121, libggi_db.h -- type 'uintl' is used. uintl is not defined in system.h, although it is in my EvStackless GGI tree. (b) ggi_gc, ggi_visual, and probably others are missing from ggi.h. (c) Others, and I gave up. So, if libggi doesn't work, how is everybody running test programs like demo to make sure the drivers work? I would really appreciate any response so I can port my driver while I have time, before I get swamped with work... -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 17:39:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA11433 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 17:39:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA03335; Wed, 28 Jan 1998 20:03:57 -0500 Resent-Date: Wed, 28 Jan 1998 20:03:57 -0500 Message-ID: <19980128190257.54809@3e8.com> Date: Wed, 28 Jan 1998 19:02:57 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: More comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Deities: e38 Resent-Message-ID: <"pwkw22.0.Sp.oKzpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/538 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com These are just comments from a first-time user. - After ggidrv.o is inserted, the VGA hardware cursor appears on screen in an incorrect place. It appears to the left of the input point, and its distance away from the input point increases as the cursor moves to the left of the screen. (I had to rmmod ggidrv to type this reasonably fast.) - EvTest utilities fail to compile. An error to do with 'fmt' keeps popping up, which has to do with the NOTICE macros, so I commented them out. kgi.o gives a fatal error because it can't find vcs_init(), so I gave up. - libggi doesn't compile, but I already said that. - My kernel messages are all appearing on VT 1 instead of VT 10, and scrollback doesn't work, but I'm sure that's a known issue. - Basically the only thing that works is module insertion/removal, which is nice, but I can't do much with the module in plain old text mode. As it is, I can't do any kind of a driver port until someone tells me how to switch video modes, test evstack, and so on. ~ jim -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 17:46:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA11469 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 17:46:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA03434; Wed, 28 Jan 1998 20:09:56 -0500 Resent-Date: Wed, 28 Jan 1998 20:09:56 -0500 Message-ID: <19980128190910.54755@3e8.com> Date: Wed, 28 Jan 1998 19:09:10 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Mouse in mc -x Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 X-Deities: e38 Resent-Message-ID: <"yAfr63.0.yq.SQzpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/539 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Well, the mouse works, but it causes massive screen corruption when moved. Is there any way to get it to work under X? /dev/mouse is inactive until I insmod ps2aux, and thereafter it's busy. If the mouse works with the standard /dev/mouse interface, then I have no problem with using the evstack kernel all the time, especially with this nice-looking orange cursor (not as good as my red one, though :) -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 18:03:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA11490 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 18:03:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA03615; Wed, 28 Jan 1998 20:27:31 -0500 Resent-Date: Wed, 28 Jan 1998 20:27:31 -0500 Date: Wed, 28 Jan 1998 18:37:06 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Here's a dump of a demo crash... Message-ID: <Pine.LNX.3.96.980128183347.849C-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-1836603450-886037826=:849" Resent-Message-ID: <"P7hBs2.0.jt.tgzpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/540 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-1836603450-886037826=:849 Content-Type: TEXT/PLAIN; charset=US-ASCII How did I get this? demo 8 320 200 What does it do? Switch to console 1 (regardless of where it starts) then complain.... Fails to set mode FWIW... Though that can probably be gotten from the logs. This is with VGA driver fwiw... the patched ViRGE I've been working on is a great way to crash yer computer (and lose files *sigh*).... Also wedges the display first so I suspect it's actually a prob in the setup code... Have to check more later. G'day, eh? :) - Teunis Oh - I'll try again after rebuilding a newer kernel.... ---1463800064-1836603450-886037826=:849 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="decode.dump" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980128183706.849D@sigil.computersupportcentre.com> Content-Description: VGhlIGR1bXAgaXMgaW50ZXJtaXhlZCB3aXRoIGRtZXNnIG91dHB1dC4uLi4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCiAwMDAwMDAxOSAwMDAwMDAwMSBjMjBhNWMwZSAwMDAwMDAwMCAwMDAw MDAwMSAwMDAwMDAwMCANCiAgICAgICBjMDA4NDAwMCBjMDMzNWEyMCBjMjBh NWNhMCBjMWZkMjcyMCAwMDAwMDAwMCAwMDAwMDA0YSAwMDAwMDAwMSBjMDQx MDY2MCANCiAgICAgICAwMDAwMDA0ZiAwMDRhNWM2MCBjMDFkOTkyZCBjMWZk MjcyMCBjMDA4NDAwMCBjMjBhNWNhMCBjMDA4NDAxNiAwMDAwMDA1MCANCkNh bGwgVHJhY2U6IFs8YzAxZDg4ZmY+XSBbPGMwMWQ5OTJkPl0gWzxjMDFjZjdi ZT5dIFs8YzAxZDUxY2U+XSBbPGMwMWNmN2JlPl0gWzxjMDFkMDY0Yj5dIFs8 YzAxZThhZGI+XSANCiAgICAgICBbPGMwMWM3Nzk0Pl0gWzxjMDEwOTUwNz5d IFs8YzAxMDk1MzU+XSBbPGMwMTA5NWYzPl0gWzxjMDEwOTY2Mz5dIFs8YzAx ZDA2YmE+XSBbPGMwMWM0MjgyPl0gWzxjMDFjNWM4MD5dIA0KICAgICAgIFs8 YzAxYzIxMjE+XSBbPGMwMWM1YjcwPl0gWzxjMDEyMzFmMD5dIFs8YzAxMDlj Y2E+XSANCkNvZGU6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDgwIDFiIDAw IDAwIDAwIDAwIDAwIDAwIDAzIDAwIDAwIDAwIA0KMDAwMTBiMjc6ZGV2Z3Jh cGguYzoxMTM4OiBMb2FkZWQgL2Rldi9ncmFwaCBzdXBwb3J0DQowMDAxMGIy ODpkZXZncmFwaC5jOjU0OTogZ3JhcGhfb3BlbiAoY29uaWQgPSAweDAwKQ0K MDAwMTBiMjg6ZGV2Z3JhcGguYzo1NTg6IGFsbG9jYXRpbmcgL2Rldi9ncmFw aDAwIC4uLiANCjAwMDEwYjI4OmRldmdyYXBoLmM6NTcxOiBvcGVuIG9uIC9k ZXYvZ3JhcGgwMA0KMDAwMTBiMjk6ZGV2Z3JhcGguYzo3NTk6IGdyYXBoX2lv Y3RsOiBkcml2ZXIgY29tbWFuZCBjMDE4MDAxMg0KMDAwMTBiMjk6ZGV2Z3Jh cGguYzo2NzU6IGFzc2VydGlvbiBHUkFQSF9JU09QRU4oY29uaWQpIGZhaWxl ZC4NClVuYWJsZSB0byBoYW5kbGUga2VybmVsIE5VTEwgcG9pbnRlciBkZXJl ZmVyZW5jZSBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDAwM2MNCmN1cnJlbnQt PnRzcy5jcjMgPSAwMGJiODAwMCwgJWNyMyA9IDAwYmI4MDAwDQoqcGRlID0g MDAwMDAwMDANCk9vcHM6IDAwMDANCkNQVTogICAgMA0KRUlQOiAgICAwMDEw Ols8YzMwYWYwMmQ+XQ0KRUZMQUdTOiAwMDAxMDI5Ng0KZWF4OiAwMDAwMDAw MCAgIGVieDogYmZmZmY1NzggICBlY3g6IGMwMjNhYTk0ICAgZWR4OiBjMDA2 NjAwMA0KZXNpOiAwMDAwMDAwMSAgIGVkaTogMDAwMDAwMDEgICBlYnA6IGJm ZmZmNTc4ICAgZXNwOiBjMTAwZmVjMA0KZHM6IDAwMTggICBlczogMDAxOCAg IHNzOiAwMDE4DQpQcm9jZXNzIHNob3dhY2NlbCAocGlkOiA4NzMsIHByb2Nl c3MgbnI6IDUxLCBzdGFja3BhZ2U9YzEwMGYwMDApDQpTdGFjazogMDAwMDAw MDAgYzMwOGMyZTQgMDAwMDAwMDAgYzAxODAwMTIgYzAxODAwMTIgMDAwMDAw NTAgMDAwMDAwMjAgMDAwMDAwMDEgDQogICAgICAgYzBkZmFjODAgMDAwMDAw MDEgYzAyNTk0ZDggMDAwMDAwMDEgMDAwMDAwNTAgMDAwMDAwMDEgYzBkZmFj ODAgMDAwMDAwMDEgDQogICAgICAgYzAyNTk0ZDggMDAwMDAwMDEgMDAwMDAx ODAgMDAwMDAwMTkgYzAxY2ZmOWIgYzBkZmFjODAgYzAxY2ZmY2YgYzBkZmFj ODAgDQpDYWxsIFRyYWNlOiBbPGMzMDhjMmU0Pl0gWzxjMDE4MDAxMj5dIFs8 YzAxODAwMTI+XSBbPGMwMWNmZjliPl0gWzxjMDFjZmZjZj5dIFs8YzAxMTMy ZTU+XSBbPGMzMDhjMmU0Pl0gDQogICAgICAgWzxjMDE4MDAxMj5dIFs8YzMw YWYzMTI+XSBbPGMzMDhjMmU0Pl0gWzxjMDE4MDAxMj5dIFs8YzMwYjBiY2Q+ XSBbPGMzMGIwMjlmPl0gWzxjMDE4MDAxMj5dIFs8YzAxODAwMTI+XSANCiAg ICAgICBbPGMwMTJiZGNlPl0gWzxjMDE4MDAxMj5dIFs8YzAxMDljY2E+XSBb PGMwMTgwMDEyPl0gDQpDb2RlOiA4MyA3OCAzYyAwMCA3NSAwOSA4MyBiOCA0 MCAwMiAwMCAwMCAwMCA3NCAxMCBiOCBmMCBmZiBmZiBmZiANCg0KPj5FSVA6 IGMzMGFmMDJkIGNhbm5vdCBiZSByZXNvbHZlZA0KVHJhY2U6IGMzMDhjMmU0 DQpUcmFjZTogYzAxODAwMTIgPGlwX21hc3FfY29udHJvbF9kZWwrOWUvMTg4 Pg0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNxX2NvbnRyb2xfZGVsKzllLzE4 OD4NClRyYWNlOiBjMDFjZmY5YiA8Y29uX3dyaXRlK2ZiLzEzYz4NClRyYWNl OiBjMDFjZmZjZiA8Y29uX3dyaXRlKzEyZi8xM2M+DQpUcmFjZTogYzAxMTMy ZTUgPHByaW50aysxNTkvMTY4Pg0KVHJhY2U6IGMzMDhjMmU0DQpUcmFjZTog YzAxODAwMTIgPGlwX21hc3FfY29udHJvbF9kZWwrOWUvMTg4Pg0KVHJhY2U6 IGMzMGFmMzEyDQpUcmFjZTogYzMwOGMyZTQNClRyYWNlOiBjMDE4MDAxMiA8 aXBfbWFzcV9jb250cm9sX2RlbCs5ZS8xODg+DQpUcmFjZTogYzMwYjBiY2QN ClRyYWNlOiBjMzBiMDI5Zg0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNxX2Nv bnRyb2xfZGVsKzllLzE4OD4NClRyYWNlOiBjMDE4MDAxMiA8aXBfbWFzcV9j b250cm9sX2RlbCs5ZS8xODg+DQpUcmFjZTogYzAxMmJkY2UgPHN5c19pb2N0 bCsxMTIvMTI4Pg0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNxX2NvbnRyb2xf ZGVsKzllLzE4OD4NClRyYWNlOiBjMDEwOWNjYSA8c3lzdGVtX2NhbGwrM2Ev NDA+DQpUcmFjZTogYzAxODAwMTIgPGlwX21hc3FfY29udHJvbF9kZWwrOWUv MTg4Pg0KDQowMDAxMGQzMDpkZXZncmFwaC5jOjU0OTogZ3JhcGhfb3BlbiAo Y29uaWQgPSAweDAwKQ0KMDAwMTBkMzA6ZGV2Z3JhcGguYzo1NTg6IGFsbG9j YXRpbmcgL2Rldi9ncmFwaDAwIC4uLiANCjAwMDEwZDMwOmRldmdyYXBoLmM6 NTcxOiBvcGVuIG9uIC9kZXYvZ3JhcGgwMA0KMDAwMTBkMzE6ZGV2Z3JhcGgu Yzo3NDE6IEhlYWQgMCBpcyBidXN5DQowMDAxMGQzMjpkZXZncmFwaC5jOjc0 MTogSGVhZCAwIGlzIGJ1c3kNCjAwMDEwZjliOmRldmdyYXBoLmM6NTQ5OiBn cmFwaF9vcGVuIChjb25pZCA9IDB4MDApDQowMDAxMGY5YjpkZXZncmFwaC5j OjU1ODogYWxsb2NhdGluZyAvZGV2L2dyYXBoMDAgLi4uIA0KMDAwMTBmOWM6 ZGV2Z3JhcGguYzo1NzE6IG9wZW4gb24gL2Rldi9ncmFwaDAwDQowMDAxMGY5 YzpkZXZncmFwaC5jOjc0MTogSGVhZCAwIGlzIGJ1c3kNCjAwMDEwZjlkOmRl dmdyYXBoLmM6NzQxOiBIZWFkIDAgaXMgYnVzeQ0KMDAwMTEzODA6ZGV2Z3Jh cGguYzoxMTU4OiBVbmxvYWRlZCAvZGV2L2dyYXBoIHN1cHBvcnQNCmttZW1f Y3JlYXRlOiBEdXAgbmFtZSAtIGdyYXBoX3Z0X2luZm8NCmttZW1fY3JlYXRl OiBEdXAgbmFtZSAtIGdyYXBoX3Z0X2NsdXQNCjAwMDExNWI0OmRldmdyYXBo LmM6MTEzODogTG9hZGVkIC9kZXYvZ3JhcGggc3VwcG9ydA0KMDAwMTE1YjU6 ZGV2Z3JhcGguYzo1NDk6IGdyYXBoX29wZW4gKGNvbmlkID0gMHgwMCkNCjAw MDExNWI1OmRldmdyYXBoLmM6NTU4OiBhbGxvY2F0aW5nIC9kZXYvZ3JhcGgw MCAuLi4gDQowMDAxMTViNTpkZXZncmFwaC5jOjU3MTogb3BlbiBvbiAvZGV2 L2dyYXBoMDANCjAwMDExNWI1OmRldmdyYXBoLmM6NzU5OiBncmFwaF9pb2N0 bDogZHJpdmVyIGNvbW1hbmQgYzAxODAwMTINCjAwMDExNWI2OmRldmdyYXBo LmM6Njc1OiBhc3NlcnRpb24gR1JBUEhfSVNPUEVOKGNvbmlkKSBmYWlsZWQu DQpVbmFibGUgdG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZl cmVuY2UgYXQgdmlydHVhbCBhZGRyZXNzIDAwMDAwMDNjDQpjdXJyZW50LT50 c3MuY3IzID0gMDA2YjAwMDAsICVjcjMgPSAwMDZiMDAwMA0KKnBkZSA9IDAw MDAwMDAwDQpPb3BzOiAwMDAwDQpDUFU6ICAgIDANCkVJUDogICAgMDAxMDpb PGMzMGFmMDJkPl0NCkVGTEFHUzogMDAwMTAyOTYNCmVheDogMDAwMDAwMDAg ICBlYng6IGJmZmNkZmM4ICAgZWN4OiBjMDIzYWE5NCAgIGVkeDogYzAwNjYw MDANCmVzaTogMDAwMDAwMDEgICBlZGk6IDAwMDAwMDAxICAgZWJwOiBiZmZj ZGZjOCAgIGVzcDogYzEwMGZlYzANCmRzOiAwMDE4ICAgZXM6IDAwMTggICBz czogMDAxOA0KUHJvY2VzcyBkZW1vIChwaWQ6IDg4NSwgcHJvY2VzcyBucjog NTEsIHN0YWNrcGFnZT1jMTAwZjAwMCkNClN0YWNrOiAwMDAwMDAwMCBjMzA4 YzJlNCAwMDAwMDAwMCBjMDE4MDAxMiBjMDE4MDAxMiAwMDAwMDAwOCBjMDEx MTUyYyAwMDAwMDAwMSANCiAgICAgICBjMDI4NDA5MCAwMDAwMDAwMCAwMDAw MDAwMSBjMTAwZmYyMCAwMDAwMDI5NiBjMTAwZmYxOCBjMDExNzlhOSAwMDAw MDAwMCANCiAgICAgICAyMDAwMDAwMCBjMDEwYWJjNSAwMDAwMDAwMCBjMDI1 OTRkOCAwMDAwMDAzZSAwMDAwMDAwMCAwMDAwMDAwMSBjMDEwOWRiMCANCkNh bGwgVHJhY2U6IFs8YzMwOGMyZTQ+XSBbPGMwMTgwMDEyPl0gWzxjMDE4MDAx Mj5dIFs8YzAxMTE1MmM+XSBbPGMwMTE3OWE5Pl0gWzxjMDEwYWJjNT5dIFs8 YzAxMDlkYjA+XSANCiAgICAgICBbPGMwMTEzMmU1Pl0gWzxjMzA4YzJlND5d IFs8YzAxODAwMTI+XSBbPGMzMGFmMzEyPl0gWzxjMzA4YzJlND5dIFs8YzAx ODAwMTI+XSBbPGMzMGIwYmNkPl0gWzxjMzBiMDI5Zj5dIA0KICAgICAgIFs8 YzAxODAwMTI+XSBbPGMwMTgwMDEyPl0gWzxjMDEyYmRjZT5dIFs8YzAxODAw MTI+XSBbPGMwMTA5Y2NhPl0gWzxjMDE4MDAxMj5dIA0KQ29kZTogODMgNzgg M2MgMDAgNzUgMDkgODMgYjggNDAgMDIgMDAgMDAgMDAgNzQgMTAgYjggZjAg ZmYgZmYgZmYgDQoNCj4+RUlQOiBjMzBhZjAyZCBjYW5ub3QgYmUgcmVzb2x2 ZWQNClRyYWNlOiBjMzA4YzJlNA0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNx X2NvbnRyb2xfZGVsKzllLzE4OD4NClRyYWNlOiBjMDE4MDAxMiA8aXBfbWFz cV9jb250cm9sX2RlbCs5ZS8xODg+DQpUcmFjZTogYzAxMTE1MmMgPHRpbWVy X2JoKzExMC8zNGM+DQpUcmFjZTogYzAxMTc5YTkgPGRvX2JvdHRvbV9oYWxm KzQ1LzYwPg0KVHJhY2U6IGMwMTBhYmM1IDxkb19JUlErZTkvZjQ+DQpUcmFj ZTogYzAxMDlkYjAgPHJldF9mcm9tX2ludHI+DQpUcmFjZTogYzAxMTMyZTUg PHByaW50aysxNTkvMTY4Pg0KVHJhY2U6IGMzMDhjMmU0DQpUcmFjZTogYzAx ODAwMTIgPGlwX21hc3FfY29udHJvbF9kZWwrOWUvMTg4Pg0KVHJhY2U6IGMz MGFmMzEyDQpUcmFjZTogYzMwOGMyZTQNClRyYWNlOiBjMDE4MDAxMiA8aXBf bWFzcV9jb250cm9sX2RlbCs5ZS8xODg+DQpUcmFjZTogYzMwYjBiY2QNClRy YWNlOiBjMzBiMDI5Zg0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNxX2NvbnRy b2xfZGVsKzllLzE4OD4NClRyYWNlOiBjMDE4MDAxMiA8aXBfbWFzcV9jb250 cm9sX2RlbCs5ZS8xODg+DQpUcmFjZTogYzAxMmJkY2UgPHN5c19pb2N0bCsx MTIvMTI4Pg0KVHJhY2U6IGMwMTgwMDEyIDxpcF9tYXNxX2NvbnRyb2xfZGVs KzllLzE4OD4NClRyYWNlOiBjMDEwOWNjYSA8c3lzdGVtX2NhbGwrM2EvNDA+ DQpUcmFjZTogYzAxODAwMTIgPGlwX21hc3FfY29udHJvbF9kZWwrOWUvMTg4 Pg0KDQowMDAxMWE3YzpkZXZncmFwaC5jOjExNTg6IFVubG9hZGVkIC9kZXYv Z3JhcGggc3VwcG9ydA0K ---1463800064-1836603450-886037826=:849-- From evstack-request@ontv.com Wed Jan 28 18:16:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA11497 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 18:16:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA03740; Wed, 28 Jan 1998 20:39:44 -0500 Resent-Date: Wed, 28 Jan 1998 20:39:44 -0500 Date: Wed, 28 Jan 1998 18:45:33 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Jim Ursetto <ursetto@uiuc.edu> cc: evstack@ontv.com Subject: Re: Compile errors In-Reply-To: <19980128182112.19082@3e8.com> Message-ID: <Pine.LNX.3.96.980128184354.849G-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ZUBjw.0.fv.Hszpq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/541 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Wed, 28 Jan 1998, Jim Ursetto wrote: > OK, since I can't figure out what's going on, I'm going to ask some stupid > questions now. > > Is libggi supposed to work with EvStack right now? The CVS snapshot I > got today failed libggi compilation with several errors: [clipa-clipa] Oh - this is easy :) The libggi that comes with standard GGI works fine :) (Crashes for me on modeset - but otherwise works fine :) ... Am looking foreward to seeing svgalib-target.... *grin* libggi (and all other libs fwiw) in evstack CVS are broken as near as I can tell. G'day, eh? :) - Teunis From evstack-request@ontv.com Wed Jan 28 18:32:34 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA11530 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 18:32:32 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA03936; Wed, 28 Jan 1998 20:56:51 -0500 Resent-Date: Wed, 28 Jan 1998 20:56:51 -0500 Message-ID: <19980128195614.13823@3e8.com> Date: Wed, 28 Jan 1998 19:56:14 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: Compile errors References: <19980128182112.19082@3e8.com> <Pine.LNX.3.96.980128184354.849G-100000@sigil.computersupportcentre.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <Pine.LNX.3.96.980128184354.849G-100000@sigil.computersupportcentre.com>; from teunis on Wed, Jan 28, 1998 at 06:45:33PM -0700 X-Deities: e38 Resent-Message-ID: <"4_Bzw.0.sy.e6-pq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/542 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 06:45 PM on 1998 January 28, teunis did write: > On Wed, 28 Jan 1998, Jim Ursetto wrote: > > Is libggi supposed to work with EvStack right now? The CVS snapshot I > > got today failed libggi compilation with several errors: > Oh - this is easy :) > The libggi that comes with standard GGI works fine :) > (Crashes for me on modeset - but otherwise works fine :) Hmm, OK, all it does for me is say Requesting mode [320x200] Got mode [0x0] and exits. No crash, but no graphics. It seems like that /dev/graph support in your next message isn't being loaded. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 18:47:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA11560 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 18:47:33 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA04208; Wed, 28 Jan 1998 21:11:20 -0500 Resent-Date: Wed, 28 Jan 1998 21:11:20 -0500 Message-Id: <m0xxjHQ-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: More comments To: evstack@ontv.com Date: Thu, 29 Jan 1998 13:00:36 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <19980128190257.54809@3e8.com> from "Jim Ursetto" at Jan 28, 98 07:02:57 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7dUX_2.0.B11.QK-pq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/543 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jim Ursetto writes: > - After ggidrv.o is inserted, the VGA hardware cursor appears on screen in > an incorrect place. It appears to the left of the input point, and its > distance away from the input point increases as the cursor moves to the left > of the screen. (I had to rmmod ggidrv to type this reasonably fast.) Yeah, known problem. > - My kernel messages are all appearing on VT 1 instead of VT 10 Did you compile with the "printk following console" option ? > - Basically the only thing that works is module insertion/removal, which is > nice, but I can't do much with the module in plain old text mode. Lots of things in EvStack are still 'to-be-done'... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 28 19:03:36 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11577 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 19:03:35 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA04395; Wed, 28 Jan 1998 21:27:47 -0500 Resent-Date: Wed, 28 Jan 1998 21:27:47 -0500 Message-Id: <m0xxjXL-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/event _is_ working ... To: evstack@ontv.com Date: Thu, 29 Jan 1998 13:17:03 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xxYaM-0000WvC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 28, 98 03:35:25 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VKRsF1.0.v31.gZ-pq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/544 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > As Teunis wants to write a GPM-like mouse-emulator on a pipe, I > thought I'd check /dev/event code. .... > They way to get this working is : > > insmod devevent.o > echo create >/proc/sys/evstack/class/devevent > ll /proc/sys/evstack/stack [find out the name of the created stack] > echo + [deveventstack] >some-termstack Andy, this way of using devevent is not very libGGI friendly. For example, say there are a couple of libGGI programs running in other consoles, how will libGGI know which stack is the one it created ? I propose that devevent is an evstack _device_, and when a process opens /dev/eventNN, a devevent stack is automatically created and attached to the appropriate termstack. And when the process closes the fd, the devevent stack is detached and destroyed. If a program wishes to attach to the input_stack instead, then it could either do it with "detach ... attach ..." through /proc, or through some ioctl call. [A sneakier way is to use command events between the process and the devevent stack]. What do you think ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Wed Jan 28 19:09:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11587 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 19:09:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA04502; Wed, 28 Jan 1998 21:33:31 -0500 Resent-Date: Wed, 28 Jan 1998 21:33:31 -0500 Message-ID: <19980128203256.40344@3e8.com> Date: Wed, 28 Jan 1998 20:32:56 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: More comments References: <19980128190257.54809@3e8.com> <m0xxjHQ-00012NC@ajax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <m0xxjHQ-00012NC@ajax>; from Andrew Apted on Thu, Jan 29, 1998 at 01:00:36PM +1100 X-Deities: e38 Resent-Message-ID: <"oVjiz3.0.p51.0f-pq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/545 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 01:00 PM on 1998 January 29, Andrew Apted did write: > Jim Ursetto writes: > > - After ggidrv.o is inserted, the VGA hardware cursor appears on screen in > > an incorrect place. It appears to the left of the input point, and its > > distance away from the input point increases as the cursor moves to the left > > of the screen. (I had to rmmod ggidrv to type this reasonably fast.) > > Yeah, known problem. I found the culprit, in case the solution was not known. These are numbers which came up from the show_cursor function as I moved the cursor across the screen: Jan 28 20:09:20 alice kernel: (x,y)=(0,384) adr 1920 Jan 28 20:09:20 alice kernel: (x,y)=(8,384) adr 1920 <--- Jan 28 20:09:20 alice kernel: (x,y)=(16,384) adr 1921 Jan 28 20:09:20 alice kernel: (x,y)=(24,384) adr 1922 [...] Jan 28 20:09:20 alice kernel: (x,y)=(56,384) adr 1926 Jan 28 20:09:20 alice kernel: (x,y)=(64,384) adr 1927 Jan 28 20:09:20 alice kernel: (x,y)=(72,384) adr 1928 Jan 28 20:09:20 alice kernel: (x,y)=(80,384) adr 1928 <--- Jan 28 20:09:24 alice last message repeated 2 times As you see the function is passed actual screen coordinates and divides by the font width and height to get to location. And the duplicated coor- dinates occur at precise times, which suggested and led me to confirm that show_cursor divides the x coordinate by 9, and not 8, even though we're using 8x16 font. I don't know why TEXTX [or mode->request.text.x] is 9 and not 8, but that's the entire problem. I assume a structure is not initialized properly. > > - My kernel messages are all appearing on VT 1 instead of VT 10 > > Did you compile with the "printk following console" option ? Well, I guess I'll try to figure out what you're talking about :) > > - Basically the only thing that works is module insertion/removal, which is > > nice, but I can't do much with the module in plain old text mode. > Lots of things in EvStack are still 'to-be-done'... Some people were claiming "fully working drivers!" soon to come to EvStack, and that /dev/graphic was working, so I figured I could at least run demo programs to test a possible driver. But no problem, I'll just wait for someone to tell me how they can tell their drivers are working if you can't display graphics :). Anyway, due to the module insertion/removal stuff, I found that bug in less time than it took to write this message, so I'm impressed. But my computer's oopsing and/or crashing, so I'm wary of staying in this environment for too long--then again, it may be 2.1.79, so whatever. If the actual reason for the cursor-trailing bug was unknown to you, tell me so I can track down what's happening--otherwise I'll assume that you did know about it and it's not an easy fix. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 19:31:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA11599 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 19:31:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA04720; Wed, 28 Jan 1998 21:55:23 -0500 Resent-Date: Wed, 28 Jan 1998 21:55:23 -0500 Message-ID: <19980128205439.34785@3e8.com> Date: Wed, 28 Jan 1998 20:54:39 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: More comments References: <19980128190257.54809@3e8.com> <m0xxjHQ-00012NC@ajax> <19980128203256.40344@3e8.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19980128203256.40344@3e8.com>; from Jim Ursetto on Wed, Jan 28, 1998 at 08:32:56PM -0600 X-Deities: e38 Resent-Message-ID: <"494Td3.0.591.Kz-pq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/546 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 08:32 PM on 1998 January 28, Jim Ursetto did write: > As you see the function is passed actual screen coordinates and divides by > the font width and height to get to location. And the duplicated coor- > dinates occur at precise times, which suggested and led me to confirm that > show_cursor divides the x coordinate by 9, and not 8, even though we're > using 8x16 font. I don't know why TEXTX [or mode->request.text.x] is 9 and > not 8, but that's the entire problem. I assume a structure is not > initialized properly. Just to follow up, I hardcoded TEXTX to be 8 in both show_cursor functions and it works perfectly, although it's not a permanent solution. I also changed the cursor from unbearable yellow to pleasing red (0x48) but that's my perogative ;) Try red, it's real nice. BTW, _is_ the mouse usable in X? -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Wed Jan 28 22:23:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id WAA11763 for <ggi@synergy.foo.net>; Wed, 28 Jan 1998 22:23:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id AAA06092; Thu, 29 Jan 1998 00:46:48 -0500 Resent-Date: Thu, 29 Jan 1998 00:46:48 -0500 Message-Id: <m0xxme6-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: More comments To: evstack@ontv.com Date: Thu, 29 Jan 1998 16:36:14 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <19980128203256.40344@3e8.com> from "Jim Ursetto" at Jan 28, 98 08:32:56 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cwRHJ1.0.dU1.PU1qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/547 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jim Ursetto writes: > I found the culprit, in case the solution was not known. These are numbers > which came up from the show_cursor function as I moved the cursor across the > screen: > > Jan 28 20:09:20 alice kernel: (x,y)=(0,384) adr 1920 > Jan 28 20:09:20 alice kernel: (x,y)=(8,384) adr 1920 <--- > Jan 28 20:09:20 alice kernel: (x,y)=(16,384) adr 1921 > Jan 28 20:09:20 alice kernel: (x,y)=(24,384) adr 1922 > [...] > Jan 28 20:09:20 alice kernel: (x,y)=(56,384) adr 1926 > Jan 28 20:09:20 alice kernel: (x,y)=(64,384) adr 1927 > Jan 28 20:09:20 alice kernel: (x,y)=(72,384) adr 1928 > Jan 28 20:09:20 alice kernel: (x,y)=(80,384) adr 1928 <--- > Jan 28 20:09:24 alice last message repeated 2 times Ahhh yes. > As you see the function is passed actual screen coordinates and divides by > the font width and height to get to location. And the duplicated coor- > dinates occur at precise times, which suggested and led me to confirm that > show_cursor divides the x coordinate by 9, and not 8, even though we're > using 8x16 font. I don't know why TEXTX [or mode->request.text.x] is 9 and > not 8, but that's the entire problem. I assume a structure is not > initialized properly. Yes, I also think it's a 'structure-not-initialized' problem. There's a similiar problem with the pointer cursor -- at first it is limited to the a small box in the top-left corner, but this goes away by insmodding and rmmoding the VGA driver... > > Did you compile with the "printk following console" option ? > > Well, I guess I'll try to figure out what you're talking about :) There's a CONFIG_GGI_PRINTK_FOLLOWING option in the kernel config. > If the actual reason for the cursor-trailing bug was unknown to you, tell me > so I can track down what's happening--otherwise I'll assume that you did > know about it and it's not an easy fix. I'll look into it some more, and if it's easily fixed, I will. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 29 03:44:09 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA12191 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 03:44:08 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA09577; Thu, 29 Jan 1998 06:08:26 -0500 Resent-Date: Thu, 29 Jan 1998 06:08:26 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxsil-0000XZC@charon.beck-sw.de> Subject: Re: More comments To: evstack@ontv.com Date: Thu, 29 Jan 1998 13:05:26 +0100 (MET) In-Reply-To: <19980128203256.40344@3e8.com> from "Jim Ursetto" at Jan 28, 98 08:32:56 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"9WXCy3.0.wF2.rB6qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/549 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > I found the culprit, in case the solution was not known. Great. Who wants to fix this ? > > > - My kernel messages are all appearing on VT 1 instead of VT 10 > > Did you compile with the "printk following console" option ? > Well, I guess I'll try to figure out what you're talking about :) YOu can configure that at kernel config time. > > Lots of things in EvStack are still 'to-be-done'... > > Some people were claiming "fully working drivers!" soon to come to EvStack, soon to come :-) ... > and that /dev/graphic was working, so I figured I could at least run demo Somewhat ... we have problems with input ... > But my computer's oopsing and/or crashing, so I'm wary of staying in this > environment for too long--then again, it may be 2.1.79, so whatever. Oh - for me EvStack is pretty stable ... The only annoying effect is that I loose CMOS sometimes when rebooting corectly (just to warn you). There must still a bug in the shutdown code. Funnily it never happens, if I go to single-user and unmaout evrything and then simply press reset ... > If the actual reason for the cursor-trailing bug was unknown to you, Not sure, if Jason knew, but its nice you told us. Try to find a fix, if you feel like it ... Probably the advance of 8 is hardcoded womewhere, where the font width should be used ... CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 03:44:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA12197 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 03:44:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA09613; Thu, 29 Jan 1998 06:09:01 -0500 Resent-Date: Thu, 29 Jan 1998 06:09:01 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxscB-0000XZC@charon.beck-sw.de> Subject: Re: /dev/event _is_ working ... To: evstack@ontv.com Date: Thu, 29 Jan 1998 12:58:39 +0100 (MET) In-Reply-To: <m0xxjXL-00012NC@ajax> from "Andrew Apted" at Jan 29, 98 01:17:03 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"XHI6U.0.9F2.nB6qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/548 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > They way to get this working is : > > > > insmod devevent.o > > echo create >/proc/sys/evstack/class/devevent > > ll /proc/sys/evstack/stack [find out the name of the created stack] > > echo + [deveventstack] >some-termstack > Andy, this way of using devevent is not very libGGI friendly. It is not intended for LibGGI usage. The devevent devices have been designed as a "tunnel" for userspace/kernelspace stacks and for "spying" on the kernel events so you can make something of them in userspace. > For example, say there are a couple of libGGI programs running in other > consoles, how will libGGI know which stack is the one it created ? The idea is rather to rip the code from devevent or the traditional graphic.c and get the eventstream directly via the /dev/graphic device. > I propose that devevent is an evstack _device_, and when a process opens > /dev/eventNN, a devevent stack is automatically created and attached to > the appropriate termstack. This limits the use of devevent devices. e.g. you can now move things like the spaceorb driver to usermode by attaching the devevent stack to the input stack and send events from userspace. BTW: Why are events sent to the input stack not distributed on it ? This would be very helpful to spy on _all_ input events, not only those that are directed to a given VT. > And when the process closes the fd, the devevent stack is detached and > destroyed. I'd say the devevent stack is not intended for that. The traditional way of having the events on /dev/graphic seems the better way to me. This keeps devevent free for other "tricks" ... CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 03:45:08 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA12201 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 03:45:07 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA09616; Thu, 29 Jan 1998 06:09:02 -0500 Resent-Date: Thu, 29 Jan 1998 06:09:02 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xxsRQ-0000XZC@charon.beck-sw.de> Subject: Re: More comments To: evstack@ontv.com Date: Thu, 29 Jan 1998 12:47:31 +0100 (MET) In-Reply-To: <19980128205439.34785@3e8.com> from "Jim Ursetto" at Jan 28, 98 08:54:39 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"qkTNl.0.RH2.yB6qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/550 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Just to follow up, I hardcoded TEXTX to be 8 in both show_cursor functions > and it works perfectly, although it's not a permanent solution. Good. Now that the culprit is found, we can probably squash the bug easily (Jason ?). > BTW, _is_ the mouse usable in X? Yes. The trick is _not_ to insert the EvStack mouse module and use the traditional device. At least this works for serial mice. Other than that Teunis (?) is working on a GPM-like mouse-emulator on a pipe. This allows you to tell all traditional programs you have a mousesystems mouse on /tmp/some_pipe. CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 04:38:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA12264 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 04:38:03 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA10148; Thu, 29 Jan 1998 07:02:15 -0500 Resent-Date: Thu, 29 Jan 1998 07:02:15 -0500 Sender: core@tron.mirus.fr Message-ID: <34D06C8A.3A7DE488@mirus.fr> Date: Thu, 29 Jan 1998 12:48:26 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: More comments References: <m0xxme6-00012NC@ajax> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2VQIb3.0.VR2.Yz6qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/551 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > As you see the function is passed actual screen coordinates and divides by > > the font width and height to get to location. And the duplicated coor- > > dinates occur at precise times, which suggested and led me to confirm that > > show_cursor divides the x coordinate by 9, and not 8, even though we're > > using 8x16 font. I don't know why TEXTX [or mode->request.text.x] is 9 and > > not 8, but that's the entire problem. I assume a structure is not > > initialized properly. > > Yes, I also think it's a 'structure-not-initialized' problem. There's > a similiar problem with the pointer cursor -- at first it is limited to > the a small box in the top-left corner, but this goes away by insmodding > and rmmoding the VGA driver... I know the problem : The default font is 8x16. The kernel tries to set it. Unfortunately, there can only be one font per height in current design, and the one we have is 9x16. The kernel reverts to using it, but doesn't change the size back in the mode. I'll fix that if noone does it - I seem to be in people killfile too, or something.. I need an answer to an important API change question :( ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Thu Jan 29 05:26:37 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id FAA12315 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 05:26:36 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA10344; Thu, 29 Jan 1998 07:49:49 -0500 Resent-Date: Thu, 29 Jan 1998 07:49:49 -0500 Message-Id: <m0xxtEC-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/event _is_ working ... To: evstack@ontv.com Date: Thu, 29 Jan 1998 23:37:56 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xxscB-0000XZC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 29, 98 12:58:39 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"80dLN3.0.xW2.Mg7qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/552 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > The idea is rather to rip the code from devevent or the traditional > graphic.c and get the eventstream directly via the /dev/graphic > device. Oh right. I had thought that read & write on /dev/graphic would be reserved for accessing the framebuffer or something... Okay, I reckon I could implement that if you like. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 29 07:26:51 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12411 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 07:26:49 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA11369; Thu, 29 Jan 1998 09:51:00 -0500 Resent-Date: Thu, 29 Jan 1998 09:51:00 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: /dev/event _is_ working ... Date: 29 Jan 1998 14:49:43 GMT Organization: OnTV Pittsburgh, L.P. Lines: 17 Distribution: local Message-ID: <6aq4u7$sa1$1@grits.visus.com> References: <6aq43l$rp4$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"PtYlA.0.wm2.VR9qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/553 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > For example, say there are a couple of libGGI programs running in other > > consoles, how will libGGI know which stack is the one it created ? > The idea is rather to rip the code from devevent or the traditional > graphic.c and get the eventstream directly via the /dev/graphic > device. So both /dev/graph read() and write() are Event stuff? And IOCTL is all graphics? and so is mmap(), right? -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 07:29:12 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12427 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 07:29:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id JAA11442; Thu, 29 Jan 1998 09:53:29 -0500 Resent-Date: Thu, 29 Jan 1998 09:53:29 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Boot problem ... Date: 29 Jan 1998 14:52:10 GMT Organization: OnTV Pittsburgh, L.P. Lines: 20 Distribution: local Message-ID: <6aq52q$sa1$2@grits.visus.com> References: <6aq3gs$qog$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"r8RZf1.0._n2.nT9qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/554 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com becka@rz.uni-duesseldorf.de wrote: > > From: Marcus Sundberg <e94_msu@elixir.e.kth.se> > > > > kgi_arch_init: 1 displays detected > > Can't bind to VT 0x10 > > Unable to handle kernel paging request > > > Ouch ... Anyone knows how to fix that easily. A default kernel _should_ > be configured with both drivers and work on single-headed systems as well > as on headless ones, too ... Yeah yeah.. That is a `hardcoded' #define in console.c - it should really get kernel boot options from lilo (ie, `vt_console=0x10' ), but I haven't had the time yet.. -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 07:39:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12458 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 07:39:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA11694; Thu, 29 Jan 1998 10:03:29 -0500 Resent-Date: Thu, 29 Jan 1998 10:03:29 -0500 Message-Id: <199801291501.QAA17602@cairo.e.kth.se> X-Mailer: exmh version 2.0zeta 7/24/97 To: evstack@ontv.com Subject: Patch to make EvStack patch 2.1.8x kernels Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5074433119140" Date: Thu, 29 Jan 1998 16:01:40 +0100 From: Marcus Sundberg <e94_msu@elixir.e.kth.se> Resent-Message-ID: <"GTmcZ3.0._r2.4d9qq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/555 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This is a multipart MIME message. --==_Exmh_5074433119140 Content-Type: text/plain; charset=us-ascii Here's a tiny diff to make evstack patch 2.1.8x kernels (tested on 2.1.82 only, but 80 and 81 should work too). It patches cleanly into the kernel, which then compiles and boots, but when I tried inserting the vga driver I got the "Device or resource busy" message. I don't know if some changes are needed to linux/drivers/console/* too, or if there was something wrong with EvStack when I got the snapshot. (DLed yesterday ~2200 CET from the EvStack page) //Marcus --==_Exmh_5074433119140 Content-Type: text/plain ; name="mydiff"; charset=us-ascii Content-Description: evstack-2.1.82-diff Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mydiff" LS0tIE1ha2VmaWxlLm9yaWcJVGh1IEphbiAyOSAxMDo0MToxNCAxOTk4CisrKyBNYWtlZmls ZQlUaHUgSmFuIDI5IDEwOjQyOjI5IDE5OTgKQEAgLTE1LDEwICsxNSwxNyBAQAogIyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQogCiAyXzFfNzc9JChmb3JlYWNoIGJlZywgNzcsJChmb3Jl YWNoIGVuZCw3OSwkKGNvdW50OiU9X3BhdGNoXzIuMS4lKSkpCisyXzFfODA9JChmb3JlYWNo IGJlZywgODAsJChmb3JlYWNoIGVuZCw4MiwkKGNvdW50OiU9X3BhdGNoXzIuMS4lKSkpCiAK ICQoMl8xXzc3OiU9ZG8lKToKIAkuL2RvX3BhdGNoLTIuMS54ICQoQVJHUykgMi4xLjc3CiAK ICQoMl8xXzc3OiU9dW4lKToKIAkuL3VuX3BhdGNoLTIuMS54ICQoQVJHUykgMi4xLjc3CisK KyQoMl8xXzgwOiU9ZG8lKToKKwkuL2RvX3BhdGNoLTIuMS54ICQoQVJHUykgMi4xLjgwCisK KyQoMl8xXzgwOiU9dW4lKToKKwkuL3VuX3BhdGNoLTIuMS54ICQoQVJHUykgMi4xLjgwCiAK LS0tIHBhdGNoLTIuMS43NwlXZWQgSmFuIDIxIDE0OjAyOjU4IDE5OTgKKysrIHBhdGNoLTIu MS44MAlUaHUgSmFuIDI5IDEwOjUwOjA4IDE5OTgKQEAgLTY5NCwxNyArNjk0LDE3IEBACiAg ZXh0ZXJuIHZvaWQgc29ja19pbml0KHZvaWQpOwogIGV4dGVybiB2b2lkIHVpZGNhY2hlX2lu aXQodm9pZCk7CiAgZXh0ZXJuIHVuc2lnbmVkIGxvbmcgcGNpX2luaXQodW5zaWduZWQgbG9u ZywgdW5zaWduZWQgbG9uZyk7Ci1AQCAtNzYsNyArNzYsOSBAQAotIGV4dGVybiB2b2lkIGRx dW90X2luaXQodm9pZCk7CitAQCAtNzcsNyArNzcsOSBAQAogIAogIGV4dGVybiB2b2lkIHNt cF9zZXR1cChjaGFyICpzdHIsIGludCAqaW50cyk7CisgZXh0ZXJuIHZvaWQgaW9hcGljX3Bp cnFfc2V0dXAoY2hhciAqc3RyLCBpbnQgKmludHMpOwogKyNpZm5kZWYgQ09ORklHX0dHSQog IGV4dGVybiB2b2lkIG5vX3Njcm9sbChjaGFyICpzdHIsIGludCAqaW50cyk7CiArI2VuZGlm CiAgZXh0ZXJuIHZvaWQgc3dhcF9zZXR1cChjaGFyICpzdHIsIGludCAqaW50cyk7CiAgZXh0 ZXJuIHZvaWQgYnVmZl9zZXR1cChjaGFyICpzdHIsIGludCAqaW50cyk7CiAgZXh0ZXJuIHZv aWQgcGFuaWNfc2V0dXAoY2hhciAqc3RyLCBpbnQgKmludHMpOwotQEAgLTQ3OCw3ICs0ODAs OSBAQAorQEAgLTQ4Myw3ICs0ODUsOSBAQAogIAl7ICJwYW5pYz0iLCBwYW5pY19zZXR1cCB9 LAogIAl7ICJjb25zb2xlPSIsIGNvbnNvbGVfc2V0dXAgfSwKICAjaWZkZWYgQ09ORklHX1ZU CkBAIC03MTQsMTUgKzcxNCwyNCBAQAogICNlbmRpZgogICNpZmRlZiBDT05GSUdfQlVHaTM4 NgogIAl7ICJuby1obHQiLCBub19oYWx0IH0sCi1AQCAtMTAwNCw3ICsxMDA4LDcgQEAKLSAj aWYgZGVmaW5lZChDT05GSUdfUENJKSAmJiBkZWZpbmVkKENPTkZJR19QQ0lfQ09OU09MRSkK K0BAIC05ODcsNyArOTkxLDcgQEAKKyAJbWVtb3J5X3N0YXJ0ID0gcGFnaW5nX2luaXQobWVt b3J5X3N0YXJ0LG1lbW9yeV9lbmQpOworIAl0cmFwX2luaXQoKTsKKyAJaW5pdF9JUlEoKTsK Ky0JbWVtb3J5X3N0YXJ0ID0gY29uc29sZV9pbml0KG1lbW9yeV9zdGFydCxtZW1vcnlfZW5k KTsKKysJbWVtb3J5X3N0YXJ0ID0gdGVybWlvc19pbml0KG1lbW9yeV9zdGFydCxtZW1vcnlf ZW5kKTsKKyAJc2NoZWRfaW5pdCgpOworIAl0aW1lX2luaXQoKTsKKyAJcGFyc2Vfb3B0aW9u cyhjb21tYW5kX2xpbmUpOworQEAgLTEwMTQsNyArMTAxOCw3IEBACiAgCW1lbW9yeV9zdGFy dCA9IHBjaV9pbml0KG1lbW9yeV9zdGFydCxtZW1vcnlfZW5kKTsKICAjZW5kaWYKKyAjaWYg SEFDSwogLQltZW1vcnlfc3RhcnQgPSBjb25zb2xlX2luaXQobWVtb3J5X3N0YXJ0LG1lbW9y eV9lbmQpOwogKwltZW1vcnlfc3RhcnQgPSB0ZXJtaW9zX2luaXQobWVtb3J5X3N0YXJ0LG1l bW9yeV9lbmQpOworICNlbmRpZgogICNpZiBkZWZpbmVkKENPTkZJR19QQ0kpICYmICFkZWZp bmVkKENPTkZJR19QQ0lfQ09OU09MRSkKICAJbWVtb3J5X3N0YXJ0ID0gcGNpX2luaXQobWVt b3J5X3N0YXJ0LG1lbW9yeV9lbmQpOwotICNlbmRpZgogZGlmZiAtLXJlY3Vyc2l2ZSAtdSBs aW51eC0yLjEueC9rZXJuZWwva3N5bXMuYyBsaW51eC0yLjEueC1nZ2kva2VybmVsL2tzeW1z LmMKIC0tLSBsaW51eC0yLjEueC9rZXJuZWwva3N5bXMuYwlNb24gRGVjIDIyIDE3OjE0OjM3 IDE5OTcKICsrKyBsaW51eC0yLjEueC1nZ2kva2VybmVsL2tzeW1zLmMJVHVlIEphbiAxMyAx ODozNTowNyAxOTk4Cg== --==_Exmh_5074433119140 Content-Type: text/plain; charset=us-ascii -------------------------------+------------------------------------ Marcus Sundberg | WWW: http://www.e.kth.se/~e94_msu/ Royal Institute of Technology | This space for rent... Stockholm, Sweden | E-Mail: e94_msu@e.kth.se --==_Exmh_5074433119140-- From evstack-request@ontv.com Thu Jan 29 07:52:22 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id HAA12469 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 07:52:21 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA11811; Thu, 29 Jan 1998 10:10:19 -0500 Resent-Date: Thu, 29 Jan 1998 10:10:19 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Modification in driver API ? Date: 29 Jan 1998 15:07:49 GMT Organization: OnTV Pittsburgh, L.P. Lines: 124 Distribution: local Message-ID: <6aq605$t15$1@grits.visus.com> References: <6ansja$7bl$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"E-2Ot1.0.mt2.Ri9qq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/556 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [sorry for the delay - I _thought_ I had sent this yesterday...] Emmanuel Marty (core@mirus.fr) wrote: > moving the chipset private data from display to mode would, I think, > require that chipset register access functions (DAC_out8, etc) are > given a pointer to the mode rather than the display. if it doesn't > matter for VGA which doesn't make use of it at all, it does matter > for other driver such as mediaGX caching register mmio pointers > there, for example. i did all the necessary changes in the includes, > then all necessary drivers for compiling VGA and mediaGX and it > still works fine.. with those changes i can go further with the > porting. should i commit them, or is someone against the change > (requires more porting work, but i think it's necessary.. if it > isn't, then it isn't logical and private data should stay in > the kgi_display) From the way, I take it, driver_data should be for driver-specific data (ie, MMIO regions that are in use, etc), and mode_data should be data _specific_ to that mode. Theoretically, a KGI kernel module should be able to `check_mode' a mode, generate the KGI mode, and cache it for later use. [There are `lock down' mechanisms in my current codebase that I'm working on to help with this.] A KGI module [ie, /dev/graph] should ONLY care about the kgi_mode struct. The kgi_display struct is hidden away by KGI itself. KGI display drivers will still deal with the kgi_display struct, as they are intimately tied to it's definition. Given that, DAC_* and friends will probably need the `display-wide' information in driver_data, so you should keep them the way they are now. Ie, DAC_out8 may need to know the MMIO region the display is using (via dpy->display_data), but may also need to know some mode information (via dpy->mode_data) What we'll probably end up with is something like: [sorry, got kinda carried away coding...] struct kgi_mode *dev_graph_request_mode(int head,ggi_mode *req) { kgi_mode *mode; int err; /* Allocate memory to a kgi_mode struct in KGI */ mode=kgi_head_allocate_mode(head); memset(&mode->request,&ggi_requested_mode,sizeof(ggi_mode)); /* `Convert' the requested mode into timing data. ** No memory is allocated to the mode at ** this time. */ err=kgi_head_check_mode(head,mode,CMD_PROPOSE); if (err) goto error; /* On the `CMD_CHECK', we're saying that we ** really want this mode. If it verifies OK, ** memory is allocated to mode_data (if needed) ** for mode state info. ** ** Also, set up the mmio, accel, textop, and fb structs ** ** NOTE: If CMD_CHECK return EOK, you can safely ** cache this mode away, as KGI will have ** performed and implicit 'acquire()' on ** the display (usually MOD_INC_USE_COUNT) */ err=kgi_head_check_mode(head,mode,CMD_CHECK); if (err) goto error; /* Allocate entries for the MMAP regions, etc... */ return mode; error: kgi_head_free_mode(head,mode); return NULL; } struct int dev_graph_activate_mode(int head,kgi_mode *mode) { int err; /* We know it's already checked for this head, ** and the _allocate_mode() did an implicit ** `acquire' of the display driver so that it ** can't drop from under us. */ err=kgi_head_set_mode(head,mode); if (err) return err; /* Now we set up the MMAP regions that have been ** requested for this mode, clear the framebuffer, ** set the CLUT, and all that jazz. */ return EOK } struct int dev_graph_free_mode(int head,kgi_mode *mode) { /* Now that we're finished with the mode, we ** can ask the driver to release the memory ** allocated to it. ** ** This also performs and implicit `release' ** of the display driver, decreasing it's ** use count (usually, MOD_DEC_USE_COUNT) */ return kgi_head_free_mode(head,mode); } -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 08:46:43 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA12517 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 08:46:40 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA12408; Thu, 29 Jan 1998 11:10:38 -0500 Resent-Date: Thu, 29 Jan 1998 11:10:38 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Modification in driver API ? Date: 29 Jan 1998 16:06:55 GMT Organization: OnTV Pittsburgh, L.P. Lines: 123 Distribution: local Message-ID: <6aq9ev$t15$2@grits.visus.com> References: <6aq6n5$ttd$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"AWsvc2.0.z03.sZAqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/557 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [once more.... Dammit...] Emmanuel Marty (core@mirus.fr) wrote: > moving the chipset private data from display to mode would, I think, > require that chipset register access functions (DAC_out8, etc) are > given a pointer to the mode rather than the display. if it doesn't > matter for VGA which doesn't make use of it at all, it does matter > for other driver such as mediaGX caching register mmio pointers > there, for example. i did all the necessary changes in the includes, > then all necessary drivers for compiling VGA and mediaGX and it > still works fine.. with those changes i can go further with the > porting. should i commit them, or is someone against the change > (requires more porting work, but i think it's necessary.. if it > isn't, then it isn't logical and private data should stay in > the kgi_display) From the way, I take it, driver_data should be for driver-specific data (ie, MMIO regions that are in use, etc), and mode_data should be data _specific_ to that mode. Theoretically, a KGI kernel module should be able to `check_mode' a mode, generate the KGI mode, and cache it for later use. [There are `lock down' mechanisms in my current codebase that I'm working on to help with this.] A KGI module [ie, /dev/graph] should ONLY care about the kgi_mode struct. The kgi_display struct is hidden away by KGI itself. KGI display drivers will still deal with the kgi_display struct, as they are intimately tied to it's definition. Given that, DAC_* and friends will probably need the `display-wide' information in driver_data, so you should keep them the way they are now. Ie, DAC_out8 may need to know the MMIO region the display is using (via dpy->display_data), but may also need to know some mode information (via dpy->mode_data) What we'll probably end up with is something like: [sorry, got kinda carried away coding...] struct kgi_mode *dev_graph_request_mode(int head,ggi_mode *req) { kgi_mode *mode; int err; /* Allocate memory to a kgi_mode struct in KGI */ mode=kgi_head_allocate_mode(head); memset(&mode->request,&ggi_requested_mode,sizeof(ggi_mode)); /* `Convert' the requested mode into timing data. ** No memory is allocated to the mode at ** this time. */ err=kgi_head_check_mode(head,mode,CMD_PROPOSE); if (err) goto error; /* On the `CMD_CHECK', we're saying that we ** really want this mode. If it verifies OK, ** memory is allocated to mode_data (if needed) ** for mode state info. ** ** Also, set up the mmio, accel, textop, and fb structs ** ** NOTE: If CMD_CHECK return EOK, you can safely ** cache this mode away, as KGI will have ** performed and implicit 'acquire()' on ** the display (usually MOD_INC_USE_COUNT) */ err=kgi_head_check_mode(head,mode,CMD_CHECK); if (err) goto error; /* Allocate entries for the MMAP regions, etc... */ return mode; error: kgi_head_free_mode(head,mode); return NULL; } struct int dev_graph_activate_mode(int head,kgi_mode *mode) { int err; /* We know it's already checked for this head, ** and the _allocate_mode() did an implicit ** `acquire' of the display driver so that it ** can't drop from under us. */ err=kgi_head_set_mode(head,mode); if (err) return err; /* Now we set up the MMAP regions that have been ** requested for this mode, clear the framebuffer, ** set the CLUT, and all that jazz. */ return EOK } struct int dev_graph_free_mode(int head,kgi_mode *mode) { /* Now that we're finished with the mode, we ** can ask the driver to release the memory ** allocated to it. ** ** This also performs and implicit `release' ** of the display driver, decreasing it's ** use count (usually, MOD_DEC_USE_COUNT) */ return kgi_head_free_mode(head,mode); } -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 09:01:56 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA12531 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 09:01:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA12673; Thu, 29 Jan 1998 11:26:09 -0500 Resent-Date: Thu, 29 Jan 1998 11:26:09 -0500 Sender: core@tron.mirus.fr Message-ID: <34D0A9FC.7F09F46B@mirus.fr> Date: Thu, 29 Jan 1998 17:10:36 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: Modification in driver API ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uP5oo2.0.053.1qAqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/558 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan wrote: > KGI display drivers will still deal with the kgi_display > struct, as they are intimately tied to it's definition. > > Given that, DAC_* and friends will probably need the > `display-wide' information in driver_data, so you should keep > them the way they are now. Ie, DAC_out8 may need to know the > MMIO region the display is using (via dpy->display_data), but may > also need to know some mode information (via dpy->mode_data) So, why does KGIM_PRIVATE retrieve data from mode->mode_data now instead of dpy->driver_data as it used to be ? Either KGIM_PRIVATE should be changed to behave the old way, or the routines using it must be passed a mode pointer, not a display one - since that, if you pass them a display, they waste time getting to the mode from the display then getting the private data structure, that's what they current evstack cvs sources do. It matters for an operation like dac_set_clut doing 256 times that in a row. Moreover, it looks like it's not always possible to get back to the parent display of a mode, so what if i want to access my KGIM_PRIVATE data, in i.e. the set_font text operation which is passed a mode? ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Thu Jan 29 09:06:43 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA12535 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 09:06:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA12752; Thu, 29 Jan 1998 11:30:38 -0500 Resent-Date: Thu, 29 Jan 1998 11:30:38 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Modification in driver API ? Date: 29 Jan 1998 16:29:04 GMT Organization: OnTV Pittsburgh, L.P. Lines: 103 Distribution: local Message-ID: <6aqaog$t15$3@grits.visus.com> References: <6ansja$7bl$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"SoOIp1.0.Y63.duAqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/559 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [This time, UUencoded...] begin 664 article.txt M4W5B:F5C=#H@4F4Z($UO9&EF:6-A=&EO;B!I;B!D<FEV97(@05!)(#\*3F5W M<V=R;W5P<SH@;&ES=',N;&EN=7@N9V=I+F5V<W1A8VL*4F5F97)E;F-E<SH@ M/#9A;G-J820W8FPD,4!G<FET<RYV:7-U<RYC;VT^"E)E<&QY+51O.B!J;6-C M0&]N='8N8V]M"D1I<W1R:6)U=&EO;CH@;&]C86P*"D5M;6%N=65L($UA<G1Y M("AC;W)E0&UI<G5S+F9R*2!W<F]T93H*/B!M;W9I;F<@=&AE(&-H:7!S970@ M<')I=F%T92!D871A(&9R;VT@9&ES<&QA>2!T;R!M;V1E('=O=6QD+"!)('1H M:6YK+`H^(')E<75I<F4@=&AA="!C:&EP<V5T(')E9VES=&5R(&%C8V5S<R!F M=6YC=&EO;G,@*$1!0U]O=70X+"!E=&,I(&%R90H^(&=I=F5N(&$@<&]I;G1E M<B!T;R!T:&4@;6]D92!R871H97(@=&AA;B!T:&4@9&ES<&QA>2X@:68@:70@ M9&]E<VXG=`H^(&UA='1E<B!F;W(@5D=!('=H:6-H(&1O97-N)W0@;6%K92!U M<V4@;V8@:70@870@86QL+"!I="!D;V5S(&UA='1E<@H^(&9O<B!O=&AE<B!D M<FEV97(@<W5C:"!A<R!M961I84=8(&-A8VAI;F<@<F5G:7-T97(@;6UI;R!P M;VEN=&5R<PH^('1H97)E+"!F;W(@97AA;7!L92X@:2!D:60@86QL('1H92!N M96-E<W-A<GD@8VAA;F=E<R!I;B!T:&4@:6YC;'5D97,L"CX@=&AE;B!A;&P@ M;F5C97-S87)Y(&1R:79E<G,@9F]R(&-O;7!I;&EN9R!61T$@86YD(&UE9&EA M1U@@86YD(&ET"CX@<W1I;&P@=V]R:W,@9FEN92XN('=I=&@@=&AO<V4@8VAA M;F=E<R!I(&-A;B!G;R!F=7)T:&5R('=I=&@@=&AE"CX@<&]R=&EN9RX@<VAO M=6QD(&D@8V]M;6ET('1H96TL(&]R(&ES('-O;65O;F4@86=A:6YS="!T:&4@ M8VAA;F=E"CX@*')E<75I<F5S(&UO<F4@<&]R=&EN9R!W;W)K+"!B=70@:2!T M:&EN:R!I="=S(&YE8V5S<V%R>2XN(&EF(&ET"CX@:7-N)W0L('1H96X@:70@ M:7-N)W0@;&]G:6-A;"!A;F0@<')I=F%T92!D871A('-H;W5L9"!S=&%Y(&EN M"CX@=&AE(&MG:5]D:7-P;&%Y*0H*"49R;VT@=&AE('=A>2P@22!T86ME(&ET M+"!D<FEV97)?9&%T82!S:&]U;&0@8F4@9F]R(`ID<FEV97(M<W!E8VEF:6,@ M9&%T82`H:64L($U-24\@<F5G:6]N<R!T:&%T(&%R92!I;B!U<V4L(&5T8RDL M(`IA;F0@;6]D95]D871A('-H;W5L9"!B92!D871A(%]S<&5C:69I8U\@=&\@ M=&AA="!M;V1E+@H*"51H96]R971I8V%L;'DL(&$@2T=)(&ME<FYE;"!M;V1U M;&4@<VAO=6QD(&)E(&%B;&4@=&\@"F!C:&5C:U]M;V1E)R!A(&UO9&4L(&=E M;F5R871E('1H92!+1TD@;6]D92P@86YD(&-A8VAE(&ET(&9O<B`*;&%T97(@ M=7-E+B!;5&AE<F4@87)E(&!L;V-K(&1O=VXG(&UE8VAA;FES;7,@:6X@;7D@ M8W5R<F5N="!C;V1E8F%S92`*=&AA="!))VT@=V]R:VEN9R!O;B!T;R!H96QP M('=I=&@@=&AI<RY="@H)02!+1TD@;6]D=6QE(%MI92P@+V1E=B]G<F%P:%T@ M<VAO=6QD($].3%D@8V%R92!A8F]U="`*=&AE(&MG:5]M;V1E('-T<G5C="X@ M5&AE(&MG:5]D:7-P;&%Y('-T<G5C="!I<R!H:61D96X@87=A>2!B>2`*2T=) M(&ET<V5L9BX@"@H)2T=)(&1I<W!L87D@9')I=F5R<R!W:6QL('-T:6QL(&1E M86P@=VET:"!T:&4@:V=I7V1I<W!L87D*<W1R=6-T+"!A<R!T:&5Y(&%R92!I M;G1I;6%T96QY('1I960@=&\@:70G<R!D969I;FET:6]N+@H*"4=I=F5N('1H M870L($1!0U\J(&%N9"!F<FEE;F1S('=I;&P@<')O8F%B;'D@;F5E9"!T:&4@ M"F!D:7-P;&%Y+7=I9&4G(&EN9F]R;6%T:6]N(&EN(&1R:79E<E]D871A+"!S M;R!Y;W4@<VAO=6QD(&ME97`@"G1H96T@=&AE('=A>2!T:&5Y(&%R92!N;W<N M($EE+"!$04-?;W5T."!M87D@;F5E9"!T;R!K;F]W('1H92`*34U)3R!R96=I M;VX@=&AE(&1I<W!L87D@:7,@=7-I;F<@*'9I82!D<'DM/F1I<W!L87E?9&%T M82DL(&)U="!M87D*86QS;R!N965D('1O(&MN;W<@<V]M92!M;V1E(&EN9F]R M;6%T:6]N("AV:6$@9'!Y+3YM;V1E7V1A=&$I"@H)5VAA="!W92=L;"!P<F]B M86)L>2!E;F0@=7`@=VET:"!I<R`*<V]M971H:6YG(&QI:V4Z"@I;<V]R<GDL M(&=O="!K:6YD82!C87)R:65D(&%W87D@8V]D:6YG+BXN70H*<W1R=6-T(&MG M:5]M;V1E("ID979?9W)A<&A?<F5Q=65S=%]M;V1E*&EN="!H96%D+&=G:5]M M;V1E("IR97$I"GL*"6MG:5]M;V1E("IM;V1E.PH):6YT(&5R<CL*"@DO*B!! M;&QO8V%T92!M96UO<GD@=&\@82!K9VE?;6]D92!S=')U8W0@:6X@2T=)"@DJ M+PH);6]D93UK9VE?:&5A9%]A;&QO8V%T95]M;V1E*&AE860I.PH);65M<V5T M*"9M;V1E+3YR97%U97-T+"9G9VE?<F5Q=65S=&5D7VUO9&4L<VEZ96]F*&=G M:5]M;V1E*2D["@H)+RH@8$-O;G9E<G0G('1H92!R97%U97-T960@;6]D92!I M;G1O('1I;6EN9R!D871A+B`*"2HJ($YO(&UE;6]R>2!I<R!A;&QO8V%T960@ M=&\@=&AE(&UO9&4@870*"2HJ('1H:7,@=&EM92X@"@DJ+PH)97)R/6MG:5]H M96%D7V-H96-K7VUO9&4H:&5A9"QM;V1E+$--1%]04D]03U-%*3L*"6EF("AE M<G(I(&=O=&\@97)R;W(["@H)+RH@3VX@=&AE(&!#341?0TA%0TLG+"!W92=R M92!S87EI;F<@=&AA="!W90H)*BH@<F5A;&QY('=A;G0@=&AI<R!M;V1E+B!) M9B!I="!V97)I9FEE<R!/2RP*"2HJ(&UE;6]R>2!I<R!A;&QO8V%T960@=&\@ M;6]D95]D871A("AI9B!N965D960I"@DJ*B!F;W(@;6]D92!S=&%T92!I;F9O M+@H)*BH*"2HJ($%L<V\L('-E="!U<"!T:&4@;6UI;RP@86-C96PL('1E>'1O M<"P@86YD(&9B('-T<G5C=',*"2HJ"@DJ*B!.3U1%.B!)9B!#341?0TA%0TL@ M<F5T=7)N($5/2RP@>6]U(&-A;B!S869E;'D*"2HJ"2!C86-H92!T:&ES(&UO M9&4@87=A>2P@87,@2T=)('=I;&P@:&%V90H)*BH)('!E<F9O<FUE9"!A;F0@ M:6UP;&EC:70@)V%C<75I<F4H*2<@;VX*"2HJ"2!T:&4@9&ES<&QA>2`H=7-U M86QL>2!-3T1?24Y#7U5315]#3U5.5"D*"2HO"@EE<G(]:V=I7VAE861?8VAE M8VM?;6]D92AH96%D+&UO9&4L0TU$7T-(14-+*3L*"6EF("AE<G(I(&=O=&\@ M97)R;W(["@H)+RH@06QL;V-A=&4@96YT<FEE<R!F;W(@=&AE($U-05`@<F5G M:6]N<RP@971C+BXN"@DJ+PH*"7)E='5R;B!M;V1E.PH*97)R;W(Z"@EK9VE? M:&5A9%]F<F5E7VUO9&4H:&5A9"QM;V1E*3L*"7)E='5R;B!.54Q,.PI]"@IS M=')U8W0@:6YT(&1E=E]G<F%P:%]A8W1I=F%T95]M;V1E*&EN="!H96%D+&MG M:5]M;V1E("IM;V1E*0I["@EI;G0@97)R.PH*"2\J(%=E(&MN;W<@:70G<R!A M;')E861Y(&-H96-K960@9F]R('1H:7,@:&5A9"P*"2HJ(&%N9"!T:&4@7V%L M;&]C871E7VUO9&4H*2!D:60@86X@:6UP;&EC:70*"2HJ(&!A8W%U:7)E)R!O M9B!T:&4@9&ES<&QA>2!D<FEV97(@<V\@=&AA="!I=`H)*BH@8V%N)W0@9')O M<"!F<F]M('5N9&5R('5S+@H)*B\*"65R<CUK9VE?:&5A9%]S971?;6]D92AH M96%D+&UO9&4I.PH):68@*&5R<BD@<F5T=7)N(&5R<CL*"@DO*B!.;W<@=V4@ M<V5T('5P('1H92!-34%0(')E9VEO;G,@=&AA="!H879E(&)E96X*"2HJ(')E M<75E<W1E9"!F;W(@=&AI<R!M;V1E+"!C;&5A<B!T:&4@9G)A;65B=69F97(L M"@DJ*B!S970@=&AE($-,550L(&%N9"!A;&P@=&AA="!J87IZ+@H)*B\*"@ER M971U<FX@14]+"GT*"G-T<G5C="!I;G0@9&5V7V=R87!H7V9R965?;6]D92AI M;G0@:&5A9"QK9VE?;6]D92`J;6]D92D*>PH)+RH@3F]W('1H870@=V4G<F4@ M9FEN:7-H960@=VET:"!T:&4@;6]D92P@=V4*"2HJ(&-A;B!A<VL@=&AE(&1R M:79E<B!T;R!R96QE87-E('1H92!M96UO<GD*"2HJ(&%L;&]C871E9"!T;R!I M="X*"2HJ"@DJ*B!4:&ES(&%L<V\@<&5R9F]R;7,@86YD(&EM<&QI8VET(&!R M96QE87-E)PH)*BH@;V8@=&AE(&1I<W!L87D@9')I=F5R+"!D96-R96%S:6YG M(&ET)W,@"@DJ*B!U<V4@8V]U;G0@*'5S=6%L;'DL($U/1%]$14-?55-%7T-/ M54Y4*0H)*B\*"7)E='5R;B!K9VE?:&5A9%]F<F5E7VUO9&4H:&5A9"QM;V1E M*3L*?0H*"0H*+2T*2F%S;VX@36--=6QL86X@+2!,:6YU>"`M($='22`M(&AT M='`Z+R]B96%N<RYV:7-U<RYC;VTO?FIM8V,*3E0@-2XP(&ES('1H92!L87-T M(&YA:6P@:6X@=&AE(%5N:7@@8V]F9FEN+B!);G1E<F5S=&EN9VQY+"!5;FEX M"FES;B=T(&EN('1H92!C;V9F:6XN+BX@270G<R!W;VYD97)I;F<@=VAA="!T M:&4@:&5C:R!I<R!S96%L:6YG(`II='-E;&8@:6YT;R!A('=O;V1E;B!B;W@@ 7-B!F965T('5N9&5R9W)O=6YD+BXN(`H` ` end -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 09:51:13 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA12564 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 09:51:12 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA13247; Thu, 29 Jan 1998 12:15:08 -0500 Resent-Date: Thu, 29 Jan 1998 12:15:08 -0500 Sender: core@tron.mirus.fr Message-ID: <34D0B44B.14924CFA@mirus.fr> Date: Thu, 29 Jan 1998 17:54:35 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: jmcc@ontv.com CC: evstack@ontv.com Subject: Re: Modification in driver API ? References: <199801291637.LAA08735@beans.visus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"fIZ6u2.0.SD3.YSBqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/560 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan was quick in replying: > 'Emmanuel Marty wrote with particular insight...' > > So, why does KGIM_PRIVATE retrieve data from mode->mode_data now > > instead of dpy->driver_data as it used to be ? Either KGIM_PRIVATE > > should be changed to behave the old way, or the routines using it > > must be passed a mode pointer, not a display one - since that, if > > you pass them a display, they waste time getting to the mode from > > the display then getting the private data structure, that's what > > they current evstack cvs sources do. It matters for an operation > > like dac_set_clut doing 256 times that in a row. > > Gak. Why not just make them `extern inline' functions? GCC > is reasonably good about that kind of optimization, IIRC. > > > Moreover, it looks like it's not always possible to get back > > to the parent display of a mode, so what if i want to access > > my KGIM_PRIVATE data, in i.e. the set_font text operation which > > is passed a mode? > > My new sources have a `kgi_display *dpy' in the kgi_mode > struct. > > I have little idea what KGIM_PRIVATE is support to be for, > anyway. Please enlighten me. [I feel, also, that we're talking > `cross purposes' here - are we discussing orthoginal arguments :^?) Correct me if I'm wrong, but KGIM_PRIVATE is used to avoid having global variables in the drivers. Probably so that if identical cards are used in multihead, the same module can be used several times without triggering expensive copy-on-write operations. The chipset (or ramdac, clock etc) private structure has been, so far, linked to the display. It is cleaner anyway. I know there is a dpy pointer in the mode structure, what I meant is, it does not always point to something valid. When the set_font operation is called, it contains NULL (so says the segfault). Since KGIM_PRIVATE doesn't really matter to you or to the vga driver :), I propose two options : 1] I change KGIM_PRIVATE to retrieve data from the display structure, as it always used to be. This implies that textops are passed a pointer to a display, not a mode. 2] I use global vars in my driver, and the use of KGIM_PRIVATE is deprecated. This is possible too, but ouch. Tell me which way to go, so that I can finish that damned porting and write that paper .. The first way is the one that implies the less porting work and is the cleaner, but you're the captain. Apart from that, no need to resend 5 times the mail to the list, I was just wondering if you had read mine, since noone usually answers my posts. ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Thu Jan 29 10:34:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA12620 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 10:34:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id MAA13606; Thu, 29 Jan 1998 12:58:12 -0500 Resent-Date: Thu, 29 Jan 1998 12:58:12 -0500 Message-Id: <199801291754.MAA01889@dew.wserv.com> From: "Jordan Mendelson" <jordy@wserv.com> To: "Evstack" <evstack@ontv.com> Subject: Current Status (State of the Union :) Date: Thu, 29 Jan 1998 12:51:58 -0500 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Resent-Message-ID: <"3yJFN3.0.OJ3.d8Cqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/561 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi all, I just wanted to know if someone could give me a quick status update on what's completed in EvStack. >From what I understand /dev/event is probably 85% complete? Has the driver API is pretty much settled down? What about /dev/graph? Does libggi compile and work yet? Does the svgalib emulation lib compile and work yet? And finally, the 100 dollar question: When do you think EvStacks will be in a usable state for main tree integration? (cvs checkout degas). Last I checked, cvs checkout degas didn't give me much and the last kernel patch was for 2.1.77. (I've learned that cvs checkout blah in my version does a cvs update if it already has the files, a lot less typing is involved :). Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Thu Jan 29 10:43:40 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA12663 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 10:43:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA13885; Thu, 29 Jan 1998 13:07:38 -0500 Resent-Date: Thu, 29 Jan 1998 13:07:38 -0500 Sender: core@tron.mirus.fr Message-ID: <34D0C1A0.502ED7AF@mirus.fr> Date: Thu, 29 Jan 1998 18:51:28 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Jim Ursetto <ursetto@uiuc.edu> CC: evstack@ontv.com, linux-ggi@eskimo.com Subject: Re: ANNOUNCE: MediaGX driver update References: <34D04835.AB2178@mirus.fr> <19980129115931.08434@3e8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ahgQi2.0.zN3.zHCqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/562 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jim Ursetto wrote: > OK, maybe you can answer my one driver porting question directly. If you've > almost fully ported your driver to EvStack, how are you testing that it > works completely (and by this I mean graphics)? I'm unable to get any > graphics to work when using the VGA driver, and this is stopping me from > porting my own driver, since obviously I can't test it. I'm just curious if > you're using a specific program to display graphics (/dev/graph doesn't work > at all over here right now). > > And hurry up and write that porting documentation!! ;) No, I'll figure it > out myself, if I can just test the damn thing. Hehe.. Well, I posted about that on the EvStack mailing list. The first thing you need to do is : cd /dev /wherever-evstack-is/patches/Linux/MAKEDEV.ggi this will build the required graphic/event/vty files. Then ln -s /graph00 graphic Looks like the script forgets to do that. Last, edit /etc/conf.modules and add "alias char-major-121 devgraph" Redo depmod -a. Doing all of this, it works for me. Well, I still have MMIO trouble with my MediaGX driver, but at least it works (even textemulation does now.. woo hoo.. :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Thu Jan 29 10:59:17 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id KAA12687 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 10:59:16 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id NAA14035; Thu, 29 Jan 1998 13:23:07 -0500 Resent-Date: Thu, 29 Jan 1998 13:23:07 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: Modification in driver API ? Date: 29 Jan 1998 18:21:38 GMT Organization: OnTV Pittsburgh, L.P. Lines: 38 Distribution: local Message-ID: <6aqhbi$6lt$1@grits.visus.com> References: <6aqdo5$3ra$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"7jO0c2.0.bQ3.8YCqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/563 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > I know there is a dpy pointer in the mode structure, what I meant is, > it does not always point to something valid. When the set_font > operation is called, it contains NULL (so says the segfault). Oops! Bug bug! > Since KGIM_PRIVATE doesn't really matter to you or to the vga driver :), > I propose two options : > 1] I change KGIM_PRIVATE to retrieve data from the display structure, > as it always used to be. > This implies that textops are passed a pointer to a display, not > a mode. Ding ding ding - sounds like the right answer. I don't know what I was smoking when I said it should be mode_data.. I think I thought teunis was referring to vga_text16.inc.... > Tell me which way to go, so that I can finish that damned porting > and write that paper .. The first way is the one that implies the > less porting work and is the cleaner, but you're the captain. Go the first way. I was stoopide when I said it should be the other way 'round... > Apart from that, no need to resend 5 times the mail to the list, I was just > wondering if you had read mine, since noone usually answers my posts. No, it kept popping up in my newsreader as blank... I think my mail->news system is hokey or something.... -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Thu Jan 29 11:39:29 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA12756 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 11:39:26 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA14585; Thu, 29 Jan 1998 14:03:31 -0500 Resent-Date: Thu, 29 Jan 1998 14:03:31 -0500 Date: Thu, 29 Jan 1998 12:12:35 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: Re: More comments In-Reply-To: <m0xxsRQ-0000XZC@charon.beck-sw.de> Message-ID: <Pine.LNX.3.96.980129120942.1188A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"trAlT.0.wY3.08Dqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/564 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Thu, 29 Jan 1998 becka@rz.uni-duesseldorf.de wrote: > > Just to follow up, I hardcoded TEXTX to be 8 in both show_cursor functions > > and it works perfectly, although it's not a permanent solution. > Good. Now that the culprit is found, we can probably squash the bug easily > (Jason ?). Did some hunting - but didn't find it yet *sigh*... Maybe someone else has got it already? (otherwise I'll look again tonight) > > BTW, _is_ the mouse usable in X? > > Yes. The trick is _not_ to insert the EvStack mouse module and use the > traditional device. At least this works for serial mice. Works fine! (also - if you have two mice installed *grin*, the first could be X and the second EvStack without problems :) Tested - works! > Other than that Teunis (?) is working on a GPM-like mouse-emulator on a pipe. > This allows you to tell all traditional programs you have a mousesystems > mouse on /tmp/some_pipe. Yep :) Just recompiling EvStack kernel now with new updates... (hopefully /dev/graphic is getting closer... :) Then I'll start working with that demo-proggy for the stack... It's exactly what I was looking for :) G'day, eh? :) - Teunis PS: sure are a lot of :)'s, eh? From evstack-request@ontv.com Thu Jan 29 11:53:11 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id LAA12777 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 11:53:09 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA14754; Thu, 29 Jan 1998 14:17:18 -0500 Resent-Date: Thu, 29 Jan 1998 14:17:18 -0500 Date: Thu, 29 Jan 1998 12:25:57 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Emmanuel Marty <core@mirus.fr> cc: EvStack list <evstack@ontv.com> Subject: Re: Modification in driver API ? In-Reply-To: <34D0B44B.14924CFA@mirus.fr> Message-ID: <Pine.LNX.3.96.980129122500.1188B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"OFNCS3.0.Xb3.ZKDqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/565 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > Apart from that, no need to resend 5 times the mail to the list, I was just > wondering if you had read mine, since noone usually answers my posts. > > ----------------------------------------------------------------------------- > Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org > GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! > ----------------------------------------------------------------------------- > That's because your posts tend to make a lot of sense and I never see the reason to add anything :) G'day, eh? :) - Teunis From evstack-request@ontv.com Thu Jan 29 12:32:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA12817 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 12:31:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA15079; Thu, 29 Jan 1998 14:55:31 -0500 Resent-Date: Thu, 29 Jan 1998 14:55:31 -0500 Date: Thu, 29 Jan 1998 13:03:55 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: more /dev/graph tests Message-ID: <Pine.LNX.3.96.980129130039.4413B-200000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463800064-1286201164-886104235=:4413" Resent-Message-ID: <"hDmLx1.0.lg3.AuDqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/566 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463800064-1286201164-886104235=:4413 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay... ran the MAKEDEV.ggi script (thanks BTW - I didn't know about that) Linked /dev/graph01 to /dev/graphic (to match the fact I was using VT01 at the time....) [also set LIBGGI_DISPLAY=display-KGI:/dev/graphic] BTW - /dev/graphic _SHOULD_ follow the console-switch! OOPS no longer happened. Mode-set worked. Video crashed *sigh*. Recovered by removing ggidrv and running "kon" - savetextmode/restoretextmode under svgalib don't work so hot for me... No sign (yet) what happened... but I'll look some more (VGA driver) Attached is dmesg output... G'day, eh? :) - Teunis ---1463800064-1286201164-886104235=:4413 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=booga_list Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.980129130355.4413C@sigil.computersupportcentre.com> Content-Description: NTU4OiBhbGxvY2F0aW5nIC9kZXYvZ3JhcGgwMSAuLi4gDQowMDU5OWM4MTpk ZXZncmFwaC5jOjU3MTogb3BlbiBvbiAvZGV2L2dyYXBoMDENCjAwNTk5Yzgy OmRldmdyYXBoLmM6NzQxOiBIZWFkIDAgaXMgYnVzeQ0KMDA1OTljODI6ZGV2 Z3JhcGguYzo3NDE6IEhlYWQgMCBpcyBidXN5DQowMDU5OWZhZjpkZXZncmFw aC5jOjExNTg6IFVubG9hZGVkIC9kZXYvZ3JhcGggc3VwcG9ydA0Ka21lbV9j cmVhdGU6IER1cCBuYW1lIC0gZ3JhcGhfdnRfaW5mbw0Ka21lbV9jcmVhdGU6 IER1cCBuYW1lIC0gZ3JhcGhfdnRfY2x1dA0KMDA1OWEwNGU6ZGV2Z3JhcGgu YzoxMTM4OiBMb2FkZWQgL2Rldi9ncmFwaCBzdXBwb3J0DQowMDU5YTA0ZTpk ZXZncmFwaC5jOjU0OTogZ3JhcGhfb3BlbiAoY29uaWQgPSAweDAxKQ0KMDA1 OWEwNGU6ZGV2Z3JhcGguYzo1NTg6IGFsbG9jYXRpbmcgL2Rldi9ncmFwaDAx IC4uLiANCjAwNTlhMDRmOmRldmdyYXBoLmM6NTcxOiBvcGVuIG9uIC9kZXYv Z3JhcGgwMQ0KMDA1OWEwNGY6ZGV2Z3JhcGguYzo3NTk6IGdyYXBoX2lvY3Rs OiBkcml2ZXIgY29tbWFuZCBjMDE4MDAxMg0KMDA1OWEwNGY6ZGV2Z3JhcGgu Yzo2Nzk6IGRldmdyYXBoX2lvY3RsKERSSVZFUl9TRVRHUkFQSE1PREUpOiBH ZXR0aW5nIG1vZGUgZnJvbSBiZmZjZGZjOA0KMDA1OWEwNTA6ZGV2Z3JhcGgu Yzo2OTA6IGRldmdyYXBoX2lvY3RsKFNFVEdSQVBITU9ERSk6IFB1dHRpbmcg bW9kZSB0byBiZmZjZGZjOA0KMDA1OWEwNTA6ZGV2Z3JhcGguYzo2OTc6IGRl dmdyYXBoX2lvY3RsKFNFVEdSQVBITU9ERSk6IFNldHRpbmcgVlRZMDEncyBt b2RlDQowMDU5YTA1MDpkZXZncmFwaC5jOjQ3NDogZ3JhcGhfc2V0dXBfbW9k ZTogU2V0dGluZyB1cCAvZGV2L2dyYXBoMDENCjAwNTlhMDUwOmRldmdyYXBo LmM6NTEzOiBncmFwaF9zZXR1cF9kcHkoMCk6IEdldHRpbmcgZGVmYXVsdCBj bHV0IGZvciAxIGZyYW1lcw0KMDA1OWEwNTA6ZGV2Z3JhcGguYzo3MDk6IGRl dmdyYXBoX2lvY3RsKERSSVZFUl9TRVRHUkFQSE1PREUpOiBPayENCjAwNTlh MDUwOmRldmdyYXBoLmM6NzY5OiBpb2N0bCBmaW5pc2hlZCwgZXJyPTB4MDAw MDAwMDANCjAwNTlhMDUxOmRldmdyYXBoLmM6Nzg2OiBtbWFwKCk6IGRldiAx LCA0MDBkNDAwMC00MDBlNDAwMCwgb2Zmc2V0IDEsIHNpemUgMTAwMDANCjAw NTlhMDUxOmRldmdyYXBoLmM6ODA1OiBtbWlvIHBlci10eXBlICgweDAwMDEp IG1hcHBpbmcNCjAwNTlhMDUxOmRldmdyYXBoLmM6ODIxOiBObyByZWdpb24g Zm9yIDQwDQowMDU5YTA1NDpkZXZncmFwaC5jOjc2MjogZ3JhcGhfaW9jdGw6 IGRpc3BhdGNoZWQgY29tbWFuZCBjMjA0MDUwMQ0KMDA1OWEwNTQ6ZGV2Z3Jh cGguYzo3Njk6IGlvY3RsIGZpbmlzaGVkLCBlcnI9MHgwMDAwMDAwMA0KMDA1 OWEwNTY6ZGV2Z3JhcGguYzo3NjI6IGdyYXBoX2lvY3RsOiBkaXNwYXRjaGVk IGNvbW1hbmQgYzIwNDA1MDENCjAwNTlhMDU2OmRldmdyYXBoLmM6NzY5OiBp b2N0bCBmaW5pc2hlZCwgZXJyPTB4MDAwMDAwMDANCjAwNTlhMDU2OmRldmdy YXBoLmM6NzYyOiBncmFwaF9pb2N0bDogZGlzcGF0Y2hlZCBjb21tYW5kIGM2 MDAwMjExDQowMDU5YTA1NzpkZXZncmFwaC5jOjc2OTogaW9jdGwgZmluaXNo ZWQsIGVycj0weDAwMDAwMDAwDQowMDU5YTA1NzpkZXZncmFwaC5jOjc2Mjog Z3JhcGhfaW9jdGw6IGRpc3BhdGNoZWQgY29tbWFuZCAwMDAwMDQxMQ0KMDA1 OWEwNTc6ZGV2Z3JhcGguYzo3Njk6IGlvY3RsIGZpbmlzaGVkLCBlcnI9MHhm YmZmZmZmZg0KMDA1OWFmNWU6bnVsbHNjcm9sbC5jOjExNTogbnVsbHNjcm9s bF9jcmVhdGUoYzEwOGE4MDApOiBTdGFydA0KMDA1OWFmNWU6bnVsbHNjcm9s bC5jOjE2NzogbnVsbHNjcm9sbF9jcmVhdGU6IFN1Y2Nlc3NmdWwNCjAwNTlh ZjVlOm51bGxzY3JvbGwuYzoyNDY6IG51bGxzY3JvbGxfc2V0X21vZGU6IFNl dHRpbmcgbW9kZSBvZiBjMTA4YTgwMA0KMDA1OWFmNWU6bnVsbHNjcm9sbC5j OjMxMDogbnVsbHNjcm9sbF9zZXRfbW9kZTogTWFwIGNvbXBsZXRlDQowMDU5 YWY1ZTpudWxsc2Nyb2xsLmM6MTE1OiBudWxsc2Nyb2xsX2NyZWF0ZShjMDNi YWM2MCk6IFN0YXJ0DQowMDU5YWY1ZjpudWxsc2Nyb2xsLmM6MTY3OiBudWxs c2Nyb2xsX2NyZWF0ZTogU3VjY2Vzc2Z1bA0KMDA1OWFmNWY6bnVsbHNjcm9s bC5jOjI0NjogbnVsbHNjcm9sbF9zZXRfbW9kZTogU2V0dGluZyBtb2RlIG9m IGMwM2JhYzYwDQowMDU5YWY1ZjpudWxsc2Nyb2xsLmM6MzEwOiBudWxsc2Ny b2xsX3NldF9tb2RlOiBNYXAgY29tcGxldGUNCjAwNTlhZjVmOm51bGxzY3Jv bGwuYzoxMTU6IG51bGxzY3JvbGxfY3JlYXRlKGMwZWQwZDgwKTogU3RhcnQN CjAwNTlhZjVmOm51bGxzY3JvbGwuYzoxNjc6IG51bGxzY3JvbGxfY3JlYXRl OiBTdWNjZXNzZnVsDQowMDU5YWY1ZjpudWxsc2Nyb2xsLmM6MjQ2OiBudWxs c2Nyb2xsX3NldF9tb2RlOiBTZXR0aW5nIG1vZGUgb2YgYzBlZDBkODANCjAw NTlhZjVmOm51bGxzY3JvbGwuYzozMTA6IG51bGxzY3JvbGxfc2V0X21vZGU6 IE1hcCBjb21wbGV0ZQ0KMDA1OWFmNWY6bnVsbHNjcm9sbC5jOjExNTogbnVs bHNjcm9sbF9jcmVhdGUoYzAwOGQ1YzApOiBTdGFydA0KMDA1OWFmNWY6bnVs bHNjcm9sbC5jOjE2NzogbnVsbHNjcm9sbF9jcmVhdGU6IFN1Y2Nlc3NmdWwN CjAwNTlhZjVmOm51bGxzY3JvbGwuYzoyNDY6IG51bGxzY3JvbGxfc2V0X21v ZGU6IFNldHRpbmcgbW9kZSBvZiBjMDA4ZDVjMA0KMDA1OWFmNWY6bnVsbHNj cm9sbC5jOjMxMDogbnVsbHNjcm9sbF9zZXRfbW9kZTogTWFwIGNvbXBsZXRl DQowMDU5YWY2MDpudWxsc2Nyb2xsLmM6MTE1OiBudWxsc2Nyb2xsX2NyZWF0 ZShjMTA4YTRhMCk6IFN0YXJ0DQowMDU5YWY2MDpudWxsc2Nyb2xsLmM6MTY3 OiBudWxsc2Nyb2xsX2NyZWF0ZTogU3VjY2Vzc2Z1bA0KMDA1OWFmNjA6bnVs bHNjcm9sbC5jOjI0NjogbnVsbHNjcm9sbF9zZXRfbW9kZTogU2V0dGluZyBt b2RlIG9mIGMxMDhhNGEwDQowMDU5YWY2MDpudWxsc2Nyb2xsLmM6MzEwOiBu dWxsc2Nyb2xsX3NldF9tb2RlOiBNYXAgY29tcGxldGUNCjAwNTlhZjYwOm51 bGxzY3JvbGwuYzoxMTU6IG51bGxzY3JvbGxfY3JlYXRlKGMxMDhhMDIwKTog U3RhcnQNCjAwNTlhZjYwOm51bGxzY3JvbGwuYzoxNjc6IG51bGxzY3JvbGxf Y3JlYXRlOiBTdWNjZXNzZnVsDQowMDU5YWY2MDpudWxsc2Nyb2xsLmM6MjQ2 OiBudWxsc2Nyb2xsX3NldF9tb2RlOiBTZXR0aW5nIG1vZGUgb2YgYzEwOGEw MjANCjAwNTlhZjYwOm51bGxzY3JvbGwuYzozMTA6IG51bGxzY3JvbGxfc2V0 X21vZGU6IE1hcCBjb21wbGV0ZQ0KMDA1OWFmNjA6bnVsbHNjcm9sbC5jOjEx NTogbnVsbHNjcm9sbF9jcmVhdGUoYzA0NDE2YzApOiBTdGFydA0KMDA1OWFm NjA6bnVsbHNjcm9sbC5jOjE2NzogbnVsbHNjcm9sbF9jcmVhdGU6IFN1Y2Nl c3NmdWwNCjAwNTlhZjYwOm51bGxzY3JvbGwuYzoxMTU6IG51bGxzY3JvbGxf Y3JlYXRlKGMwNDQxYjQwKTogU3RhcnQNCjAwNTlhZjYxOm51bGxzY3JvbGwu YzoxNjc6IG51bGxzY3JvbGxfY3JlYXRlOiBTdWNjZXNzZnVsDQowMDU5YWY2 MTpudWxsc2Nyb2xsLmM6MjQ2OiBudWxsc2Nyb2xsX3NldF9tb2RlOiBTZXR0 aW5nIG1vZGUgb2YgYzBlZDBkODANCjAwNTlhZjYxOm51bGxzY3JvbGwuYzoz MTA6IG51bGxzY3JvbGxfc2V0X21vZGU6IE1hcCBjb21wbGV0ZQ0KMDA1OWFm NjE6bnVsbHNjcm9sbC5jOjIxMDogbnVsbHNjcm9sbF9tYXA6IE1hcHBpbmcg YzBlZDBkODANCjAwNTlhZjYxOm51bGxzY3JvbGwuYzoyMTQ6IG51bGxzY3Jv bGxfbWFwOiBNYXAgY29tcGxldGUNCjAwNTlhZjYxOm51bGxzY3JvbGwuYzoy MjI6IG51bGxzY3JvbGxfbWFwOiBVbm1hcHBpbmcgYzBlZDBkODANCmdlbmVy aWMgbGluZWFyIGZyYW1lYnVmZmVyIEdyYXBoaWNzIERyaXZlciByZW1vdmVk DQpWR0EgY2xvY2sgZHJpdmVyIHVubG9hZGVkPDM+VkdBIERBQyBkcml2ZXIg cmVtb3ZlZC4NCg== ---1463800064-1286201164-886104235=:4413-- From evstack-request@ontv.com Thu Jan 29 15:15:47 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA13054 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 15:15:45 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA16755; Thu, 29 Jan 1998 17:38:40 -0500 Resent-Date: Thu, 29 Jan 1998 17:38:40 -0500 Message-ID: <19980129163615.50388@3e8.com> Date: Thu, 29 Jan 1998 16:36:15 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: /dev/graph?? minor number incorrect Mail-Followup-To: evstack@ontv.com References: <19980129162101.18880@3e8.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" X-Mailer: Mutt 0.89i In-Reply-To: <19980129162101.18880@3e8.com>; from Jim Ursetto on Thu, Jan 29, 1998 at 04:21:01PM -0600 X-Deities: e38 Resent-Message-ID: <"u-74t2.0.754.4HGqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/568 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii At 04:21 PM on 1998 January 29, Jim Ursetto did write: > Unfortunately, mknod doesn't parse hex numbers, and silently substitutes > zero. Here's a patch to fix this. All it does is change the three occurrences of 0x$h$v to $((0x$h$v)). Apply in the patches/Linux directory. DISCLAIMER!! Keep in mind this arithmetic expansion will only probably work with Bash v2.0 or above. This is just a quick fix. Thank you for flying USAir. ~ jim --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="MKDEV.uue" begin 644 MKDEV.patch M+2TM($U!2T5$158N9V=I+F]R:6<)5&AU($IA;B`R.2`Q-CHR-SHU,2`Q.3DX M"BLK*R!-04M%1$56+F=G:0E4:'4@2F%N(#(Y(#$V.C(W.C`Q(#$Y.3@*0$`@ M+3(U+#$Q("LR-2PQ,2!`0`H@9F]R(&@@:6X@,"`Q(#(@,R`T(#4@-B`W(#@@ M.2!!($(@0R!$($4@1CL@9&\*(`EF;W(@=B!I;B`P(#$@,B`S(#0@-2`V(#<@ M."`Y($$@0B!#($0@12!&.R!D;PH@"0ER;2`M9B!V='DD:"1V"BT)"6UK;F]D M("TM;6]D93TP-C8P('9T>21H)'8@8R`D1$565E197TU!2D]2(#!X)&@D=@HK M"0EM:VYO9"`M+6UO9&4],#8V,"!V='DD:"1V(&,@)$1%5E9465]-04I/4B`D M*"@P>"1H)'8I*0H@"0ER;2`M9B!G<F%P:"1H)'8*+0D);6MN;V0@+2UM;V1E M/3`V-C`@9W)A<&@D:"1V(&,@)$1%5D=205!(7TU!2D]2(#!X)&@D=@HK"0EM M:VYO9"`M+6UO9&4],#8V,"!G<F%P:"1H)'8@8R`D1$561U)!4$A?34%*3U(@ M)"@H,'@D:"1V*2D*(`D)<FT@+68@979E;G0D:"1V"BT)"6UK;F]D("TM;6]D M93TP-C8P(&5V96YT)&@D=B!C("1$159%5D5.5%]-04I/4B`P>"1H)'8**PD) M;6MN;V0@+2UM;V1E/3`V-C`@979E;G0D:"1V(&,@)$1%5D5614Y47TU!2D]2 M("0H*#!X)&@D=BDI"B`)"65C:&\@+6X@(G9T>21H)'8@9W)A<&@D:"1V(&5V 796YT)&@D=@TB"B`)9&]N90H@9&]N90H@ ` end --W/nzBZO5zC0uMSeA-- From evstack-request@ontv.com Thu Jan 29 15:18:39 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA13065 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 15:18:38 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA16831; Thu, 29 Jan 1998 17:42:17 -0500 Resent-Date: Thu, 29 Jan 1998 17:42:17 -0500 Message-ID: <19980129164114.09894@3e8.com> Date: Thu, 29 Jan 1998 16:41:14 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: more /dev/graph tests Mail-Followup-To: evstack@ontv.com References: <Pine.LNX.3.96.980129130039.4413B-200000@sigil.computersupportcentre.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <Pine.LNX.3.96.980129130039.4413B-200000@sigil.computersupportcentre.com>; from teunis on Thu, Jan 29, 1998 at 01:03:55PM -0700 X-Deities: e38 Resent-Message-ID: <"TjTTw1.0.P64.nLGqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/569 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 01:03 PM on 1998 January 29, teunis did write: > Okay... ran the MAKEDEV.ggi script (thanks BTW - I didn't know about that) > OOPS no longer happened. Mode-set worked. Video crashed *sigh*. > Recovered by removing ggidrv and running "kon" - > savetextmode/restoretextmode under svgalib don't work so hot for me... Once I changed the graph* etc. devices to have the proper minor numbers, I got demo to display the "Press any key to begin tests..." screen, before it crashed! Cool! -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Thu Jan 29 15:18:55 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id OAA13023 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 14:59:37 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA16635; Thu, 29 Jan 1998 17:22:30 -0500 Resent-Date: Thu, 29 Jan 1998 17:22:30 -0500 Message-ID: <19980129162101.18880@3e8.com> Date: Thu, 29 Jan 1998 16:21:01 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: /dev/graph?? minor number incorrect Mail-Followup-To: evstack@ontv.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i X-Deities: e38 Resent-Message-ID: <"HS8je3.0.J34.r2Gqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/567 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com I just noticed, after applying Emmanuel's advice (and getting devgraph support loaded! Now it lasts another couple of milliseconds before crashing!) that all the /dev/graph?? files the script creates have minor number 0. Upon checking the script, I found a typical creation command would be mknod --mode=0666 c graph38 121 0x38 Unfortunately, mknod doesn't parse hex numbers, and silently substitutes zero. My system is rather upgraded (bash 2, newest everything) but may have an old GNU fileutils (3.12), and maybe that's the problem. I don't know what's supposed to be doing the translation to decimal, but it's not being done, and I figured I'd inform you of this bug. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Thu Jan 29 16:22:21 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA13142 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 16:21:39 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA17553; Thu, 29 Jan 1998 18:44:49 -0500 Resent-Date: Thu, 29 Jan 1998 18:44:49 -0500 Message-ID: <19980129174350.61348@3e8.com> Date: Thu, 29 Jan 1998 17:43:50 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: more /dev/graph tests Mail-Followup-To: evstack@ontv.com References: <19980129164114.09894@3e8.com> <m0xy4NK-0000XaC@charon.beck-sw.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <m0xy4NK-0000XaC@charon.beck-sw.de>; from becka@rz.uni-duesseldorf.de on Fri, Jan 30, 1998 at 01:32:06AM +0100 X-Deities: e38 Resent-Message-ID: <"mgLHV.0.gH4.UGHqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/573 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 01:32 AM on 1998 January 30, becka@rz.uni-duesseldorf.de did write: [me:] > > Once I changed the graph* etc. devices to have the proper minor numbers, I > > got demo to display the "Press any key to begin tests..." screen, before it > > crashed! Cool! > IIRC it doesn't actually crash, but block on input indefinitely ... Actually it seems to just exit, leaving the VC in graphics mode. I have to rmmod and reinsert the driver to fix things. However, to do this I had to switch VCs, so I suppose the switch killed the waiting program. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Thu Jan 29 17:18:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA13121 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 16:08:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA17329; Thu, 29 Jan 1998 18:31:28 -0500 Resent-Date: Thu, 29 Jan 1998 18:31:28 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xy2ga-0000XaC@charon.beck-sw.de> Subject: Re: /dev/event _is_ working ... To: evstack@ontv.com Date: Thu, 29 Jan 1998 23:43:51 +0100 (MET) In-Reply-To: <m0xxtEC-00012NC@ajax> from "Andrew Apted" at Jan 29, 98 11:37:56 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"sGJR61.0.5D4.i2Hqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/570 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > The idea is rather to rip the code from devevent or the traditional > > graphic.c and get the eventstream directly via the /dev/graphic > > device. > > Oh right. I had thought that read & write on /dev/graphic would be > reserved for accessing the framebuffer or something... > > Okay, I reckon I could implement that if you like. Please do. I'm very busy here ... CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 17:19:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA13124 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 16:09:48 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA17406; Thu, 29 Jan 1998 18:33:18 -0500 Resent-Date: Thu, 29 Jan 1998 18:33:18 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xy4NK-0000XaC@charon.beck-sw.de> Subject: Re: more /dev/graph tests To: evstack@ontv.com Date: Fri, 30 Jan 1998 01:32:06 +0100 (MET) In-Reply-To: <19980129164114.09894@3e8.com> from "Jim Ursetto" at Jan 29, 98 04:41:14 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"l2pyH1.0.4F4.o5Hqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/572 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > OOPS no longer happened. Mode-set worked. Video crashed *sigh*. > > Recovered by removing ggidrv and running "kon" - > > savetextmode/restoretextmode under svgalib don't work so hot for me... > > Once I changed the graph* etc. devices to have the proper minor numbers, I > got demo to display the "Press any key to begin tests..." screen, before it > crashed! Cool! IIRC it doesn't actually crash, but block on input indefinitely ... CU,ANdy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 17:19:01 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA13120 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 16:07:55 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id SAA17311; Thu, 29 Jan 1998 18:30:18 -0500 Resent-Date: Thu, 29 Jan 1998 18:30:18 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xy3aX-0000XaC@charon.beck-sw.de> Subject: Re: Current Status (State of the Union :) To: evstack@ontv.com Date: Fri, 30 Jan 1998 00:41:41 +0100 (MET) In-Reply-To: <199801291754.MAA01889@dew.wserv.com> from "Jordan Mendelson" at Jan 29, 98 12:51:58 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"Fixlg3.0.PD4.m2Hqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/571 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > From what I understand /dev/event is probably 85% complete? Yep. Somewhere around that. Kernel code is fully functional. I'll write some demo code soon for things like speech recognition etc. > Has the driver API is pretty much settled down? You mean for the KGI driver ? Not completely. But the changes are not major. > What about /dev/graph? We are having slight problems with input, but I suppose they are fixed soon, as /dev/event works. > Does libggi compile and work yet? > Does the svgalib emulation lib compile and work yet? Both will be taken from the "traditional" tree. > When do you think EvStacks will be in a usable state for main tree > integration? (cvs checkout degas). Soon. Actually I say the Evstack kernel is even now more usable for everyday work than the GGI one (as I can run traditional X, SVGATextMode and friends). I really missed my 100x37 console. CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 18:46:05 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id SAA13308 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 18:46:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA18982; Thu, 29 Jan 1998 21:09:25 -0500 Resent-Date: Thu, 29 Jan 1998 21:09:25 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xy61k-0000WvC@charon.beck-sw.de> Subject: devevent ... more ... To: evstack@ontv.com (Evstack Mailing List) Date: Fri, 30 Jan 1998 03:17:56 +0100 (MET) Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"UxuTc1.0.ud4.gNJqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/574 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi PPL ! I played around with the devevent devices a bit more. The result is an enhanced deveventdump.c utility that actually does what the name says. The compile shows a lot of warnings, but they are only about unused inlines. However there are two real bugs in evstack.h that prevent it being used from usermode. Jason : Could you either armor the offending parts with "#ifdef __KERNEL__" or move it somewhere else, as suggested in the file ? I have stolen code from debug.c and the utility has now the following usage : deveventdump /dev/event?? [-r|-w] Without the options, /dev/event?? is dumped as if a debug-stack was attached. Up to now, it always dumps all types of events. This will change, so that you can give a mask for normal and one for consumed events. With the -r option you get "read" behaviour which reads the dev/event device and dumps it to stdout. This can be used to "grab" a session. With the -w option the inverse happens, stdin is copied to dev/event. Please note that this does not work yet, as the report_to property of the stack seems to be not set. My old code did that automatically on attaching a substack to a parent stack. Andrew : You probably know about how that works now, so could you enlighten me what to do (or simply do it) ? CU,Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Thu Jan 29 19:12:06 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA13345 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 19:12:04 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA19224; Thu, 29 Jan 1998 21:36:02 -0500 Resent-Date: Thu, 29 Jan 1998 21:36:02 -0500 Message-Id: <m0xy67q-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: devevent ... more ... To: evstack@ontv.com Date: Fri, 30 Jan 1998 13:24:14 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xy61k-0000WvC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 30, 98 03:17:56 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"UBWI2.0.kh4.smJqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/575 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > Please note that this does not work yet, as the report_to property of the > stack seems to be not set. My old code did that automatically on attaching > a substack to a parent stack. > > Andrew : You probably know about how that works now, so could you enlighten > me what to do (or simply do it) ? It should still work... checking... looks okay. I changed the logic slightly to handle multible parents. In substack.inc there is: if (what->report_to == 0) { what->report_to = whereto; } What is the output of /proc/sys/evstack/stack/12345678-devevent before and after attachment ? Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 29 19:14:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA13349 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 19:14:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA19291; Thu, 29 Jan 1998 21:38:02 -0500 Resent-Date: Thu, 29 Jan 1998 21:38:02 -0500 Message-Id: <m0xy6A2-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: /dev/event _is_ working ... To: evstack@ontv.com Date: Fri, 30 Jan 1998 13:26:30 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <m0xy2ga-0000XaC@charon.beck-sw.de> from "becka@rz.uni-duesseldorf.de" at Jan 29, 98 11:43:51 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TLGiP2.0.mi4.zoJqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/576 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Andreas Beck writes: > > > The idea is rather to rip the code from devevent or the traditional > > > graphic.c and get the eventstream directly via the /dev/graphic > > > device. > > > > Okay, I reckon I could implement that if you like. > > Please do. I'm very busy here ... Alrighty. Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 29 19:23:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id TAA13360 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 19:23:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id VAA19418; Thu, 29 Jan 1998 21:46:57 -0500 Resent-Date: Thu, 29 Jan 1998 21:46:57 -0500 Message-Id: <m0xy6IO-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: More comments To: evstack@ontv.com Date: Fri, 30 Jan 1998 13:35:08 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980129120942.1188A-100000@sigil.computersupportcentre.com> from "teunis" at Jan 29, 98 12:12:35 pm X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"3ux7t1.0.ak4.2xJqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/577 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [re: the cursor positioning bug] teunis writes: > Did some hunting - but didn't find it yet *sigh*... Maybe someone else > has got it already? (otherwise I'll look again tonight) I've narrowed it down to this: When the VTs are transferred to the nullscroll (during VGA driver insertion), it seems that getting the mode from the kgiscroll (through scroll_get_mode) fails, which then leaves the nullscroll's mode blank. This blank mode (i.e. all 0s) is then tried to be set when the VTs are transferred back to the kgiscroll, and this fails because text.x is not 8 or 9. I guess this causes the default text.x to be used instead, and they get out of sync... I still don't know why kgiscroll_get_mode() fails though... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Thu Jan 29 20:14:57 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA13408 for <ggi@synergy.foo.net>; Thu, 29 Jan 1998 20:14:56 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id WAA20025; Thu, 29 Jan 1998 22:38:45 -0500 Resent-Date: Thu, 29 Jan 1998 22:38:45 -0500 Message-ID: <19980129213732.38885@3e8.com> Date: Thu, 29 Jan 1998 21:37:32 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: More comments Mail-Followup-To: evstack@ontv.com References: <Pine.LNX.3.96.980129120942.1188A-100000@sigil.computersupportcentre.com> <m0xy6IO-00012NC@ajax> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <m0xy6IO-00012NC@ajax>; from Andrew Apted on Fri, Jan 30, 1998 at 01:35:08PM +1100 X-Deities: e38 Resent-Message-ID: <"W3eIW.0.Bu4.bhKqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/578 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 01:35 PM on 1998 January 30, Andrew Apted did write: > [re: the cursor positioning bug] > This blank mode (i.e. all 0s) is then tried to be set when the VTs are > transferred back to the kgiscroll, and this fails because text.x is not > 8 or 9. I guess this causes the default text.x to be used instead, and > they get out of sync... It appears more than text.x is fragged -- the number of columns on the screen is computed by (virtual.x/font-width) and it's still 80. Thus virtual.x is 720 instead of 640, since font-width is 9. Symptoms of the same problem, of course. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Fri Jan 30 00:49:18 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id AAA13811 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 00:49:17 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA22106; Fri, 30 Jan 1998 03:13:18 -0500 Resent-Date: Fri, 30 Jan 1998 03:13:18 -0500 Date: Fri, 30 Jan 1998 03:12:08 -0500 (EST) From: Jordan Mendelson <jordy@wserv.com> To: evstack@ontv.com Subject: Report for 1/29/98 snapshot (LONG) Message-ID: <Pine.LNX.3.96.980130025633.31514A-100000@snappy.wserv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"WtVTs2.0.pO5.-iOqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/579 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Ok, decided to take a fresh kernel (2.1.79) and a fresh tree gotten with cvs checkout -r EvStack-0-0-9 ggi, patch and compile. I'm sure the bug about the cursor not following the words has been talked about. It seems to lag behind by 3 characters or so, but the faster I type, the farther behind it gets. The EvTest program compiles correctly after a modification to fake.h (the NOTICE #define is incorrect and vcs_init() doesn't work, so I commented it out). It looks like it does something to my 7th console, but I can't tell what :) When it's scrolling across the screen (after loading ggidrv.o), I witched between the first console where it was scrolling and the second console and noticed there was some text from the first console on the second. Doing this repeatedly verified that there is a problem. Mouse support seems to work. mc -x let's me move the mouse (ps2aux.o driver). Unfortunatly, i can't move my mouse all the way to the right of the screen, it stops about 1/8th the way over). Also when I move it, there are 6 colums of small white dots. lsmod reports something odd. When I insmod ggidrv.o, it says: Module Size Usedby ggidrv 23492 0 (unused) Now, of course ggidrv is eing used, otherwise my screen wouldn't be shifted down. What else, oh yes, scroll-lock won't halt the screen from scrolling any longer. Of course those pesky keyboard lights still aren't working. Libggi won't compile (won't even get close), is there some KGI video demos that I can use instead to test to see if something other then text console mode is working? MAKEDEV.ggi makes what? close to 800 devices. This is a bit silly don't you think? Would it be so hard to just use /proc instead and make dynamic devices? Well, I guess when devfs is done and accepted it could happen. Oh, 2.1.8x won't patch cleanly. Other than that, everything seems to work. I can switch consoles, evstack responds to requests. I haven't tried listening for mouse events with raw evstacks yet, but I might later tomarrow. Please note, if this mail looks strange, it's because I"m in Linux using he EvSTacks kernel, and it's really hard to figure out what I'm typing with the cusor in the wrong place :) Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com From evstack-request@ontv.com Fri Jan 30 01:27:02 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13913 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 01:27:01 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA22365; Fri, 30 Jan 1998 03:51:10 -0500 Resent-Date: Fri, 30 Jan 1998 03:51:10 -0500 Sender: core@tron.mirus.fr Message-ID: <34D189ED.69C90B11@mirus.fr> Date: Fri, 30 Jan 1998 09:06:05 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: Modification in driver API ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"g4ugL2.0.CS5.RHPqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/582 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan wrote: > > I know there is a dpy pointer in the mode structure, what I meant is, > > it does not always point to something valid. When the set_font > > operation is called, it contains NULL (so says the segfault). > > Oops! Bug bug! Ahh.. Okay. Sorry I didn't look into that, I thought it was on purpose - i.e. mode not attached to a display yet or something.. :) > > 1] I change KGIM_PRIVATE to retrieve data from the display structure, > > as it always used to be. > > > This implies that textops are passed a pointer to a display, not > > a mode. > > Ding ding ding - sounds like the right answer. I don't know > what I was smoking when I said it should be mode_data.. I think > I thought teunis was referring to vga_text16.inc.... Gimme the crackpipe now :-) > Go the first way. I was stoopide when I said it should be > the other way 'round... Okay, I'll change KGIM_PRIVATE to fetch data from *display_data; Questions: * Is the mode_data structure deprecated and should it be removed then? I assume yes and to replace it by a placeholder, and *duck* remove Teunis' allocation code in i386.c .. and when we have to recompile the kernel for some reason, then remove it for good ;) I'll do the changes. * Should textops be passed a display pointer? I assume yes too and to change the vga driver to take that into account (and my GX driver too obviously). I'll do the changes too. I'll do all the changes and commit them as soon as I got your green light (note that everyone should probably at least make clean; make the drivers when the changes are commited). Comments anyone? :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: yes yes, i will! ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 01:27:44 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13917 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 01:27:43 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA22375; Fri, 30 Jan 1998 03:51:19 -0500 Resent-Date: Fri, 30 Jan 1998 03:51:19 -0500 Sender: core@tron.mirus.fr Message-ID: <34D18854.72F988F1@mirus.fr> Date: Fri, 30 Jan 1998 08:59:16 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: more /dev/graph tests References: <Pine.LNX.3.96.980129130039.4413B-200000@sigil.computersupportcentre.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2__-3.0.vR5.PHPqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/581 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com teunis wrote: > Okay... ran the MAKEDEV.ggi script (thanks BTW - I didn't know about that) We should write an "EvStack for dummies" paper :-) Just kidding.. Jason told me that, else I would still be wondering. > OOPS no longer happened. Mode-set worked. Video crashed *sigh*. > Recovered by removing ggidrv and running "kon" - > savetextmode/restoretextmode under svgalib don't work so hot for me... > > No sign (yet) what happened... but I'll look some more > (VGA driver) > > Attached is dmesg output... "You are not alone..." That's exactly what I get with the GX driver now; the mode setting works but as soon as it tries to write to the framebuffer, boom, back to the prompt.. And I have the same funny message : > 0059a051:devgraph.c:805: mmio per-type (0x0001) mapping > 0059a051:devgraph.c:821: No region for 40 Jason, Andy, any clue ? The VGA driver _does_ work (i.e. warp-ggi works the way it used to, and is handy since it doesn't block for keyboard output so we can test it without events :) (Btw jason, teunis, jim, do you want an email alias in ggi-project.org ? :P) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: still coding.. ! ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 01:32:03 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13927 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 01:32:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id DAA22368; Fri, 30 Jan 1998 03:51:12 -0500 Resent-Date: Fri, 30 Jan 1998 03:51:12 -0500 Sender: core@tron.mirus.fr Message-ID: <34D186F1.E804E19B@mirus.fr> Date: Fri, 30 Jan 1998 08:53:21 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: /dev/graph?? minor number incorrect References: <19980129162101.18880@3e8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BcDsK2.0.gR5.NHPqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/580 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jim Ursetto wrote: > I just noticed, after applying Emmanuel's advice (and getting devgraph > support loaded! Now it lasts another couple of milliseconds before > crashing!) that all the /dev/graph?? files the script creates have minor > number 0. Upon checking the script, I found a typical creation command > would be > > mknod --mode=0666 c graph38 121 0x38 > > Unfortunately, mknod doesn't parse hex numbers, and silently substitutes > zero. My system is rather upgraded (bash 2, newest everything) but may have > an old GNU fileutils (3.12), and maybe that's the problem. Yes, this is a known 'feature' of old mknod. mknod --version says here : mknod (GNU fileutils) 3.16 And it works "as is", i.e. minor numbers are correct - and I get to the same point as you do with VGA driver: demo blocking on "press a key blahblah.." until userspace events work (no problem, it's not like we're in a hurry anyway .. :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: yes yes, i will! ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 01:36:07 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id BAA13935 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 01:36:06 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id EAA22568; Fri, 30 Jan 1998 04:00:13 -0500 Resent-Date: Fri, 30 Jan 1998 04:00:13 -0500 Message-ID: <19980130025954.43889@3e8.com> Date: Fri, 30 Jan 1998 02:59:54 -0600 From: Jim Ursetto <ursetto@uiuc.edu> To: evstack@ontv.com Subject: Re: Report for 1/29/98 snapshot (LONG) Mail-Followup-To: evstack@ontv.com References: <Pine.LNX.3.96.980130025633.31514A-100000@snappy.wserv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <Pine.LNX.3.96.980130025633.31514A-100000@snappy.wserv.com>; from Jordan Mendelson on Fri, Jan 30, 1998 at 03:12:08AM -0500 X-Deities: e38 Resent-Message-ID: <"v04KT3.0.LU5.fPPqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/583 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com At 03:12 AM on 1998 January 30, Jordan Mendelson did write: > I'm sure the bug about the cursor not following the words has been talked > about. It seems to lag behind by 3 characters or so, but the faster I > type, the farther behind it gets. We found this is due to an incorrect font-width divisor. I think you are experiencing an illusion--the cursor position is determinstic, and gets farther behind as the input point moves to the right of the screen, not based on how fast you type. Read on: > Mouse support seems to work. mc -x let's me move the mouse (ps2aux.o > driver). Unfortunatly, i can't move my mouse all the way to the right of > the screen, it stops about 1/8th the way over). Also when I move it, there > are 6 colums of small white dots. The same problem, theoretically, as the text. Some of the mode structure information is invalid. It could be hardcoded as a temporary fix; see my other posts on this. Regarding the white dots, it's most likely akin to the video corruption I reported on the linux-ggi list. I'm still waiting for the go-ahead to commit the fix, but you can use the patch from that list that I posted, although the line offset is slightly wrong. (It's a one-line fix.) > Libggi won't compile (won't even get close), is there some KGI video demos > that I can use instead to test to see if something other then text console > mode is working? Use libggi from the standard ggi tree. > MAKEDEV.ggi makes what? close to 800 devices. This is a bit silly don't > you think? Would it be so hard to just use /proc instead and make dynamic > devices? Well, I guess when devfs is done and accepted it could happen. Make sure the devices have different minor numbers. The default script makes some assumptions (conversion of hex to decimal) that don't work on my system, so I made a little patch and posted it. I'd like to know if anyone has the same problem. -- ; ; ,,,,, ; ;, ,,,;,, ,,,;,,, ; ' ,; ; ; ; '''''''''';''''' james f. ursetto ,; e ;,,;,,; , ; 8 ; ursetto@uiuc.edu ,;;,, ; ; ; 3 ; ;''' '; murasakiryuu '' ; '' ;,,;,,; ; ; ;, ; ; ;,,;''' ;, , ; ; ''' ';' From evstack-request@ontv.com Fri Jan 30 03:58:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id DAA14076 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 03:58:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id GAA23321; Fri, 30 Jan 1998 06:22:06 -0500 Resent-Date: Fri, 30 Jan 1998 06:22:06 -0500 From: becka@rz.uni-duesseldorf.de Sender: becka@rz.uni-duesseldorf.de Message-Id: <m0xyFDV-0000WvC@charon.beck-sw.de> Subject: Re: devevent ... more ... To: evstack@ontv.com Date: Fri, 30 Jan 1998 13:06:41 +0100 (MET) In-Reply-To: <m0xy67q-00012NC@ajax> from "Andrew Apted" at Jan 30, 98 01:24:14 pm Reply-To: andreas.beck@ggi-project.org X-Mailer: ELM [version 2.4 PL25] MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: 8bit Resent-Message-ID: <"phb9-2.0.kh5.bURqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/584 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com > > Please note that this does not work yet, as the report_to property of the > > stack seems to be not set. My old code did that automatically on attaching > > a substack to a parent stack. > > > > Andrew : You probably know about how that works now, so could you enlighten > > me what to do (or simply do it) ? > It should still work... checking... looks okay. I changed the logic > slightly to handle multible parents. In substack.inc there is: You are right. I did a stupid mistake when testing. I had attached the devevent stack _below_ the xterm what caused all "interesting" events to be already consumed. It works like a charm now. You can now simply do ./deveventdump /dev/event0 -r >bla and later "play back" that file with ./deveventdump /dev/event0 -w <bla . There are still quite a few things to fix like allowing to specify event masks on the commandline and allowing to choose to play back either "high-speed", or "as typed", maybe "slow motion", too. Anyone here who would like to code that ? It's just a matter of adding some commandline parsing and a few trivial additions. What's the most urgent topic with evstacks now ? I suppose multiple keymaps and some more Linux console capability. I'll probably check into the latter first, as this seems simpler to me. I.e. get SKBENT and GKBENT etc. working. CU, Andy -- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = From evstack-request@ontv.com Fri Jan 30 04:58:04 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id EAA14151 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 04:58:02 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id HAA23713; Fri, 30 Jan 1998 07:22:06 -0500 Resent-Date: Fri, 30 Jan 1998 07:22:06 -0500 Message-Id: <m0xyFHf-00012NC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Re: Report for 1/29/98 snapshot (LONG) To: evstack@ontv.com Date: Fri, 30 Jan 1998 23:10:59 +1100 (EST) Reply-To: evstack@ontv.com In-Reply-To: <Pine.LNX.3.96.980130025633.31514A-100000@snappy.wserv.com> from "Jordan Mendelson" at Jan 30, 98 03:12:08 am X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"C1OMz2.0.xn5.aMSqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/585 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jordan Mendelson writes: > lsmod reports something odd. When I insmod ggidrv.o, it says: > > Module Size Usedby > ggidrv 23492 0 (unused) That's because we can now rmmod the driver. [hear the sound of hordes of rejoicing minions... ;-)] It will only show up as used when graphic consoles are being used. [text consoles aren't exalted enough :)] > What else, oh yes, scroll-lock won't halt the screen from scrolling any > longer. Our 'to-be-done' list keeps getting longer and longer... :-) > Of course those pesky keyboard lights still aren't working. I'll get onto that one real soon now... Cheers, _____________________________________________ ____ \ / Andrew Apted. ajapted@netspace.net.au \/ From evstack-request@ontv.com Fri Jan 30 06:25:43 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id GAA14284 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 06:25:42 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id IAA24335; Fri, 30 Jan 1998 08:49:36 -0500 Resent-Date: Fri, 30 Jan 1998 08:49:36 -0500 Sender: core@tron.mirus.fr Message-ID: <34D1D734.FF6F8969@mirus.fr> Date: Fri, 30 Jan 1998 14:35:48 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: linux-ggi@eskimo.com CC: evstack@ontv.com Subject: new email aliases Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nntkh1.0.ax5.3eTqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/586 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Ok, I created the following new email aliases in ggi-project.org : Full: Short: Aliases to: marcus.sundberg@ marcus@ e94_msu@elixir.e.kth.se jim.ursetto@ murasaki@ ursetto@uiuc.edu andrew.apted@ andrew@ ajapted@netspace.net.au /me thinks about creating an evstack-minions.ggi-project.org subdomain *grin* Everyone involved in the project, if you sent me mail for getting an alias and it didn't get replied, sorry, it got lost in the flood of mails I get every day, please resend .. :-) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: yes yes, i will! ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 08:06:00 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA14399 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 08:05:59 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA25475; Fri, 30 Jan 1998 10:29:17 -0500 Resent-Date: Fri, 30 Jan 1998 10:29:17 -0500 To: evstack@ontv.com Path: jmcc From: jmcc@grits.visus.com (Jason McMullan) Newsgroups: lists.linux.ggi.evstack Subject: Re: more /dev/graph tests Date: 30 Jan 1998 15:26:47 GMT Organization: OnTV Pittsburgh, L.P. Lines: 26 Distribution: local Message-ID: <6asrfn$us8$1@grits.visus.com> References: <6as4qk$d8m$1@grits.visus.com> Reply-To: jmcc@ontv.com NNTP-Posting-Host: beans.visus.com X-Newsreader: TIN [version 1.2 PL2] Resent-Message-ID: <"jIW8h1.0.4D6.C4Vqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/587 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Emmanuel Marty (core@mirus.fr) wrote: > "You are not alone..." That's exactly what I get with the GX driver now; the > mode setting works but as soon as it tries to write to the framebuffer, boom, > back to the prompt.. And I have the same funny message : > > 0059a051:devgraph.c:805: mmio per-type (0x0001) mapping > > 0059a051:devgraph.c:821: No region for 40 > Jason, Andy, any clue ? The VGA driver _does_ work (i.e. warp-ggi works > the way it used to, and is handy since it doesn't block for keyboard > output so we can test it without events :) No idea. I've been busily re-writing /dev/graph... See my Saturday release this weekend.... > (Btw jason, teunis, jim, do you want an email alias in ggi-project.org ? :P) Can I have 'jmcc@ggi-project.org'? (and mcmullanj, or whatever your longname system is...) -- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... From evstack-request@ontv.com Fri Jan 30 08:30:47 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id IAA14417 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 08:30:46 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id KAA25734; Fri, 30 Jan 1998 10:54:41 -0500 Resent-Date: Fri, 30 Jan 1998 10:54:41 -0500 Sender: core@tron.mirus.fr Message-ID: <34D1F43C.8D5060C8@mirus.fr> Date: Fri, 30 Jan 1998 16:39:40 +0100 From: Emmanuel Marty <core@mirus.fr> Reply-To: Emmanuel Marty <core@mirus.fr> Organization: Mirus X-Mailer: Mozilla 4.03 [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: evstack@ontv.com Subject: Re: more /dev/graph tests References: <6as4qk$d8m$1@grits.visus.com> <6asrfn$us8$1@grits.visus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sACoA3.0.uG6.NSVqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/588 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Jason McMullan wrote: > > Jason, Andy, any clue ? The VGA driver _does_ work (i.e. warp-ggi works > > the way it used to, and is handy since it doesn't block for keyboard > > output so we can test it without events :) > > No idea. I've been busily re-writing /dev/graph... See my Saturday > release this weekend.... Ok... Can't wait :) > > (Btw jason, teunis, jim, do you want an email alias in ggi-project.org ? :P) > > Can I have 'jmcc@ggi-project.org'? (and mcmullanj, or whatever > your longname system is...) Done. Added : jmcc@ggi-project.org and jason.mcmullan@ggi-project.org to alias to jmcc@ontv.com :P ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: yes yes, i will! ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 09:27:16 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA14520 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 09:27:15 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA26335; Fri, 30 Jan 1998 11:50:55 -0500 Resent-Date: Fri, 30 Jan 1998 11:50:55 -0500 Date: Fri, 30 Jan 1998 09:59:26 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Emmanuel Marty <core@mirus.fr> cc: evstack@ontv.com Subject: Re: more /dev/graph tests In-Reply-To: <34D18854.72F988F1@mirus.fr> Message-ID: <Pine.LNX.3.96.980130085616.6686A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wyLBA.0.bQ6.EHWqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/589 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 30 Jan 1998, Emmanuel Marty wrote: > teunis wrote: > > > Okay... ran the MAKEDEV.ggi script (thanks BTW - I didn't know about that) > > We should write an "EvStack for dummies" paper :-) Just kidding.. Jason told me > that, else I would still be wondering. Anyone wanna write this? I'll continue tossing out messages and notes :) > > OOPS no longer happened. Mode-set worked. Video crashed *sigh*. > > Recovered by removing ggidrv and running "kon" - > > savetextmode/restoretextmode under svgalib don't work so hot for me... > > > > No sign (yet) what happened... but I'll look some more > > (VGA driver) > > > > Attached is dmesg output... > > "You are not alone..." That's exactly what I get with the GX driver now; the > mode setting works but as soon as it tries to write to the framebuffer, boom, > back to the prompt.. And I have the same funny message : > > > 0059a051:devgraph.c:805: mmio per-type (0x0001) mapping > > 0059a051:devgraph.c:821: No region for 40 The scary thing is I'm using the VGA driver here.... ... Very odd... As my system crashes if I insert the ViRGE driver... or does so quite quickly (VT-switch definitely) I'll haveta look some more... More later... > Jason, Andy, any clue ? The VGA driver _does_ work (i.e. warp-ggi works > the way it used to, and is handy since it doesn't block for keyboard > output so we can test it without events :) > > (Btw jason, teunis, jim, do you want an email alias in ggi-project.org ? :P) Sure :D G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 30 09:29:58 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA14524 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 09:29:57 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA26409; Fri, 30 Jan 1998 11:52:54 -0500 Resent-Date: Fri, 30 Jan 1998 11:52:54 -0500 Date: Fri, 30 Jan 1998 10:02:25 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Emmanuel Marty <core@mirus.fr> cc: evstack@ontv.com Subject: Re: Modification in driver API ? In-Reply-To: <34D189ED.69C90B11@mirus.fr> Message-ID: <Pine.LNX.3.96.980130100005.6686B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"2_5zL2.0.qR6.AKWqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/590 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 30 Jan 1998, Emmanuel Marty wrote: > Questions: > > * Is the mode_data structure deprecated and should it be removed then? > I assume yes and to replace it by a placeholder, and *duck* remove > Teunis' allocation code in i386.c .. and when we have to recompile > the kernel for some reason, then remove it for good ;) I'll do the > changes. Aww *shucks*... Actually - good idea to handle that allocation in device_data - where I guess it belongs :) > * Should textops be passed a display pointer? I assume yes too and to > change the vga driver to take that into account (and my GX driver > too obviously). I'll do the changes too. Yes. S3 (at least) will need that info. I currently pull it out of mode->dpy, but it'd be cleaner to have it directly. (hey - that could be why ViRGE crashes.... mode->dpy becoming NULL... hmmm :) > I'll do all the changes and commit them as soon as I got your green > light (note that everyone should probably at least make clean; make > the drivers when the changes are commited). As long as the kernel doesn't change I don't care (too much trouble to repatch and recompile *sigh*... and reboot...) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 30 09:33:26 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id JAA14534 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 09:33:25 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id LAA26502; Fri, 30 Jan 1998 11:57:13 -0500 Resent-Date: Fri, 30 Jan 1998 11:57:13 -0500 Date: Fri, 30 Jan 1998 10:06:49 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Emmanuel Marty <core@mirus.fr> cc: linux-ggi@eskimo.com, evstack@ontv.com Subject: Re: new email aliases In-Reply-To: <34D1D734.FF6F8969@mirus.fr> Message-ID: <Pine.LNX.3.96.980130100457.6686C-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"e_u233.0.VT6.DOWqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/591 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 30 Jan 1998, Emmanuel Marty wrote: > Ok, I created the following new email aliases in ggi-project.org : > > Full: Short: Aliases to: > > marcus.sundberg@ marcus@ e94_msu@elixir.e.kth.se > jim.ursetto@ murasaki@ ursetto@uiuc.edu > andrew.apted@ andrew@ ajapted@netspace.net.au > > /me thinks about creating an evstack-minions.ggi-project.org > subdomain *grin* Cool :) Go fer it... > Everyone involved in the project, if you sent me mail for getting an > alias and it didn't get replied, sorry, it got lost in the flood of > mails I get every day, please resend .. :-) if you're serious about alias for this poor worm, one's name is "Teunis Peters".... not so obvious from email (sorry)... Good day lord of the evstack-minions :) - Teunis ps: now watching for changes to mode structures... have feeling will solve S3-trio probs at least :) From evstack-request@ontv.com Fri Jan 30 12:14:14 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id MAA14669 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 12:14:11 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id OAA28488; Fri, 30 Jan 1998 14:37:48 -0500 Resent-Date: Fri, 30 Jan 1998 14:37:48 -0500 Message-Id: <3.0.32.19980130203313.00c48250@tron.mirus.fr> X-Sender: core@tron.mirus.fr X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 Jan 1998 20:33:15 +0100 To: evstack@ontv.com From: Emmanuel Marty <core@mirus.fr> Subject: Re: Modification in driver API ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"X7KTY3.0.Ly6.TkYqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/592 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Huwo, >> * Is the mode_data structure deprecated and should it be removed then? >> I assume yes and to replace it by a placeholder, and *duck* remove >> Teunis' allocation code in i386.c .. and when we have to recompile >> the kernel for some reason, then remove it for good ;) I'll do the >> changes. > >Aww *shucks*... Actually - good idea to handle that allocation in >device_data - where I guess it belongs :) That will cut the porting work to a few changes too (the biggest being the textops). >> * Should textops be passed a display pointer? I assume yes too and to >> change the vga driver to take that into account (and my GX driver >> too obviously). I'll do the changes too. > >Yes. S3 (at least) will need that info. I currently pull it out of >mode->dpy, but it'd be cleaner to have it directly. >(hey - that could be why ViRGE crashes.... mode->dpy becoming NULL... >hmmm :) Okay, I will work on that right now and probably commit the changes (when I have tested that everything works fine under all circumstances) tomorrow (saturday).. I'll need your feedback about the S3 driver, I really hope it makes it work - I suppose it should, since I've been experiencing really bad crashes with those mode->dpy pointers set to NULL in textops. >As long as the kernel doesn't change I don't care (too much trouble to >repatch and recompile *sigh*... and reboot...) Well, this will require changes to kgiscroll.c since that's where textops are called - this is built into the kernel, right? (if you just redo a make (b)zImage, it will take a minute.. since most of the code will already have been compiled..) Woo woo, with Jason rewriting devgraph, Andy getting devent to work, EvStack will almost be functional-for-masses by this weekend.. Interestingly, Andy cloned himself on the GGI who's who.. :)) Willie meant to add me so copypasted andy's entry but forgot to change the name.. rotfl.. >G'day, eh? :) Friday (i.e. no work tomorrow) ? always :) ----------------------------------------------------------------------------- Emmanuel Marty - Mirus - http://www.core.netnation.org - core@ggi-project.org GGI project: http://www.ggi-project.org - Netnation project: yes, yes, yes .. ----------------------------------------------------------------------------- From evstack-request@ontv.com Fri Jan 30 15:09:02 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@[192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id PAA14948 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 15:08:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id RAA30254; Fri, 30 Jan 1998 17:29:42 -0500 Resent-Date: Fri, 30 Jan 1998 17:29:42 -0500 Date: Fri, 30 Jan 1998 15:39:14 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: evstack@ontv.com Subject: Re: Modification in driver API ? In-Reply-To: <3.0.32.19980130203313.00c48250@tron.mirus.fr> Message-ID: <Pine.LNX.3.96.980130153505.7041B-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"1c3Ne.0.9O7.fFbqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/593 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com On Fri, 30 Jan 1998, Emmanuel Marty wrote: > Huwo, > > >> * Is the mode_data structure deprecated and should it be removed then? > >> I assume yes and to replace it by a placeholder, and *duck* remove > >> Teunis' allocation code in i386.c .. and when we have to recompile > >> the kernel for some reason, then remove it for good ;) I'll do the > >> changes. > > > >Aww *shucks*... Actually - good idea to handle that allocation in > >device_data - where I guess it belongs :) > > That will cut the porting work to a few changes too (the biggest being > the textops). No prob - let everyone know when the changes are posted though, eh? > >> * Should textops be passed a display pointer? I assume yes too and to > >> change the vga driver to take that into account (and my GX driver > >> too obviously). I'll do the changes too. > > > >Yes. S3 (at least) will need that info. I currently pull it out of > >mode->dpy, but it'd be cleaner to have it directly. > >(hey - that could be why ViRGE crashes.... mode->dpy becoming NULL... > >hmmm :) > > Okay, I will work on that right now and probably commit the changes (when > I have tested that everything works fine under all circumstances) > tomorrow (saturday).. I'll need your feedback about the S3 driver, I > really hope it makes it work - I suppose it should, since I've been > experiencing really bad crashes with those mode->dpy pointers set to > NULL in textops. A VT-switch instantly nukes the ViRGE driver at the moment - so that might indicate where the trouble's happening in the first place... Also crashes after a couple of seconds - so I have a bit of time to remove if it doesn't work :) > >As long as the kernel doesn't change I don't care (too much trouble to > >repatch and recompile *sigh*... and reboot...) > > Well, this will require changes to kgiscroll.c since that's where > textops are called - this is built into the kernel, right? (if you > just redo a make (b)zImage, it will take a minute.. since most of > the code will already have been compiled..) Okay - as long as I don't have to repatch actually... I've been taking to leaving a live/compiled linux tree lying around :) So - what's the latest kernel EvStack patches now? > Woo woo, with Jason rewriting devgraph, Andy getting devent to work, > EvStack will almost be functional-for-masses by this weekend.. An' even some drivers :) Hopefully S3-ViRGE and Trio64V+ will be operational... VGA pretty much is, as (apparently) is MediaGX... Good, yes? :) > Friday (i.e. no work tomorrow) ? always :) I could get called out (I'm on contract/callout as a techie)... but Saturday's usually a programming day for me... It is SOO nice to get paid for work even though it's minimal... *grin* (and finishable unlike software..) G'day, eh? :) - Teunis From evstack-request@ontv.com Fri Jan 30 20:41:46 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id UAA15300 for <ggi@synergy.foo.net>; Fri, 30 Jan 1998 20:41:44 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id XAA00623; Fri, 30 Jan 1998 23:05:27 -0500 Resent-Date: Fri, 30 Jan 1998 23:05:27 -0500 Message-Id: <m0xyU15-00012OC@ajax> From: Andrew Apted <ajapted@netspace.net.au> Subject: Events from /dev/graph working To: evstack@ontv.com Date: Sat, 31 Jan 1998 14:54:51 +1100 (EST) Reply-To: evstack@ontv.com X-Mailer: ELM [version 2.4 PL25 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bNp0p.0.19.RBgqq"@salsa.visus.com> Resent-From: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/594 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi folks, I just committed the changes to devgraph.c (and a few others) which re-implements the sending of events to userspace. Thus when demo.c says "press any key to ...", it should work. But note that since events structures have changed in EvStack (some additions to COMMON_DATA), the events you get with an old libGGI & app will be screwed. For example, ggiGetc() will return rubbish keys, but it should pause properly until a key is hit. Cheers, _____________________________________________ ____ \ / Andrew Apted. andrew@ggi-project.org \/ From evstack-request@ontv.com Sat Jan 31 16:57:20 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id QAA16333 for <ggi@synergy.foo.net>; Sat, 31 Jan 1998 16:57:19 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA10565; Sat, 31 Jan 1998 19:20:55 -0500 Resent-Date: Sat, 31 Jan 1998 19:20:55 -0500 Date: Sat, 31 Jan 1998 17:29:52 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: Nimrod Zimerman <zimerman@earthling.net> cc: EvStack list <evstack@ontv.com>, Linux-GGI list <linux-ggi@eskimo.com> Subject: Re: um... why I can't patch kernel In-Reply-To: <19980131202253.28668@hexagon> Message-ID: <Pine.LNX.3.96.980131172640.32530A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"_zz5q.0.Pa2.4-xqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/595 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com [I've clipped this message a whole pile so as not to offend I hope] [that and changed the site-reference to an URL (I hope)] On Sat, 31 Jan 1998, Nimrod Zimerman wrote: > On Tue, Jan 20, 1998 at 03:53:44PM -0700, teunis wrote: > > I'm probably *very* late, but just in case I'm not: > > > dialog is available from where? *hunting* > <A HREF="ftp://sunsite.unc.edu/pub/Linux/utils/shell/dialog-0.6z.tar.gz"> Dialog, eh? </A> Seems to work (I think I picked up dialog from RedHat though eventually) Something to toss in those "REQUIRED_SOFTWARE" thingies. Incidentally, "make" did not work for me... though that was a bit ago... G'day, eh? :) - Teunis From evstack-request@ontv.com Sat Jan 31 17:00:25 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA16347 for <ggi@synergy.foo.net>; Sat, 31 Jan 1998 17:00:24 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id TAA10639; Sat, 31 Jan 1998 19:23:43 -0500 Resent-Date: Sat, 31 Jan 1998 19:23:43 -0500 Date: Sun, 1 Feb 1998 00:24:05 +0000 (GMT) From: Ray Glendenning <ray@hackery.demon.co.uk> To: evstack@ontv.com Subject: 2.1.84 patch Message-ID: <Pine.LNX.3.96.980201001949.345A-100000@hackery.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"LtviH.0.Zb2.x0yqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/596 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com Hi I made a replacement patch against 2.1.84 which I have added below. I have tested this patch (for a few hours, and it seems to run) so could people please test this and possibly comit it. It was made using the patch included at mat.cythere.com as of today (7pm GMT). ***BEGIN*** begin 644 patch-2.1.84.gz M'XL("-B^TS0"`W!A=&-H+3(N,2XX-`"L.WU_VDB/?YM/,9ON;:!`@LU+(&UZ MI>`F-+SD;))MK\\^_CG&)-X8F[5-TMP^O<]^TLSXW4[2I]?=@M%(&HVDD30: M=V6MUZ2YFWO$MIS=M\.9?F>N+=MD/YO2@7C0[S3->S_0C;MHM-)L-C,$@JH' MY)/ND+9(1.FX*QYW^T0<#/J5>KW^-+<DJ=0^;O>/.T>,]/U[TA3%0:-'ZOC5 M)^_?5\A<7OZ^4,Y5X<0Q@T/X^^!Z=P=ZA8R5R96LJ()PLO*L>]/S#Z]M%^:A MGP<Z^4>%"`()QXQ;W:,?=*0ND/!/A.`ZOFN;X?=S:+]6A\KHK'9X[;H!GRR' MN[%\@WZ@N-/)!Y3UU^IR<3&>*+5#V[K&OSBF7GX`$`[?F9YCVB$'LMF0M4]@ MT<3:&J#6Z\HJ8T'=,VX/K7:_]XPM\W@)J^8'A>7.)&/3``L1L7_<ZAY+(AKI MJ-R^!4S2ENX<';=:L:7;G<81J=-/M+/IP-(JI$*L]<I<D]%B_G%RJLVZ_5ZE M.?HX'9ZJY/B$_%IESS72W'3Z/?C4;>O&:=JNN_5/I.CWG[M-ZO=ZYQB!!;9# MV'AT<7F"C.O%C+>F$UB[30*Q3+H>C)5;!'QE;=T<6,YS"HL0"VT2C0K+VQW5 MIS0@(NP<^%]Z9M,5<4E:13KN]&`+QE;I=7#[P2?;?73E&]/9P6/==W>>8>:V MPBB2OEXA&9RMLTV,D]PXV[(Q!@T!G2/T#+$S:`RH$-::?"5[OW*E7RB+CY.I MO$=.R-[C'OGC#0EN3>!-B.4$9)]<>"[=!OZMM0Z(X>Z<8)^D:37U;/)Q2:0* M65N5)FQAF^S/]!O+(.JCK_Q%[LS'B&0V/)V,-/6+JOQ7I9Z6Y/1T0J5P8BGJ MA/P`.Y@]H5\"GF4YID89</2KTZ$&C^IB*I/')UP-2)F!GW.#"+'0U:+1GW*U MF$O&U8Z.VXE0+W7Z#;%%ZO@M=:FE7X7KGD]58D'D<P/BFP$JYU6E#J/,Y;C[ M``2V<&2+D\?D+^WS4E9F&1@\3B?SR\\9\%B^@O_FRY--%GRJ#"_.,F#YZES^ M,AM>9)C(5_/9XE*5,]@,5QO.9&4R&LXS1*@O1/E0!!\MI@L%!W"AJ!M(7[H1 MF!YXRKUEF#YJ)?*4)6#&/T*O2?`%X-5(36"I(-)PBH!7:5#D<DD39'%D4/!\ M+(^32%D'#;?YT[DIBY5PS>Q0)B^)XC$ZZ)-Y*<<BYY3=0>R4-/0<\9Q$M3YW M`Y-(OY#EK4EXOJ`;U:+YA.B>"<M_@."#$8!L='C8\*D.#@[`=9N0WC7,[[0X M@%Q#@Q[!8H2F=JP0R"L_\$Q]XU?J3V#SB%M`16:+L191TGP6_JH1_WH'&,/I MM!1C:UC$-WR+HF*,=E;$6'GN!HR[<@A$<5B3`?'5]6]A165F9M'\QG1N5P?& MT]9(H188/#6>CT92[YEH5,PG8_K^<5=*EIYBBR8>_&:91P!-:[#9-#1WM?8& M_(%7`J]2A<#5$J,3)"HG`81]#!RXS;2-OHVX(&[()ZHLA+7KD>H6$LH-POP[ M[=;45^0-V>+?DVWSG6-^"VKD[U+UTQIW]'3148Q;8(`T0D$^:+_0`AE&:1-T MV\>MA`DZ#0D2`OU$]>-FPN2HN5O<;`05H!GN!F`0D/@#V<_%Q7W<=2P/7UE> ML--M`J,;R]'M_83)FNET?K7,UA3-,)NKN^W6]0*")@HW(<AS7\X\#*&5)B;Y MP+-`*1!']M5`=U:ZMT*7-#TH$:JKW>8:]BC\`$X^FV@_'6LK=2:&_"T`US!7 M!&E"$J9GPE3D[Y=$Z6P5Q88+BBB^8G@H632?MD#,:,V)LNK_7>1H^$6R;UP( MS\$M^%LG*7ANSMEP_D6[6"A+M5P'/KB9Y=R$?"`:FIZWV^:9J6=#1=8F4.$5 M\O*WIH$,-CL[L"CDV@6/R,MT.5U.4*9B-IAM/IBV39:F<>NXMGMCF3XYN_S0 M(P:PB[@A!.O2F,/HAXR)I(6&X`A9.]3Y*1BK<3H=RLRF27@1%(GWAT'PJ#HE M\U)K$)&RPRV$?]D*YJ[3]/DV2BZ@9/-H<V"X',['0Z7,I1(8V=4\&6M?5M:D M4,LB;5S@I`.M=-P6?R30EE0YW4$JSDH2)+@Z?/)`.],6'SZIM-ZHD&G\@X"% M-,L]<(FCP2-\,X`1V/"\I9"-N8%/#^SAP@-&WFQJ;'*.]9/0`X#@/L`/0_,- MSS0=>.9#D"=3/R#]KH-KF`[8?([X^*9MT@,]P"&;3M;D`4X%KK,?D`?=89L# M\F_D<?ZC'YB;!MGY)AUS[15X(2W0ZOFL72<DE][1C4O7\:SLC+Q$_K`8J+.) MS;](]==JJFBO-1YK.)C@D%`=Y6#[)INEA,&FQH9GI2PB,:+B)-'U2/%DVX8* M13LY1]@S@%,<JYISY`4:SI1*ZN6<GH(6?(^F=9_0.QRE:;`$B6F]T*?=BA:? M.<8#>WM_H3>F1*F7+6BX'"IPWE,ONKUSNJP$JY6_[?;N^(3M(SIC>R#^V&(S M"\KXUS(^Y5=2;A;<Z.'$_2Z;>!!-G.9:QN(>69![T]>U:UMW<"&QI9^Q\]E' M.%;(,ZJ1)P-A9!;C!2$J1BX+AC'&S]:="4[I9F1+.A8[B=J_W:6]"/[-6E^' MKZ$"_69M=AMRK]L[R*ZF;MRB#VI04:QL*&$,8,B>R>O#"MWZ`<U\0*@!D?_U M#T@H?U>:@M3M-H@Z^6^YBKU(+="O;;-&FD3D4*P*M+63&I@KVL5P3)^!`_P: MR_PGH>S:%(4ULS@2A0-PJ(XFDXC+=#$ZC^D8KQ!6J?];LIUKTZ&ZC.6K"QSR MG(Q\.HZ=D)-#4"XYP2'F'(]4R/<W:*%8WS#'\LN%K(*VJ<BA_N&T11/>@![M MV!<]V<&?[_0+`U_\5'V=,._7X'%K_E&K`LA_W)#?2.O;>@U)9*NM;?T&6#<Y M%5055<0EOYR0\Z6FHJ2UY/5!XD\*EZ^)Z:<624'(W?6J^<['PRL[.)R0UALZ M_)V&>G"I$)=ZZ>,U5E7V(^5.:>%CXZZ`\(1<C;3+^60$6[E&_A/]%#72;6,D MJ;,OVNQ@[4<RU):3Z5B&VNU_]Y/0\60H*P#=2T%'\G@R!6ACOX)%60`GFIWC M6S<.E/RT9^'A"=K2#>\K]U_8$)7Z,Z@)5T)T(OP]U$Z5X97<@"F'H\LE?1A] MG,J?&Z'`C5#&1B06<Q)0$-0'.AP.X3@-IB1;S_1]F#1X@,-B@[B[8+L+`,&( MSI&&ZP'.UH6X"`5_X!(K:`A<<;TC;([7V1<+%`),,;,VL"`T[(-G`8]C=B.D MDY&^]57:B\:Y@;\/<>O.)`QV#3/OH'2"X(*(4^SUP$1-`0U)HPY:\/QJ.*V> M:Z/AA<H\I49CBL`1PG$V]@8<KXAZOE!F6%\#$TI?S]%SC)`->!CR^27T=^IR MANUI4#B`>VFVN4)?:Z"#(5?J]4CVG;72H+X$1;$OMN=P%YV0R^K6AI,]MD2^ MWOT13E0]APU<!8P:E7G)Q6">3C`"AX(B#MU[;#/1D2(=,904:5)'A>0I)3&D M#(.\DF"W:BOWP?D*>'_4ZQQ&[Q\TMGO_=4*JXMNW,,XHOC^=3K&D?DDFI7AE M290._D3G+,$DDSK;QUTQ<9;H86$"GZQE]LIR#'L'@>>M[F\.X>QP^RX+W-[0 M1$)'H'I/U3&T_+YW+=BI-Q9KF.$OVC0K;+VIB\LYU(R4A#8N\?";(@Q[;#3J M22)*VY4Z88</7<`S;RPX'WB:<>O!N;0ZDV?:;/AIH33V0`%[C=_@T_4>M;6[ M]6MT&VP]2#IWU;V=@RO!"'&#/5G]3]<C_[&B[0)&@RTI_Q_.7H-$3*D+X'F) M2@FG5^M_3-85S&M"B+20U(!`3V%12S)%=J%,YDM9`20[;C@^[6UX0_TB=Z.( MI?Y&1W_:X1B7C,=UCJ7$S7&GBYD+/KG'1>5K[&9,/CRR@I.A8G,U>18W/I%1 MBD)?.Y>5N3P=YXG9M?V*^3HC?5+E_%C]$J6'J&5J#\<%=>=0E8FP-SO'K?YQ MM_4CBH_YI%3?;45\Z/YAVT?DJB>O\2]1(.?A+0FZ&[;+"3@W9'/;U'V3_H;] M8=H6]D@!"W*LZ1\@H0!+^F#9-CG3'R`!OGVXQ>_W()UWX)C!NP;YM(,J`V]W M8";X2R9.8-YXP&457KCD3_D4$?\`]T^Z[SID9LQV-AQ^R-L_-X;QWG6"^P/# MW0#_A1$@>T*K][Q=^:4YF!47W\=K@7J_W1#;!:&.35X0[JZM`.)&>;2+L6]N MK.C]$^:%>*K/>QOD7O2XS%QL\#XH'ROV\7_'R]E]27_`[DL&O8;(R^KO!5<C M+,BRWCRFVK##-Y:O:!U2%/<$+.J-G0?%1D"B?@N]$M$@U&+ML#57,%AML62. M^.L;C2.^P68**U]")F])BU<]`@>=M"CE=_R(24]FYU$/<C*NMAJA&"P"4XL( M@OD-\H5#<K-&(5H(UTMFY[#0ZG+YA>>4!`&I$Y%5!(YKP`X$;#$NH,2>)%(% M]]K]^-@"5?(.9H:25=OYIE<%LN8[>X5QT]EM&J2*,KVN$=V[8:P-V(5D.5F, M5'DY/D[R`%<P?#-8(8\L8;/@A@O4R0K_5=Q=JI'??B._9,!@PUIJ:GKKGIN; MNA6;G$N;2-7@77`6EV#Y`U'"!U9K8SU?:=)0$"9/&@="C3*U'Y#EK>7CU;2A MVU"GDM>F[MF/KQM0(_!`4DCM!]X.*O0GR3'B/9AX]-\/B&-",/-US[(QU6]! M?.QNVRY4^>Z:\->Y;DU["Q^>2:,>!#4XM*Y<X+4Q"65,HDI`IU<B#1I!`87) MMMG:YC>\8-]M*0,;`J!WP*)6TW;AB!+N#YKP*>0.Z@^L/KV@06(`R`=5+?U- M+ZU<_V4DM`J'4XZ*,E"IP.+ZS@X(^#5F%P"`!UI;?#R@T50`8A"Y2ET35@0; MR0=UNVL.J?&CN3B0VM3+!YU6`Y(7=7-8I.5`%;4A^C6<S^#(YD*=M?&)&1AX MJ2[0*4HN8?-%5+0PV&!84;'RC2T]N>IHP?R.EFWV%#EH.DM7?*.;*5,S-V1I MINP60TM9L40NIK*C#E/9`+N"41V+.3RJ95EVK_Z&U]>0FY`WA_$25G<LH[HW M<G?V"CTY)&17,T;J31LH8'%W%@0%@G$N$IQ?[)W@+L0+`PYX4XAVP+XT1]]@ MF-P+KX1:>R7X'/$93G72#;7$>J92J]4-P^>36DHS?8F64-J,B@J+30%3]C/O M$,CJ!7,2VM)!9`(@<FVN\0[3\S'VP!?!7@%*XILL=-&K+]Z;D%IBG_:Y6E%; M1^#7C=:WO`#"-G&.*`[X*0C>)`#5O>$7\.)QO?7,:2.^='A)]9O`+BN`$R@_ M6P.G6*7*8%&,[N%H-[Y-F_'ML'66*910.3];G&5&-^YJQX_,Z>IRIQN8@5AY M25[MJ._I0>#Q=^SHZ]12%T(K>\5.B'IN886%;@_;JCJ;S!<*%`'NRFR^LS0\ M"4-R)Z)T1.L(:UV-L#'E@[)H3($$Z1I8D4?#39'M'>X137G^>;)@%1F^IC29 MC[1+5898>#E?8@46>T[].V+QYB#(5ZFCK_&31)4E9T(E)*_I5X-G;$*O85_# MYQ;RV]]\IK&<FBGIH]CRY>T+$;-.73H2(Q7-+Z?3AH#YCEYULG06`S=0?#(8 M2N="TF\@&!]8[RY&Y:(CN"XDUM+(##+VE&3M/SH&A7U_DS@QP'HN\38>K4;/ M6<PC6),C*DPUNC&QBT^KN6BG4JQ:7)YB.D<$T_-<#,],%9!5VJ")?C^\`WE1 MHP,FX577'K8"U627@^D[G(5:-[,>VK@Q0!'.;IM9$YIQYV2;,]$,#;('4V/4 M1;<I.7;SO7(8_N+O;!S<%H>#4O1$]"G%*?A'$<_U/E[$B[T[+R;>4NQ(M`,2 M-5;#NU/MPUD#?HZ^C*;#L:R&/V=2JT>?F\(G!()>/['!NG"A2L/+SPCD[?)T M>(&PN+*\OS"\/*W:^%#ZDI7&V*6*C5&R_QBAQZ_NCEZJUP2KC%H'QYU^\A:0 M]C+QJ\,42Z]2X`"`_6_6ROTG'-'(V[<$(3R,-,/KD,OJMQJIXL<_\:JHU6K5 M*LW2CE!&QO"F\F7ZB[#+]1>AY/\Q1_L']1>S>EI_5'O<*<,Z2-/HX2^ZW]?. MXONCHK%\[HN[,/68]/R4M>"%5@HV6BH01J44;#A="D*;2L@;%IDKKY"7(G1S MS*9"+P=3A*/8Z`@+[QP$V.H9N``P$G,([T*%01AT6^PE>"GJ*G',V?"S!MB+ MCYC"%/X>N4HDB"F8)OQ;+$FA/(1D3S"/!.0HZF*MF>)9)T?3BHM2WL+(WZ&^ M*1B+[[/CT:B2`%FP!L6;4TB-_E<N.A>YG"*^!F+8B%I/KG\\&8X4`98<9R[. MB:?]!QTRX5\[$QS\-=ZOT:L]#:&)TI2%S!9>1G7"\U)D)7[/!!9-PF;R<D@M MEX#1JVJP6S,!PRLO01!;*2"]"!-$*6GW\VK0N*\)0K5:#6IOW_9K_ZK>8Y44 MDWVY@,"!"!`^WKTC??YN38N]]]'J9WU6NYR/%X)P7H49/\X;4K=;H_V1V`&U MJ\5DS#'4"WG4:"4GU,[@(%H^*N,M0G)83`VK9YHBGZJ)<8D++#&!I4%81,1$ M4/DI_`2<9'R4YGPQ_'U>@-5/87T8*O+\<D8UG4`:U)+K7\J?E^I(D>5Y4LY6 M"H?^"X\\DIAFM#@]G<IY+"F%1>^L<4"0VK24LW%7AJ][&EBUZC[?`%''.:(> M3F$QPZ4\3JY'ZM7P-+AZA*.MA;VH1Q+5V^CO824:LYDOU,O1&>R[%)LCRH:5 M8T!Y_4C.QZ?G'\#(X=&QW:5O2+2[>4>[N$!E3QG#B^$8;8'+@_F;6WT%T6<- M>UGW3`?.H[[E9R1BY$J"?)`B]ZR;VSQ]O*/86S`0U%LY92,\8@N&C90>9BR\ M;\<WQR.]9[4^IJ\5,";XND%F%XSIRP:)89%[>7<`U@=U]8X:72FCK_%X(BM) MHDZ:)WTY(3%,-VYRN0@5A%YNN13>RRQ@\?N<;]/1I9(1?RI#9(L'TUM8F9R> M)4>EU.CE16*HG9*07Z*'P0&?&V$*K2716#).8R$LA42S<QH'0%F44Z4`Z52I MY:2:%DDUS>,I17A*3ORI0`H6,,WA*85X&7Y1F9#!C%Y9R%D<E"]TZ*DI@G^< M*##`WD(0TJ\C)-&2\&)#Y9&IO8K,E4=%JQ48K1#Q5"DV78FT918L02\S9/'R MIL76+$96BDU:@(R%7MZH>7MFS8981>9EKX4)Z??#4MP2\.3,T;MV=5)H:4Z7 MM72:+&=T3I4Q>IHH:_^8)FW_'%7&%9(KFSZSM&DII?(,I5*FE6?4,BVC4YZF M*YXOXS89LD(/RGI&F0>IR\GH_`O@L8>\!R7A22&DU\_Y$*?,^E"6,.=%G"[C M15FRK!_%5&D_*J#+>%)RA=-GES@MI56>I57*]/.L@J9EE,ISE,5S9CPJ1UCH M4UE?R?H4_\.Q9XOQY"-4.*3]?[U<W7/:1A!_5O\*I0\-V.`@P&";VAW;(0E3 M.TF#[4FGTS**$:`Q0D0"[+3N_][]N)/N3@?8>6@>''2WN_>U][6WO\V$&R?9 M_GE-[-9T9S(.)9#F:=GB3-6L-2IU-&LU,Q-"?E?I?@XTGKI^IH+\D9Y?.%3Q M]:W>^J%:/#-DMPC\M?XL4Z2SG6:*5-;SC)7,>J)94SW;H68-J>5<8V^+Y6!C M)T2)A>+%S9?U;W-76DEMO6DEM';H.DIKGZZOJJU;UU-;>G9MTRR=NY;V4W&6 M9@JLZS6;('+#DX-62*=4>WA3J]7<OUSXTJ:";E=YFG&2[/U/LTP*TK5F29%O M`?)[S[))2CFZ0;+N'7D*SJU-]ESX:Y@B\%;<.[WH?9;G,'I0<-O[-I)SO)E? M7TF:EFIC>=V]N9&./8Y7K]';[24".PF\?7.5HCO(!=:8/-7P'4CA)>-#QNT9 MW./$GT_"['5ELR@*8)&)JANB@A4BI85+$G*2&PWZDEP%Z2*E=YS^>;\GBQ+. M)5NT(GJB2D2;]"%"93"=1KW]9SV<D)!BM*&6XKA8(\?%FGPQR2R1Y.BRB@;Q M:)0&:#5TA&EQ"#V6?(,>@DS^W;'QS1=!QW'8(NLGD!$%$??PKD-O6SM(E(0K M/R.<Q/$=];A$$8EL=^@O_/SE#T>(E)@>F]O[AEWFYG+0_=P]O[XZ/;OH.K4' M#Z:[EBM.BK6'NIG3^Z#@46H/35PH2%_899E]Z]S>JP\NPI[#*)SZB:9O(.,- M+$GO3M^_ONA^@B(.I`C4S,O+TX_0-D8RN%K)_:O3<SBA8A0-X*IY[;8EG(0^ MMN3$^Q0E(,*U>D:Y%N_DPV<I&DO9K&GXC+P+?Z6+K/N2N%X*W[F4_;Y8RY8) M?"]3-LEE7L'H_$5$@F-/.JAN?AJ1,WH2I.S1MO!G"XY0XD_3&,L9+:>D>>@Y M6)W"JC!U8;!3MQ3LC??P]98D0*7"O\/9N"P+SO:.WGLT[`OK;-_QZ#D<W=G4 M=PB/=:7PY$#*WQO/&)./E0P1M_L2/I<I`FW$LF8^@63%M1HTSQCR/>6^)`\J M*+K5M+'2TXGD=YE?UC>)XP4^:$N#*KJ:K;!FP@))U<7H+T?D9\.N`#=7@[?= M*U#CJRYYXE#H&PQ)A]W*P`_IC)>Z7HN&<A*.)S#+2]!&6'W#A;##PLCP.TB9 M^\MTQU7>;PK.(J-4>N$BI(W\%PZ;\@5)?R(1?GZD7>EB.!#?G0(=Y=-/U(!A MF`2W"RL5^>^Y[,6'[T&[&]^7=!?9"MEG\R]$:RONL^8[D71N9"\&+5D%1&B% MW47I>)`W`(ZISY.J2TM2'4RB9$F`A<@J+F/AXA6&,%GGZ:00:,M6EEI<KIK> MUN4JYS:6J8.CIK),M<CILB5=F+*&T9Y%#B:]3[^9K<XSV5,CE02RB^W.J)5L MP%2R@@-J1J85E\:W=]8AH-QE.+SU;R>!E4(?\/EM:!GPBFN./^VY'`>J+7`. M1HVB^8"<<4L$6]R!J5$AA=B!/VFANV)_'MX.YF'R=3/7IDE$DF8QNJ?%T^EZ M"?HC*=?VWG].=;\L1Z-GD)-_Y&9Z!NJ3NC4/)&C'^<?]D7B/?ZRH0MQ_*YPI MO?$A6^I33O#DZ$L@:!97N==`4M:#*&6KS^[9]5N,PY:)F4P7+&/B3Q<H@3P* M#DA5#K.(`(X`BTG?WKD_AKV--4_-JH@/=NMUG46B1(A"[RPQ!0GJ:,C49MAZ MH;LFGS;E-E4FA2FE>*PZBS`*E,^YGZ2!B,J4EC`0$\+9<$>6'LHUCSV4V2'5 MVB]R.FZHAS(N[CLX.?[_/:'6P``Y?#SO6<$/D"Z/'.7O:K:YD3"*X-5=^BU* MU^TE.HVRG>@9W[&C&`*,^_9!%AA2AE%H:U$4NI\QCL^@__OEV8>+TBJBPQ9V MK)$Q2H*@F(QN[W`;P0'4,^:(-Z.G79%O,"84?@6F7C!(_-DX*$KX>UM^D,0% M&6;U_`<L?I84LV9+N/5-OJ7(GA:S\4@XX$$7,Z9Q2%W7.#P0*R0</N>I#Y?] M*%X*)U%=!N0-^+H^0+<7N*(6T:`8?4?G0E^X!%%4D9_>">2"-0(._-O.68AB M9ZR@%[\BRFMP^7J=4K-_Z1:MED1%M98YWW&Q,R488:F]HZ;B<-GP*,8-_B=6 M,]SL'-@L__!:?]**J00RP`,H7ZZ.84YT)/7.5UR(Q$%:`BQV=F#P5I4=A`=U M1#`!PK<X_4!<D$1(HUA$+T)4DH;.V./X1\(Q@6/H-?;W*PT)N_\"PW;'N#)7 MA!9X41(RJB?DV^C^A&,VZ+Y':\)KQL[S-05/T'FE/BX7>A4$#',:PJ6JZMX% M`<&#F!A:-@H2-(H(8(C/D9G()!6/,L8]#)7!F$T*U0!W*KPP"28H3/H`@Z3[ M<#&A$G*6%&$?B/VHJ+&=D&^8Q&C*8/GH@LTQ%J'#CW_2T1YI!0?@V$CLB!@> MF(?Q.M!)N^,R?PD315!&9E82)/@0!OLVFN=]3;44=/"S?'Q<(UHY1&@U@HG_ M,0G0'P;'''Y-?8R8O)Q/0[RFIEECL`"4]>(8ZR7`C<:P/AZ[7!Q]$MZQ1!I7 M5JI+R483,.U?69^^]&%"=W74$WIC%#`L5BB[/A%=V7U\=(V>11RHK'55J346 MK6SKV3CD-+D$-[LW5O.P*-N%R?8519H<,I+&IJ91IULU*N_50H8KNM:L*2\" MNW*(M)J(NFR=N+OYQ-T5B"<["T4*.+M^\Z;[B4)NU,JN9!3+D+EF1]$KWK/6 MK=<*@;)6*ZG%\';-;>NTRFVLT8TC3\&FMP\I=CG^Y[5L5EY_.$3W4+Z=4)26 M`8-GX`8"O^'&0IL]!:>0263X%?A'XSH)M!V>'FBW&J'EZ_*R]R&SZE;1IG<Z M@S+]U#T+V!S*@X@'H>K)*AK(\=`-JC2(<+*45/&<(#?*)VA,C!4@_9.+C24? MTRI9PV4\$[7M=(*UU8>B6()"2=`T+)UPTH`>*/5[;\^N^XR+YE.'1%%GBD<[ M#2O?"^S(&2S()>Y+@@:-8UC:Z&;*W6C3-(RFMT'/*-O0,DJSO":TGZ!CS&MH M6$O3L'VOP>$/&O(9`;8@1.4)(`_L/A%#=Y<S],PD>!ZTSZ7SH\"MX@Y'VQ1L M46(/3(,Q1K(EP#%%<?H2A*1A"8*"X9O$P496$=!84%\,FX!ABV;!/3Y#P&[A M"_-=*2VCAC-X6`R]"P?1VT#LLZBN'!()AAW+3(-D)4S0P%+0Y`J>02;^BO8C MA.HDBASDN)_@20"K&*)!!1^;\.3BRQ:([KCW<2?_N@Q@*Q]F(%X'C_Y#&>#J M?H)`KE(IFL]P0:1K@=QY41,YB$N3?.;WZZULICM15#W!\SH%_*]6.PQ`B^(5 MZ"P]S`Q6D>P@%,YX5@>.8U`,]I+[LXOI-`WXLO:+F7!$A+1S(-";^7:GP4Q) MPK\G.2-^_J)_'B$-<2`>6K!4W92W89PR&?F:Y4',2*JZ7D42(6JB%LI35.Z1 M&?,SVYW+SAN>ISVYY;Q:X']Y!U2Q^:X,.95QB95/_:Z>D#9Q-"I+!C$C+I#Q MYN)ZU6K5*51D.P\`1^'>,@&P2J&>X;XKO\O.XV.1$*ND$F),("LA#YY*2BE$ H+!;BDDG]:!);!E\I*R/&WGUA*D-91.R*9PM8].AV\1]RR)27`6@````` ` end ***END*** Good luck everyone, and yes, this minion is trying to help *8-) Ray Glendenning From evstack-request@ontv.com Sat Jan 31 17:39:48 1998 Return-Path: <evstack-request@ontv.com> Received: from salsa.visus.com (slist@salsa.visus.com [192.76.184.34]) by synergy.caltech.edu (8.8.7/8.8.7) with ESMTP id RAA16401 for <ggi@synergy.foo.net>; Sat, 31 Jan 1998 17:39:47 -0800 Received: (from slist@localhost) by salsa.visus.com (8.8.7/8.7.3) id UAA11069; Sat, 31 Jan 1998 20:03:21 -0500 Resent-Date: Sat, 31 Jan 1998 20:03:21 -0500 Date: Sat, 31 Jan 1998 18:13:58 -0700 (MST) From: teunis <teunis@mauve.computersupportcentre.com> X-Sender: teunis@sigil.computersupportcentre.com To: EvStack list <evstack@ontv.com> Subject: advantage of that raw kbd code :) Message-ID: <Pine.LNX.3.96.980131181237.512A-100000@sigil.computersupportcentre.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"uDOrP2.0.Oi2.jcyqq"@salsa.visus.com> Resent-From: evstack@ontv.com Reply-To: evstack@ontv.com X-Mailing-List: <evstack@ontv.com> archive/latest/597 X-Loop: evstack@ontv.com Precedence: list Resent-Sender: evstack-request@ontv.com /sbin/kbdrate -r30 -d 250 works again :) I have fast repeat again :) I is happy [I finally noticed :] G'day, eh? :) - Teunis [back to playing with ELF files and learning about the EvStack protos... and learning Objective C - a very fun language :]