From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49C4177D.5070904@orcasystems.com> Date: Fri, 20 Mar 2009 15:23:57 -0700 From: James Tomaschke User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <8935727bfb98e59a33fb7a243441ed8f@terzarima.net> In-Reply-To: <8935727bfb98e59a33fb7a243441ed8f@terzarima.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c1885182-ead4-11e9-9d60-3106f5b1d025 Charles Forsyth wrote: > 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 did have an implementation where the program could open the driver and select which input stream they were interested in from an enumerated list, if more than one stream is selected it will mux them (interrupt events are simply discarded if not desired). As far as 'k' 'm' 'w' 'p', better choice would be buttons/axis. A three button mouse with wheel would have 5 buttons and 2 axis. This can keep the complexity down in the driver.