Unexpected (WW) stylus(0) a base pressure of 0 persists while the pen is in proximity

[Pinglinux]

While testing my fix to the (EE) message of #186, I encountered the following (WW), only once though:

[ 10299.002] (WW) On Wacom Co.,Ltd. Pen and multitouch sensor stylus(0) a base pressure of 0 persists while the pen is in proximity.
    This is > 20 percent of the maximum value (4095).
    This indicates a worn out pen, it is time to change your tool. Also see:
    https://github.com/linuxwacom/xf86-input-wacom/wiki/Pen-Wear.

It happened when the device was driven by hid-generic driver. @whot do you have any ideas? The code involved is in xf86-input-wacom/src/wcmCommon.c:

        if (priv->oldMinPressure > pressureThreshold &&
            priv->eventCnt > MIN_EVENT_COUNT)
            wcmLogSafe(priv, W_WARNING,
                "On %s(%u) a base pressure of %d persists while the pen is in proximity.\n"
                "\tThis is > %d percent of the maximum value (%d).\n"
                "\tThis indicates a worn out pen, it is time to change your tool. Also see:\n"
                "\thttps://github.com/linuxwacom/xf86-input-wacom/wiki/Pen-Wear.\n",
                priv->name, priv->serial, priv->minPressure, LIMIT_LOW_PRESSURE, common->wcmMaxZ);

I feel it has something to do with priv->eventCnt > MIN_EVENT_COUNT.

[whot]

I think this message needs to get fixed because it doesn't actually tell us the problem: we check wcmOldMinPressure but print minPressure (which is zero here).

Without that, it's hard to guess but: this is the device that switches between the tools, right? Does the kernel reset ABS_PRESSURE when this happens (easy to verify with libinput record). If the pressure never gets reset to zero between BTN_TOOL_PEN 0 and BTN_TOOL_RUBBER 1, the pen will leave proximity with the current pressure. This looks to the driver like the pen is worn out. So a sequence like this would trigger it, I think:

ABS_PRESSURE 1234
BTN_TOOL_PEN 1
--- SYN_REPORT ---
# now press eraser button
---
BTN_TOOL_PEN 0
--- SYN_REPORT ---
BTN_TOOL_RUBBER 1
--- SYN_REPORT ---
# oops, ABS_PRESSURE is still on 1234

likewise, libinput (which detects this on prox in, not prox out) would probably complain the same about the eraser coming in with pre-loaded pressure.

[Pinglinux]

Yes, it's the device that reports invert usage by a side-switch.The hid-generic driver indeed DOES NOT reset pressure to 0. But, for hid-generic driver, it has a valid reason: when tool type switches, the tip could still be on the tablet, which means the initial pressure is a "large" number. Do we have an intelligent solution in the X driver/libinput for this case, without asking hid-generic to set it to 0 for us?

[Pinglinux]

@whot how do we retrieve serial number? In usbInitialize() of wcmUSB.c we retrieve the initial values for almost all events. But, we didn't retrieve MSC_SERIAL. I can't find a EVIOCG in include/uapi/linux/input.h for MSC_SERIAL. Any hint?

[whot]

we just handle MSC_SERIAL when it comes in. it's guaranteed to come in the first event (or for AES: one of the first events) anyway, so iirc we hold the event stream back until we have it. drivers/input/input.c:input_get_disposition() doesn't check the value so unlike EV_ABS and others it's always passed to userspace, even when the value doesn't change. So unlike the EV_ABS events, we don't need to fetch the state since we're guaranteed to get it.

And that state check is only for the initial setup anyway, once we have the fd we can cache it ourselves anyway.

r. Do we have an intelligent solution in the X driver/libinput for this case, without asking hid-generic to set it to 0 for us?

I haven't looked into it yet, but we'll just have to put sufficient heuristics in place, I guess. That wacom always resets to 0 on a legal proximity out should help, we can use that as a flag to check whether we need to trigger the worn-out check.

Oh, and I'll really need some libinput record for this device, very soon. It'll be a lot easier to reproduce this if we have reliable reproducers.

[Pinglinux]

With the hid-generic driver in kernel 5.18+, the reported issue doesn't show up any more. However, another log message showed up when I didn't even press the side-switch/eraser:

[ 1574.732] (EE) WCOM4900:00 056A:4900 Stylus eraser: usbParse: Ignoring event from invalid serial 0

I am looking into the root cause...

[whot]

More for the archives: libinput has the code for the delayed serial numbers since https://bugs.freedesktop.org/show_bug.cgi?id=97526. Which isn't the same as the old kernel driver holding back the events but it's a start.

For this driver, it's best to file a separate bug with this issue so we can handle it there - with a libinput record of an event sequence please!

[Pinglinux]

I see how you worked around the issue in libinput, with the assumption that there is only one tool on the tablet at a time. Historically, X driver checks for serial number and made sure it is not 0 if the firmware claimed to report serial number. I'll open another issue and figure out a way to get rid of the useless (EE) message.