[AD] Proposal for an input model

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

Laurence's proposal for the new keyboard API implicitly introduced an
underlying input model: polling only. I think we should make a more explicit
decision about this model.

I can think of three input models:

- asynchronous input/callbacks/global variables a la Allegro 4.0: the input
drivers must be able to asynchronously update status variables and call
functions, a polling-like API lives on top of them. The requirements are
somewhat high (threads, ...) for a library.

- polling only: the user must poll to update the status variables,
asynchronous callbacks are not supported. The most lightweight solution and
the cleanest (no more difference between keyboard, mouse and joysticks), but
the asynchronous framework is dropped.

- polling with an optional asynchronous framework on top of it: like the
previous model, but the input drivers are required to expose additional
hooks so that *registered* callbacks can be called asynchronously. If no
callbacks are registered, input behaves the same as in the previous model.
If callbacks are registered, an input thread (except of course under DOS) is
created and is responsible for the asynchronous work, either by periodically
polling or by blocking and waiting for an event (DirectInput).


It seems that the first model is no longer trendy ;-) so my preference would
be for the third one.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx