evdev/xorg help? USB mouse/kbd: 2.6.24="just works">2.6.25="unplug/replug to work".
"Find Similar Threads" found 2 nice threads 4-5 years old with 4 replies between them, and no conclusion.
This is Xorg 6.9 (Slackware 11 default) and current kernel is 188.8.131.52.
The USB mouse/kbd thingy is a PS2 Wireless job made by GE, with its base-station connected to USB thru a PS2->USB adapter.
My motherboards USB controller identifies at startup as a 8-port HUB as you will see below in /log/messages.
NOTE that regardless which kbd/mouse set I have connected to the adapter (the wireless OR my usual one), this thread applies equally.
Previously, on 184.108.40.206, the USB mouse and keyboard just worked, all the time, in VT console (kbd only because of GPM) or on the desktop. I had not configured either of them in xorg.conf, I just connected them and away I went. Right from boot/login, they just worked.
Now, I have lately spent significant time trying to configure the silly things (wireless USB mouse & kbd) in xorg.conf because they are no longer working since 2.6.25.x, and one day I decide what the heck, unplug them and plug them back in.. And voila, stupid things work as they used to, still with no xorg.configuration of them.
1st question: WHY is this?
Now, AFAIK, my kernel build has the same USB config options going on, as I don't generally change anything there when rebuilding.
On to part 2:
Let's say I want to configure the mouse & kbd explicitly in xorg.conf. How to go about it?
For the most part, I have discovered that whatever I put into xorg.conf in reference to this mouse & kbd either does nothing at all, OR it hangs X &/or the desktop &/or the machine. None of the usual friendly ways of killing the hang (or X) works, but I can usually get out by hitting the power button (which IS set up via acpid to shut off the machine, and it works cleanly to shut down-- unlike the da*ned reset button).
This hang/lockup happens primarily if I try to use the "evdev" driver on what I believe is the second mouse device (/dev/input/something), combined with the "AlwaysCore" option.
Without this magic combination of options that hangs the machine, there is simply no change in either detection or function of the mouse/kbd, except that when it doesn't work (which is usually), I see in the xorg.0.log that the second mouse was detected/identified as a keyboard. Grr..
For help, I have mostly consulted what is often a very helpful www place for stuff like this: The Gentoo Wiki's Advanced Mouse Configuration. Unfortunately, the description there of how to go about what I want to do is not really intuitive, particularly when it came to the EVDEV configuration.
The reason I want to use EVDEV is, AFAIK, it would allow for seamlessly operating the USB mouse (and kbd I guess) in cases when it happens to be/get connected to a different port some day, without me having to go through this rubbish of figuring out where the heck it is in /dev.
THEIR FIRST EXAMPLE showed how to use EVDEV the "old" way, by telling the X server to use Driver "evdev" and Device "/dev/<you-need-the-right-device-here>" which is not working for me for two reasons:
1) experimenting with evdev is hanging my machine leaving me nowhere;
2) I am not sure what the correct /dev node IS for this mouse and kbd (yes, the mouse and keyboard appear as ONE device with two pieces, AFAICT, yet they seem to work properly when they do work.)
2nd question: Incidentally, what is the /dev node for the FIRST keyboard on the PS2 port? Anyone know? Is there one?
THEIR SECOND EXAMPLE told me how to use evdev the "way evdev was indended to be used" which I suppose is supposed to be dynamic?? As before in their FIRST EXAMPLE above, they used Driver "evdev" but then went on to include a bunch of cryptic Options with no explanation, and stated that it would work.
I did not try the 'cryptic options method', because whether they work or not, I would like to know what they mean, where they got them, and WHY they work. Surely the cryptic options are not the exact same on everyones machine??
OK, I think that's enough questioning for now.. Here's some reference material:
First, some stuff from /proc when the USB devices are connected (this stuff is identical whether the USB stuff is connected but NOT working, or if I have unplugged it and reconnected it):
If anyone wants more info, of if there's something I missed or should try, please feel free!
OK, by following the instructions at the Gentoo Static Mouse config page, as well as at Writing UDEV Rules page here I have managed to get udev to latch onto the mouse by some unique identifier, as shown in the rules file included below.
I used UDEVTEST and UDEVMONITOR to identify the mouse when it got plugged in, and after about 10 tries, got the rule worked out.
SO.. I now have my symlink for the mouse at /dev/input/usbwirelessmouse and when I use that in my DEVICE line in xorg.conf, X starts, and the mouse is actually (FINALLY) identified as a mouse in the xorg.0.log file.
CORRECTION: The mouse is not identified at all.
HOWEVER!! Though the USB keyboard still works (without an explicit config in xorg.conf) the mouse itself seems to be going a million pixels-per-hour!! The cursor flies all over the place so fast that it cannot be seen, and there are menus and files and stuff opening and closing all over the place :p !! But X didn't crash, I was able to use the PS2 mouse to right-click and logout.
NOTE: Testing is pretty quick and convenient when it doesn't crash, as I am using a second X session for testing, on VT6.
Look at this from the xorg log file:
Also, in xorg.conf, I am using Driver="mouse" but should I maybe try another driver?
UDEV RULES file I made:
UPDATE: getting rid of the Option "mouse1" "AlwaysCore" has eliminated the rapid zooming of the pointer all over the place, and the mouse works, however the log xorg.0.log still shows that bunch of AUDIT..Relected lines, and there is still no mention in the log of anything for "mouse1" configured..
It should be noted at this point that I have NOT YET tried booting the machine with the mouse/kbd connected, to see if it works off the bat. I would prefer to see in xorg.log that the devices (s) have been configured properly first..
Well, I know I had similar problems in SW 11.0, and I never really found a clean way around the problem, heck I'm not all too sure exactly what the problem was. I ended up implementing some sort of hack or workaround much like you did. I made a script that handled all of this nonsense in a quasi-intelligent manner. I seem to have misplaced it tho :)
mouse/keyboard fails at startx
This works for me (xorg-7.7; Xorg-server-1.12.4; Linux-3.3.7; udev-182).
Line in my .xinitrc script:
sudo /sbin/udevadm trigger --action=add &
This comes before the window manager (FVWM in my case) is called.
In /etc/sudoers provision is made for udevadm to be accessible to "sudo-ing".
Apparently the X-Server loses whatever udev did at boot.
|All times are GMT -5. The time now is 08:32 AM.|