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
