| Summary: | Evdev input lost when last application closes. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Rémy Gottschalk <gottsc.r> | ||||||
| Component: | Input/evdev | Assignee: | Peter Hutterer <peter.hutterer> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | huax.lu, peter.hutterer | ||||||
| Version: | 7.7 (2012.06) | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 62881 [details]
Xorg log
Here is the related Xorg log
(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. (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) (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. (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. 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. *** Bug 50872 has been marked as a duplicate of this bug. *** 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.
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)