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
