Hi!
On Tue, Jul 26, 2022 at 01:58:24PM -0400, Stefan Hansson wrote:
> Hi again!
>
> On 2022-07-25 18:48, José Expósito wrote:
> > Hi everyone,
> >
> > On Sun, Jul 24, 2022 at 01:48:49PM +0200, José Expósito wrote:
> >
> > [...]
> >
> > The first bad commit is 87562fcd1342 ("HID: input: remove the need for
> > HID_QUIRK_INVERT"):
> > https://lore.kernel.org/all/20220203143226.4023622-11-benjamin.tissoires@xxxxxxxxxx/
> > (CCing the folks whose email is in the patch tags)
> >
> > I reverted the patch on hid/for-next and, after fixing a tiny conflict,
> > I can confirm that the tablet works again as expected.
>
> Thanks for looking into this! Bisecting has been slow on my end
> unfortunately. I built today's linux-next (20220726) with your proposed
> patch below and my drawing tablet curiously still does not work as expected.
> The stylus works a couple of times, but eventually stops working (unlike
> prior where it always seemed to only work once). Do I need both your revert
> and this diff for it to work properly?
You are right, I just tested for a while with the diff applied (without
reverting the commit causing the issue) and after putting the pen in
and out proximity a fair amount of times (> 100) it stopped working.
I added some logs with the hope that they help to understand the issue:
Once the stylus stops working, hidinput_hid_event() is called with a
usage->hid of HID_DG_TIPSWITCH.
Next, it gets called again with HID_DG_INRANGE. At this point
report->tool_active and report->tool evaluate to true, i.e.,
hid_report_set_tool() is not invoked.
This succession of HID_DG_TIPSWITCH + HID_DG_INRANGE is repeated while
the stylus is in range and the tool used is never reported to user
space. In other words, using "libinput record" I can see ABS_* events
but without a leading and trailing BTN_TOOL_PEN event.
Notice that when the stylus works, report->tool evaluates to false and
hid_report_set_tool(), which calls hid_report_release_tool(), is
invoked.
> Also, do you know whether the revert be backported to stable 5.18?
Let's wait for Benjamin's opinion. I don't think that reverting the
commit is the best option in this case. While checking Benjamin's
series I remembered this libinput MR:
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/724
And I think they are related. Ideally we'd like to keep that fix.
Usually, these kind of patches get backported eventually. I'm afraid I
can not tell you if it'd be the case this time.
Jose
