Summary: | >=xf86-input-evdev-2.1.0 + control-C = X crash | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Dobai-Pataky Balint <dpblnt> | ||||||
Component: | Input/evdev | Assignee: | Peter Hutterer <peter.hutterer> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | mikhail.krivtsov, mrsteven, remi | ||||||
Version: | unspecified | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Dobai-Pataky Balint
2009-03-14 04:35:34 UTC
Please attach your xorg.conf, your Xorg.0.log along with the output of dmesg. Let's centralize everything here. Thanks Please attach your xorg.conf, your Xorg.0.log along with the output of dmesg. Let's centralize everything here. Thanks Created attachment 23849 [details]
Xorg.1.log
Xorg.1.log
I had similar problem. The "AllowEmptyInput" "true" option in "ServerFlags" section of "xorg.conf" file solved it for me: Section "ServerFlags" Option "AllowEmptyInput" "true" EndSection My explanation: With Option "AllowEmptyInput" "true" console is switched into "raw" mode. As result the "X" server is protected against SIGQUIT leaking into console from "evdev" device driver working without "EVIOCGRAB". i just tested it with these: x11-base/xorg-server-1.5.3-r4 x11-drivers/xf86-input-evdev-2.2.0-r1 my mice stopped working, but control-c still crashes X. Created attachment 23859 [details]
xorg.log
make sure you have b33905234025f005819c7e2acd653a3a0ecfeb82 in your server, the problem goes away then. I think you may be triggering a combination that doesn't set RAW mode on the console. Is there any particular reason you're specifying your devices in the config file? If not, just remove all input-related stuff from xorg.conf and let the server do it automagically. (In reply to comment #7) > make sure you have b33905234025f005819c7e2acd653a3a0ecfeb82 in your server, what do you mean by this? > > Is there any particular reason you're specifying your devices in the config > file? If not, just remove all input-related stuff from xorg.conf and let the > server do it automagically. i have three monitor on two screens, i have to assign the mouse to it's monitor. xorg will not do that for me automatically. (In reply to comment #8) > (In reply to comment #7) > > make sure you have b33905234025f005819c7e2acd653a3a0ecfeb82 in your server, > what do you mean by this? this patch always switches the TTY to RAW mode. http://cgit.freedesktop.org/xorg/xserver/commit/?id=b33905234025f005819c7e2acd653a3a0ecfeb82 Rémi, please help me out: is b33905234025f005819c7e2acd653a3a0ecfeb82 in x11-base/xorg-server-1.5.3-r4 ? 1.5.3-r5 that I've just committed does. Let me know if it works for you. Thanks xorg-server-1.5.3-r5 works as expected. thank you all Closing this bug as fixed then. Shouldn't the evdev driver "grab" the keyboard (so that keypresses no longer reach the tty layer of the kernel) making this unneccessary? If it did so, this would be the better solution - or am I wrong here? (In reply to comment #14) > Shouldn't the evdev driver "grab" the keyboard (so that keypresses no longer > reach the tty layer of the kernel) making this unneccessary? If it did so, this > would be the better solution - or am I wrong here? If the driver does it, then the device cannot be used for other legitimate uses such as gmp (console mouse) or hal's input addon. IIRC, Peter had already tried that approach and clearly the current way is the best. The issue here is that the 1.5 branch is a near-dead end and it's missing a few important patches. Cheers we used to grab the device until 2.1 and it was the wrong thing to do for reasons stated above - no-one else could use this device and that broke a few things (rfkill, mouse button emulation, etc). so not grabbing is actually the correct solution, it means we're behaving nicely on a global scale. |
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.