Egbert Eich wrote:
> > 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.
> >
> Hm, doesn't ProcessInputEvents() only process the events already in
> the queue on the server? From looking at the code it doesn't seem
> to do a read() to obtain events that have not been read from the
> kernel - but that's what we'd need.
Right. ProcessInputEvents doesn't read events from the kernel.
Such check in the autorepeat callback function might make sense only being used
with a SIGIO driven input.
> > 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.
> >
>
> One could move the timer handlers past the end of the
> if (i <= 0) { } else { } statements. However with input queued
> (ie when the mouse is constantly moved) the timers don't get
> called either.
Can the mouse movement really make such frequent stream of events?
BTW for timers that need the devices input checked first (screensaver, DPMS,
keys autorepeat) it is not a problem. Anyway they do something useful when
input evens absent some time. But for other timers it can be important.
If such danger really exists it argues for a making two kinds of timers and
distinguishing them.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
