Reference wayland-server and standard desktop APIs

1. As it currently stands all the Wayland compositors must implement (some of which are yet to be standardized):

   • Screen recording and casting, remote desktop (VNC/RDP/etc.) and management (AnyDesk/TeamViewer/etc.)
   • Querying of the mouse position, keyboard layout and LED state (CAPS/SCROLL/NUM), active window position or name, moving windows (xdotool, wmctrl)
   • Global shortcuts
   • System tray
   • Input Method support/editor (IME)
   • Graphical settings management (i.e. tools like xranrd)
   • Fast user switching/multiple graphical sessions - with Wayland it becomes unclear whether it's the login manager or compositor task
   • Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
   • HDR/deep color support
   • VRR (variable refresh rate); the tear protocol for minimum latency in games
   • Disabling input devices (xinput alternative)
   • Absolute positioning for windows (issue)
   • Crash resistance (a Wayland compositor going down means all your apps crashing - this should be implemented in KDE/KWin/Qt applications sooner rather than later)
   • Sending input to multiple applications at once
   • Querying of displays and managing their power/enabled/disabled state
   • Accessibility features

   All these features and APIs are re-implemented again and again by all the Wayland compositors. The existing libraries e.g. wlroots or libweston only help so much. Why are we talking about such an extreme amount of duplication of work and code, and a ton of effort required to debug and make these features work reliably?

   This all sounds like too high of a price to pay for ostensibly improved security guaranteed by Wayland. Not a single person however has provided a single proof of X.org's "insecurity" ever having been abused to gain unauthorized access to the user account. To abuse X.org's insecurity model you first need to be able to run applications within the user session and at least Linux users normally don't run random applications from the net.

2. As it currently stands the Wayland compositor cannot be reloaded or replaced on the fly without taking down all the running graphical applications. Qt has fixed the issue internally but every toolkit must implement it as well. Some applications, e.g. mpv, don't use any major toolkits such as GTK or Qt which means mpv will not survive a Wayland compositor crash, so not only toolkits must be compositor crash tolerant, everything running under Wayland must be as well. Would be great if the feature was in the protocol itself instead of delegating it to toolkits.

3. As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.

4. Well-established competing desktop OS'es work exactly this way: a single display server and single window manager. In Linux there's a need for multiple window managers but a single reference Wayland server is still highly desired.

I wonder if Wayland developers could maybe consider writing a reference Wayland server which provided all these features and APIs and only required WMs and DEs to provide very simple window managers which drew window decorations and managed application windows, instead of implementing an entire display server along the way.