Add option to disable input device rotation

[KivApple]

On my Arch Linux you don't need to specify wacom rotation - all works fine without this. I can rotate screen via xrandr and touch works normally. But if I use thinkpad-scripts touch events do not work well - they behave as if the orientation has been changed twice.

I think that should be added to the configuration file as option, which disables the rotation of wacom sensor.

[martin-ueding]

It is interesting that it works directly. Apparently something in your system knows that the devices are physically attached to the screen. I wonder where that knowledge would be.

I can implement such a configuration option in the next days.

[jturner314]

This reminds me a lot of issue #117. (The cause was something modifying the Wacom Rotation property, which conflicted with thinkpad-rotate modifying the Coordinate Transformation Matrix property. We resolved it by always setting Wacom Rotation to 0.)

@KivApple It sounds like Martin is going to add a config option to disable Wacom rotation, but ideally we'd get this working by default. The following information would be helpful to diagnose the root cause of the behavior you're experiencing:

1. the version of thinkpad-scripts you have installed (you can obtain this with pacman -Qi thinkpad-scripts)
2. your desktop environment (Gnome/XFCE/KDE/LXDE/etc.)
3. the output of thinkpad-rotate -vv --force-direction cw and thinkpad-rotate -vv --force-direction normal
4. the output of xinput
5. the output of xinput list-props <id> before rotation and after rotation (where <id> is the ID listed for the touch device in the output of xinput)
6. the contents of your personal config file if you have one (~/.config/thinkpad-scripts/config.ini) and any custom hooks you may have (~/.config/thinkpad-scripts/hooks/*)

@martin-ueding Looking back at issue #117, we talked about using the Wacom Rotation property instead of the Coordinate Transformation Matrix property but decided against it because there were some people using non-Wacom devices. I wonder if we'd be better off using the Wacom Rotation property where it's available, and using the Coordinate Transformation Matrix property otherwise. This may cooperate better with desktop environments.

[KivApple]

1. 4.7.4-1
2. KDE 3, 4, 5. http://pastebin.com/DE7JeGfN 6 . http://pastebin.com/FcX177Gn When I screen rotated touch coordinates translated wrong. If I rotate screen via xrandr I have no problems.

[martin-ueding]

Reading through #117, I have the impression that we reset the Wacom rotation after setting the rotation matrix? Perhaps we should indeed just set the Wacom rotation if it is available and not try to work against XRandR automatisms or so.

It would be better to have no config option but have a working default. So let us try to figure out what we should do on @KivApple's platform.

[jturner314]

Looking at the output @KivApple posted, I'm not sure what's going on. The verbose output from thinkpad-rotate indicates that it's setting the properties correctly, but the output of xinput list-props 12 does not show any changes.

@KivApple: Thanks for posting the output. I don't think I was clear in question 5 -- I'd like to see the output of xinput list-props <id> when (a) the touch is in the normal state (not rotated) and (b) when the touch is rotated strangely (what you described as "the orientation has been changed twice"). I'm very surprised at your output, so I wonder if you posted something else. If so, will you please post the output of xinput list-props <id> for case (a) and case (b)?

[KivApple]

I already do it. In the text that I have shown you seen a sequence of commands, which I performed. I called the change of orientation with thinkpad-rotate, then called xinput list-props, then returned to normal orientation and again called xinput list-props.

By "orientation changed twice" I mean the orientation of the input device. Coordinates are transformed in such a way as if they had turned two times instead of one and get the wrong result (I touch a single point, but the cursor moves in the opposite point).

[jturner314]

@KivApple: Okay, thanks for clarifying. One more question: are you using X.Org or Wayland?

If @KivApple is using X.Org, I have no idea what's going on. I would expect the output of xinput list-props <id> to change when the touch device is rotated.

@martin-ueding: Do you have any idea what's going on? If not, I propose changing thinkpad-rotate to use Wacom Rotation where possible (since that's probably a good idea anyway) and see if that fixes the problem for @KivApple. If that still doesn't work, we could add a config option to disable touch input rotation. Alternatively, I just came up with a possible workaround: change the config to

[touch]
regex = Wacom ISDv4 E6 (?!Finger).*id=(\d+)

to exclude the touch device but still include the other Wacom devices.

[KivApple]

Problem affected not only touch, but also stylus. I use X.Org.

[martin-ueding]

I have created a new branch feature/use-xsetwacom-where-possible that checks whether the property Wacom Rotation exists for the given device. If that is the case, I use the old xsetwacom code that we had in previous versions to rotate the screen. It works on my Fedora 25 X220.

In case there is no such property, the old way with the xinput transformation matrix is used. The reset call to xsetwacom has been guarded with such a check anyway, so there is no need for that on this code path any more.

Since it works on my machine and falls back to the xinput code, there should not be much possible breakage with this.

@KivApple: It would be nice if you could test that branch on your machine and tell us whether that solves the problem you are seeing.

[martin-ueding]

There has been no feedback for 9 days now. Shall I merge this change now? @jturner314, does it work for you?

[jturner314]

I just reviewed and tested the feature/use-xsetwacom-where-possible branch, and it works correctly for me (X220 tablet running Arch Linux with XFCE + i3wm, tested with one external monitor connected and with no external monitors connected). It looks good to merge.

[martin-ueding]

Okay, I will merge that and release it with the next release.