There's a kbdin device used by the usb keyboard driver to feed scan codes (from usb) to the kernel keyboard driver for processing.
If you are modifying kbd to read scan codes as well, this may be relevant. On Fri, Mar 20, 2009 at 12:05 PM, Charles Forsyth <fors...@terzarima.net> wrote: > i think it is a mistake to reintroduce single even streams let alone > `callbacks'. > > it's easy enough to provide a device (say /dev/scancode) or a consctl mode > that gives you the raw keyboard codes. we used the former in inferno, > but the latter might be more logical since it's a different mode > of the same device. either way, it worked fine in native inferno. > (i can't remember how much was in the hosted versions, but i thought there > was support for scan codes in windows and x11.) > > the ordering problem is misleading: you need timely response for > interactive applications; it's a reasonably straightforward application > of real-time programming. (by the way, if you're passing low-level > things like that across lossy wireless networks, you're possibly > not addressing the most relevant problem first.) the effects you're trying > to synchronise > are typically changes to data structures inside a program (including effects > on the display), > so that's where the synchronisation and interlocking should be. > > it's not as though the underlying devices > weren't separate streams; they are, and it makes sense for the view > of them to reflect that. it also makes it easier to add new input > devices. i see already you've got 'k' and 'm', with surprisingly different > content, but what about that fingerprint thingy to unlock the cheats? or > perhaps more to the point the > 'w' for wheel and 'p' for pedals? you'll never finish. > > I include these for people that haven't seen them before: > > http://swtch.com/~rsc/thread/cws.pdf > http://herpolhode.com/rob/lec5.pdf > >
