Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
X GUI

Two Mouse Pointers And One Display? 52

Posted by Cliff from the the-rodents-they-are-a-multiplying dept.
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?
This discussion has been archived. No new comments can be posted.

Two Mouse Pointers and One Display? More

Two Mouse Pointers and One Display?

Comments Filter:
  • You may want to investigate the Spaceball [labtec.com].

    Back when I was doing a lot of CAD stuff, I saw a few guys running spaceballs. Basically, a spaceball is something you run in combination with your mouse. Your mouse does most of the selecting and drawing, but the spaceball does all the movement of the part selected.

    Another way of moving parts on screen was to click on an icon (for translating & turning). A slight improvement involved a few hotkeys that are held while the mouse is moved, letting the mouse do the work.

    I think that the spaceball I used ran on an HP (hpux) box, but I know for sure it was a UNIX flavor.

    I would investigate what exactly you're trying to do. Is it really necessary to run 2 mouse pointers, or would a second input device such as a spaceball help you do what you're trying to do.
  • I'm guessing the later editions were radically revised/had extra chapters with more up-to-date experience of software engineering.

    You'd be surprised how little software engineering has changed ;-) - I joined this game professionally a year ago, and when (6 months ago) someone clued me into MMM, I found it spookily accurate. Sure, the projects have different scope - but they're still run the same. The first project I worked on, it was looking like running late. Management response? "You've got as much money as you like to hire new people". I regard my project manager as a god for replying "Adding new people now would make us later". No-one new joined and we shipped on time and under budget :-)

  • which keyboard? the local one, associated with the local mouse --- or the remote one associated with the remote mouse? How about some buttons down the bottom of the screen that you click a mouse in and then mash your keyboard and the OS maps the two together? How about two entirely separate users logged in with different permissions sharing a desktop on a third machine? One with red and one with blue so you don't get confused, and the security model of the system knows about "I want to be asked if it's OK before new users can join" and "I want to be asked before I open document X in a multi-user situation". There's gotta be ways to do this stuff - it's not like trying to make pipes work in a GUI!

  • The issue of using two mice came up while I was taking my User Interfaces course at the University of Waterloo.

    Basically the idea is that with two mice you have many more degrees of freedom to work with. If you look at a standard mouse, you have 2 + number of buttons degress of freedom. When working with CAD programs and VR design, you need to have at least 3 degrees of freedom (one for each dimension, obviously). The problem comes in when trying to work with a 3D object on a 2D screen with a 2D instrument (mouse). In order to get the third dimension, many programs will do the "natural" thing and project 2D mappings of the 3D object. You manipulate these 2 dimensions, while the third remains fixed. However, when getting into operations like rotations and scaling, which are no longer natural movements done in a 2D plane (ie. moving something on a 2D vector), things get even more interesting.

    Such things require the user to turn the operation on (click an option, hold a key on the keyboard, etc.) Using the keyboard with one hand and the mouse in the other is actually quite effective, but there is still a transition where we are no longer translating; we are transforming. Hence the second mouse. One mouse is useful for translations, and the other is useful for transformations. The buttons on the transformation mouse allow to switch between the transformations, and the motions allows you to perform continuous scaling/rotations while all the time maintaining the ability to translate the object as well.

    Two mice would be killer in Quake! :-)

  • I've got a similar setup where I work. I have a USB keyboard that has a PS2 port in the side, which I hooked up to a nice trackball, and use the PC's ps2 for a standard mouse...It keeps all the people who walk by and use the comp happy.
  • Why would the app have to know that it was dealing with two mice?

    Rather than:
    mouse1.button1
    mouse2.button1

    Why not:
    mice.button1
    etc...
    mice.button7

    Then you wouldn't have to rewrite apps to poll two mice.

  • Seriously though - yeah, universally, it would be hard to do, but on the application level, it would be quite cool.

    Get enough apps that want to do it, though, and next-gen OS's will have to support it - perhaps apps that wanted to play in a multi-mouse environment could describe themselves as such to the OS, and those that didn't could do the same, and the OS would handle bubbling mouse events only to those apps you opened, or which said they could play multi-user ball?

  • no no no no no no no --- mouse 2 is being used by person 2! person 2 probably doesn't have the same security permissions you do (eg. you're showing him your document, so he's got rights over the scrollbars, but he *definitely* doesn't own the delete button). use the desktop metaphor --- on my desk at work, I can move stuff around. Other people can move stuff around, and write on some stuff, but some stuff I tell them not to throw away and some stuff I say "that's important, get your own scratch paper". why don't virtual desktops work the same way?
  • yesyesyesyesyes - this is the point. a physical desktop isn't something that you own that no-one else can join in on, so why do virtual desktops behave like that? OK, we get our work done now, but I cuss a blue streak every day about one thing or another, so something's got to change ;)

  • Well, as a universally accepted n-mice configuration, you are correct that this would require a considerable amount of work and verification. But to be honest, it wouldn't be impossible to implement in a specific application such as a CAD package. But it would have to be specific to the application.

    Personally, I imagine teleoperated n-mice systems such that a CAD supervisor could direct or go over designs with home working CAD layout people. A phone/teleconferencing call could allow for more CAD people to work at/out of their homes.

    In my job, I take a webcam with me to email pictures of components off of assembly lines to show the designers at the home office - often saves a FedEx shipment or worse, a designer shipment. Because we all know "A picture is worth a thousand words or so depending on what compression ratio you use."

    Seriously though - yeah, universally, it would be hard to do, but on the application level, it would be quite cool.

  • I've used multiple mice on my Win2k machine. One was a USB Mouse, the other a PS2 mouse.. I only had one USB Mouse, and I left the PS2 mouse connected at all times so I could grab the USB Mouse when I had my portable in the office w/o turning my desktop off.

    Also I've worked with enough people that use graphics tablets (that act sort of like mice) for their fine drawing, but use mice for general moving around the machine.

    Either of these cases is simple, the software knows how to deal with mouseovers, click1, click2, doubleclick etc... When Microsoft came out with their mouse with the wheel, and immediately supported it with IE, there are still programs that I use that don't support the wheel. How much support are you really going to get for Mouse2 and Button4?
  • When I saw this question, I went "WTF?!" - then I started thinking...

    I first imagined a drawing program - one hand controls the rotation of the paper, the other controls the brush or pen (could make some wacky designs)...

    Then (of course) my thoughts turned to VR apps - imagine one hand controlling a "virtual" hand pointer in space (left button to control left/right/zoom, right to control "grabbing" - no buttons for X/Y positioning). The other hand could control (in a similar manner) avatar positioning in the world - so one could move around, and grab things.

    A similar scheme could be done for games - it is a little awkward, but it might be something fun to play with...

    Worldcom [worldcom.com] - Generation Duh!
  • Actually X suppots two mice at the same time without any problems. They just end up driving the same pointer, so far. I'm sitting here in front of my laptop which has a touchpad built-in and a Logitech optical USB mouse plugged-in.

    Anyway, I can't imagine that it would take much work to make the X server add another pointer to the screen getting input from the nth-mouse. It might be difficult to have most applications do anything different with it though. (However, it is amazing what you can do with your .Xresources file.)

  • Over all, I think I would have liked network or modem multiplayer support better than the two mouse method. It was too tempting to peek at that the other player was doing.

    Too tempting? If you didn't pay attention to what the other person was doing, you were likely to find all of your lemmings falling down a new hole that was not originally part of the map. :)


    OpenVerse Visual Chat: http://openverse.org [openverse.org]
  • Check out the -M option for gpm, and set X Windows to use /dev/gpmwheel with the MouseSystems protocol.

    I haven't looked into the X source code, but I'd imagine that the only real problem would be with focus. Maybe one pointer keeps the focus, and the other has it only while clicking? Hm.

    Maybe I'll look at the source code of gpm and see if it can be done in the console.

    -lf
  • IBM's Trackpoint researchers have implemented a dual Trackpoint keyboard. See Two-handed Keyboard [ibm.com] for a brief description, rationale, and further links.
  • What applications would support that? In order to get any actions from the second pointer supported, you'd have to change the event hierarchy and structure, and nothing currently supports that.

    What's the point of having two pointers if you can only click on things with one?

  • The Atari ST also has this support. On could use two mice, two joysticks, a mouse and a joystick...

    Perhaps it's because the Atari ST (and Amiga) were systems designed in part for gaming. (?)

  • There is apparently a fair amount of research being done on using two mice for various tasks. The approach I've read about is the idea of a transparent tool - instead of moving the mouse over to a tool selection palette, then back to the work area, over and over again, you move the tool palette over the work area with one mouse, and then click through it with the other mouse.

    The idea, I think, is it's a bit like driving in nails - your off hand does the work that uses less coordination, positioning and holding the nail in place, while your good hand does the accurate work of pounding it in without smashing your thumb.

    Here's a link to what if I'm not mistaken is an influential paper [xerox.com] on the subject, some work done at Xerox PARC.

  • Since this came up in several responses, when I say "two mice" I mean "two pointers," in the spirit of the original question. Everything is able to support two mice driving the same pointer. The issue is having two pointers. All my comments after the first paragraph are with respect to the issue of two pointers.

  • XFree4 (Score:1)

    by cfish ( 61161 )
    I assume that you are talking about one pointer per screen, otherwise I have been using two devices on my graphics workstation (windows, WACOM, trackball) for years.

    XF4 has this utility that lets you configure multiple devices:

    xf86cfg

    and it seems to work with multiple monitors and video card. it has a icon to "add mouse" but it crashed :(
  • One joystick controls your head: changing your view of the world; the other joystick moves you forward, back, left and right (strafing, not turning)

    Almost no serious Quake/GenericFPS players nowadays play any other way --- the mouse is your head, the keyboard is your feet. Once you've learnt to do it, you never go back --- in fact, nowadays I find I physically cannot control the game any other way! Of course like any good rule there are exceptions - the guys who can speedrun Quake levels on keyboard only are too scary for words.

  • This has been bothering me for the last couple of days, I can't seem to get X(4.0.1) to use both my trackpoint(it's a ThinkPad) AND my USB msIntelliEye mouse. It handles it OK when I plug the USB mouse into the PS/2 port using the little converter thingy, but it responds slow so I don't like it; but it's got an "either-or" rule about it when I use my USB mouse, i.e. I can't make both the trackpoint and usbmouse move the pointer on the screen, in which case I have to restart the Xserver switch the mouse-input device.
  • I wouldn't have thought that lemmings were a big problem in "Settlers".
    (Check the chain of comments again.)
  • and the old-skool macs with ADB, the precursor to USB

    actually with the new macs you can have two mice control one pointer with usb - try it yourself, go grab two hockeypuck mice and an imac, plug em in and see
  • I agree. From a UI perspective you'd want the same thing to happen whichever mouse/pointer was used.

    So if you clicked button1 on mouse1 the event would be something like: mouse.button1.buttondown
    And if you clicked button1 on mouse2 it would be: mouse.button1.buttondown

    This way it wouldn't matter if you used the wrong mouse.
  • I've only just realised the potential of that feature, after clocking up hundreds of hours in GE and PD.

    I'm going to have to give it a go when I get home.
  • What applications would support that? In order to get any actions from the second pointer supported, you'd have to change the event hierarchy and structure, and nothing currently supports that.

    Actually, isn't this how scroll mice are supported (by treating the scrolling up/down as button 4/5)? And, as a related question, how much does the functionality of the second pointer depend on being able to actually see it? If the problem is hardware sprites, etc., could you use the second pointer to, i.e., spin your 3d model, without needing to see a little arrow moving around on the screen?

  • ...but it was two simultaneous players with a mouse each playing simultaneously on one computer with one screen split down the middle. Settlers ? Settlers II ? It was running under DOS way back when. Obviously the game implemented everything from interrupts to game logic.
  • Why not ? Most people have two hands. Two mice could be useful for gfx programs or games.
  • My theory is it would be a good way for 2 people to both contribute to a project on a single computer.
    I guess this could work. It's one of those things where it's a nice novelty but no real future.

    - Jasirus
  • A few years back, I wrote a game on the Amiga which implimented exactly this - two mice operating two pointers, both on the same screen.

    The game in question was a two-player variant of Pipeline. If the truth be told, I never actually finished the game properly, but the two-players/two-pointers thing worked brilliantly.

    Unfortunately, the method I used won't translate to another platform; I used a third-party extension to an existing language, which offered the commands to access a second mouse (and various other good stuff).

    My point is that I've proved it can be done, and that it works well when it is done properly.

    I've also seen an art package demonstrated that used a second mouse, with the second mouse being used to move palettes. Interesting concept, though maybe a little hard to get used to.

    I'm not sure, though, how useful it would be on a general desktop. If one pointer does something that occuldes the screen space the other pointer is using (maybe it opens a new window, or something), it could cause problems.

  • Three mice (Score:3)

    by Hermetic ( 85784 ) on Wednesday December 13, 2000 @04:19AM (#563258)
    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 [thinkgeek.com]) 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.

  • Re:er, (Score:1)

    by Tower ( 37395 )
    I like that warcraft (or starcraft, etc) idea, though... dual head display, one system... I suppose you could use the front audio channels for one player and the rear for the other. Hmmm, for more graphic intensive games you'd need dual AGP slots, though, since one card might not be able to handle it so well.
    --
  • A while back I remember some guy next to me was asking the tech at CompUSA if he could plug 2 mice in , and the tech was asking him why he would want to. Turns out he wanted to play warcraft with his son.

    If this was implemeted correctly, and with left and right pointers like in MS Word, you could have a hit. Think of chess games.

  • I seem to remember that Lemmings on the Amiga had a two player option which used 2 mice pointers on the same screen to control the 2 sets of lemmings.

    Did the PC version of this allow the same?

    Of course none of that helps you with X much...

  • This is mentioned in the "20 years after" section of The Mythical Man Month, under user interfaces. There he (Brooks) gives references to research done into doing this. I don't have my copy handy or else I'd post them here.


    --

  • Re:Good idea... but... (Score:1)

    by Anonymous Coward
    I disagree. You would need to do the following to keep things sane:
    For programs which have no need for two mice, have them do nothing and let the window manager keep track. For example, if you have two versions of netscape open, you can have one window be focused by mouse 1 and one window focused by mouse 2. Moving mouse 2 over window 1 would do one of several things (I'm thinking the first would obey the principle of least asstonishment better, but perhaps it could be user configurable):
    a. Mouse 2 turns to a different cursor indicating it doesn't have focus anywhere. Life goes on.
    b. Mouse 2 steals Mouse 1's focus, Mouse 1 changes as above.
    c. Mouse 2 bounces off the window region or else warps through it.

    For programs which want to use two mice simulataneously (games, graphics programs, whatever...), let them register with the window manager.

    This would probably be more work than it's worth, but I don't think the overhead would be significant, and if there are cases where two mice would be useful, the overhead could probably be justified. Besides, that way, Mac users could now mock windows users for only having one mouse.
  • I used it a couple of times with two mice on a pc. It worked pretty well.
    I think it supported two mice by having a driver for serial mice built in, so that it would use the installed driver for one mouse, and the internal driver for the other.

    Over all, I think I would have liked network or modem multiplayer support better than the two mouse method. It was too tempting to peek at that the other player was doing.
    --
  • OK, primary mouse on /dev/aux or whatever is the pointer.
    Is there anything to stop another app reading /dev/ncua1 or whatever? It would have to translate the movements into coordinates, and paste its own sprite? It's a bit clunky but it coulld work

    FP.
    -- Real Men Don't Use Porn. -- Morality In Media Billboards

  • Mutiple Mice (Score:3)

    by lrichardson ( 220639 ) on Wednesday December 13, 2000 @04:51AM (#563266) Homepage
    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.

  • Microsoft has been able to use multiple mice to drive one pointer since Win 3.1. I don't know when they first implemented this, but it was a feature of the MS EasyBall [kidsdomain.com]. It plugged into one serial port and an conventional mouse plugged into the other. When the normal mouse was used, the mouse pointer was like ..er.. well..normal. When the EasyBall was used, the pointer would change shape. This was so a parent and a child could interact with the computer. I doubt very many geeks would use it: it had only one button, and the trackball was yellow and about the size of a softball. Given that the base of white, it looked like a mutant fried egg.

  • You'd break virtually all apps and the WM. (Score:5)

    by MemRaven ( 39601 ) <kirk.kirkwylie@com> on Wednesday December 13, 2000 @06:42AM (#563268)
    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?

  • In Golden Eye for Nintendo 64 you can configure your control setup so that you can play the game with two joysticks. One joystick controls your head: changing your view of the world; the other joystick moves you forward, back, left and right (strafing, not turning). You get much more control when playing this way.

    I always thought it would be useful to do this on a computer, but I doubt that X will support multiple mouse pointers or keyboards anytime soon.

  • What, you're ever at a computer without access to TMMM!? :-)

    Brooks does mention two mice, but has no pointers to further info. In Chapter 19 (pp. 261--262 in my A-W softcover edition), the section ``Command utterances and the two-cursor problem'' discusses how most commands consist of a verb and a noun---action and object---and how convenient it would be to use two cursors to simultaneously select each. The notes for that chapter are prefaced with ``Material quoted without citation is from personal communications.'' The note from that subsection, says in its entirety:

    7. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.
    His thoughts on the human-machine interface are well worth considering, including ways around the need for two mice.

    If you haven't read this book, do so now. If you wonder why, you might check some reviews:

  • you can have one window be focused by mouse 1 and one window focused by mouse 2

    And to which text editor window would keyboard input go? Mouse 1 focus or mouse 2 focus?


    Tetris on drugs, NES music, and GNOME vs. KDE Bingo [pineight.com].
  • This might also be useful for those working in virtual desktop environments often, such as VNC, windows terminal server, PC Anywhere, or even VMware. Some of these (mostly VMware, I think) require a hotkey to move the mouse between the various desktops. It might be useful to have a special pointing device which would be confined to a specific window or application, especially where the app required a special input device (say a 25-button mouse for CAD) which MIGHT not be as useful for the rest of your day. None of this is urgent as we all get our work done now, and as more of these specialty devices go USB and become hot-swappable, it might just be moot.
  • That is indeed interesting, but I've always wanted two pointers in existing graphics apps. Moving the menu under the cursor with the second mouse is intreaguing (sp), but I'd settle for a second pointer to keep over the toolbar while I do "the real work" with the first pointer. It's not (usually) a problem to flick my eyes across the screen to move a second curser a little, but to move the first cursor over to the toolbar and then back where it was takes considerably longer. Also, the article makes some allusion to tear-off menus that can be positioned closer to what you're working on to minimize mouse movement (ok, I admit it, I only skimmed the article), but (a) if you have your mouse on say, a specific pixel, any movement necesitates extra time to reposition, and (b) at least the way I usually do things, tearring off toolbars means they eventually get in in the way and have to be moved around. On top of that there's the problem of something like a CAD application that has lots of toolbars and can get confusing if they're not in their normal place.

    -Golden Eagle

  • Re:Lemmings on the Amiga (Score:1)

    by Anonymous Coward
    The PC version of Settlers had support for two mice in two player mode.

    Never tried to use it though.
  • I'm writing this on my laptop, which has a nipple and a mouse plugged in. Both can move the pointer (I can have mouse fights with myself! - the nipple always wins). Both can click. I have yet to find an app that can tell the difference.
  • You are so right. Many many times I have had this situation: on the phone to someone, they need to show me something. So I PCAnywhere to them. Now my mouse is their mouse --- which means we have to adopt a CB radio style way of using it ("I need to drive --- look at this --- hang on, let me back in --- no no no you gotta see this --- jesus, you lost all that stuff I was doing --- right, you know how to do x and I know how to do y, but there's no multithreaded way for us to do this 'cos there's only one mouse; I'll go first"). Two (N) mice (local mice plus remote mice) is the obvious solution. How on earth didn't I see this? I could use it almost every day!
  • I wasn't aware of any newer editions.

    I have a 1982 reprint of the (original?) 1975 edition, with lots of descriptions of his experiences with the IBM OS/360 project.

    I'm guessing the later editions were radically revised/had extra chapters with more up-to-date experience of software engineering.

    Still, i've managed to ref. lots of pertinent chapters in recent essays.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close