Egbert Eich
Sun, 21 Sep 2003 12:05:22 -0700
Keith Packard writes: > 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. > That was my suggestion. But I'm afraid xkb doesn't work like that. Not xkb checks for pending input the ddx layer does in a wakeup handler that does so and passes information on to xkb. The timeout handling would have to be moved from xkb to ddx. > > 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 agree, but I don't think there is a restriction on the amount of processing done before the events are queued. Therefore events could be processed far enough to know if a pending timer for a repeat should be canelled. But then this would require more extensive changes in xkb. > > 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. I haven't looked at the code myself - but David just mentioned that there don't seem to be any timers that do. Appearantly all file descriptor are handled in BlockHandlers. If there really are such timers we should do that - probably only if a timer changed the file descriptors. > > 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. > I think that's what Ivan's patch does: The only place where timers are called is after the select and the WakeupHandlers. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel