Bug#142569: interaction between kernel and xfree86 v 4
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? :)
Reply to: