Kevin Vance - When configuring the X.org server, the preferred way to access all…

Entries | Archive | Friends | Friends' Friends | User Info

11:39 pm

Tuesday, July 11th, 2006
Previous Entry Share Next Entry
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 on kvance.com.

Edit: 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.
Link )Reply )

Comments
[User Picture]From: rspeed
2006-07-12 02:41 pm (UTC)
I've never used a KVM on Linux box. In fact, I rarely have them running anything but headless.

At work we have three machines set up to perform backups. Two are PowerMac G4s and the third is an Intel Mac mini. There's a KVM set up and it works quite nicely at saving desk space. I found it quite amusing that when the mini is booted into Windows, however, every time you switch to a different machine the USB port dies and disappears from the device manager until the machine is rebooted.

So, look on the bright side... at least you don't have to deal with Windows.
(Reply) (Thread)
[User Picture]From: kvance
2006-07-12 04:21 pm (UTC)
I guess it depends on the hardware. In my experience (the other machine on this KVM runs WinXP), Windows handles peripheral unplug/replugs with dignity and grace. Before my screen has adjusted to the new video mode, the mouse is ready to go.
(Reply) (Parent) (Thread)