Re: [9fans] Raw Input Driver

[Francisco J Ballesteros <nemo@lsub.org>]

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 <forsyth@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
>
>