Bug 95169

Forgot to add, the wacom pen does work.

please attach the output from evemu-record for a touch or two for this device, thanks.

Created attachment 123338 [details]
evemu-record log

I have attached the evemu-record log. I did several touches, single and pinch movements.

Note: In the meantime I have learned that sometimes the touchscreen works and other times it does not. It can go from working to not-working or vis-versa and I have not been able to yet understand the trigger. The capture log was from when it was not working.
I did not notice this behaviour with F23, but then I only ran it for a few hours before I upgraded to F24 Alpha (because of HiDPI issues with external displays).

looking at this log this appears to be a kernel problem - there are no events in the log itself (check the bottom). Please verify that when the touchscreen isn't working evemu doesn't see any events - if so then we need to move this to the kernel.

Created attachment 123430 [details]
evemu-record log when touch is working

I confirm. Here is also the log for when things do work.

Punting to benjamin and jason

With touchscreen currently working;

$ dmesg |grep -i wacom
[    2.323420] usb 1-10: Manufacturer: Wacom Co.,Ltd.
[    2.340176] input: Wacom Co.,Ltd. Pen and multitouch sensor Finger as /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/0003:056A:5040.0001/input/input9
[    2.340564] wacom 0003:056A:5040.0001: hidraw0: USB HID v1.11 Device [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-10/input0
[    2.340777] input: Wacom Co.,Ltd. Pen and multitouch sensor Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.1/0003:056A:5040.0002/input/input11
[    2.341093] wacom 0003:056A:5040.0002: hidraw1: USB HID v1.11 Mouse [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-10/input1
[229768.608915] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[229768.609042] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[229798.804979] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[229798.805221] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[229829.216144] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[229829.216357] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[229864.384726] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[229864.384853] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[230226.088235] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[230226.088352] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[230982.131514] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[230982.131613] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[234854.680992] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[234854.681155] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)
[320160.619758] wacom 0003:056A:5040.0001: wacom_set_report: ran out of retries (last error = -32)
[320160.619870] wacom 0003:056A:5040.0002: wacom_set_report: ran out of retries (last error = -32)

We once received a report of a Lenovo Yoga Thinkpad 260 producing the same kind of "wacom_set_report: ran out of retries (last error = -32)" messages, but the issue apparently resolved itself. We've heard from several other 260 and X1 users, but none of them had this issue.

To debug this further, I would first be interested in knowing if the fix for another issue affecting the 260 and X1 (pen/touch doesn't work after rebooting into Linux from Windows) has any effect on this issue. That fix subtly changes the operation of the code which calls "wacom_set_report" (which is failing for you) -- perhaps enough to resolve this.

To do this, follow the instructions at [1], except downloading the driver from [2] instead of from Sourceforge. If all goes well, running `modinfo wacom | grep version` should show the version as "v2.00-UNKNOWN".

If that doesn't seem to do anything, it would be interesting to know if the device works properly in Windows. Its hard to say right now if this is a hardware issue or some subtle software bug that others haven't run into.


[1]: http://linuxwacom.sourceforge.net/wiki/index.php/input-wacom
[2]: https://github.com/linuxwacom/input-wacom/archive/jiri/for-4.6.zip

Thanks, I installed the driver and modinfo wacom indeed shows v2.00-UNKNOWN

Immediately after booting I notice that Pen is working (which has also been flaky, but less so then Finger), but Finger is not working.

dmesg shows no wacom errors for the moment.

As regarding Windows. It had Win10 on it originally and Pen and Finger worked in the short period that I tested it, which was probably around three hours before I wiped the disk and installed Fedora.

I do have the recovery media, but it would take a lot of time to put windows back on and test again (backing up my data first and such). Let me know if you think this is really necessary.

The machine has BIOS 1.11 which was the latest, until I just now noticed that 1.14 was published yesterday. Looking at the changelog there is nothing that should effect the wacom device, but regardless I will go ahead and update.

I installed the new BIOS (1.14) and as I suspected it made no noticeable difference.

A few more comments
- Pen does not work when Wayland is running (login screen, or starting the wayland desktop)
- since installing the v2.00UNKNOWN driver, the touch screen has not worked even once despite several reboots. No errors in the log though.

Apologies for the delay -- this slipped off my radar...

It would be good to get another evemu-record log to see if there's any difference between the stock driver and the v2.00-UNKNOWN you installed. Also, could you please try using the HID-replay[1] program to capture events from the touchscreen? After installing, you should only need to run `sudo hid-recorder > /tmp/touch.log`, select your touchscreen device, and then touch the screen a few times. Press CTRL+C to afterwards and attach the /tmp/touch.log file for review.

[1]: https://bentiss.github.io/hid-replay-docs/

Created attachment 123873 [details]
hid-recorder, touch not working with v2.00UNKNOWN driver

All tests with kernel 4.5.4-300.fc24.x86_64.

Please note, I can trigger the wacom_set_report: ran out of retries (last error = -32) error by putting the machine in suspend (to ram) and resuming it. Doing so will generate two entries each time.

Behavior has been identical for both the stock and patched wacom driver in all of this.

Also, when I say touch does not work, what I see is one of the following;
- touch causes mouse cursor to disappear, but I cannot interact with anything
OR
- mouse cursor follows finger for a bit, then vanishes, but again no interaction with anything on screen is possible

I also guess the pen not working in Wayland is a separate issue from the above.

Created attachment 123874 [details]
Broken touch with stock driver

Created attachment 123875 [details]
working touch with stock driver

Created attachment 123876 [details]
working touch with patched driver

(In reply to Robert de Rooy from comment #12)
> Also, when I say touch does not work, what I see is one of the following;
> - touch causes mouse cursor to disappear, but I cannot interact with anything
> OR
> - mouse cursor follows finger for a bit, then vanishes, but again no
> interaction with anything on screen is possible
> 

This (along with the provided hid-recorder dumps) strongly suggests that the kernel driver is working well enough and that the problem may be in userspace. I don't see anything strange when replaying the "broken" event stream locally, but that doesn't mean a whole lot. You might try uninstalling the xf86-input-wacom driver to see if the evdev / libinput driver works correctly with the touchscreen.

In the meantime, I'll try to grab a copy of the F24 alpha to see if replaying the event stream within it works any differently than on my current box.

> I also guess the pen not working in Wayland is a separate issue from the
> above.

Wayland pen support is still a work in progress. We recently had a protocol for stylus events accepted, but there's still additional protocol to finalize and then work to implement everything in the various compositors. Its slow going, but definitely in the works :)

I recommend grabbing libinput from git://git.freedesktop.org/git/wayland/libinput and building it with the gtk+ devel headers available. That gives you a binary in ./tools/event-gui that you can use for analysis. It brings up a GTK-window and displays what events libinput sees, independent of what X driver is in use. You'll need to run it as root though to have access to the event nodes.

If you see the touch circle in that tool follow your finger just fine then the problem is really in userspace. But given comment 5 I'm still thinking this is a kernel issue.

ping?

Sorry for the delay. I build the libinput debug tool and ran it.

Note that before testing, touch and pen where working, so this does not prove anything for now.

What I did notice was that there seems to be a calibration issue, it was putting the red dot for finger roughly a centimeter below where my finger actually was.

The same happened to the dot that appeared when I put the pen on the display, the dot was roughly a centimeter below the pen. Also the line being drawn was much exaggerated in movements and not below the pen either.

I don't notice this calibration issue outside of the debug tool.

I will try running the tool again, when touch or finger stops working.

The calibration issue is probably caused by the window decoration, we just map the touchscreen into the canvas so if the window bar is ca 1cm, you'll see that offset. That's nothing to worry about.

But if you say it's working now, can we close this as WORKSFORME and re-open when it comes back?

Well, as I indicated in the first post, it works when you just boot the machine, then at some point stops working.

And indeed, that is what happened again. Note, the machine has not been in suspend since being booted.
Finger stopped working, and pen still worked.

I ran the libinput debugging gui, and it does NOT detect finger events, but does detect pen.

I do however see quite a few of these in the log;
Jun 14 13:09:46 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is tagged by udev as: Touchscreen
Jun 14 13:09:46 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is a touch device
Jun 14 14:16:17 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is tagged by udev as: Touchscreen
Jun 14 14:16:17 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is a touch device
Jun 14 14:26:04 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is tagged by udev as: Touchscreen
Jun 14 14:26:04 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is a touch device
Jun 14 14:43:31 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is tagged by udev as: Touchscreen
Jun 14 14:43:31 x1yoga /usr/libexec/gdm-x-session[1536]: (II) input device 'Wacom Co.,Ltd. Pen and multitouch sensor Finger', /dev/input/event7 is a touch device

These seem to be being caused by the unlock of the lock screen. But why for the Finger device, but not for any other input device?

It may be that we have two bugs interacting with each other.

First I tried rebooting the ThinkPad, and touch still did not work, then I powered off the machine and started it back up, and touch still did not work. Then I powered it off and removed the power (cannot pull the battery in this model) and put it back and booted and touch again worked.

Then I did a few (3 or 4), lock/unlock of the screen cycles and touch again started to act strange. In this case, touching the screen worked as if it was a touchpad, so the mouse moved but I could not interact with anything. Not even by tapping the screen could I press buttons, although it would highlight them briefly. running the libinput debug tool, showed input events in this case. And after a bit, touch simply started working again, only to revert to the semi-working state moments later again, and again a bit later it worked again.

I again did a few lock screen/unlock events in a row and after another 4 or so, I got back again in the same semi-working state.

For the moment I still have not figured out how to get it into the state where it stops working completely on command.

any updates here? this is still a bit confusing :)

closing after 4 weeks of silence, please re-open if necessary

Problem has not changed.

Jason, any more comments? This looks like a kernel bug.

Does the following touchscreen firmware update apply to your model of Yoga? It claims to resolve issues that sound similar to what you're experiencing. Unfortunately, it looks like the updater can only be run from within Windows...

Link to touchscreen firmware update thread (forgot to add to prior comment):

https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X1-Yoga-Type-20FQ-and-20FR-Touchscreen-Firmware/td-p/3345624

Thanks!

I have done the firmware update, and have tried to trigger the failure, and so far have not been able to. I put the system to sleep several times and so far, each time the touchscreen and pen input worked afterwards.

Let me give it a few days, but it seems that may have fixed it :-)

Closing as resolved as I have not been able to trigger the failure since doing the firmware update.