Hello,
Egbert Eich wrote:
> > One use for timeouts is to handle external network events, such as font
> > server reconnect or XDMCP messages. In those cases, the timeout routine
> > can modify which sockets will be needed in the select mask, hence the
> > desire for the timeout routine to execute before the select (and various
> > BlockHandler) routines are invoked. When the timeout routine fires only
> > after select returns, the server will go through a complete scheduling
> > interval before the BlockHandler is invoked.
> >
>
> 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.
>
> The only way to ensure that a possible release event is detected is
> to read the keyboard in the xkb callback handler to check for
> pending release events. However I'm afraid xkb simply doesn't work
> that way.
>
> Another solution may be a a SIGIO driven keyboard input.
Except the solution I offered I considered as possible solutions:
- a check for input directly in the autorepeat timer callback function,
- a using of additional wakeup handler,
- a using SIGIO driven input,
- an additional flag for timers to distinguish them in the first check
in WaitForSomething.
1. Check for input in the callback function.
I don't like it because it works on the level that is far from an interface
with a kernel. In our case a release event is not even read from a kernel
driver hence the callback routine should somehow start this reading. But it
deals with a dix level device structure _DeviceIntRec. That structure has
a pointer to an input device driver but the driver itself is opaque for this
level. Moreover in the case of a built-in keyboard driver the DeviceIntRecord
even has not such pointer and so has not any hooks to initiate a reading.
Also we need to be sure that a file to the kernel driver is in NONBLOCK mode.
In most cases it is but I'm not sure it is always.
And finaly, the state when unneeded events are generated happens very seldom
but to avoid it the callback routine has to call a read syscall every time.
2. An additional wakeup handler.
Frankly speaking I didn't consider it deeply because it seemed to me unnecessary
complex. What happens if there are not real key events and the autorepeat
event is really wanted? The timer check before the select doesn't emit
an event but only puts a task for a wakeup handler that will be executed after
the select. But since the timer is already expired, WaitForSomething thinks
this timeout already consumed and makes the select wait until a next timeout
expire or any other event happens. It is incorrect too.
Therefore in this way we need: change a timeout figuring out, add a wakeup
handler itself (and we need to be sure it stands in queue after input devices
reading), insert a ProcessInputEvents() somewhere between handlers processing
and so on. And anyway WaitForSomething has to be changed.
3. SIGIO driven input.
It is almost ideal. Frankly speaking I didn't guess how to solve the problem
that a SIGIO handler only reads input devices but doesn't do a complete
event processing. But now after reading replays to my message I see that it
is quite simple. The callback routine can call ProcessInputEvents. It is
much simpler than to make a driver read events from a kernel and doesn't
consume much time if a queue is empty.
But there is another issue. As far as I understand not all target platforms
now support SIGIO input. Therefore it will be a solution for Linux and BSD
only. Is not it?
4. Distinguishing the timers that can be processed before the select and
the timers that should not.
Although nobody mentioned it I still think it could be a solution. I mean
we can add additional flag to a timer (or more if it is needed).
BTW a subroutine TimerSet already has a 'flags' argument but doesn't save it
for a future use. On the other hand it means we don't need to change all
TimeSet calls but only those that really need to be checked after an input
devices reading.
The first timers check in WaitForSomething should check this flag in a timer
and skip such timers.
--
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
