#339 Lenovo pen upper side button state not tracked out of prox

[Denis Auroux]

As initially reported in the discussion of #327: the Lenovo Thinkpad Pen Pro (AES pen)'s upper side button (which is mapped to stylus button 2, while the lower side button maps to the eraser device button 1) doesn't keep track of its state while out of proximity: pressing it out of proximity, or keeping it pressed while moving out of proximity and back in, does not result in a button 2 event as expected, instead generates a button 1 (pen tip) event upon contact with the screen.

What is surprising is that the lower side button (= eraser tool) does not suffer from this amnesia and works fine out of proximity.

Attached log (with TabletPCButton on).

Denis

[Jason Gerecke]

Again, thanks for the quick reply :) It looks like when the pen enters proximity with the side switch pressed, the "BTN_STYLUS" event (which represent that switch's state) is being sent before we get an MSC_SERIAL event. This could cause problems since our driver tries to associate pen state with serial numbers (since some old/exotic devices can have multiple tools in proximity at the same time).

I'm guessing what happens is that our driver stores the fact that the switch is pressed in a tool slot which has no serial number. Later events (such as the BTN_TOUCH event that is sent when the tip contacts the screen) are stored in a tool slot whose serial number is MSC_SERIAL. Since the state of the side switch isn't stored in the latter's slot, the X driver doesn't send a right-click event when expected. (Eraser state is handled by the X driver a bit differently so it wouldn't be too surprising if it isn't affected).

Fixing this might be done by haivng the kernel driver not send any event until it has the pen's serial number. There's a chance this might not be possible though -- I seem to remember that we ran into a different bug that could have been solved the same way but that I had to go a different route for some reason...

[Jason Gerecke]

I've created a modification to xf86-input-wacom which I believe fixes this issue. Please install the build preqrequisites outlined in the "Building From Source" section of our instructions for compiling & installing xf86-input-wacom.

Once the prerequisites have been installed, use the following instructions rather than those provided in the guide:

1. Run git clone https://github.com/jigpu/xf86-input-wacom -b fix-bug-339 to checkout a copy of the modified code
2. Run cd xf86-input-wacom to enter the source directory
3. Run ./autogen.sh --prefix=/usr && make && sudo make install

If all goes well, the updated driver should be installed and you can reboot to test to see if it fixes your issue.

[Denis Auroux]

Sorry for the long delay. I can confirm that the patch does fix this bug for me (Lenovo X1 Yoga 2nd gen, "AES" pen). The upper side button is now in the correct state when the pen re-enters proximity. Thanks a lot!!

As far as I can tell this helps partially with #338 but not completely: I don't seem to get any erroneous button press events when the stylus is still hovering (though I will need to test over time); but the first few coordinates of every stroke still suffer from a lot of parallax, the problem being worse when RawSample is larger.

Denis

[Jason Gerecke]

Awesome, thanks for the report back. I should send this patch off to the list tonight or tomorrow for review and it will hopefully make it into the next xf86-input-wacom release.

[Denis Auroux]

Hmm, not so fast... the touch device now seems to behave erratically -- sometimes works, sometimes sends only button press and release events but not motion events when moving the finger on the screen. I should try to check whether this is caused by the patch or by other system updates.

[Denis Auroux]

The patched driver causes the touchscreen to work properly at startup, but to mostly cease functioning after the first multi-touch hit on the screen (which gets somehow converted to a button 5 or something like that -- scroll event maybe? -- xinput test <...> lists things like

button press 5
button release 5
key release 37
key press 37

and after that point I might get some button press/release events but no motion events at all from the touchscreen, or just nothing at all anymore. I've sometimes seen it come back to life briefly upon some other multi-finger touch that seems to unfreeze it, but usually the touch device is pretty much dead until the next X server restart.

Attaching 3 xorg.0.logs from ToolDebugLevel = TabletDebugLevel = 10 on the touch device. Each corresponds to touching the screen once with a single finger and sliding across in one continuous motion then releasing.

LOG-TOUCH-0.34.2-WORKING = standard 0.34.2 as packaged by Fedora 26
LOG-TOUCH-PATCHED-WORKING = initial behavior with patch -- touch works ok
LOG-TOUCH-PATCHED-BROKEN = after a multi-finger touch, broken state -- events come in from the USB device but don't get dispatched to X.

Denis

[Jason Gerecke]

I can confirm these pointer freezes on my own system. It looks like the modifications I made end up being applied to touches as well, causing the driver to get confused about which touches control which channel. I've pushed some changes that should fix this to the fix-bug-339 branch. Run git remote update; git checkout fix-bug-339; git pull to get the latest code and then rebuild/reinstall. I've also included a version of your reset fix from bug #338, so that issue should go away too.

Let me know if this works any better.

Also just a note to my future self (I'm out on vacation next week...): I can reproduce similar symptoms even with this fix in place or with the 0.34.2 package installed. I believe its related to the driver improperly setting an out-of-prox channels as in-prox if a particularly pathological event sequence occurs. Commenting out the line ds->proximity = 1; on line 1761 of src/wcmUSB.c seems to fix this, but I think that line might be necessary for allowing tools to work which were in prox prior to the server starting.

[Denis Auroux]

Thanks! The new version works much better -- doesn't freeze the touchscreen all the time, and does fix this bug (the upper side button state).

(Disclaimer: after a lot of random whole-hand touching, I did get the touchscreen to freeze once, but it took quite a bit of malicious effort, and I seem to recall the standard 0.34.2 isn't completely immune either; so I think the new fix-bug-339 patch is ok).

Regarding whether this addresses #338: the random button presses without hitting the screen with the stylus seem to be gone; but the position of the button press event is still wrong when RawSample > 1; the behavior with RawSample=1 is good. Since this remaining issue is in #338, I'll continue the discussion there. Meanwhile, thanks for fixing this one!

Denis

[Mario Botsch]

Thanks a lot to Jason and Denis to fixing bugs #338 and #339 to actively. I have a Thinkpad X1 Yoga (2nd gen) and had exactly those two problems.

With the branch fix-bug-339 the random clicks (#338) are gone and it seems to fix #339, too. However, the freezes of the touchscreen do still happen. It is rare and hard to reproduce, but during a 1h presentation (which I have to do regularly) the touchscreen will freeze very likely. Any idea what I could try? Any way to reset the driver without restarting X?

Thanks a lot in advance!

Mario

[Jason Gerecke]

Sorry for the delay in replying, Mario. I've been working on a number of things, including an alternative to the "fix-bug-339" branch that I'd like you to test out (details in bug #338).

Pinpointing and fixing the cause of your touchscreen issue would be ideal, but in the meantime you might have luck with reloading the kernel driver. Try running sudo modprobe -r wacom && sudo modprobe wacom when the touchscreen freezes next time. Its possible that the freeze is due to something within X itself getting confused, in which case reloading the kernel module won't help, but it may resolve a kernel or hardware issue. There's not really any way that I'm aware of to reload the X driver without completely restarting X.

[Jason Gerecke]

This bug (eraser state not being properly tracked) should be fixed in input-wacom 0.38.0 by commit 829537bcc8b40838a4bb5b1f265d40545cb7958d. It should be fixed in the upstream Linux kernel by commit 8341720642 which is expected to be part of Linux 4.16.

Please let us know if the bug persists. For other issues, please file a new bug.