can you check the valuator mode and apply the required bits for absolute devices? it's not always correct since abs devices may send rel events, but we can try to do the right thing by default and leave the outliers to set the matrix by hand.

(In reply to comment #1)
> can you check the valuator mode and apply the required bits for absolute
> devices? it's not always correct since abs devices may send rel events
Well, actually I found that absolute devices require also a proper scaling and translation components of the matrix.
Usually one rotate an absolute device like a tablet in order to match the screen, and this use case is already covered by the "map-to-output" option.

> but we can try to do the right thing by default and leave the outliers to set
> the matrix by hand.
The "rotate" option included in my patch just disallow to set axes rotation to absolute devices exactly for this reason.
In fact, it makes sense to have axes rotation for a relative devices, but one is free to do the same to an absolute device by manually setting the matrix.

(In reply to comment #2)
> Well, actually I found that absolute devices require also a proper scaling
> and translation components of the matrix.
> Usually one rotate an absolute device like a tablet in order to match the
> screen, and this use case is already covered by the "map-to-output" option.

some touchscreens are mounted upside-down, for those the use of rotation-only is beneficial. note that rotation on an absolute device simply requires translation because the rotation point is the origin, thus a rotation by 180 degrees without offset would map x to [-width, 0]. that's without any specific monitor binding, that's just part of how the matrix is used

(In reply to comment #3)
> some touchscreens are mounted upside-down, for those the use of
> rotation-only is beneficial. note that rotation on an absolute device simply
> requires translation because the rotation point is the origin, thus a
> rotation by 180 degrees without offset would map x to [-width, 0]. that's
> without any specific monitor binding, that's just part of how the matrix is
> used
This is true only in the particular case of absolute movements and +/-180 degrees rotation.
How to handle other cases, say 90 or even 32 degrees? Should we start to fill the code with if/switch statements? I think it is better to do not add more complexity than it is really needed.

In my opinion the most general case is to support only relative movements.
For any other outlier case one can directly use the matrix.
Well, we can also say that the rotation itself is not the general case, discard this patch and tell users to directly use the matrix. It's fine too.

Please remind that the "mouse" driver has the AngleOffset option that is not present in evdev (https://bugs.freedesktop.org/show_bug.cgi?id=27688).
This patch is just meant to reproduce that behaviour with xinput in a user-friendly way.

(In reply to comment #4)
> (In reply to comment #3)
> > some touchscreens are mounted upside-down, for those the use of
> > rotation-only is beneficial. note that rotation on an absolute device simply
> > requires translation because the rotation point is the origin, thus a
> > rotation by 180 degrees without offset would map x to [-width, 0]. that's
> > without any specific monitor binding, that's just part of how the matrix is
> > used
> This is true only in the particular case of absolute movements and +/-180
> degrees rotation.
> How to handle other cases, say 90 or even 32 degrees? Should we start to
> fill the code with if/switch statements? I think it is better to do not add
> more complexity than it is really needed.

I want at least the 90 degree cases covered for abs devices. I don't think other angles make much sense anyway here. for all other rotations we can provide an error message if the code turns out too complex.
for rel devices having any degree of rotation is good to have.

> In my opinion the most general case is to support only relative movements.

fwiw, graphics tablets are absolute and a good example for rotation on abs devices. all graphics tablet devices would benefit by rotation.

I tried your patch on top of xinput as included in Wheezy. It builds fine, but there is zero effect. Using something like "xinput --rotate 9 180" doesn't rotate anything.

Did I miss something here?

(In reply to comment #6)
> I tried your patch on top of xinput as included in Wheezy. It builds fine,
> but there is zero effect. Using something like "xinput --rotate 9 180"
> doesn't rotate anything.
> 
> Did I miss something here?
You're not, it's Wheezy that is missing something :)

As written here https://bugs.freedesktop.org/show_bug.cgi?id=27688#c33 the rotation is included in server 1.14 and Wheezy still has the 1.12 (see http://packages.debian.org/search?suite=wheezy&keywords=xserver-xorg-core).

I am using Sid and I'm waiting for new the packages too, it seems they are in experimental (upgrading Xorg is a delicate issue and Debian is known to be quite conservative to such kind of changes).

Thanx for the update.

I really liked the AxesRotation patch for evdev. It was an easy fix affecting just a minimum of code, to be configured on a central place where all the other config options are, too. 

Now the server has to support it, an up-to-date user space tool is needed, _and_ the user has to know about the rotation. Usually the freedesktop.org developers put so much effort upon ease of use and not confusing the user. I wonder how this fits together.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/app/xinput/issues/2.