I've got AllowMouseOpeFail option set to true in my xorg.conf, but when the mouse is absent, server hangs. Relevant x.org conf sections: Section "ServerLayout" Identifier "X.org" Screen 0 "screen" 0 0 InputDevice "usbmouse" "CorePointer" InputDevice "touchpad" "AlwaysCore" InputDevice "trackpoint" "AlwaysCore" InputDevice "keyboard" "CoreKeyboard" Option "AllowMouseOpenFail" "true" EndSection Section "InputDevice" Identifier "usbmouse" Driver "evdev" Option "Device" "/dev/input/event_usb" Option "Buttons" "9" Option "SampleRate" "500" Option "Resolution" "800" EndSection /dev/input/event_usb is a udev-created link to the mouse's event interface. When the usb mouse is not plugged in, the server hangs, console contains: (II) RADEON(0): no multimedia table present, disabling Rage Theatre. *** glibc detected *** X: double free or corruption (fasttop): 0x082ae7c0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7ceb4af] /lib/libc.so.6(__libc_free+0x8b)[0xb7cebfdb] X(Xfree+0x21)[0x81cfe01] X(xf86DeleteInput+0x72)[0x80cac42] X(InitInput+0x23a)[0x80a539a] X(main+0x379)[0x806fe19] /lib/libc.so.6(__libc_start_main+0xe3)[0xb7c9d893] X(FontFileCompleteXLFD+0x89)[0x806f4c1] ======= Memory map: ======== 000a0000-000c0000 rwxs 000a0000 00:0b 882 /dev/mem 000f0000-00100000 r-xs 000f0000 00:0b 882 /dev/mem 08048000-081f2000 r-xp 00000000 03:02 3843091 /usr/bin/Xorg 081f2000-08200000 rw-p 001aa000 03:02 3843091 /usr/bin/Xorg 08200000-082bf000 rw-p 08200000 00:00 0 [heap] b4b00000-b4b21000 rw-p b4b00000 00:00 0 b4b21000-b4c00000 ---p b4b21000 00:00 0 b4ce3000-b4ee3000 rw-s d0102000 00:0b 1916 /dev/dri/card0 b4ee3000-b4ee4000 r-xp 00000000 03:02 3045802 /usr/lib/xorg/modules/multimedia/theatre_detect_drv.so b4ee4000-b4ee5000 rw-p 00000000 03:02 3045802 /usr/lib/xorg/modules/multimedia/theatre_detect_drv.so b4ee5000-b53c5000 rw-s d0302000 00:0b 1916 /dev/dri/card0 b53c5000-b55c5000 rw-s d0102000 00:0b 1916 /dev/dri/card0 b55c5000-b55c6000 rw-s d0101000 00:0b 1916 /dev/dri/card0 b55c6000-b56c7000 rw-s d0000000 00:0b 1916 /dev/dri/card0 b56c7000-b76c7000 rw-s e0000000 00:0b 882 /dev/mem b76c7000-b76cd000 r-xp 00000000 03:02 3843066 /usr/lib/xorg/modules/libshadowfb.so b76cd000-b76ce000 rw-p 00005000 03:02 3843066 /usr/lib/xorg/modules/libshadowfb.so b76ce000-b771a000 r-xp 00000000 03:02 3843062 /usr/lib/xorg/modules/libxaa.so b771a000-b771c000 rw-p 0004b000 03:02 3843062 /usr/lib/xorg/modules/libxaa.so b771c000-b7723000 r-xp 00000000 03:02 3843131 /usr/lib/xorg/modules/libramdac.so b7723000-b7724000 rw-p 00006000 03:02 3843131 /usr/lib/xorg/modules/libramdac.so b7724000-b775e000 r-xp 00000000 03:02 3843080 /usr/lib/xorg/modules/libfb.so b775e000-b775f000 rw-p 00039000 03:02 3843080 /usr/lib/xorg/modules/libfb.so b775f000-b7762000 r-xp 00000000 03:02 3842997 /usr/lib/xorg/modules/libi2c.so b7762000-b7763000 rw-p 00002000 03:02 3842997 /usr/lib/xorg/modules/libi2c.so b7763000-b7769000 r-xp 00000000 03:02 3843121 /usr/lib/xorg/modules/libddc.so b7769000-b776a000 rw-p 00005000 03:02 3843121 /usr/lib/xorg/modules/libddc.so b780a000-b7810000 r-xp 00000000 03:02 3843087 /usr/lib/xorg/modules/libint10.so b7810000-b7811000 rw-p 00006000 03:02 3843087 /usr/lib/xorg/modules/libint10.so b7811000-b7816000 r-xp 00000000 03:02 3843069 /usr/lib/xorg/modules/libvgahw.so b7816000-b7817000 rw-p 00005000 03:02 3843069 /usr/lib/xorg/modules/libvgahw.so ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]]-2.4.somodules/fonts/libbitmap.sord.so.so.1
Which version of the evdev driver are you using. Try upgrading to the latest one (1.1.2)
Isn't it masked? I'm using 1.0.0.5. Should I really try 1.1.2? It requires masked xorg-server, too
You should be able to compile evdev 1.1.2 against xserver 7.0.
Created attachment 5648 [details] mouse doesn't work now Xorg.0.log
Upgraded to 1.1.2. Had to also upgrade mesa to 6.5, xorg-server to 1.0.99.903, xf86-input-keyboard to 1.1.0, xf86-video-ati to 6.6.0, xf86-input-mouse to 1.1.0 to satisfy gentoo dependencies. The AllowMouseOpenFail problem disappearead (i.e., I'm posting this bug in X started with mouse disconnected (using notebook's trackpoint only)). However, with the 1.1.2 driver, I'm unable to make it work with the mouse :(. I get: (EE) PreInit returned NULL for "usbmouse" No core pointer Fatal server error: failed to initialize core devices Tried both my previous config and the default config from evdev driver manual (with Option "Name" set to what i found in /proc/bus/input/devices). Config sections (commented - old stuff): #Section "InputDevice" # Identifier "usbmouse" # Driver "evdev" # Option "Device" "/dev/input/event_usb" # Option "Buttons" "9" # Option "SampleRate" "500" # Option "Resolution" "800" #EndSection Section "InputDevice" Identifier "usbmouse" Driver "evdev" Option "Name" "Microsoft Microsoft Wireless Optical Mouse 1.0A" Option "evBits" "+1-2" Option "keyBits" "~272-287" Option "relBits" "~0-2 ~6 ~8" Option "Pass" "3" EndSection #Section "InputDevice" # Identifier "usbmouse" # Driver "evdev" # Option "Device" "/dev/input/event_usb" # Option "Buttons" "9" # Option "SampleRate" "500" # Option "Resolution" "800" #EndSection Section "InputDevice" Identifier "usbmouse" Driver "evdev" Option "Name" "Microsoft Microsoft Wireless Optical Mouse 1.0A" Option "evBits" "+1-2" Option "keyBits" "~272-287" Option "relBits" "~0-2 ~6 ~8" Option "Pass" "3" EndSection Attached failing Xorg.0.log. I have to say that evdev driver manual's section on "Bits" is incomprehensible and I'd say incomplete, I totally didn't understand how i should set them to anything other than default values (and if i need to, also).
Any difference if you try without your custommade udev rule and bind it directly to the event device?
Could you give me a complete inputdevice config section to test with?
As this is now dealing with evdev bugs I'm moving it over to being an evdev bug. That said, at this point it's more a bug of documentation and the user setup, specificly that having a custom udev rule that keep a /dev/input/event<n> entry from appearing breaks xf86-input-evdev. Sadly, there is pretty much nothing at all that we can do in that case aside from telling the user not to do it.
Understood. So, you're telling me that if I remove my custom udev rule and don't specify a Device option, but rather specify a Name option, it should work? What various "Bits" options should I set? My mouse has got a tilt-wheel (scrolls in 2 directions) and 2 side buttons, is it somehow connected to these bits?
(In reply to comment #9) > Understood. So, you're telling me that if I remove my custom udev rule and don't > specify a Device option, but rather specify a Name option, it should work? What > various "Bits" options should I set? My mouse has got a tilt-wheel (scrolls in 2 > directions) and 2 side buttons, is it somehow connected to these bits? Just use the settings from the manpage, those will catch any mouse that we know how to deal with. I agree that the documentation on the bits is not exactly the best, but I have no idea how to properly explain how they work without a few more paragraphs and including several hundred lines from a linux kernel header file. But yes, if you remove your udev rule and use the settings from the manpage, or have no bits settings and just use the Name or Phys options, everything should work fine. Though, I would appreciate a confirmation that it works with no more problems. Thank you. Zephaniah E. Hull.
Once again, upgraded to necessary versions, removed /dev/input/event_* (only event? are left). The driver couldn't find the mouse by it's name from /proc/bus/input/devices. This config didn't work: Section "InputDevice" Identifier "usbmouse" Driver "evdev" Option "Name" "Microsoft Microsoft Wireless Optical Mouse 1.0A" Option "evBits" "+1-2" Option "keyBits" "~272-287" Option "relBits" "~0-2 ~6 ~8" Option "Pass" "3" EndSection Changing Name to Phys made it work: Option "Phys" "usb-0000:00:1d.1-2/input0" Phys is not convenient, because I frequently reconnect my mouse, so... Changing Phys to vendor & product worked, too: Option "vendor" "045e" Option "product" "008c" Name not working is probably a bug, though. Also, there's one not working thing since the previous (1.0.0.5) driver - my tiltwheel now works backwards for horizontal scrolling (i.e., tilting left produces button 7 event - scrolls to the right, tilting right produces button 6 event - scrolls to the left). It worked correctly in 1.0.0.5
Oh, by the way, I'm using gentoo and to upgrade the evdev driver I also had to upgrade the mouse driver to 1.1.0-r1 as a dependency. Don't know if it's mouse driver related or it's some effect of the upgraded evdev driver, but the EmulateWheel option of my other input device stopped working. Section "InputDevice" Identifier "trackpoint" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mouse_trackpoint" Option "Emulate3Buttons" "off" Option "EmulateWheel" "on" Option "EmulateWheelButton" "2" Option "XAxisMapping" "6 7" Option "YAxisMapping" "4 5" EndSection
Yeah, the Name field not working sounds like a bug, could you add as an attachment the contents of /proc/bus/input/devices for me? As far as the tilt wheel being backwards, some mice do it one way, some the other, you'll probably find 'Option "HWheelRelativeAxisButtons" "7 6"' to be useful. The problem with your other device is unrelated to evdev, except due to the dependency, nothing I can do about it. You might want to file a bug against xf86-input-mouse about it though. Zephaniah E. Hull.
Created attachment 5895 [details] cat /proc/bus/input/devices
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.