Bug 50957 - Evdev input lost when last application closes.
Summary: Evdev input lost when last application closes.
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 7.7 (2012.06)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-11 03:33 UTC by Rémy Gottschalk
Modified: 2012-07-09 00:30 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg-x11-* packages version (1.14 KB, text/plain)
2012-06-11 03:33 UTC, Rémy Gottschalk
no flags Details
Xorg log (33.40 KB, text/plain)
2012-06-11 03:33 UTC, Rémy Gottschalk
no flags Details

Description Rémy Gottschalk 2012-06-11 03:33:03 UTC
Created attachment 62879 [details]
xorg-x11-* packages version

When the last application application using X is stopped from another VT, every input is lost.
I observe that both keyboard and mouse are lost.

All seems fine at lower levels. (eg. a cat /dev/input/[whatever] from a ssh connection outputs correctly.) So I suppose this is indeed a X misbehavior.
 
From the log I suppose that, at this time X reloads all its drivers and I observe that the system automatically switch VT to X, maybe it is related to this behavious.



How to reproduce :
- Stop the X server ($ init 4)
- Start an empty X  ($ Xorg)
- Switch to another VT (ctr-alt F2)
- Start some application from this VT ($ xclock)
- Stop this application from this VT ($ killall xclock)
Comment 1 Rémy Gottschalk 2012-06-11 03:33:56 UTC
Created attachment 62881 [details]
Xorg log

Here is the related Xorg log
Comment 2 Peter Hutterer 2012-06-11 16:04:39 UTC
(In reply to comment #0)
> When the last application application using X is stopped from another VT, every
> input is lost.
> I observe that both keyboard and mouse are lost.

do you mean when the server comes back you cannot use mouse or keyboard anymore? judging by the log, the devices come back normally. is this not the case?

the server has a regeneration feature, whenever the last client disconnects it restarts internally with a clean slate - almost as if the server was completely restarted. you can turn this behaviour off by passing '-noreset' to Xorg.
Comment 3 Rémy Gottschalk 2012-06-12 00:29:09 UTC
(In reply to comment #2)

> do you mean when the server comes back you cannot use mouse or keyboard
> anymore? judging by the log, the devices come back normally. is this not the
> case?

Exactly, even if the log looks fine the X loose all input devices (I actually tested only with mouse and keyboard).
However even if X is completely unresponsive to input devices, if I remotely test the devices at a lower level by doing a "cat /dev/input/[...]" I got the expected outputs.
Plus when the system is in this state I still can remotely start X applications. Theses applications seems ok (except that interacting with them is kinda hard :) ) 
 
> the server has a regeneration feature, whenever the last client disconnects it
> restarts internally with a clean slate - almost as if the server was completely
> restarted. you can turn this behaviour off by passing '-noreset' to Xorg.

Thank you, turning of the reset feature does indeed solve my problem.

To tell you a little more, this only happens if the VT in use when the reset happens is not the one in use by X.
If X's VT is active when the reset happen I observe no misbehavior.

Furthermore this seems pretty consistent over different hardware. (I tested this on a few x86 based platforms)
Comment 4 Peter Hutterer 2012-06-13 22:25:38 UTC
(In reply to comment #3)
> To tell you a little more, this only happens if the VT in use when the reset
> happens is not the one in use by X.
> If X's VT is active when the reset happen I observe no misbehavior.

well, yes. X disables all input devices when you VT switch so no input will reach X. that's intended behaviour, not a bug. Otherwise you'd be sending the keyboard events on the tty to whatever currently has focus in X. Not ideal behaviour.
I believe rendering is stopped too, it's just not as obvious since you can't see it.

Closing this as notabug, this is indeed intended behaviour.
Comment 5 Rémy Gottschalk 2012-06-13 23:59:00 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > To tell you a little more, this only happens if the VT in use when the reset
> > happens is not the one in use by X.
> > If X's VT is active when the reset happen I observe no misbehavior.
> 
> well, yes. X disables all input devices when you VT switch so no input will
> reach X. that's intended behaviour, not a bug. Otherwise you'd be sending the
> keyboard events on the tty to whatever currently has focus in X. Not ideal
> behaviour.
> I believe rendering is stopped too, it's just not as obvious since you can't
> see it.
> 
> Closing this as notabug, this is indeed intended behaviour.

What made me think it is a bug is that afterward the machine is unusable with only the local input devices. For example I can't switch back to another VT neither.
Furthermore even if I unplug an plug back an event device it is recognize but still as useless.
Concerning the rendering, it seems to work since I can still see remotely started X application running.

Anyway thanks for the information.
Comment 6 Peter Hutterer 2012-06-14 16:27:28 UTC
ok, now I understand it, this is indeed a bug.

Summary:
if server regeneration is triggered while the server is vt-switched away, the server comes back (including vt switch back to X) but input devices do not work.

Quick gdb shows that EnableDevice is called for all devices.
Comment 7 Peter Hutterer 2012-06-14 17:16:09 UTC
http://patchwork.freedesktop.org/patch/10672/
Comment 8 Peter Hutterer 2012-07-01 22:53:29 UTC
*** Bug 50872 has been marked as a duplicate of this bug. ***
Comment 9 Peter Hutterer 2012-07-09 00:30:08 UTC
commit 9f1edced9abc066f0ba47672d006fe50fb206371
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jun 15 10:00:51 2012 +1000

    xfree86: always enable SIGIO on OsVendorInit (#50957)


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.