jft: The event renaming idea is a good one, and much better than what I had in mind (which I probably wasn't going to do, at least any time soon)... which was to try to figure out how to recompile the kernel modules and add some way to disable things in there.
It should work. We just need a startup process that runs before the framework starts up, which renames those events (probably to something with no chance of a collusion, like eventKeyboardHook and eventFiveWayHook). Then we can try to create pipes for event[01] and do what you said with selectively passing on input events (if that's sufficient, and something in the code layer doesn't try to check it for device major/minor numbers...)
If something DOES want a real device, a passthrough device can probably be done without a whole lot of trouble. (Is there already such a thing? It seems like a potentially common enough need) Certainly less trouble than trying to modify the input device modules themselves.
If, however, something in the framework actually looks for the device major/minor numbers... then we have to change the actual modules themselves. (Unless there's a way to load devices at a different major number?)
The startup script would have to be very careful not to rename the device files if any part of the replacement system was missing or didn't work (or didn't uninstall cleanly).
|