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

[Laurence Withers <lwithers@xxxxxxxxxx>]

I wrote:
>> al_register_keyboard_callback(void(*)(int));
>> al_register_scancode_callback(void (*)(int));

In reply to Eric Botcazou <ebotcazou@xxxxxxxxxx>:
>Do these functions detect key releases ?

The scancode callback detects releases, but the unicode one doesn't.
This mirrors the simple polling functions. (Obviously, if you can think
of better semantics, let me know).

>> On Linux, this would be fairly difficult; the very simple polling system
>> would need to be unhooked, and a different subsystem (operating in its
>> own thread) would be installed and have to emulate the current system.
>
>Why fairly difficult ?

Because:
 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.

 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.

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

>> Hmm. It would be simpler, solving both your questions, if we provide our
>> own thread API, but should we really do that?
>
>I personally don't think so.

Oh well ;-) That's another question for another time entirely.

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature