This post applies to most tools that interface with the X server and change settings in the server, including xinput, xmodmap, setxkbmap, xkbcomp, xrandr, xsetwacom and other tools that start with x. The one word to sum up the future for these tools under Wayland is: "non-functional".
An X window manager is little more than an innocent bystander when it comes to anything input-related. Short of handling global shortcuts and intercepting some mouse button presses (to bring the clicked window to the front) there is very little a window manager can do. It's a separate process to the X server and does not receive most input events and it cannot affect what events are being generated. When it comes to input device configuration, any X client can tell the server to change it - that's why general debugging tools like xinput work.
A Wayland compositor is much more, it is a window manager and the display server merged into one process. This gives the compositor a lot more power and responsibility. It handles all input events as they come out of libinput and also manages device's configuration. Oh, and instead of the X protocol it speaks Wayland protocol.
The difference becomes more obvious when you consider what happens when you toggle a setting in the GNOME control center. In both Wayland and X, the control center toggles a gsettings key and waits for some other process to pick it up. In both cases, mutter gets notified about the change but what happens then is quite different. In GNOME(X), mutter tells the X server to change a device property, the server passes that on to the xf86-input-libinput driver and from there the setting is toggled in libinput. In GNOME(Wayland), mutter toggles the setting directly in libinput.
Since there is no X server in the stack, the various tools can't talk to it. So to get the tools to work they would have to talk to the compositor instead. But they only know how to speak X protocol, and no Wayland protocol extension exists for input device configuration. Such a Wayland protocol extension would most likely have to be a private one since the various compositors expose device configuration in different ways. Whether this extension will be written and added to compositors is uncertain, I'm not aware of any plans or even intentions to do so (it's a very messy problem). But either way, until it exists, the tools will merely shout into the void, without even an echo to keep them entertained. Non-functional is thus a good summary.
10 comments:
so if i'm one of those emacs people who configure the keyboard to generate control, alt, meta, super, and hyper prefixes using xmodmap, what is the wayland alternative? is it specific to gnome and kde? or general?
I know it's unrelated to this post, but not being able to show icons on desktop makes Gnome on Wayland unusable to me.
...and redshift
Osqui: https://copr.fedorainfracloud.org/coprs/mystro256/gnome-redshift/
Oooh yeah!! Thanks a lot Frantisek!!! It works like a charm!!
Mark T. Kennedy said. "one of those emacs people"
wayland is a conspirary to move people to atom text editor.
you might as well tell emacs to use other keys. Appart from countless packages you have about billion ways to do this. It would be nice if you precise the issue here (or maybe in Emacs wiki) if it's not that easy. Maybe time is the only issue, this would be fair, but please tell us so this is useful for other people.
I think this is a looming obstacle in the wider adoption of Wayland by applications. The current assumption seems to be that platform specific API's will be used for these sorts of settings and many other display related operations such as color management etc., but platform API's seem highly fragmented due to the range of Wayland compositors, UI environments, Linux distributions and OS platforms contemplating Wayland support. The correct answer in my view, is an effort to add the necessary support to the Wayland protocol and reference implementations, to at least put Wayland on a par with X11.
Graeme: some of this is explicitly outside of what some compositors want to permit, e.g. the ability of any client to change any device. things like xmodmap are a leftover from *before* xkb and barely work in X (xmodmap to xkb and back is lossy). the amount of effort to make this even *mostly* compatible would be crazy and effort down the drain.
It's not a request for any client to change any device, it's a request that there be standardized management API's/protocols for managing Wayland displays, so that Wayland management applications can be written to support the user. Things like display color calibration and profiling are not something a sane compositor will want to take on - those functions belong in specialized applications, and the API's/protocols are needed if Wayland is not going to be a second class citizen. The current situation is heading towards fragmentation and disconnects, and hence poor support for Wayland in these areas.
It seems like the answer that would satisfy so many of these users is a cl tool that speaks wayland and exposes, for instance, libinput's configuration model (and probably wayland's for that matter, so something like redshift can be made more general).
Basically a gsettings-like tool.
I'm not suggesting you write this, but I think that is what most of these folks probably want (well, that's assuming Graeme's call for xdg support don't happen).
Post a Comment