Matt_H wrote:
I've actually got a USB mouse, and it's a lot better than my PS2 mouse. But I'd rather only have one device plugged into the machine, to be used under OS4, Linux, or MacOS.
Now, without doing *any* research, I'm going to guess it's a problem of multiplexing the mouse, and if so, configuring your system to use gpm and letting it create the GNU equivalent of BSD moused's /dev/sysmouse miiight solve it? (Rather than letting the X server access the /dev node for the port directly, which probably locks out MOL from opening it and doing what it needs to do?)
Still don't know enough about Linux to have any idea what that means :-)
In short form, "mouse daemons" talk to the mouse over whatever protocol it uses, and provide a 'pure' abstraction over One True Mouse Protocol on a magical mystery device node (e.g. /dev/sysmouse in the case of moused, or /dev/mouse with gpm)... basically acting as a mouse driver for the system, so every application doesn't have to support every mouse protocol on the planet, and nobody has to worry about what might happen if multiple apps open the 'real' mouse port for reading at once. They also have the nice side effect of offering mouse support on text consoles, being another layer where you can tackle/screw-up scroll wheel support, etc.
In theory, a misbehaved program could do something like change the serial rate on the mouse port and screw it up for everything else. So whether or not the device actually gets locked when two *normal* programs try to open it, trying to, say, 'cat' the 'real' mouse device with moused running will produce the following (this is FreeBSD, so psm0 = psaux):
$ cat /dev/psm0
cat: /dev/psm0: Device busy...nothing can screw up the state of the physical port except for the daemon itself, the idea being that once it's configured properly, nothing can come along to 'harm' it.
Meanwhile, if I su to a user with appropriate permissions and try the 'virtualized' mouse device:
# cat /dev/sysmouse
þÿþÿþþÿÿþþþÿÿÿÿÿÿÿÿÿÿÿÿÿþÿÿÿÿÿÿÿþÿÿÿÿþÿÿþÿÿÿÿÿÿÿÿÿ[...]...I get a screen of comforting gobbledygook when I slide the mouse around, even with X running and accessing the same device. (Okay, to be honest about it -- and so you don't get confused when testing -- for some d*mn reason my X cursor does freeze while this is in progress, though it works fine at the console. Just remember that, technically, it's even less deterministic trying to have two programs read the same 'real' port at the same time. Or at least, it may have been at some point in the dark ages. Eat your peas, there are children starving in Africa.*)
The 'recommended' settings in the comments section of the config file don't work at all, and plugging in /dev/psaux (my mouse port) produces an effect similar to trying to use a mouse to control a joystick-based Amiga game from the 2D era - movements are erratic, pointer doesn't follow mouse movements, tends to hug one corner of the screen, buttons automatically press themselves at random, etc. So it almost works, but not quite...
In that case, it sounds like the port is being opened properly (whether or not X is trying to share it at the same time), but MOL expects one particular protocol (Microsoft or Mouse Systems?), while it's getting another one (Logitech, perhaps, or the 'wrong' one of those commonly-accepted two)...
In that case, you can either 'massage' the data with gpm, or just tell MOL what kind of mouse you have, if it lets you and has appropriate support for it.
Unfortunately, unlike BSD moused, in turns out gpm doesn't believe in One True Protocol, so you'll have to find out what MOL actually wants and isn't getting.
See this Debian guide for some configuration examples, and notice how gpm is being used to 'relay' and translate whatever the hardware actually uses to 'standard' Intellimouse on /dev/mouse in example 3.3.1.1, passing it through 'raw' in 3.3.1.2, and doing the same 'raw' thing in 3.3.1.3.
...So what you *want* to do is configure gpm to translate to whatever the appropriate MOL-friendly protocol turns out to be,** do whatever Linux mojo you need to do to make sure it runs at boot time (don't look at me, all I had to do was add moused_enable="YES" in /etc/rc.conf... and people say BSD rc scripts are hard?), change your X server configuration to expect that protocol on /dev/mouse, change MOL to also look at /dev/mouse, and then everything will probably work. Except your scroll wheel, at which point you can come to my house and murder me in my sleep.
Er, and don't forget to ln -s /dev/gpmdata /dev/mouse if you need to... and if /dev/gpmdata doesn't exist or get created when you run gpm, give me an extra stab.
(Hint: When you edit your XF86Config or xorg.conf CorePointer section, *comment out* what you've got working at present, don't just delete it. Then, if switching everything to /dev/mouse makes MOL work but your wheel stops being useful in X, see if Linux will let you get away with using psaux for X at the same time. If that fails, jab me with a sharp object, and I'll try to figure out how to get the wheel working through gpm.)
---
*I find reference to this mostly having been a problem with "bus" mice, if you remember those seemingly-but-not-really PS/2-like things. So if you later switch back to /dev/psaux with X, and everything actually continues to work, it's okay to the extent that nothing should *actually* screw with things like PS/2 port speed in operation. I'm telling you to switch X to use the gpm device because it makes things muuuch more 'sane' for testing... and because, as you'll see me suddenly ponder below, it *could* be that you're seeing the effects of sharing access to the 'real' port, rather than a protocol snafu!
**As far as I can tell, the use of "ps2" on
http://www.maconlinux.org/userguide/mouse.html maps to straight "ps2" from gpm. You could try your luck with imps2 (more likely to be wheel-friendly with X), but when in doubt, give it exactly what it wants first.
---
*NIX gives you 'a lot of flexibility' in setting up the mouse, so this isn't the only way to do it. (For instance, I come across one guy who used gpm to translate to the 'bm' protocol, and told X and MOL to use that. He was also complaining about it not working, so maybe that's not such a good idea. You could also try just enabling gpm with a repeat_type=raw and seeing if it *is* a concurrency issue accessing /dev/psaux -- maybe half the bytes end up going to X and half to MOL, heck if I know -- but I can't guarantee that alone would work, so I'm telling you to pick repeat_type=ps2 at first try... and to let it autodetect what the hardware *actually* is with type=autops2.)
