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

Three mice

[Hermetic]

I currently have three mice at work.
It is on a W2K machine, but it works just as well in Win98. Since it is USB dependant, I have never been able to make it work in *nix.

With USB mice you can plug in a mouse in the USB slot and one in the PS/2 hole. I don't know if there is a limit, barring the 127(?) device limit on a USB chain. They all move the same pointer, however.

This can still be useful when the mice can have different sensitivity settings. One of my mice is the Razer Boomslang 2000 (order from ThinkGeek) that can be set to absurdly high responsiveness, which makes it unwieldy for graphics work, but great for gaming. The PS/2 mouse and the castrated mouse are both a lot easier to use for fine work, or when someone that can't handle the Razer sits at my desk.

I have long looked for a utility that would enable mutiple pointers so I would be able to use whichever hand wasn't typing to mouse with, but have never found anything that makes it look possible.

Mutiple Mice

[lrichardson]

Geez, I saw this implemented several years back. Engineering office, using AutoCAD, with mutiple monitors per user. A couple of the people there had the 'keyboard with touchpad', as well as a regular mouse. Very useful having a pointer on different screens. I think the implementation had something to do with the net-admin's desire for killer gaming, rather than enhanced productivity. Oddly enough, I think it was a DOS/Win 3.x system.

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?