[MiNT] IKBD (or generally user input) driver with "hasFocus" feature

[Petr Stehlik <pstehlik@sophics.cz>]

Hi all hackers,

there has been a long and interesting thread about user input in (Xa)AES
in this list more than two years ago (January 2001). I don't remember it
but Standa forwarded me one little mail (from Sven) containing some
interesting bits of info. It would be worth to read the whole thread
(for me at first).

Anyway. Henk just told us about a sync problem with mouse (while the
keyboard in XaAES is also accessed in two different OS levels) and also
current vconsoles are accessing the keyboard in a weird way so that
shutting down the system does not work properly (if I understood
Konrad's notice). So it seems that we should do something about this and
create proper /dev/devices that would finally solve all these issues in
a clean way (mouse, keyboard, joystick).

Now after reading Sven's mail (Date: Mon, 08 Jan 2001 19:52:54 +0100) I
thought it would be worth re-opening the discussion about the user input
capturing in MiNT. Sven said the whole AES should be put into the device
driver completely (to save a context switch) - I think it's too radical
(or even crazy) but I like the idea of the lowlevel device driver
knowing which application is 'on top' or has the input focus. The goal
is that when there are two programs running in parallel and both call
Bconin(), only one of them (the one with the input focus) should get the
pressed key.

Now I've got the following idea: the input devices could recognize a
'hasFocus' kernel attribute/function and send the input events only to
the app that would have this hasFocus attribute set. By default (when no
AES is loaded?) it could be true for all running applications (this
would probably be compatible with current implementation?). But if AES
got loaded it would decide which application has the input focus (which
window is on top). That way we'd get the user keyboard/joystick events
distributed to right applications.

And there's one bonus: imagine that we would write new vconsoles that
would be reading keyboard with standard clean Bconin(). Now vconsoles
could also hook to the 'hasFocus' mode and decide which of the 10
consoles should get the user input. Cool, isn't it? The new vconsoles
could be running on top of VDI so that all graphics card users could
enjoy the vconsoles again. Now that would be something! :-)

When I am thinking about it I feel it even makes sense. The "hasFocus()"
would work similarly to XBRA chaining so that several kernel drivers
could load in and drive it. Say first woud load vconsoles - they would
decide if it's F1-F9 (one of the virtual consoles) or F10 - console. 
And on console GEM would be running and the AES input kernel driver
would decide which of the GEM apps does have the input focus... Or it
could be loaded in different order - say first AES and then VDI
vconsoles (virtual consoles running in a fullscreen window on gfx
card)... I can see it working. It would be great. Or wouldn't? :-)

Petr