Speakup in userspace

[Doug Sutherland]

Samuel said:
What we want is stealing some keypresses, but not all of
them.  The way to achieve this with input is currently to grab the
physical device, and re-emulate the keypresses we don't want in a uinput
device, which is quite tedious.

Fair enough. But it would seem that the components that make up a 
specialized system like this need to be decoupled rather than monolithic,
for many reasons, one being allowance for alternative modalities. What 
would be very useful I think, would be if those "stolen" keypresses could
land in a  /dev/input event queue. This decouples the input device from 
what is done what those stolen keypresses. It would also allow for some
other modality, not PC keyboard, to generate those same events by 
some other means. Consider someone who cannot type for whatever
reason, who needs an alternative interface other than the keyboard.

The Input Driver may be tedious but it's uniform and modular. If we are 
talking about potential user space versus kernel space, then it would make 
some sense to dissect the overall functionality into layers and separate 
them, then figure out what needs to remain in the kernel, ideally as 
somewhat "atomic" functionality, probably as several drivers instead of 
one, then think about how in user space an application might use those. 
The approach of putting it all in the kernel has quite a few detriments, 
probably the largest being the need for constant maintenance as the kernel 
changes. One small example, although it may be tedious to steal key
presses and then re-implement them, once that is done as a separate 
driver on its own, then very little should change from kernel to kernel 
version. One the other end of things, console output, there is even 
greater need for layering and atomicity of function, since what used 
to be a serial port is functionally the same now but the protocols and 
hardware to implement it (usb serial) is completely different. 

It might be a good idea to think in terms of what I would call 
vertical protoype if we want to explore user space versus kernel.
What I mean by that is rather than thinking of how the entire new 
design would work, take a small cross-section of the whole and 
try re-designing a simple example that traverses from input to output. 
In commercial, in-house, or contract software this approach is 
essential (vertical prototype) to ensure that the architecture is 
sound before attempting to re-design the whole mess. 

The need to steal keypresses is not new or unique. It makes a lot
of sense to pay close attention to the re-architecture of linux input
method and console projects. Even if it's tedious or we don't like 
how some things are done, throwing it out and going direct to 
hardware digs a hole that makes it hardware specific to x86 and
most likely a never ending cycle of maintenance so it doesn't 
break as the kernel evolves. 

Thinking about the whole process in abstraction somewhat like
the model-view-controller design pattern would make sense.
Stealing the keypresses should be independent and atomically
abstracted from what those keypresses do.

  -- Doug