Subject: Re: Apollo keyboard, serial drivers (announce)
To: None <miff@spam.frisbee.net.au>
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
List: port-hp300
Date: 04/16/1997 15:33:28
Date: Wed, 16 Apr 1997 22:22:45 +0930
From: mike smith <miff@spam.frisbee.net.au>
MIME-Version: 1.0
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
CC: thorpej@nas.nasa.gov, port-hp300@NetBSD.ORG, tech-kern@NetBSD.ORG
Subject: Re: Apollo keyboard, serial drivers (announce)
References: <199704151931.VAA28680@theory.cs.uni-bonn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ignatios Souvatzis wrote:
>
> /dev/wskbd0: ok.
> /dev/wsms0: is not universal.
>
> I don't want the mouse driver to listen to all serial ports at half a
> dozen bitrates and try to guess whether a serial mouse is connected,
> and at what bitrate, and with what protocol.
... so mandate that the mouse driver has to translate to a standard,
arbitrary protocol. Pick something like the Mouse Systems protocol
(which is just nice because it's easy), and insist that everything
else remassage its bits to comply.
> Xnetbsd (it it is going to be universal) will need a -mouseDev
> /dev/xxx -mouseType someTypeCode parameter (it will be able to
> autodetect wsms events, but I dont see how this can be done reasonably
> for serial mice with 5.5 protocols at 6 different baud rates).
If you have a mouse driver shim, you needn't care about baudrates
or protocols.
> [It might be reasonable to provide a libmouse.so, which provides Event
> encoding for the different protocols... this will make e.g. mouse
> interfaces to userland text windowing systems easier.]
You don't understand.
The mouse driver has no way to know what particular hardware is
connected to the serial interface, and which to which one.
Or, maybe you do:
ie. stacking the protocol translation somewhere else. IMHO that's
actually a better idea, as it lets you use any supported pointing
device on any platform that has a compatible interface. Perhaps
look at the model that FreeBSD's moused(8) uses too, where you have
a user-space daemon that performs the translation and pukes the
results out on a standard mouse queue device. (Don't go looking
to moused for code examples though, it's a fairly grubby individual.)
I don't think its wise to do dozens of kernel/user
translations. Wouldn't matter too much for mice at 1200 bps, but don't
want to start this business.
Why not a standard mouse library, with (maybe) a standard way to set
device and (for non-Event, serial mice/tablets) protocol from the
environment/a config file?
It would provide a mouseopen(name) call, which would return a struct
mousedev, which contains a function pointer for the translation
callback function.
-is