dear herbet, it was suggested to me after conversations with branden that i relate to you a story that may be of assistance to you.
i believe that there is interaction between the linux kernel and xfree86 that is causing keyboard and mouse problems. the linux kernel is not at fault. xfree86 is not at fault. any hypothesis along the lines of "x version 3 worked "fine" with the linux kernel therefore any changes to either the kernel or xfree86 must be the fault of the other developer" is neither helpful nor true. the story that may be of assistance is as follows: i was called in to help work on X11r4 which was running, back in 1992, on an Atari Transputer Workstation (ATW). this machine was an array of 32 Inmos T800s using an Atari ST 520 as its human interaction "device driver". the ATW had no keyboard, no mouse, no screen: it communicated everything via the ACSI (atari computer systems interface which was actually a SCSI interface with a 16 byte buffer it was a royal pain). X11r2 and X11r4 did not have middle-mouse-button emulation, so it had been added into the ST 500's communications code and also as a hack into the X11r2 code. the ATW in the research centre had been upgraded from X11r2 to X11r4. X11r2 was dog-slow, and as it turned out had a useful "feature" where, being so slow, X-Events took quite a significant amount of time to be processed. therefore, it was altogether possible that when someone "clicked" both buttons on the mouse on the ST 500, it was entirely possible that both "mouse down" events would be in the X-event queue when transferred over to the ATW at the time that this occurred. so therefore the X11r2 code had been "hacked" to have a "hook" which said, "if there are two down-events, one on left and one on right next to each other in the queue, replace them with a single down-event on the middle button". ... but X11r4 was modified: it processed mouse events almost immediately (as received?). therefore there was _no_ occurrence of there being two mouse events in the queue. therefore, the middle button emulation - which wasn't very _good_ emulation - failed. and despite that i was called in to fix X11r4, in the end i had to write a proper interrupt-driven mouse handler at the Atari ST 500 end (including coping with and tracking down a bug in the Lattice C Compiler). the little driver basically had an interrupt timer and stored mouse button events for 100ms or whatever before sending them on via the interrupt handler: if both were pressed, then a middle-press was sent instead. the point of mentioning this story is because there are now TWO XFree86 problems, one with mouse and one with keyboard, that did NOT occur with X version 3, that ARE now occurring with the rewritten xfree86 version 4 code, and they sound suspiciously to me like an "interaction" issue similar to the problem i had to solve, ten years ago. i understand also from branden that the keyboard bug has been dismissed as "definitely an xfree86 problem". yes it _is_ definitely an xfree86 problem: xfree86 don't work properly with the linux kernel!!! ... just a thought: perhaps it would be best to contact, say, one of the FreeBSD developers to see if these two xfree86 v4 issues can be reproduced under FreeBSD / OpenBSD? that would at least give more info on the nature of the problems. l. p.s. i was the person who came up with the repro method for finding the Xfree86 v4.0 bug back in march 2000 - the one where if the computer is very very busy (loadavg > 20.0), and you're running a few X applications, and you then spang the mouse all over the place whilst at the same time randomly pressing and releasing the two buttons as rapidly as you can, it caused a SERIOUS lock-up failure of the entire GNU/Linux system, i.e. power-cycle time. what _was_ that one all about, in the end, anyway? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
