Bug 1185070 - Switching to vconsole and back to X causes X to lock up. Plugging, unplugging usb trackball crashes X.
Summary: Switching to vconsole and back to X causes X to lock up. Plugging, unpluggin...
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-01-22 20:19 UTC by stan
Modified: 2015-02-08 08:58 UTC (History)
3 users (show)

Fixed In Version: xorg-x11-drv-libinput-0.4.0-2.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-08 08:58:45 UTC
Type: Bug

Attachments (Terms of Use)
The Xorg.0.log file from an instance of the crash. (62.81 KB, text/plain)
2015-01-22 20:19 UTC, stan
no flags Details
Xorg.0.log showing the unplug and replug of the mouse and keyboard (64.01 KB, text/plain)
2015-01-23 16:34 UTC, stan
no flags Details

Description stan 2015-01-22 20:19:20 UTC
Created attachment 983033 [details]
The Xorg.0.log file from an instance of the crash.

Description of problem:
I boot F21 into multiuser.  I then start a mate desktop with startx.  As long as I remain within X, there are no problems.  Everything works as expected.  But if I switch to a virtual console, using say Shift-Alt-F4, and then switch back to X, using Shift-Alt-F1, X is locked.  No keyboard or pointer input is possible i.e. I can't switch back to a vconsole.  If I unplug the USB trackball, and plug it back in, nothing changes, the screen remains locked, until I try to use the trackball.  Then, X server crashes, and throws me back to virtual console 1.

Version-Release number of selected component (if applicable):
Name        : xorg-x11-server-common
Version     :
Release     : 1.fc21
Architecture: x86_64

How reproducible:
Every time.

Steps to Reproduce:
1.  Boot to multiuser.
2.  Start an X session using startx.
3.  Switch to vconsole, and back to X.

Actual results:
X server locks.

Expected results:
X is responsive and functioning.

Additional info:
This works fine with the version of X server in F20.  The evdev configuration is identical for both, but one works and one doesn't.

Comment 1 Hans de Goede 2015-01-23 09:55:17 UTC

Thanks for the bug report.

The backtrace in the server log looks familiar, and is related to using input drivers build against an older server version.

Can you please make sure that your system is fully up2date with all f21 updates ?


yum distro-sync

Let it do its thing and then after that run:

package-cleanup --orphans

This second command should only list:
1) 1 or 2 older kernels
2) packages which you've installed manually from 3th party sources

This second command should certainly NOT list any xorg packages.

Also do you have an /etc/X11/Xwrapper.config file ? If so try removing it.



Comment 2 stan 2015-01-23 16:33:21 UTC
I ran your suggestions.  My system was already up to date, except for the package audio-entropyd.  I only installed my version of that yesterday, so it isn't the cause of this issue.  As you said, the orphans only listed some older kernel packages, except for the package xorg-x11-drv-mouse from f21.  I had it installed to see if I could determine why the buttons weren't working on the trackball.  I erased it.  There was no /etc/X11/Xwrapper.config file.

This improved things, sort of.  When I switch to a vconsole from X now, it still locks up on return to X, but when I unplug and replug the trackball and the keyboard, both USB, the function again without crashing X.  However, the ps2 mouse is dead on return, regardless of whether I unplug it and replug it or not.  I use gpm a lot, to select with the mouse and paste at the cursor.  The trackball has no way to invoke the middle mouse button, so I can select with it, but can't paste.  I tried the two-button mouse trick of clicking the left and right buttons at the same time, doesn't work.  

As a work around, I can always exit X, and then restart it to get everything working again.  But this is clumsy, and I have to stop everything I'm doing.

I'll attach the Xorg.0.log, where it shows the keyboard and trackball being unplugged and replugged, but shows no changes for the ps2 mouse (a three button roller mouse).

This is all happening with your new version of libinput.

Comment 3 stan 2015-01-23 16:34:36 UTC
Created attachment 983452 [details]
Xorg.0.log showing the unplug and replug of the mouse and keyboard

Comment 4 Hans de Goede 2015-01-24 08:31:50 UTC

Can you check that you've no (old) custom xorg config files under either of /etc/X11/xorg.conf.d or /usr/share/X11/xorg.conf.d ?

If you do have custom config files there, please try moving them to some other place where Xorg will not search for them, and then try again.



Comment 5 stan 2015-01-24 15:35:21 UTC
The only file in the /etc/X11/xorg.conf.d directory was a file for the custom keymapping I use, put there by systemd.  It said not to edit it manually, so I left it there.

In /usr/share/X11/xorg.conf.d, there were many files.
$ ls -n /usr/share/X11/xorg.conf.d/
total 28
-rw-r--r--. 1 0 0 1099 Dec  9 17:39 10-evdev.conf
-rw-r--r--. 1 0 0 1350 Dec  9 17:39 10-quirks.conf
-rw-r--r--. 1 0 0 2611 Sep 17 14:56 50-synaptics.conf
-rw-r--r--. 1 0 0  115 Jun  8  2014 50-vmmouse.conf
-rw-r--r--. 1 0 0  858 Aug 18 22:08 50-wacom.conf
-rw-r--r--. 1 0 0  350 Jan 18 16:33 90-keyboard-uneaf.conf
-rw-r--r--. 1 0 0  789 Jan 22 18:45 90-libinput.conf

I removed all of them, and when I started X, there was no input available.  I had to reboot to get back to the vconsoles, even though the system was running fine (I saw an selinux warning pop up and disappear while in the locked X).

I put back 90-libinput.conf only, and the behavior returned to lockup with unplugging and re-plugging USB restoring functionality.

I added, in order, 90-keyboard-uneaf.conf, 10-evdev.conf, 10-quirks.conf, and the behavior remained the same after each addition.

This has to be a corner case.  If people who were starting directly to graphical interface were experiencing this, there would be loads of tickets out there, and I didn't find any.  Do you think it makes sense to look at how the greeters start X, say lightdm, to see what they are doing differently that doesn't lead to this problem?  It could have to do with how I am starting X via startx.  Maybe it isn't sharing the input devices with the vconsoles properly because of the way I'm invoking it.  Or something has changed, the greeters have incorporated the change, but startx hasn't. 

Thanks for your help.

Comment 6 Hans de Goede 2015-01-28 11:08:30 UTC
Ok, I've figured out what is going on. I'm preparing a xorg-x11-drv-libinput package update fixing this.

Comment 7 Fedora Update System 2015-01-28 11:27:39 UTC
xorg-x11-drv-libinput-0.4.0-2.fc21 has been submitted as an update for Fedora 21.

Comment 8 stan 2015-01-28 21:55:04 UTC
Yesss!  This solves the problem.  Thanks a lot!

Comment 9 Fedora Update System 2015-01-30 04:35:14 UTC
Package xorg-x11-drv-libinput-0.4.0-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-libinput-0.4.0-2.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2015-02-08 08:58:45 UTC
xorg-x11-drv-libinput-0.4.0-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.