At 04:00 PM 7/27/98 , Lennart Augustsson wrote:
>
>> Why push this complexity into the kernel?  Things like the X server
>> already need to be able to cope with different streams of input, etc.
>> It seems to me that it would most logically be handled there.
>Well, it's always a problem where functionality should go.
>You could argue that the mouse protocol decoding should be
>done in the X server (as it partly is today) rather than in
>the kernel, but the current NetBSD trend is to move that to
>the kernel.  I think this situation is similar.  Yes, the X
>server could try and open /dev/wmsN (with N = 0 .. 15 say)
>regularely, and take care of new devices that show up.
>But personally I think putting this kind of functionality 
>in the kernel more pleasing.  Too bad our configuration code
>can't do it in a simple way.

Maybe I'm missing something basic here, but should there be a 1:1
correspondence between a wsmouse? and a device?  Why not allow
a process to open a /dev/wsmouseN and then via ioctl's select
what mice to get events from.  (the problem with multiple devices
has to do serialization of events).  The default could be defined
in the config file be either ALL mice or a device per mouse.