Red Hat Bugzilla – Bug 60977
USB mouse not detected by X if not present at boot
Last modified: 2014-01-21 17:48:02 EST
Description of Problem: If you have configured USB mouse support via /dev/input/mice in your Xserver but boot the computer (a laptop) w/o the mouse plugged in at boot time, the Xserver will not pick up on it if you choose to use it later on. This is due to the Xserver not being able to see the input device because the hid and mousedev modules are not autoloaded at boot w/o the mouse being there. Note: this is using a stock redhat built kernel (2.4.9-31 at the moment). Version-Release number of selected component (if applicable): How Reproducible: Always. Steps to Reproduce: 1. configure usb mouse for X11 2. boot computer w/o mouse in 3. insert mouse once in runlevel 5 Actual Results: Xserver doesn't respond to mouse. Expected Results: USB is a hot pluggable device .. it should be detected, attached and work. Additional Information: I was able to fix this in two ways .. one was a bit more than the other. The hackish fix was to add /sbin/modprobe hid /sbin/modprobe mousedev to /etc/X11/prefdm to have the modules loaded immediately before the Xserver started. A better fix (I think) was to fix it by adding post-install usb-uhci /sbin/modprobe hid post-install usb-uhci /sbin/modprobe mousedev options -k hid mousedev to my modules.conf .. due to the way /etc/rc.sysinit initializes the usb support, I was unable to use the more generic reference to usb-controller in the post-install stanzas (it loads the specific module name rather than the alias which is there .. any reason?). I guess that kudzu needs to do this automagically or should /etc/rc.sysinit just load the mouse/keyboard support automagically if requested perhaps via a mechanism like /etc/sysconfig/usbdevs .. MOUSE=yes, KEYBOARD=no ..
I filed it under kudzu, but maybe initscripts might have been more appropo.
As a follow up to this, I have not been able to get the modules.conf setup to work reliably. Alas, only the hackish way of doing the mod- probles in /etc/X11/prefdm has worked consistently for me. Is this working due to a race condition?
Probably the best way to handle this is to have hotplug kick the X server so that it reopens the mouse device.
But could you do that in such a way as to not kill a current xsession? That is really what prompted this.. I hate to have to do a ctrl+alt+bksp just use my hotpluggable mouse. The prefdm hack works (I cannot explain why, per se). The other thing that would be nice would be a userland mouse abstraction daemon (a la .. dare I say it .. FreeBSD's moused, which back in my bsd days would allow me to share focus between usb mouse and on board mouse). I was never able to get gpm under linux to do what moused could do under FreeBSD.
Not an issue for hotplug. You could have a X configuration with multiple devices in it, both active, if you want to and anaconda wants - it shouldn't break anything.
Deferring to a future release. The real "right" answer is to use the new input layer stuff from 2.5 (lets you use ps2 and usb both from a combined input mutex similar to how usb mice work already)
I think we've come up with a solution that will make this case work.
cool. i am curious to hear what you came up with.
Time tracking values updated