SUMMARY KWin as a compositor can be used independently of KDE Plasma, but one of the problems in the Wayland ecosystem that impairs its independent adoption is the lack of support for the following wlr protocols: * wlr-gamma-control-unstable-v1 * wlr-output-management-unstable-v1 * wlr-output-power-management-unstable-v1 These protocols are used by a variety of little tools referenced on arewewaylandyet.com (such as wlr-randr and wlsunset), and smaller desktops are relying on tools that use these protocols to function. Please consider implementing them. STEPS TO REPRODUCE 1. Install wlr-randr and wlsunset 2. Attempt to set outputs with them OBSERVED RESULT Nothing happens. EXPECTED RESULT KWin responds and the displays change accordingly. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 (KDE Plasma) (available in About System) KDE Plasma Version: 5.91 KDE Frameworks Version: Qt Version: 6.6.1 ADDITIONAL INFORMATION Fedora LXQt is considering using KWin as the compositor for its Wayland environment in the near future. Currently it's oriented around labwc and stuff is being built and selected around what it expects and supports.
We intentionally don't support wlr-gamma-control-unstable-v1; the equivalent in kde protocols has been deprecated and then removed a long time ago. Clients setting random lookup tables has proven to not work / cause conflicts on X11 even within the KDE ecosystem, and using a lookup table for night color is the wrong approach as well (for power efficiency, performance and color management reasons). wlr-output-management-unstable-v1 is missing half the features of the kde one, and can't be quickly adjusted to fit our needs when we add new features or change things, so it won't be a priority for KWin. Implementing it would probably not be a big problem though, as long as it's only used to explicitly and intentionally change the configuration by the user - external configuration daemons that react to the connected displays are likely to cause problems, as KWin 6 takes care of that internally. wlr-output-power-management-unstable-v1 could be done without any issues afaict, and could probably be used by kscreen instead of the kde dpms protocol.
(In reply to Zamundaaa from comment #1) > We intentionally don't support wlr-gamma-control-unstable-v1; the equivalent > in kde protocols has been deprecated and then removed a long time ago. > Clients setting random lookup tables has proven to not work / cause > conflicts on X11 even within the KDE ecosystem, and using a lookup table for > night color is the wrong approach as well (for power efficiency, performance > and color management reasons). > > wlr-output-management-unstable-v1 is missing half the features of the kde > one, and can't be quickly adjusted to fit our needs when we add new features > or change things, so it won't be a priority for KWin. Implementing it would > probably not be a big problem though, as long as it's only used to > explicitly and intentionally change the configuration by the user - external > configuration daemons that react to the connected displays are likely to > cause problems, as KWin 6 takes care of that internally. > > wlr-output-power-management-unstable-v1 could be done without any issues > afaict, and could probably be used by kscreen instead of the kde dpms > protocol. Would it make sense to maybe meld the kde and wlr protocols and propose them as a new ext- protocol?
We could upstream the dpms protocol, but doing the same with the output management one would just make the flexibility problem worse. For night color we use dbus (because it still has to support X11), we may change its architecture significantly to add some related features soon-ish, and it works very differently from how wlroots compositors handle this, so I don't see any chances of upstreaming that either.
Well, I mean that we could upstream a protocol that would supersede both dpms and wlr-output-* protocols that both kwin and wlroots compositors can support, and essentially be a superset of both.