Phantom touches on HP Elite x2 1012 G2

[kaat]

I installed Ubuntu 18.04 on this tablet. It has following devices:

>xinput
   ↳ Wacom HID 485E Pen stylus               	id=10	[slave  pointer  (2)]
   ↳ Wacom HID 485E Finger touch             	id=11	[slave  pointer  (2)]
   ↳ Wacom HID 485E Pen eraser               	id=17	[slave  pointer  (2)]

I tested the pen in Windows 10. The tip works as button 1. Button 3 switches pen to eraser mode while pressed. Button 2 works as right mouse button, but not by itself. I need to hold the button then touch the screen, it is registered as a click. In Ubuntu holding button 3 makes the system get events from Wacom HID 485E Pen eraser device.

Before further testing I issued these commands to terminal, with them I can see a reaction to pressing button 2 in different programs:

# button 2 is the second button from the the tip
xsetwacom set "Wacom HID 485E Pen stylus" "Button" "2" "button +3 "
# button 3 activates eraser and doesn't work by itself,
# it is the first button from the tip
xsetwacom set "Wacom HID 485E Pen stylus" "Button" "3" "button +0 "
# button 8 doesn't work or doesn't exist
xsetwacom set "Wacom HID 485E Pen stylus" "Button" "8" "button +0 "

Next I used the following command to monitor events: >xinput test "Wacom HID 485E Pen stylus"

The first issue is when I only hover the pen near the monitor but do not touch it, the system registers button 1 presses and releases. It may happen for a minute or two, then these button events stops, then it happen again after some time. In Windows I detected no such behavior.

The second issue is when I hold the button 2 and touch the screen I got both button 1 and button 3 events. But I expect only button 3 events:

button press   3 a[0]=17993 a[1]=8808 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18043 a[1]=9301 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button press   1 a[0]=18043 a[1]=9301 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 3 a[0]=18043 a[1]=9301 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18042 a[1]=9327 a[2]=15335 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18040 a[1]=9370 a[2]=25462 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18038 a[1]=9426 a[2]=30706 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18039 a[1]=9549 a[2]=31610 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18042 a[1]=9647 a[2]=31610 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18046 a[1]=9722 a[2]=33346 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18051 a[1]=9786 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 1 a[0]=18051 a[1]=9786 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=18038 a[1]=9704 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 

The third issue is after pressing button 2 and touching the screen the system from time to time begins to register both button 3 and button 1 events when touching the screen. Here is an example, I only touched the screen without pressing any buttons:

button press   3 a[0]=14053 a[1]=8493 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14049 a[1]=8527 a[2]=27122 a[3]=0 a[4]=0 a[5]=-900 
button press   1 a[0]=14049 a[1]=8527 a[2]=27122 a[3]=0 a[4]=0 a[5]=-900 
button release 3 a[0]=14049 a[1]=8527 a[2]=27122 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14049 a[1]=8527 a[2]=22958 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14049 a[1]=8527 a[2]=22170 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14036 a[1]=8540 a[2]=21795 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14024 a[1]=8551 a[2]=20107 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=14009 a[1]=8559 a[2]=17331 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=13994 a[1]=8564 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 1 a[0]=13994 a[1]=8564 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 

I expect only button 1 events in this case. The pen returns to the expected behavior after some time.

Sometimes after holding button 2 and touching the screen another issue appears. Hovering the pen near the screen produces both button 1 and button 3 events, while no button is pressed:

motion a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button press   3 a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button press   1 a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 3 a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 1 a[0]=17906 a[1]=10561 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 

[jigpu]

Thanks for the detailed report. I'll reply to each issue in turn:

The first issue is when I only hover the pen near the monitor but do not touch it, the system registers button 1 presses and releases. It may happen for a minute or two, then these button events stops, then it happen again after some time. In Windows I detected no such behavior.

This could be caused if the pressure sensor in the pen reports a non-zero pressure while hovering above the screen. Its pretty rare but has been known to happen, and if Windows is better at filtering these events then you could potentially see them. Please run my capture.sh script and try to reproduce the issue. If you're able to capture a few random clicks while not touching the screen, attach the generated tarball to this bug for review.

The second issue is when I hold the button 2 and touch the screen I got both button 1 and button 3 events. But I expect only button 3 events: [snipped]

Could you please run xsetwacom get "Wacom HID 485E Pen stylus" TabletPCButton and tell me if it returns "on"? It looks like this is the case, but I need to be sure to properly diagnose what is going on.

The third issue is after pressing button 2 and touching the screen the system from time to time begins to register both button 3 and button 1 events when touching the screen. Here is an example, I only touched the screen without pressing any buttons: [snipped] I expect only button 1 events in this case. The pen returns to the expected behavior after some time.

Sometimes after holding button 2 and touching the screen another issue appears. Hovering the pen near the screen produces both button 1 and button 3 events, while no button is pressed:

These are both generally signs that the X server has become confused about the actual state of the buttons. If the xf86-input-wacom driver is sending button up/down events at the wrong time (which issue 2 seems to indicate) then it is common to see buttons being registered as pressed when they shouldn't be and it can be difficult to get back to a working state (and non-obvious how the working state was re-achieved). Hopefully figuring out the first two issues will fix this as well.

[kaat]

Thank you for your reply. Regarding the settings, I have this: xsetwacom set "Wacom HID 485E Pen stylus" "TabletPCButton" "off" I also attached the rest of settings if you need to check some of them.

xsetwacom_settings.txt

I ran your script and reproduced events. They appeared after I pressed button 2 and touched the screen. For some reason they stopped after I pressed button 3 and touched the screen, looks like switching to eraser mode resets something in the system. I have two captures, the smaller one is with the single hover and the bigger one is with multiple hovers. multiple_hovers.tar.gz one_hover.tar.gz

I couldn't reliably reproduce button 1 events when hovering. I succeeded only once, here is the file with multiple hover events: button_1.tar.gz

[zlinkort]

I am having the same problem as Issue 1 above (phantom touches). I am running Xubuntu 18.04 on a Dell Latitude 3189 laptop along with a Wacom Bamboo Ink Smart Stylus. I was able to capture a few of the events with "xinput test", and it looks like the stylus is registering a button press but without any pressure:

motion a[0]=7427 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=7427 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button press   1 a[0]=7427 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=7427 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
button release 1 a[0]=7427 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=7424 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 
motion a[0]=7421 a[1]=1353 a[2]=0 a[3]=0 a[4]=0 a[5]=-900 

Is there something I can do to fix the issue (perhaps aw a way to ignore button "presses" with 0 pressure), or is it a limitation of the drivers or hardware?

[jigpu]

Apologies for letting this fall through the cracks... I'll take a renewed look at this to see if I can figure out what is going on.

In theory the X driver shouldn't trigger clicks for zero-pressure events. I can't remember off the top of my head if the driver re-scales pressure values so that anything below/at the click threshold is reported as '0', however. If the driver doesn't re-scale, then that would indicate that something is causing the driver to send a click even though the threshold hasn't been reached. If the driver does re-scale, then there's a chance that noise from the pressure sensor could occasionally be interpreted as a click -- this is what I suspected in the first paragraph of my previous reply.

[Pinglinux]

If input events were not posted correctly from xinput, we need to test the kernel input events first. The issue could have happened before events reached X driver. Please use one of the tools to test the kernel events first.

[Pinglinux]

Please try a distribution running kernel 5.18 or later. There is a fix for the side switch as an eraser issue in the kernel. Basically, pressure should not be zero when "button 1 pressed" event is posted, whether it is in the kernel or X driver.