On a fedora 21 with xorg-x11-server-Xorg-1.16.3 and xorg-x11-drv-libinput-0.8.0-2.fc23.x86_64 (this is the rawhide version, not the fc21) I compiled my own libinput from the git version to give it a try and I let libinput manage my touchscreen (HP EliteBook Revolve 810) It works great, except that when I rotate the screen with xrandr, there does not seem to be any way to rotate the input coordinates of the touchscreen. When using evdev, one had to play with the properties Evdev Axis Inversion (280): 0, 0 Evdev Axes Swap (282): 0 When using wacom, you have the property "Wacom Rotation" to play with. But with libinput, I only have Device 'Atmel Atmel maXTouch Digitizer': Device Enabled (139): 1 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Calibration Matrix (276): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Send Events Modes Available (260): 1, 0 libinput Send Events Mode Enabled (261): 0, 0 Device Node (262): "/dev/input/event8" Device Product ID (263): 1003, 33803 I tried to play with the "Coordinate Transformation Matrix", but it doesn't seem possible: the correct setting would be the matrix 0 1 0 -1 0 0 0 0 1, where I had hopes the -1 would be interpreted as an axis inversion; unfortunately it is not the case. Did I miss something, or is there no way to rotate the input coordinates ?
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.