Keith Packard
Sun, 21 Sep 2003 09:30:24 -0700
Around 18 o'clock on Sep 21, Egbert Eich wrote: > So what would be the way out? I suppose one could use a wakeup handler > instead. This however would only work if the wakeup handler for keyboard > input was called before the xkb timer handler. The latencies of > other handlers that are called before the xkb handler could also > cause the timer to expire with the key release unnoticed. One fix would be to have the xkb timer check for pending input before testing for a pending key repeat. That might be a good change in any case as it makes the interdepence between input processing and xkb timeouts explicit, rather than trusting to careful coding elsewhere to ensure that pending key events are processed before examining the current state. > Another solution may be a a SIGIO driven keyboard input. SIGIO driven keyboard input can't solve the fundemental problem -- SIGIO driven devices can only queue events, not process them. Event processing can only be done in the main thread of X server execution, not a signal handler. I do like having timers processed at only one place in the server, and my concern that some existing timer usage relates to some file descriptor activity can be resolved by having WaitForSomething return 0 if it processes any timer events so that Dispatch will immediately loop back around and invoke it again. It might also be a good idea to move the check for queued input above timer execution loop; that will further shrink any problematic window where input events affect how timer code should execute. -keith _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel