Input hotplugging and usb mouse

Posted on Sun 25 October 2009 in Technology • 2 min read

After loosing few matches on FICS on time control, poor me realized that it’s the mouse which matters when you’ve 10-20 seconds to mate. So I got myself an usb mouse and we’ve some new adventure.

Ok, plugged in the usb mouse, checked that lsusb recognizes it. A dmesg suggested only a generic “low speed” usb device plug in. I did a X -configure but it didn’t show up my usb mouse :( Few web pages suggested some cool ways to check if your mouse is recognized:

- Do a cat /proc/bus/input/devices and look for your mouse. Get mouse model from lsusb - If there are multiple mice showing up in /dev/input/* then do a cat /dev/input/mice and try moving your mouse, if it’s recognized you’d see random output on screen

None of these worked for me. I gave up on XOrg.conf. Let’s try upgrading to Xorg input hotplugging and see if HAL does some magic. So added hal and dbus to rc.conf, pacman’ed xf86-input-evdev. Hotplugging totally disregards can replace/compliemt your xorg.conf, all inputs are added at runtime, real hotness! Well still my mouse was not working.

After pulling out hair after hair, finally I figured out the whole story (yep! I still have a few hairs left:)). Although kernel was recognizing my usb device, it couldn’t know that it was a mouse. Hence there was no device file created for the mouse in /dev/input. The missing link was usbhid (USB Human Interaction Device) module. A quick modprobe usbhid and we’re golden. The clever /me had disabled MOD_AUTOLOAD in rc.conf, and I had listed every module loaded by my system (optimization!).

Anyways hotplugging is super awesome. I enabled scroll on my touchpad this time, configuration is real easy and human readable. E.g. to disable the caps lock key, just add the following option to /etc/hal/fdi/policy/10-keymap.fdi: <merge key="input.xkb.options" type="string">ctrl:nocaps</merge>. Thanks to the arch wiki.

Update:.xmodmap causes problems with multimedia keys. Evdev is intelligent enough to guess the right names for all key codes, so commenting .xmodmap worked for me. Most of issues are caused because X detects two keyboards (thanks HAL), /var/log/XOrg.0.log is your friend. My current setup doesn’t use a xorg.conf, everything is detected by HAL, and things work OOB.

Good day!