Re: [RFC PATCH] HID: wacom: Stop mangling tool IDs

[Peter Hutterer <peter.hutterer@who-t.net>]

On Thu, Sep 05, 2024 at 11:01:58AM +0200, Benjamin Tissoires wrote:
> On Sep 05 2024, Jiri Kosina wrote:
> > On Tue, 3 Sep 2024, Gerecke, Jason wrote:
> > 
> > > From: Jason Gerecke <jason.gerecke@wacom.com>
> > > 
> > > In ancient times, an off-by-one-nybble error resulted in the Wacom
> > > driver sending "mangled" tool IDs to userspace. This mangling behavior
> > > was later enshrined into a function so that devices using the then-new
> > > generic codepath could share the same broken behavior. The mangled IDs
> > > have not historically been a major problem for userspace since few
> > > applications care about the exact numeric value of the IDs. As long as
> > > the IDs were unique it didn't much matter. Some programs (cross-
> > > platform and remote-desktop applications in particular) /do/ rely on
> > > the IDs being correct, however.
> > > 
> > > This patch rids the driver of the mangling behavior.
> > > 
> > > Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> > > References: 493630b20389 ("Input: wacom - fix serial number handling on Cintiq 21UX2")
> > > References: 82527da319ee ("HID: wacom: Read and internally use corrected Intuos tool IDs")
> > > ---
> > > I'd like to get the opinion of the kernel maintainers on making a
> > > change like this at some point in the future. There are _very_ few
> > > userspace uses of these IDs (primarily: drivers, compositors, and
> > > tablet control panels) and my plan is to update those bits and then
> > > give some time for the changes to roll out to users before re-
> > > submitting this for real. I don't expect any kind of breakage since
> > > we'll be taking our time with the rollout and userspace needs to
> > > have handling for "unknown" IDs anyway (since Wacom periodically
> > > releases new pens).
> > 
> > As you are in control of the whole ecosystem anyway (because it's Wacom 
> > specific), I don't see it as particularly problematic.
> > 
> 
> Yeah, same here. And that change doesn't impact the basic functionality
> of the styluses: they'll still be handled properly as pointers, but only
> the configuration panel IIUC. Peter mentioned about some slight
> differences in libinput which shouldn't impact the users as well IIRC.

Assuming libwacom is updated (and used) before this happens in the
kernel, then there won't be a difference in libinput behaviour at all.
And that's the plan for this anyway, have libwacom updated well before
the kernel update ships.

Otherwise, the only difference in libinput will be that it is treated as
an unknown stylus. Those default to capabilities matching the kernel
evdev codes (i.e. "everything") whereas a known stylus will only
initialize capabilities that the stylus actually has. IOW you may get a
libinput_tablet_tool that e.g. claims to support rotation and has a
wheel when it doesn't. Not the end of the world either.

Cheers,
  Peter