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