Stylus clicks are not recognised by some software

I hope I am at the right place since I literally have no clue on what might be the reason for this:

Some software such as the Teamviewer remote support software v15.25 and up (https://community.teamviewer.com/English/discussion/122230/linux-downgrade-to-version-15-27-3) and the - completely unrelated - Ultimaker Cura 3D slicer software seemingly since version 5.0 (https://github.com/Ultimaker/Cura/issues/12554, https://github.com/Ultimaker/Cura/issues/13707 and some others) does not recognise any click events that originate from the Wacom stylus.

Other software works perfectly fine at the same moment.

My setup is a Wacom PTH-651 on Linux Mint 21.1 with the standard Wacom driver provided by the system (currently 1:1.0.0-3ubuntu1) - the problem however survived two system upgrades since Linux Mint 20 when I updated to the mentioned Teamviewer version. Since other people are affected as well, I assume this is nothing specific to Linux Mint alone.

The PTH-651 also has Multitouch capabilities. If I use that and tap with a finger instead of the stylus, clicks are recognised correctly in both programs.

The only issue here I found that seemed to remtoly fit to my problem suggested to set the gesture parameter to "off" - but that is already the case on my computer.

Any hints on what to check or do to narrow down or maybe even solve this problem are highly appreciated.

As a general rule: if an issue is only visible in one (or some specific) applications, it's not the driver since the driver has no clue if any application is even running - it just passes on events regardless and where those events are delivered is up to the X server.

So this is some event sequence that's disliked by those particular applications. A good start would be to check what actual events are submitted by the driver for a click event - the best/only way to do this is to run xinput test-xi2 and click into that window.

If you have the git repo, you can build with the gwacom helper library enabled (see meson.build and the dependencies needed for build_gwacom) - that will give you builddir/wacom-record which records events from the driver but prints them instead of passing them to the X driver (only an approximage description). The output of that would be useful to see if there's anything specifically amiss - digging through xi2 output is hard.

I stuck with the xinput test-xi2 command for now. This is what I got:

A click with multitouch (finger) which is detected by the program:

EVENT type 15 (RawButtonPress)
    device: 2 (10)
    detail: 1
    flags: 
    valuators:

EVENT type 16 (RawButtonRelease)
    device: 2 (10)
    detail: 1
    flags: 
    valuators:

A click with the pen yielded the following results:

Pen vertically dropped some centimeters onto the tablet surface with the hand kept at a distance to minimise any disturbances (ignored by the program):

EVENT type 15 (RawButtonPress)
    device: 2 (8)
    detail: 1
    flags: 
    valuators:
          0: 16324.00 (16324.00)
          1: 15667.00 (15667.00)
          2: 42964.00 (42964.00)
          3: 0.00 (0.00)
          4: 4.00 (4.00)
          5: -900.00 (-900.00)

--------- numerous EVENT type 17 (RawMotion) events ----------

EVENT type 16 (RawButtonRelease)
    device: 2 (8)
    detail: 1
    flags: 
    valuators:
          0: 15986.00 (15986.00)
          1: 15339.00 (15339.00)
          2: 0.00 (0.00)
          3: 0.00 (0.00)
          4: 2.00 (2.00)
          5: -900.00 (-900.00)

And the same thing done with a mouse with deliberate motion while pressing the button to simulate pen behaviour (again, detected by the program):

EVENT type 15 (RawButtonPress)
    device: 2 (16)
    detail: 1
    flags: 
    valuators:

--------- numerous EVENT type 17 (RawMotion) events ----------

EVENT type 16 (RawButtonRelease)
    device: 2 (16)
    detail: 1
    flags: 
    valuators:

This tells me the events are there, but the software either fails due to the speed of the motion events in between or (I guess more likely) due to the valuators... I will tell this to the program developers. Thank you very much!

Just one more question: is it possible to remove the valuators from the pen ButtonPress/Release events by changing driver parameters in order to simulate a "mouse click" event? Then I could confirm what I suspect.

Mini XI2 primer: "raw" events are those submitted from the driver and sent directly to the root window. If you click in the test-xi2 window (the little white one with the black square) and you are not getting any normal non-raw events, that means that something has a grab of your device and the normal events aren't delivered to the application as they should be.

IOW, getting raw events means the device works and all buttons/axes seem to be correct (from a quick glance), so we can mostly rule out a driver issue. If you're not getting the normal events as well, then the issue is either in the server, or with whatever has a grab on your device.

is it possible to remove the valuators from the pen ButtonPress/Release events by changing driver parameters in order to simulate a "mouse click" event? Then I could confirm what I suspect.

Not easily, no. [1] Though, I vaguely remember always sending a motion event before button events if the position changed, because this was a bug 15 years ago. But I cannot remember if that was a driver thing or a server thing (reading through fill_pointer_events in xserver/dix/getevents.c to check if it's done there might help).

But either way - first order of the day: check if you get normal events from test-xi2.

[1] maybe, and this is a big maybe, if you set the Suppress value to something ridiculously high.

Mini XI2 primer: "raw" events are those submitted from the driver and sent directly to the root window. If you click in the test-xi2 window (the little white one with the black square) and you are not getting any normal non-raw events, that means that something has a grab of your device and the normal events aren't delivered to the application as they should be.

IOW, getting raw events means the device works and all buttons/axes seem to be correct (from a quick glance), so we can mostly rule out a driver issue. If you're not getting the normal events as well, then the issue is either in the server, or with whatever has a grab on your device.

Thanks for the explanation! Until now, I never cared about the depths behind my mouse pointer ;-) But yes, that works - I get normal events in addition to the raw events if I click into the window:

EVENT type 15 (RawButtonPress)
    device: 2 (8)
    detail: 1
    flags: 
    valuators:
          0: 28385.00 (28385.00)
          1: 4290.00 (4290.00)
          2: 20457.00 (20457.00)
          3: 20.00 (20.00)
          4: 26.00 (26.00)
          5: -900.00 (-900.00)

EVENT type 4 (ButtonPress)
    device: 8 (8)
    detail: 1
    flags: 
    root: 2438.17/221.09
    event: 100.17/81.09
    buttons:
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 28385.00
        1: 4290.00
        2: 20457.00
        3: 20.00
        4: 26.00
        5: -900.00
    windows: root 0x1e0 event 0x7400001 child 0x0

EVENT type 9 (FocusIn)
    device: 3 (3)
    windows: root 0x1e0 event 0x7400001 child 0x0
    mode: NotifyNormal (detail NotifyNonlinear)
    flags:  [same screen]
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  2438.00 / 221.00
    event x/y: 100.00 / 81.00

EVENT type 4 (ButtonPress)
    device: 2 (8)
    detail: 1
    flags: 
    root: 2438.17/221.09
    event: 100.17/81.09
    buttons:
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 28385.00
        1: 4290.00
        2: 20457.00
        3: 20.00
        4: 26.00
        5: -900.00
    windows: root 0x1e0 event 0x7400001 child 0x0

EVENT type 17 (RawMotion)
    device: 2 (8)
    detail: 0
    flags: 
    valuators:
          0: 28382.00 (28382.00)
          1: 4289.00 (4289.00)
          2: 27405.00 (27405.00)
          3: 19.00 (19.00)
          4: 26.00 (26.00)
          5: -900.00 (-900.00)

EVENT type 6 (Motion)
    device: 8 (8)
    detail: 0
    flags: 
    root: 2438.91/221.04
    event: 100.91/81.04
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 28382.00
        1: 4289.00
        2: 27405.00
        3: 19.00
        4: 26.00
        5: -900.00
    windows: root 0x1e0 event 0x7400001 child 0x0

EVENT type 8 (Leave)
    device: 2 (8)
    windows: root 0x1e0 event 0x7400001 child 0x0
    mode: NotifyNormal (detail NotifyInferior)
    flags: [focus] [same screen]
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  2437.00 / 221.00
    event x/y: 99.00 / 81.00

EVENT type 7 (Enter)
    device: 2 (8)
    windows: root 0x1e0 event 0x7400002 child 0x0
    mode: NotifyNormal (detail NotifyAncestor)
    flags: [focus] [same screen]
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  2437.00 / 221.00
    event x/y: 49.00 / 31.00

------- Numerous events of Types EVENT type 6 (Motion) and EVENT type 17 (RawMotion) in between here -------

EVENT type 16 (RawButtonRelease)
    device: 2 (8)
    detail: 1
    flags: 
    valuators:
          0: 28359.00 (28359.00)
          1: 4255.00 (4255.00)
          2: 0.00 (0.00)
          3: 16.00 (16.00)
          4: 28.00 (28.00)
          5: -900.00 (-900.00)

EVENT type 5 (ButtonRelease)
    device: 8 (8)
    detail: 1
    flags: 
    root: 2435.94/219.29
    event: 97.94/79.29
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 28359.00
        1: 4255.00
        2: 0.00
        3: 16.00
        4: 28.00
        5: -900.00
    windows: root 0x1e0 event 0x7400001 child 0x7400002

EVENT type 5 (ButtonRelease)
    device: 2 (8)
    detail: 1
    flags: 
    root: 2435.94/219.29
    event: 97.94/79.29
    buttons: 1
    modifiers: locked 0x10 latched 0 base 0 effective: 0x10
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
        0: 28359.00
        1: 4255.00
        2: 0.00
        3: 16.00
        4: 28.00
        5: -900.00
    windows: root 0x1e0 event 0x7400001 child 0x7400002

EVENT type 8 (Leave)
    device: 2 (2)
    windows: root 0x1e0 event 0x7400001 child 0x0
    mode: NotifyUngrab (detail NotifyInferior)
    flags: [focus] [same screen]
    buttons:
    modifiers: locked 0x10 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  2435.00 / 219.00
    event x/y: 97.00 / 79.00

is it possible to remove the valuators from the pen ButtonPress/Release events by changing driver parameters in order to simulate a "mouse click" event? Then I could confirm what I suspect.

Not easily, no. [1] Though, I vaguely remember always sending a motion event before button events if the position changed, because this was a bug 15 years ago. But I cannot remember if that was a driver thing or a server thing (reading through fill_pointer_events in xserver/dix/getevents.c to check if it's done there might help).

But either way - first order of the day: check if you get normal events from test-xi2.

[1] maybe, and this is a big maybe, if you set the Suppress value to something ridiculously high.

No, that does not work - it dampens motion significantly (feels a bit like an Atari ST mouse on a big TV set...) and reduces the motion events - but the additional valutators within the ButtonPress/Release events are still there - and these are the ones I guess might produce the problems, not the motion events. My guess is the driver would need to discard the pen pressure results transmitted by the tablet, handling the click taps purely as a "mouse click" as a result.

Then I fear I need to hope that the program developers can find something based on my information...

The root cause is in the app. It doesn't recognize/process pen pressure. That is, the app is not pen-enabled.

linuxwacom / xf86-input-wacom

Stylus clicks are not recognised by some software #304