Keith Packard
Sun, 21 Sep 2003 13:10:19 -0700
Around 21 o'clock on Sep 21, Egbert Eich wrote: > 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. The XKB code could call ProcessInputEvents just above the check for a pending repeat key; that would ensure that any input queued either in the X server or the kernel would get processed before repeat status was checked. > 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. The server really can't process events even this far -- detecting which keysyms are associated with each key requires accessing keymap tables which may be manipulated by clients outside of the signal handler. It's far easier to restrict SIGIO processing to event queuing -- that requires no global server state aside from the event queue itself. > I think that's what Ivan's patch does: The only place where timers are > called is after the select and the WakeupHandlers. The timers are invoked just before the test for queued input; moving the queued input test above that should eliminate cases where key events are queued with SIGIO and then not processed before the timer function is invoked. In any case, the current spot isn't sufficient as the timers will never be executed if the server is constantly receiving application input, so at least that needs to be fixed. -keith _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel