home *** CD-ROM | disk | FTP | other *** search
Wrap
Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id LAA13256 for <executor@nacm.com>; Fri, 8 Sep 1995 11:45:17 -0700 Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id MAA13824 for nacm.com!executor; Fri, 8 Sep 1995 12:45:11 -0600 Received: from beaut.ardi.com by mailhost with smtp (nextstep Smail3.1.29.0 #11) id m0sr8K0-000YbDC; Fri, 8 Sep 95 12:38 MDT Received: by beaut.ardi.com (linux Smail3.1.28.1 #5) id m0sr8K0-00005oC; Fri, 8 Sep 95 12:38 MDT Message-Id: <m0sr8K0-00005oC@beaut.ardi.com> Date: Fri, 8 Sep 95 12:38 MDT From: ctm@ardi.com (Clifford Thomas Matthews) To: executor@nacm.com Subject: [LINUX ANNOUNCE] SVGAlib suggestion: wait for 1.99o8 Sender: owner-paper@nacm.com Precedence: bulk Hi Folks, This message won't make a lot of sense to non-Linux users. Mat and I have done a little more work on the SVGAlib port and we have overcome the freezes with a black screen bug. However, much to our chagrin it turns out that the feature that is present in the newer kernels isn't present in all the new mouse drivers, only in one of four. Ack. That means that upgrading to 1.3.x isn't particularly useful unless you happen to have a PSAUX mouse. The driver mods that we would like to see made are easy enough to make that I'm tempted to make them myself, but that would then require everyone to move up to the absolutely latest kernel, so it makes more sense for us to put extra code into Executor to get around this lack of functionality. Specifically what I'm talking about is the ability to get a SIGIO signal sent to you every time the mouse moves or the mouse button state changes. So, I need to finish working around the SVGAlib bug that Mat described earlier today and then I need to make it so Executor can poll the mouse a few times a second. Then, if Mat is finished with the linear frame buffer mapping code for Executor/DOS, we'll roll 1.99o8 and it should work without much trouble. I don't know if we'll have an ELF version at the same time or not. Cotton has been running an ELF Executor for a while, but his connectivity is lacking and we haven't gotten his mods integrated into our main source tree yet. There is, however, another kernel mod that I *did* make that is fairly important if you want to run certain games at approximately the correct speed (Solarian is an example). I've sent it to Linus for inclusion in an upcoming kernel but I haven't heard anything back from him. If you feel comfortable applying patches of dubious quality, it's included below. All it does is fix an apparent off by one error that prevents setitimer from functioning the way it should. Sorry to have hyped the SVGAlib version of Executor so much only for it to lose on most of your systems. The bugs aren't in Executor per-se, but the buck stops here so we'll work around the problems. --Cliff ctm@ardi.com beaut 4.28 rcsdiff -c3 sched.c =================================================================== RCS file: RCS/sched.c,v retrieving revision 1.1 diff -c3 -r1.1 sched.c *** 1.1 1995/09/05 19:31:40 --- sched.c 1995/09/05 19:32:44 *************** *** 531,537 **** struct timer_list * timer; cli(); ! while ((timer = timer_head.next) != &timer_head && timer->expires < jiffies) { void (*fn)(unsigned long) = timer->function; unsigned long data = timer->data; timer->next->prev = timer->prev; --- 531,537 ---- struct timer_list * timer; cli(); ! while ((timer = timer_head.next) != &timer_head && timer->expires <= jiffies) { void (*fn)(unsigned long) = timer->function; unsigned long data = timer->data; timer->next->prev = timer->prev; *************** *** 706,712 **** mark_bh(TIMER_BH); } cli(); ! if (timer_head.next->expires < jiffies) mark_bh(TIMER_BH); if (tq_timer != &tq_last) mark_bh(TQUEUE_BH); --- 706,712 ---- mark_bh(TIMER_BH); } cli(); ! if (timer_head.next->expires <= jiffies) mark_bh(TIMER_BH); if (tq_timer != &tq_last) mark_bh(TQUEUE_BH);