is a bug with the elographics driver:
I'm using XFree86 Version 4.4.0 (with circa redhat6.2 libraries and linux kernel 2.6.4)
with an ELO touchscreen (elo2300 I think). If I have a "real-time" high priority (SCHED_FIFO)
task that periodically sucks a lot of CPU time, the ELO touch interface falls behind. Once
it's behind, it stays behind, even if I kill the high priority task. It seems to have a queue of
data that doesn't get serviced unless a new event happens.
For example, say that during a period when the CPU is being hogged, I try to move
the pointer in a big clockwise circle multiple times. Then I kill the CPU hog process.
The pointer does not start moving to catch up when the CPU hog dies. It just sits there
at its last location. If I wait 5 minutes and then touch the screen, the pointer starts
moving in the circle that my finger followed 5 minutes earlier. When I stop touching the
screen, the pointer stops. If I touch it again, it continues following my earlier finger
motion. It seems to slowly catch up if I continue interacting with the screen.
If I have a mouse in addition to the touchscreen, movement of the mouse also causes
the pointer to service the events in the elo touchscreen queue and at a much faster
rate. However, motion of the mouse during the time that the CPU is being hogged
does not seem to fall behind the way the touchscreen does.
Thanks:
David
_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
