From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8935727bfb98e59a33fb7a243441ed8f@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Fri, 20 Mar 2009 11:05:38 +0000
To: 9fans@9fans.net
In-Reply-To: <a104dd0de7ac139f1036ce147b53ade6@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Raw Input Driver
Topicbox-Message-UUID: bff02002-ead4-11e9-9d60-3106f5b1d025

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