When configuring the X.org server, the preferred way to access all the buttons on a USB mouse is to use the evdev
driver on a /dev/input/event*
device. The preferred way to be able to unplug and replug mouses is to use the mouse
driver on the /dev/input/mice
device. Linux helpfully multiplexes all mouse communication into that one device for you, but it's not an event device. If you don't use this, the specific mouse or event device you were using will "disappear" when it's unplugged.
Switching computers on a USB KVM switch is equivalent to a USB unplug/replug. So you can see why I've had this black spot in my heart for X for quite some time now. Gentoo recently forced me to update to X11R7 (the modular version), and it still wasn't fixed.1
So I went off on a stupid day-long goose chase to hack in a fix myself.
Now, when a read() fails with ENODEV inside the evdev driver's read function, that evdev read function will poll the device every second until it comes back. Then it reopens it, and like magic everything works again.
Unfortunately, it didn't quite work out that way. X won't call evdev's read unless it has a valid file descriptor and it just sent an IO signal. At this point, I almost gave up on this path, thinking instead of a new event device that acts as a proxy for other event devices, but instead I just started hacking on the X server instead. So now it sets the fd to -42 after an unplug, and the next time the X server gets around to calling the read functions, it will call anything with an fd of -42 unconditionally. It's still not polling in the background, because it has to wait until some input comes in from something that *is* plugged in.
The solution to that is just to press a key on the keyboard. I can live with that.
This makes two beautiful log lines and one suspicious one:(II) Logitech MX1000: Unplugged; waiting for replug.
(II) Logitech MX1000: Device replugged.
(WW) Logitech MX1000: Release failed (Invalid argument)
I have terrible visions of an input device table slowly filling up with invalid mouse entries. But right now, tonight, I don't care so much. I'll see what happens as I use it for several days. Anyway, this is the first time in all my years of using KVM switches that I can switch between two machines without any ill effects on the mouse requiring a VT switch.
I put the patches
You probably shouldn't use this yet. It turns out that if X receives input from somewhere else while the mouse is unplugged, it freezes up until it gets plugged back in.
1. It may be fixed in the very latest version. At least, the evdev driver is much larger. I haven't read the whole thing. But it's not stable in Gentoo yet, so I don't want any part of it.