Bug 20657 - >=xf86-input-evdev-2.1.0 + control-C = X crash
Summary: >=xf86-input-evdev-2.1.0 + control-C = X crash
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-14 04:35 UTC by Dobai-Pataky Balint
Modified: 2009-03-16 22:04 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.1.log (16.87 KB, text/plain)
2009-03-14 05:01 UTC, Dobai-Pataky Balint
no flags Details
xorg.log (18.43 KB, text/plain)
2009-03-14 11:26 UTC, Dobai-Pataky Balint
no flags Details

Description Dobai-Pataky Balint 2009-03-14 04:35:34 UTC
if i install >=xf86-input-evdev-2.1.0 and press control-C, X quits.
this means i'm stuck at xorg-server-1.5.2


http://bugs.gentoo.org/show_bug.cgi?id=260700
Comment 1 Rémi Cardona 2009-03-14 04:49:13 UTC
Please attach your xorg.conf, your Xorg.0.log along with the output of dmesg.

Let's centralize everything here.

Thanks
Comment 2 Rémi Cardona 2009-03-14 04:49:26 UTC
Please attach your xorg.conf, your Xorg.0.log along with the output of dmesg.

Let's centralize everything here.

Thanks
Comment 3 Dobai-Pataky Balint 2009-03-14 05:01:41 UTC
Created attachment 23849 [details]
Xorg.1.log

Xorg.1.log
Comment 4 Mikhail Krivtsov 2009-03-14 08:40:37 UTC
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".
Comment 5 Dobai-Pataky Balint 2009-03-14 11:24:11 UTC
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.
Comment 6 Dobai-Pataky Balint 2009-03-14 11:26:08 UTC
Created attachment 23859 [details]
xorg.log
Comment 7 Peter Hutterer 2009-03-15 04:17:20 UTC
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.
Comment 8 Dobai-Pataky Balint 2009-03-15 10:10:20 UTC
(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.
Comment 9 Peter Hutterer 2009-03-15 19:20:57 UTC
(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
Comment 10 Dobai-Pataky Balint 2009-03-16 02:54:10 UTC
Rémi, please help me out: is b33905234025f005819c7e2acd653a3a0ecfeb82 in x11-base/xorg-server-1.5.3-r4 ?
Comment 11 Rémi Cardona 2009-03-16 06:24:51 UTC
1.5.3-r5 that I've just committed does. Let me know if it works for you.

Thanks
Comment 12 Dobai-Pataky Balint 2009-03-16 12:43:15 UTC
xorg-server-1.5.3-r5 works as expected.
thank you all
Comment 13 Peter Hutterer 2009-03-16 14:15:35 UTC
Closing this bug as fixed then.
Comment 14 mrsteven 2009-03-16 15:13:17 UTC
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?
Comment 15 Rémi Cardona 2009-03-16 15:58:01 UTC
(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
Comment 16 Peter Hutterer 2009-03-16 22:04:23 UTC
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.