Two Mouse Pointers And One Display?

metasynth asks: "I've been looking around a bit for information on this, but haven't had much luck. What I would like to do is to get two mice running, each with its own pointer. And be able to distinguish between the two in programs, e.g. something like mouse1.button1 as an event so I can tell which mouse did what. I have found references to getting two mice working with one pointer, which I've been playing around with but have yet to get it working, but I really would like two pointers." I don't know about you all, but I would get a bit confused by the presence of two mouse pointers. Do you all see this as a neat idea, or would it be a tough thing to implement?

Comments

You'd break virtually all apps and the WM.

[MemRaven]

Someone else pointed out that on Win2K (and the old-skool macs with ADB, the precursor to USB) you can have multiple mice connected, with one pointer. That's pretty much going to be the limit of what you're able to support, but only part of it is going to be the mouse hardware itself. I know that on the mac in the bad old days, the pointer movement was actually handled by the hardware itself (i.e. the OS passed an XOR map to the graphics hardware, and the hardware passed interrupts to both the OS to handle events AND the graphics card to draw the pointer). I know that currently many of the GDI calls on windows are handled in hardware (i.e. no software rendering for some things). I suspect that there's some wizardry going on there, but I'm not sure. You think that's going to be something which is easy to figure out?

Quite a bit more is going to be the software itself. Particularly on a system which was never designed to handle multiple mice, do you think that code like the X server is necessarily able to handle multiple mice doing things simultaneously? Also, if I remember correctly (but it's been some time since I did raw Xlib programming), the X protocol assumes ONE mouse. Which means that there's no way for the X server to talk to the applications and tell them that it was the second mouse that did something (i.e. no differentiation possible). You'd have to rewrite portions of X to get the second mouse active. Even if the X server and/or hardware was able to distinguish between the two types of mouse interrupts, AND show two different pointers, what about the applications?

I know that most of the software which is happening on the front end is built to be single-threaded (for example, almost all of KDE is based on Qt, and one of the major problems I have with Qt is the crazy way it handles simultaneous events in a single-threaded model). Let's start assuming that it's possible for your application to start receiving two simultaneous mouse events. Will every bit of software be able to handle it? Not necessarily.

And then let's say that you get to the point where all the hardware, X Servers, widget toolkits and window managers are able to handle it by queueing the requests. Mouse events happen MUCH more quickly than keyboard events, so even if your application is designed to be fast enough to handle a keyboard event with reasonable speed, is it fast enough to handle multiple clicks simultaneously? What about mouseover events?

So you're looking to rewrite the X protocol, your X Server, and then spend about 6 months debugging every application you use. And that's assuming that you get the hardware to handle multiple pointers.

Still seem worth it?