On Wed, Oct 20, 2021 at 4:14 AM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > On Wed, Oct 20, 2021 at 11:44:50AM +1000, Alistair Francis wrote: > > On Wed, Oct 20, 2021 at 11:05 AM Dmitry Torokhov > > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > > > On Wed, Oct 20, 2021 at 09:33:13AM +1000, Alistair Francis wrote: > > > > On Tue, Oct 19, 2021 at 11:51 AM Dmitry Torokhov > > > > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > > > > > > > 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. 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 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 anymore, the disadvantage is that we need userspace to "fix" the kernel behaviour (so at boot, this might be an issue). 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
