Wayland support

[FrauH0lle]

This is more a general question, so I hope it is fine if I ask it here. As the title says I am wondering about possible wayland support. As I use GNOME as a DE I just gave it a try. The bezel buttons work but I think GNOME is handling this on its own as well as the remapping of the input devices.
When I tried thinkpad-rotate flip -vv I got the following debug

tps.config    DEBUG    ----------------------------------
tps.config    DEBUG    Program was started with arguments: ['/usr/bin/thinkpad-rotate', 'flip', '-vv']
tps.config    DEBUG    Default configfile is /usr/lib/python3.6/site-packages/tps/default.ini.
tps.screen    DEBUG    subprocess “xrandr”
tps.screen    DEBUG    Screens available on this system are XWAYLAND0.
Traceback (most recent call last):
  File "/usr/bin/thinkpad-rotate", line 11, in <module>
    load_entry_point('thinkpad-scripts==4.11.0', 'console_scripts', 'thinkpad-rotate')()
  File "/usr/lib/python3.6/site-packages/tps/rotate.py", line 49, in main
    tps.screen.get_rotation(tps.screen.get_internal(config)),
  File "/usr/lib/python3.6/site-packages/tps/screen.py", line 256, in get_internal
    internal = filter_outputs(screens, config['screen']['internal_regex'])
  File "/usr/lib/python3.6/site-packages/tps/screen.py", line 278, in filter_outputs
    assert len(matched) == 1, 'There should be exactly one matching screen for the `screen.internal_regex`. The outputs detected are {}, the regular expression is `{}`. If you have tinkered with that configuration option, please check it. Otherwise please file a bug report.'.format(', '.join(outputs), regex)
AssertionError: There should be exactly one matching screen for the `screen.internal_regex`. The outputs detected are XWAYLAND0, the regular expression is `LVDS-?1|eDP-?1`. If you have tinkered with that configuration option, please check it. Otherwise please file a bug report.

From what I understand is that it cannot find the screen because it now named XWAYLAND0. I tried xrandr

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
XWAYLAND0 connected 1366x768+0+0 (normal left inverted right x axis y axis) 280mm x 160mm
   1366x768      59.80*+

and xinput

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13            	id=7	[slave  pointer  (2)]
⎜   ↳ xwayland-touch:13                       	id=9	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:13                    	id=8	[slave  keyboard (3)]

and it seems that the devices are now named xwayland... What makes me curious is that it seems "just" to be a name issue in the code and that xwayland is handling the devices. As far as I remember, xwayland is a compatibility layer for "older" programs.
So, are there any plans for thinkpad-scripts to integrate wayland support? Thanks!

[jturner314]

@martin-ueding is the one to make the decision on this, but I do have some questions since I haven't tried Wayland yet:

These pages suggest to me that xrandr and xinput don't work properly under Wayland. What happens if you rotate the display and input devices with xrandr and xinput? Does it work? Does it only affect applications using XWayland, or does it also affect Wayland-native applications? What happens if you connect a second display? Is it called XWAYLAND1 or something else?

[martin-ueding]

From my limited knowledge of Wayland, the compositor takes care of all these things. So I would guess that we have to talk to the compositors to get the screens rotated. And that would require us to have some code for KWin (KDE) and Mutter (GNOME). The others (Xfce, LXDE, Awesome WM, i3, …) are still using the X server, so that this does not make a difference.

I presume the communication would go over D-Bus then? And I hope that there is some common set of functions to do what we want.

Since I myself still use KDE with seemingly X server, I had not had the need to support Wayland. But the day where I will use Wayland will come and then I will have to work on this.

[FrauH0lle]

@jturner314 You are right. XWayland supports reading out tools like xrandr but using them does not work (e.g. xrandr -o right fails). Thus @martin-ueding seems to be right that thinkpad-scripts would need to be adjusted to each compositor separately.
I found this report for Mutter https://bugzilla.gnome.org/show_bug.cgi?id=745079 but I guess it is gonna be a bigger task to implement this.