Re: Asynchronous keyboard callbacks (was: [AD] Proposal for an input model)

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> The scancode callback detects releases, but the unicode one doesn't.

Ok, then the Unicode callback would be useless. The raw scancode callback
would be enough though, if the API provided a translation function (like the
current scancode_to_ascii() function).

> 1/. We need to provide a mechanism for unhooking one subsystem and
>    installing another; this cannot simply be another driver, because
>   it needs to kick in when the user registers a callback.

Yes, it has to be the same driver. But IMHO 80% of the code would be shared
between the two sides of the driver.

> 2/. The driver implementation is non-trivial, since it not only has to
>     call the callbacks (which will therefore be called from a different
>     thread, and the user needs to be aware of this), but it also has to
>     emulate the simple polling driver by maintaining an event queue.

The callbacks are already called from threads in Allegro 4.0, so nothing
would really change.

> 3/. If pthreads aren't available (does this ever happen?), there is
>     some more messing about with SIGALRM or whatever.

Yes, signals are clearly very limiting.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx