Re: [PATCH v11 1/4] HID: wacom_sys: Add support for flipping the data values

On Wed, Oct 20, 2021 at 5:40 PM Benjamin Tissoires
[off-list ref] wrote:

On Wed, Oct 20, 2021 at 4:14 AM Dmitry Torokhov
[off-list ref] wrote:

quoted

On Wed, Oct 20, 2021 at 11:44:50AM +1000, Alistair Francis wrote:

quoted

On Wed, Oct 20, 2021 at 11:05 AM Dmitry Torokhov
[off-list ref] wrote:

quoted

On Wed, Oct 20, 2021 at 09:33:13AM +1000, Alistair Francis wrote:

quoted

On Tue, Oct 19, 2021 at 11:51 AM Dmitry Torokhov
[off-list ref] wrote:

quoted

We already have touchscreen-inverted-x/y defined in
Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml,
why are they not sufficient?

The touchscreen-* properties aren't applied to HID devices though, at
least not that I can tell.

No, they are not currently, but that does not mean we need to establish
a new set of properties (property names) for HID case.

I can update the names to use the existing touchscreen ones.

Do you have a hint of where this should be implemented though?

Right now (without "HID: wacom: Add support for the AG14 Wacom
device") the wacom touchscreen is just registered as a generic HID
device. I don't see any good place in hid-core, hid-input or
hid-generic to invert the input values for this.

I think the transformation should happen in
hid-multitouch.c::mt_process_slot() using helpers from
include/linux/input/touchscreen.h

I think the more challenging question is to how pass/attach struct
touchscreen_properties * to the hid device (i expect the properties will
be attached to i2c-hid device, but maybe we could create a sub-node of
it and attach properties there.

Sorry but I don't like that very much. This would mean that we have an
out of band information that needs to be carried over to
HID-generic/multitouch and having tests for it is going to be harder.
I would rather have userspace deal with the rotation if we do not have
the information from the device itself.

My 2c below

Foreword: I have been given a hammer, so I see nails everywhere.

The past 3 weeks I have been working on implementing some eBPF hooks
in the HID subsystem. This would IMO be the best solution here: a udev
hwdb rule sees that there is the not-wacom PID/VID (and maybe the
platform or parses the OF properties if they are available in the

I'm not sure we have a specific VID/PID to work with here. The VID is
generic AFAIK, not sure about the PID though. Maybe someone from Wacom
could confirm either way.

sysfs) and adds a couple of functions in the HID stack to rotate the
screen. The advantage is that we do not need to add a new kernel API

I would say that touchscreen-inverted-x/y isn't a new API, it's
commonly used. To me it makes sense that it's supported for all
touchscreens.

anymore, the disadvantage is that we need userspace to "fix" the
kernel behaviour (so at boot, this might be an issue).

That's a pain for me. I'm still stuck with the vendors userspace as I
need their propiritory eInk driver code. It also seems like a hassle
for different distros to handle this (compared to just in the DT).

Alistair

I am not at the point where I can share the code as there is a lot of
rewriting and my last attempt is resulting in a page fault, but I'd be
happy to share it more once that hiccup is solved.

Cheers,
Benjamin