I have a logitech combo USB wireless mouse and keyboard. With version xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386 xorg-x11-server-common-1.4.99.905-2.20080702.fc9.i386 They both function correctly. When I move to version xorg-x11-server-Xorg-1.4.99.906-1.fc9.i386 xorg-x11-server-common-1.4.99.906-1.fc9.i386 My USB wireless mouse stops functioning. The track pad mouse continues to work just fine. Reverting to the above listen versions caused the mouse to start working again. I will be attaching logs from both versions shortly.
Created attachment 312802 [details] log from xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386
Created attachment 312804 [details] log from xorg-x11-server-Xorg-1.4.99.906-1.fc9.i386 *BROKEN*
You have also switched (probably, unknowingly) from xorg-x11-drv-mouse to xorg-x11-drv-evdev.
Of course, try to run Xorg without any /etc/X11/xorg.conf whatsoever. What happens?
Created attachment 312825 [details] log from xorg-x11-server-Xorg-1.4.99.906-1.fc9.i386 *BROKEN* with no xorg.conf The updated xorg-x11-server-Xorg and xorg-x11-server-common with no config file resulted in a system with no keyboard (both the built in and USB wireless keyboard failed) and the USB mouse did not work. The touchpad mouse built into the laptop still worked. So, that made it MUCH worse.
Created attachment 312826 [details] log from xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386 with no xorg.conf
Eric: what you are seeing is a combination of multiple issues. First: The X server hotplugs input devices now, and it doesn't rely on devices specified in the xorg.conf. Instead it obtains them via HAL. This means that it doesn't force default input sections anymore if you don't have them specified in the xorg.conf. Previous versions would auto-add a pointer + keyboard section if none were specified. This was a fairly recent change (that's why a downgrade works for you). However, the evdev driver for keyboards caused a number of issues, and fedora has a patch to ignore keyboards provided by HAL. You're using a logitech wireless combo and we found that some of them (if not all) advertise the mouse as a mouse _and_ a keyboard (a quick check of hal-device shows you the info.capabilities). Because it looks like a keyboard, it's ignored when hotplugging - hence you don't get your mouse to work. The simplest solution is to add Option "AllowEmptyInput" "off" to your ServerLayout. This forces the server to auto-add a mouse/keyboard section. The correct solution is to add an InputDevice section for your mouse and your keyboard, and reference them from your ServerLayout. The even better solution is for us to get rid of the fedora anti-keyboard patch, but we're not quite there - yet.
Created attachment 312834 [details] hal-devices output Just want to make sure we are on the right track. My line which I believe is the wireless mouse shows: info.capabilities = { 'input', 'input.keys', 'input.mouse', 'button' } (string list) and the keyboard shows: info.capabilities = { 'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button' } (string list) I also have this in my xorg.conf: Section "InputDevice" # keyboard added by rhpxl Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection So I guess that explains why my built in keyboard continued to work in the new xorg-x11-server-Xorg. /me has no idea what the right magic sauce is get the new stuff working, but I guess I'll try to google myself and answer tomorrow. All of this is black magic to me :)
yeah, you can see the mouse announces having keys. The (fedora) server classifies this as keyboard and ignores it when hotplugging. The Keyboard0 needs to be referenced from your ServerLayout. For the usb mouse to work, add Section "InputDevice" Identifier "mymouse" Driver "evdev" Option "Device" "/dev/input/by-id/<device name>-event-mouse" EndSection Or just add a section with Driver mouse and device /dev/input/mice.
So I decided to cheat and just add Section "InputDevice" Identifier "Mouse0" Driver "mouse" EndSection Which as you indicated gets me working with what's in updates-testing. If its useful to you for me to add the more complete evdev entry (I assume I need one for the touchpad and one for the USB mouse even though the USB mouse disappears regularly?) I will. I assume we should leave this bug open until things "just work" as I'm guessing I'm not the only person in the world with a logitech mouse that would stop working if we pushed xorg-x11-server-Xorg to updates? Thanks for the help!
(In reply to comment #10) > (I assume I need one for the touchpad and one for the USB mouse even though the USB mouse disappears> regularly?) You wouldn't have to add a section for the touchpad, the log indicates it's working just fine. FWIW, rawhide xserver 906-5 should work fine now. The patch to ignore keyboards has been removed.
FWIW, my microsoft wireless combo keyboard/mouse stopped working some time around the same time. I haven't been able to track it down to the same specific change, though. So probably more widespread than just logitechs. (Am testing more now to see if it really is the same problem.)
Yeah, same downgrade fixed it. If someone needs me to debug more, let me know, otherwise I'll just be relying on the downgrade for now.
Luis: I have one of them too, hal-device says that they have keys, hence they are affected by the same issue. info.product = 'Microsft Microsoft Wireless Desktop Receiver 3.1A' (string) info.capabilities = { 'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button' } (string list)
xorg-x11-server-Xorg-1.5.0-1.fc9 should fix this bug. Can you please verify this? https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8032
installed everything in updates-testing including xorg-x11-server-Xorg-1.5.0-1.fc9.i386 removed all InputDevice sections from /etc/X11/xorg.conf and rebooted the computer Neither the logitech wireless keyboard or the keyboard built into the laptop worked. The logitech wireless mouse was also non-functional. The built in trackpad mount on the laptop did work. Seems nothing was better...
Eric, can you give me an updated logfile please?
After updating xorg-x11-server-\* yesterday, the mouse from my keyboard mouse wireless combo ceased to work. I could fix it adding Option "AllowEmptyInput" "off" to ServerLayout in xorg.conf And what I'm wondering is why has this been pushed to updates if it breaks existing working configurations?
Sergio: The fix for that issue is in 1.5.0-2, a simple 1 line patch that reverts a default that has changed upstream since. https://admin.fedoraproject.org/updates/xorg-x11-server-1.5.0-2.fc9 But I'm afraid I have bad news: F9 will (until further notice) keep the patch that disables evdev keyboards through HAL. This patch affects some mice as mentioned in Comment #7. Comment #9 details a workaround.
*** Bug 462815 has been marked as a duplicate of this bug. ***
I also had the same problem with my Logitech wireless combo when I got the update to 1.5.0-1.fc9 very recently. This a *VERY* bad user experience... I'm computer literate enough to fix the problem, but I know many end users aren't. Switching to have Xorg detect input devices differently in the middle of the Fedora 9 cycle doesn't seem like a wise choice either. Especially pushing the change to the stable updates when this bug report already contains evidence of unfixed failures. I can also confirm that 1.5.0-2.fc9 fixes the problem for me.
1.5.0-2.fc9 fixes my issue with the mouse not working through an Avocent KVM switch.
Eric? Does 1.5.0-2.fc9 works for you?
1.5.0-2 and I am now a proud X user with absolutely no xorg.conf what-so-ever. Lets push 1.5.0-2 very quickly.......
*** Bug 462849 has been marked as a duplicate of this bug. ***
<i>Lets push 1.5.0-2 very quickly.......</i> +1 here. Fixes my problem.
*** Bug 463098 has been marked as a duplicate of this bug. ***
*** Bug 462888 has been marked as a duplicate of this bug. ***
*** Bug 463391 has been marked as a duplicate of this bug. ***
I'm closing this bug as RAWHIDE. As explained in comment #7, mice that expose keys are interpreted as keyboards by the X server and a patch we have in F9's server disables them. This can only be fixed by removing the no-keyboard patch, which has been done for F10. However, you can get around this problem using a workaround described in comment #9.