Re: Thoughts for discussion & info request

Hi,

Wittenberger wrote:
>
> The solution would be, to register both servers under a new, different
> name. Say the old 2 button one as /dev/mouse2b, the new (build on to
> of the old) als /dev/mouse3emu. Then you may bind the name /dev/mouse
> to /dev/mouse2b in the namespace for the old client, and to
> /dev/mouse3emu for the new client.
> (BTW: how would that be done in VSTa???)
> But how the hell, should the author of the old 2 button server know
> that it will ever needed to do such? He can't!

Well, after I did some work on the serial and ps/2 mouse code a couple of
months back I think the server handles both 2 and 3 button mice
automatically (it's possible on these 2 types to handle 2 button mice as a
subset of 3 button mice).

As for the problem with what we call them, I can see two easy ways to
implement this:

1) We could simply call the mouse srv/mouse (as we do now) and use the
FS_WSTAT mechanism to allow the client to specify the mode of operation. As
an example we could define "btnemu" which could take an number of arbitrary
states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's
an exagerated example, but I think it gives the general idea.

2) We could make the mouse server provide a subdirectory of possible server
variants - whichever one is opened by the client would then define the
server's behaviour, say:

        srv/mouse:2btn
         srv/mouse:3btn
        srv/mouse:2emu3btn

When we mount the server into our namespace we can mount either the whole
server namespace and have say:
 
        /dev/mouse/2btn
        /dev/mouse/3btn
        /dev/mouse/2emu3btn

or we could mount the individual server variant we require and just call it
/dev/mouse.

In this instance I'd have a personal leaning towards solution 1, but there's
no good reason that I can point at for this, as with the modified fd server
I've used the second approach to allow the user to specify the media type
in the drive. It's exactly this sort of flexibility in server coding that
makes me prefer VSTa to say Unix (although it did take me a couple of months
to appreciate the benefits).

                Regards,
                Dave
Received on Sun Aug 14 23:31:33 1994