Summary: | Cannot rotate input touchscreen with Xorg + libinput | ||
---|---|---|---|
Product: | Wayland | Reporter: | Éric Brunet <eric.brunet> |
Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | peter.hutterer |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Updating of the man page of xf86-input-libinput. |
Description
Éric Brunet
2015-04-13 07:47:26 UTC
the coordinate transformation matrix is what you want, but when you rotate you also need to take the offset after rotation into account. https://wiki.ubuntu.com/X/InputCoordinateTransformation is the first link I found here. Created attachment 115125 [details] [review] Updating of the man page of xf86-input-libinput. Ho... Thanks for the link! I have been doing too much math lately. I saw a 3x3 matrix called InputCoordinateTransformation, and I thought (without checking, my bad) that it was transforming 3D coordinates (x,y,z) => (x',y',z') = M (x,y,z) in anticipation of future fancy input methods... The transformation is instead (x,y) => (x',y') = M (x,y) + (x0,y0) I think I would have guessed if the matrix had been 3x2 instead of 3x3, and I am still confused about the meaning of the third row, but at least I can now rotate my screen as I want. May I suggest updating the man page of the xf86 libinput driver to explain this? The interface is neither intuitive nor user-friendly, and documentation is always good. I am attaching a patch to this effect. tbh I'd prefer to have this in the xserver documentation somewhere (we used to have a wiki page for this that then disappeared during a wiki migration). we should restore the wiki page and then link to it from a man page, I'd prefer not to have these as driver-specific man page entries. Yes logically speaking, as it is a property from the X server, it should maybe be in xorg.conf. On the other hand, redundancy in documentation is good. As a user, I have learned how to rotate in "man evdev", and in "man wacom", I expected to learn how to rotate in "man libinput"; I filled a bug when I didn't find the info! By the way, out of curiosity, I looked in libinput source at the explanations in function evdev_device_calibrate. From what I could make out, the "Coordinate Transformation Matrix" and the "libinput Calibration Matrix" both do exactly the same thing. Shouldn't one of them be removed while libinput is still in development and the ABI is not completely frozen ? (In reply to Éric Brunet from comment #4) > Yes logically speaking, as it is a property from the X server, it should > maybe be in xorg.conf. On the other hand, redundancy in documentation is > good. As a user, I have learned how to rotate in "man evdev", and in "man > wacom", I expected to learn how to rotate in "man libinput"; I filled a bug > when I didn't find the info! redundancy also means that there's at least one more space where the documentation is likely out of date :) no problem pointing to the authoritative source from libinput, etc. but imo there should only be one real documentation. > By the way, out of curiosity, I looked in libinput source at the > explanations in function evdev_device_calibrate. From what I could make out, > the "Coordinate Transformation Matrix" and the "libinput Calibration Matrix" > both do exactly the same thing. Shouldn't one of them be removed while > libinput is still in development and the ABI is not completely frozen ? not quite. The libinput matrix is relative to the device range, the X server one is relative to the screen size. you can use the x server one to map a device to one of two monitors, you can use the libinput one only for e.g. turning a device upside-down. generally, the libinput matrix is supposed to undo hw oddities, not for screen mapping (because libinput doesn't have screen mappings). http://wayland.freedesktop.org/libinput/doc/latest/absolute_axes.html |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.