Bug 1251391

Summary:	Keyboard no longer works under X
Product:	[Fedora] Fedora	Reporter:	Christopher Meng <i>
Component:	xorg-x11-drv-evdev	Assignee:	X/OpenGL Maintenance List <xgl-maint>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	peter.hutterer, xgl-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-08 08:55:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Christopher Meng 2015-08-07 08:23:26 UTC

Yesterday I updated my rawhide installation and now keyboard doesn't work in X level. 

Symptoms:

1. Grub and console(runlevel 3) stage the keyboard works fine.

2. Startx to xfce or GNOME, keyboard doesn't work anymore. 

3. Runlevel 5 to login screen, unable to enter password. Unable to switch tty via hotkey, can only use mouse to log out and then back to tty. 

4. Mouse is not affected.

-----------------------------------------

dnf history showed that after Aug 6th update on my system keyboard started to encounter problem. 

Updates included:

kernel 4.2.0 rc5 git1.1
libinput 0.21.0-1 -> 0.21.0-3
xorg evdev 2.9.2-2 -> 2.9.2-3
xorg server 1.17.2-2 -> 1.18.0-0.1.20150728

Model: ThinkPad T410i, libinput-test-device works, libinput-list-devices returns "AT Translated Set 2 Keyboard".

I'm not sure if I should report this on evdev or libinput. But since X level programs don't receive keyboard strokes I'd like to report here first. 

Thanks.

Comment 1 Christopher Meng 2015-08-08 08:55:21 UTC

After updating my evdev to 2.9.99-1, keyboard works again.

It seems that some conf files were moved?

Anyway big thanks.

Comment 2 Peter Hutterer 2015-08-09 23:21:43 UTC

yeah, sorry, we had a sync issue there. the 10-evdev.conf xorg.conf snippet that assigns the evdev driver to devices was moved upstream from the server to evdev, we forgot to update evdev when we pulled the latest upstream server in.