touchegg
touchegg copied to clipboard
Feature request: Allow to specify rotation manually (e.g. with a `--rotate` option).
Is your feature request related to a problem? Please describe
I have a setup where I have two monitors, configured to show the same screen area:
- One monitor, the laptop monitor (
DSI1
in belowxrandr
output), is physically portrait, so it is rotated in software by 90° to be used in landscape (which is for the laptop the "natural" way), - the other monitor, the external monitor (
HDMI1
in belowxrandr
output), is physically in landscape and not rotated. This one is a monitor with touchscreen.
Both are configured at 1280x720 pixel (more precisely: The laptop monitor is at 720x1280 pixel and rotated right) and are at the same virtual position, i.e. they show ther same content.
touchegg
now automatically rotates the gestures by 90°, because it thinks that it has to do so from the rotation of DSI1
. This in the end leads to wrong gestures, since in fact the touch screen is the non-rotated monitor HDMI1
.
If I set HDMI1
explicitly as primary monitor with xrandr
, then touchegg
takes it's rotation from there, i.e. it does not apply rotation and gestures work normally.
However, I cannot set HDMI1
as primary because that then interferes with my window manager which then displays the window switch dialogue on <ALT>
+<TAB>
only on one monitor (if I have no monitor set as primary it displays on both), and might have other interferences (Reference: The other side of this issue at xfwm's side).
Describe the solution you'd like
Add an optional option to manually specifiy a rotation to be applied to gestures (default to the automation as it is now when no option is specified).
Describe alternatives you've considered
Setting xrandr --output HDMI1 --primary
.
Additional context
Output of xrandr
:
Screen 0: minimum 8 x 8, current 1280 x 720, maximum 32767 x 32767
DSI1 connected 1280x720+0+0 right (normal left inverted right x axis y axis) 0mm x 0mm
720x1280 60.08*+
640x480 59.94
720x405 59.51 58.99
360x640 60.00
640x360 59.84 59.32
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
1920x1080 60.00 + 50.00 59.94
1600x1200 60.00
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 74.98 59.90
1366x768 60.00
1280x800 59.91
1152x864 75.00
1280x768 59.87
1280x720 60.00* 50.00 59.99 59.94
1440x576 50.00
1024x768 75.03 70.07 60.00
1440x480 60.00 59.94
800x600 72.19 75.00 60.32
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
This seems like a bug. Touchégg checks (or should be checking) on which screen the mouse pointer is placed at before calculating the rotation.
In case you want to debug it or add some logs, the logic is in X11::calculateRotation (x11.cpp)
.
Does this behaviour changes if the mouse pointer is placed on the right screen before the gesture? I'll try to reproduce it locally when I have some time.
This seems like a bug. Touchégg checks (or should be checking) on which screen the mouse pointer is placed at before calculating the rotation.
My screens are configured to overlap, so the mouse poiner is on both.
Does this behaviour changes if the mouse pointer is placed on the right screen before the gesture?
If I configure my screens to not overlap then it works fine.
But I need to have them overlapped.
-- You can't fall off the floor.
What do you mean by overlap? Do you mean mirroring? Or actually a bit of the screen is duplicated in both displays?
Could you share a screenshot of your configuration? In GNOME display settings or similar. Just to make sure I understand the configuration.
What do you mean by overlap? Do you mean mirroring?
Yes, I mean mirroring (both screen show exactly the same) or partly-mirroring (the smaller screen completely fits in the larger screen).
Could you share a screenshot of your configuration?
In my initial post I already shared the output of xrandr
which shows the mirroring screen configuration.
Another configuration, where the laptop screen shows a proper subset of the external (touch)screen:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DSI1 connected 1280x720+640+360 right (normal left inverted right x axis y axis) 0mm x 0mm
720x1280 60.08*+
640x480 59.94
720x405 59.51 58.99
360x640 60.00
640x360 59.84 59.32
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
1920x1080 60.00*+ 50.00 59.94
1600x1200 60.00
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 74.98 59.90
1366x768 60.00
1280x800 59.91
1152x864 75.00
1280x768 59.87
1280x720 60.00 50.00 59.99 59.94
1440x576 50.00
1024x768 75.03 70.07 60.00
1440x480 60.00 59.94
800x600 72.19 75.00 60.32
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
And yes, in that configuration, depending on in which area of the touchscreen I perform the gesture, touchegg
applies a rotation to it or not.
What do you mean by a "screenshot of my configuration"? You mean a screenshot from a GUI for xrandr
?
For maybe more clarity, I have attached a two photographs:
And in case you asked for a screenshot of an xrandr
GUI, here a screenshot from arandr
for
Does that help?
... as a suggestion: Why not use the transformation matrix from xinput
to determine the transformations like rotation needed to be carried out? The transformation done for the pointer movement/ tap position is also taken from there, so using this should always yield correct results.
Taking the transformation for touchegg
from RandR
might also in other cases leading to results not coinciding with pointer movement, since the transformation for that is not necessarily the same.
Thanks for the extra information. With all of that I should be able to reproduce it and fix it when I have time to look into it.
Just to ask: What is the state of this?
Regards!
I have very little free time, and this bugs is a bit niche, so it has low priority, so other task are taking priority over this one.
I'm sorry I can't look into this right now, hopefully someone will figure it out and open a PR