Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • wayland wayland
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 121
    • Issues 121
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 39
    • Merge requests 39
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • waylandwayland
  • Issues
  • #233
Closed
Open
Created Sep 01, 2021 by Artem S. Tashkinov@birdie

Reference wayland-server and standard desktop APIs

  1. As it currently stands all the Wayland compositors must provide:

    Non-standardized APIs for and implementation of:

    • Screen recording and casting
    • Querying of the mouse position, keyboard LED state, 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
    • 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)
    • Disabling input devices (xinput alternative)

    All these features and APIs are re-implemented again and again by all the Wayland compositors. The existing libraries e.g. wlroots only help so much. Why are we talking about such an atrocious 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. Certain Wayland compositors cannot change their settings on the fly and require a full restart which sounds crazy in 2021.

  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.

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.

Edited Jun 08, 2022 by Artem S. Tashkinov
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking