Description of problem: After upgrading from Fedora 20 64-bit to Fedora 21 via Fedup, my Dell XPS 15 9530's touch screen no longer works. Touching the screen has no effect on Gnome 3. When touching the screen and running sudo cat /dev/input/event16, the terminal fills with output, presumably indicating that input data from the screen is being received. The device entry in /proc/bus/input/devices: I: Bus=0003 Vendor=06cb Product=0ac3 Version=0111 N: Name="SYNAPTICS Synaptics Large Touch Screen" P: Phys=usb-0000:00:14.0-6/input0 S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0/0003:06CB:0AC3.0004/input/input17 U: Uniq= H: Handlers=mouse2 event16 B: PROP=2 B: EV=b B: KEY=400 0 0 0 0 0 B: ABS=260800000000003 Version-Release number of selected component (if applicable): I'm running kernel 3.17.4-301.fc21.x86_64. How reproducible: Upgrade only applied once. Steps to Reproduce: 1. Install Fedora 20 x86_64 2. try out the touchscreen (works) 3. Upgrade to Fedora 21 Workstation via fedup 4. test the touchscreen (fails) Actual results: Touchscreen unresponsive Expected results: Touchscreen works as an input device as before Additional info:
Thanks for the report. Can you provide the following 2 things: - the dmesg of the failed kernel (under F21) - the evemu-record (package evemu) of your touchscreen under f21. (You need to run evemu-record as root or use sudo).
Created attachment 969127 [details] output of dmesg As requested
dmesg output should now be attached (machine has been running for a while). sudo evemu-record gives: Available devices: /dev/input/event0: Power Button /dev/input/event1: Lid Switch /dev/input/event2: Power Button /dev/input/event3: AT Translated Set 2 keyboard /dev/input/event4: HOLTEK Evoluent VerticalMouse 4 /dev/input/event5: Logitech USB Multimedia Keyboard /dev/input/event6: Logitech USB Multimedia Keyboard /dev/input/event7: SynPS/2 Synaptics TouchPad /dev/input/event8: Video Bus /dev/input/event9: Video Bus /dev/input/event10: HDA Intel HDMI HDMI/DP,pcm=3 /dev/input/event11: HDA Intel HDMI HDMI/DP,pcm=7 /dev/input/event12: HDA Intel HDMI HDMI/DP,pcm=8 /dev/input/event13: Dell WMI hotkeys /dev/input/event14: HDA Intel PCH Headphone Mic /dev/input/event15: Integrated_Webcam_HD /dev/input/event16: SYNAPTICS Synaptics Large Touch Screen Select the device event number [0-16]: 16 # EVEMU 1.2 # Input device name: "SYNAPTICS Synaptics Large Touch Screen" # Input device ID: bus 0x03 vendor 0x6cb product 0xac3 version 0x111 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event type 1 (EV_KEY) # Event code 330 (BTN_TOUCH) # Event type 3 (EV_ABS) # Event code 0 (ABS_X) # Value 1997 # Min 0 # Max 3500 # Fuzz 0 # Flat 0 # Resolution 10 # Event code 1 (ABS_Y) # Value 638 # Min 0 # Max 1988 # Fuzz 0 # Flat 0 # Resolution 10 # Event code 47 (ABS_MT_SLOT) # Value 0 # Min 0 # Max 14 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 53 (ABS_MT_POSITION_X) # Value 0 # Min 0 # Max 3500 # Fuzz 0 # Flat 0 # Resolution 10 # Event code 54 (ABS_MT_POSITION_Y) # Value 0 # Min 0 # Max 1988 # Fuzz 0 # Flat 0 # Resolution 10 # Event code 57 (ABS_MT_TRACKING_ID) # Value 0 # Min 0 # Max 65535 # Fuzz 0 # Flat 0 # Resolution 0 # Properties: # Property type 1 (INPUT_PROP_DIRECT) N: SYNAPTICS Synaptics Large Touch Screen I: 0003 06cb 0ac3 0111 P: 02 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 04 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 03 00 00 00 00 80 60 02 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 A: 00 0 3500 0 0 10 A: 01 0 1988 0 0 10 A: 2f 0 14 0 0 0 A: 35 0 3500 0 0 10 A: 36 0 1988 0 0 10 A: 39 0 65535 0 0 0 ################################ # Waiting for events # ################################ E: 0.000000 0003 0035 1990 # EV_ABS / ABS_MT_POSITION_X 1990 E: 0.000000 0003 0036 0628 # EV_ABS / ABS_MT_POSITION_Y 628 E: 0.000000 0003 0000 1990 # EV_ABS / ABS_X 1990 E: 0.000000 0003 0001 0628 # EV_ABS / ABS_Y 628 E: 0.000000 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 0.005963 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 0.005963 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 [and much, much more like that]
Thanks for the logs. Unfortunately, the dmesg output starts too late to have the proper initialization device recorded in them. You can get the full output with "journalctl -b -k" or by rebooting and re-asking for a dmesg. Also, I am interested in the full evemu-record when you are touching the device. This allows us to check if the problem lies in the kernel (missing few key events) or in the Xorg driver (by replaying the device). Please re-attach the full evemu-record to the bug (as a plain text file).
Created attachment 969152 [details] longer dmesg output
(In reply to Benjamin Tissoires from comment #4) > Unfortunately, the dmesg output starts too late to have the proper > initialization device recorded in them. You can get the full output with > "journalctl -b -k" or by rebooting and re-asking for a dmesg. Now attached. > Also, I am interested in the full evemu-record when you are touching the > device. This allows us to check if the problem lies in the kernel (missing > few key events) or in the Xorg driver (by replaying the device). Please > re-attach the full evemu-record to the bug (as a plain text file). How can I pipe this to a file effectively? evemu-record is interactive and requires that I select the necessary event number. Thanks for any tips.
(In reply to Sam Tuke from comment #6) > Now attached. Thanks. BTW, I do not see anything which would explain the misbehaviour. > How can I pipe this to a file effectively? evemu-record is interactive and > requires that I select the necessary event number. Thanks for any tips. Just calling "sudo evemu-record > output.ev" is fine. The device list is printed out to the stderr, so it will be printed out on your terminal, and not in the file :) Also, you can directly specify the input node when you know it: sudo evemu-record /dev/input/event16
Created attachment 969181 [details] evemu-record output
(In reply to Benjamin Tissoires from comment #7) > Also, you can directly specify the input node when you know it: > sudo evemu-record /dev/input/event16 Great thanks - now attached.
From what I can read (and test) from the evemu output, the kernel does its job properly. Touches are reported correctly, and they are all released at the end of the record. Moving the bug to xorg (though on my local F21, the replay of the touches definitively does something on the screen). Peter may have an idea of what is happening.
Thanks Benjamin
same here, seems to work just fine with xorg-x11-drv-evdev-2.9.0-3.fc21.x86_64 xorg-x11-server-Xorg-1.16.2.901-1.fc21.x86_64 do you have a custom xorg.conf? Can you attach the Xorg log output please? journalctl _COMM=Xorg.bin _PID=xyz where xzy is the PID of the last/current run (shown in square brackets if you leave the _PID bit off)
Created attachment 969507 [details] xorg log
Hi Peter, logfile now attached. About xorg.conf, I'm not sure if there's a custom one; just had a look in /etc/X11 and can see backup files but no file named xorg.conf. Here's the result of a 'locate' search: $ locate xorg.conf /etc/X11/xorg.conf.backup /etc/X11/xorg.conf.d /etc/X11/xorg.conf.nvidia-xconfig-original /etc/X11/xorg.conf.xorg-x11-drv-nvidia_uninstalled /etc/X11/xorg.conf.d/00-keyboard.conf /etc/X11/xorg.conf.d/20-keyboard.conf /etc/abrt/plugins/xorg.conf /etc/bumblebee/xorg.conf.d /etc/bumblebee/xorg.conf.nouveau /etc/bumblebee/xorg.conf.nvidia /etc/bumblebee/xorg.conf.d/10-dummy.conf /usr/share/X11/xorg.conf.d /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/10-quirks.conf /usr/share/X11/xorg.conf.d/50-synaptics.conf /usr/share/X11/xorg.conf.d/50-vmmouse.conf /usr/share/X11/xorg.conf.d/50-wacom.conf /usr/share/abrt/conf.d/plugins/xorg.conf /usr/share/man/man5/abrt-xorg.conf.5.gz /usr/share/man/man5/xorg.conf.5.gz /usr/share/man/man5/xorg.conf.d.5.gz
ok, I admit - no idea what's happening there. the evemu replay works just fine here and the log looks just fine too. I honestly don't know what's happening here. what desktop environment are you running?
(In reply to Peter Hutterer from comment #15) > ok, I admit - no idea what's happening there. Darn. Thanks for looking. > what desktop environment are you running? Gnome 3.14.2.
I have the same issue. evemu tracks input events fine, xorg log [attached] seems to be OK, similar to Sam's. Is it usual to have the ignore line (which both Sam & I do): Rha 12 01:54:20 localhost.localdomain gdm-Xorg-:0[1164]: (II) config/udev: Adding input device eGalax Inc. eGalaxTouch EXC7910-1031-12.00.03 (/dev/input/mouse2) Rha 12 01:54:20 localhost.localdomain gdm-Xorg-:0[1164]: (II) No input driver specified, ignoring this device. Rha 12 01:54:20 localhost.localdomain gdm-Xorg-:0[1164]: (II) This device may have been added with another device file. All was working fine until FC21. Same xorg & evdev driver as you, Peter, Gnome 3.14.2 as Sam.
Created attachment 970105 [details] xorg log
(In reply to Illtud Daniel from comment #17) > I have the same issue. evemu tracks input events fine, xorg log [attached] > seems to be OK, similar to Sam's. This is getting weird. Could you try to run the following commands in the running session: $> sudo rmmod hid-multitouch ; sudo modprobe hid-multitouch Then check if the device now works and what is the new Xorg.log. > Is it usual to have the ignore line (which > both Sam & I do): Yes, it is. The kernel creates 2 nodes for the touchscreen: the generic evdev handler (/dev/input/eventX) which is used by Xorg, and a legacy mouse node (/dev/input/mouseX). Xorg can safely ignore the latter. > All was working fine until FC21. Same xorg & evdev driver as you, Peter, > Gnome 3.14.2 as Sam. Could you also try to run from a liveUSB of a plain F21, and see if the touchscreen works?
(In reply to Benjamin Tissoires from comment #19) > Could you try to run the following commands in the running session: > $> sudo rmmod hid-multitouch ; sudo modprobe hid-multitouch Yes that works! Now the touchscreen is operational again. > Then check if the device now works and what is the new Xorg.log. Attached /var/log/Xorg.0.log
Created attachment 970175 [details] Xorg log 2
*** Bug 1174840 has been marked as a duplicate of this bug. ***
Created attachment 970262 [details] Xorg log for removing & reloading hid-multitouch Yes, removing and reloading hid-multitouch works. Thanks for your help on this, Benjamin. Here's the additional xorg logging for that.
Sam: two things to try. Take your evemu recording that you attached here, then sudo evemu-device recording-file.txt & this will print the path for the new device sudo evemu-play /device/path < recording-file.txt does that move the pointer? kill evemu-device, then run sudo evemu-play /dev/input/eventXYZ < recording-file.txt this time with the path of the real device (16 according to comments above) does that do anything?
oh, and another thing: does this happen with a plain X session started through xinit?
ok, final question I think: what's the output of xinput list-prop "device name", with the device name as displayed by xinput list.
Not the original reporter, but: After some investigation... the trigger that makes it nonresponsive for me is a suspend/resume cycle. Somehow, I'm not surprised. Following your instructions from comments #24/#25: 1. Playing back the recording from evemu-record to the fake evemu-device does activate the cursor. 2. Playing back the recording from evemu-record to the *real* device also activates the cursor... and makes the touchscreen responsive again. In fact, even something as simple as "cat <touchscreen device> ; <ctrl-c>" seems to reset it properly. [root@nostromo ~]# xinput list-props 10 Device 'ELAN Touchscreen': Device Enabled (139): 0 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (271): 0 Device Accel Constant Deceleration (272): 1.000000 Device Accel Adaptive Deceleration (273): 1.000000 Device Accel Velocity Scaling (274): 10.000000 Device Product ID (258): 1267, 769 Device Node (259): "/dev/input/event13" Evdev Axis Inversion (275): 0, 0 Evdev Axis Calibration (276): <no items> Evdev Axes Swap (277): 0 Axis Labels (278): "Abs MT Position X" (267), "Abs MT Position Y" (268), "Abs MT Touch Major" (264), "Abs MT Touch Minor" (265), "Abs MT Orientation" (266), "Abs MT Tool X" (269), "Abs MT Tool Y" (270), "None" (0), "None" (0) Button Labels (279): "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Wheel Up" (145), "Button Wheel Down" (146) Evdev Scrolling Distance (280): 0, 0, 0 Evdev Middle Button Emulation (281): 0 Evdev Middle Button Timeout (282): 50 Evdev Third Button Emulation (283): 0 Evdev Third Button Emulation Timeout (284): 1000 Evdev Third Button Emulation Button (285): 3 Evdev Third Button Emulation Threshold (286): 20 Evdev Wheel Emulation (287): 0 Evdev Wheel Emulation Axes (288): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (289): 10 Evdev Wheel Emulation Timeout (290): 200 Evdev Wheel Emulation Button (291): 4 Evdev Drag Lock Buttons (292): 0
(In reply to Bill Nottingham from comment #27) > [root@nostromo ~]# xinput list-props 10 > Device 'ELAN Touchscreen': > Device Enabled (139): 0 something disabled your touchscreen, question is what though. Benjamin found that issue too and noticed with xinput watch-props that it gets reset as soon as he changes it. So something in the desktop environment must be toggling it. I have no idea why playing back the recording through the real device would activate it though, if the device is disabled the server should drop all events.
Reassigning to g-s-d, looks like it's the fix to the gnome bug here that causes this: https://bugzilla.gnome.org/show_bug.cgi?id=720295 or at least, that's very likely candidate. Downgrading g-s-d to 3.14.1 should fix this issue for now.
*** Bug 1169292 has been marked as a duplicate of this bug. ***
Created attachment 976462 [details] xinput list-props output
(In reply to Peter Hutterer from comment #26) > ok, final question I think: what's the output of xinput list-prop "device > name", with the device name as displayed by xinput list. Attached.
(In reply to Peter Hutterer from comment #24) > Sam: two things to try. Take your evemu recording that you attached here, > then > > sudo evemu-device recording-file.txt & Output of this is: [3] 27520 > sudo evemu-play /device/path < recording-file.txt What should I replace /device/path with? Sorry I'm a bit lost. Sam.
evemu-device should print the newly created device path. otherwise just run evemu-describe without arguments, that'll list all available devices and you can check which one is the newly created one. it'll be something like /dev/input/event7 or so (don't confuse it with the physical device you recorded from)
On latest F21, stock gnome desktop, similar HW - and only way to get touch back after resume is to restart X. Device is present in xinput list, recordable via evemu just fine. Playing the recording back does not result in anything (at least, touch is still stuck). It is somehow semi-alive - when tapped, the pointer disappears from where the mouse is, but soon reappears again when mouse moved; tapped events are completely ignored by X app I was trying to tap. More information: the device gets somehow kicked into floating slave after first tap, rendering all the subsequent activity into waste. xinput reattach is successful but only until next tap, which kick touch back into float. [vitb@localhost ~]$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=14 [slave pointer (2)] ⎜ ↳ Bluetooth Travel Mouse id=11 [slave pointer (2)] ⎜ ↳ SYNAPTICS Synaptics Large Touch Screen id=12 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] [TAP] [vitb@localhost ~]$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=14 [slave pointer (2)] ⎜ ↳ Bluetooth Travel Mouse id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] ∼ SYNAPTICS Synaptics Large Touch Screen id=12 [floating slave] [vitb@localhost ~]$
(In reply to Peter Hutterer from comment #29) > Reassigning to g-s-d, looks like it's the fix to the gnome bug here that > causes this: https://bugzilla.gnome.org/show_bug.cgi?id=720295 > or at least, that's very likely candidate. Downgrading g-s-d to 3.14.1 > should fix this issue for now. Certainly wouldn't, because that code was merged into gnome-settings-daemon 3.15.1, which is targeted for Fedora 22. Sam and others apparently use Fedora 21, which ships gnome-settings-daemon 3.14.x. It might be something to do with the touchscreen mapping code. Are any of you using multiple displays? The output of: /usr/libexec/gnome-settings-daemon --replace --debug will help.
(In reply to Bastien Nocera from comment #36) > Certainly wouldn't, because that code was merged into gnome-settings-daemon > 3.15.1, which is targeted for Fedora 22. > > Sam and others apparently use Fedora 21, which ships gnome-settings-daemon > 3.14.x. upstream commit 31cc2e44d2c2e6592b912b2254e682b098c6453c, ships with 3.14.2
Created attachment 979846 [details] gsd debug output Only the laptop display here.
*** Bug 1173907 has been marked as a duplicate of this bug. ***
I think this patch would do it: https://bugzilla.gnome.org/show_bug.cgi?id=743252
Please test with the packages at: http://koji.fedoraproject.org/koji/taskinfo?taskID=8675804
Seems to fix it for me.
gnome-settings-daemon-3.14.2-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-settings-daemon-3.14.2-2.fc21
Package gnome-settings-daemon-3.14.2-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 gnome-settings-daemon-3.14.2-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1008/gnome-settings-daemon-3.14.2-2.fc21 then log in and leave karma (feedback).
works for me, thanks
*** Bug 1186785 has been marked as a duplicate of this bug. ***
after suspend the touch still works, but in a little while still disappears (moves to floating in xinput list). [vitb@localhost ~]$ xinput ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)] ⎜ ↳ Bluetooth Travel Mouse id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] ∼ SYNAPTICS Synaptics Large Touch Screen id=11 [floating slave] xinput reattach does not help - the touchscreen drops back into floating slave right away.
(In reply to Ferry Huberts from comment #45) > works for me, thanks What also seems to be fixed is that the touchscreen is now properly 'attached' to its screen: on F20 (at least) when I had multiple monitors then the touchscreen would be mapped/scaled to monitors. I don't have the issue from comment 47
Hmm - this seems somehow to be related to multimonitor too, at least I am having random taps appearing on extra monitor when it is attached. I will give it more testing without extra monitor.
gnome-settings-daemon-3.14.2-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.