4 ms·

I’m still not sure I understand Wayland. With X11, the server manages input, windows, and desktops and provides hooks so a window manager process can decorate

I’m still not sure I understand Wayland. With X11, the server manages input, windows, and desktops and provides hooks so a window manager process can decorate those objects. Other processes can make a window and logically draw to it, and the X server does the physical rendering to a screen. But with Wayland, who does the physical rendering? This responsibility is all now dumped on the window manager? Edit: ahah, modern systems punt the actual drawing off to the kernel, using Kernel Mode Setting. What I would’ve called the framebuffer when I were a lad.

charcircuit 3y ago
>But with Wayland, who does the physical rendering? The application renders to a texture. The compositor takes all of the textures from windows and composites them into a single texture that will then get displayed. > This responsibility is all now dumped on the window manager? No, the window manager manages the windows and giwen the compositor information on how it should composite.
kevincox 3y ago
For the full picture I think https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44 is still a pretty good overview of why X11's design doesn't really apply well to modern usage. Particularly the second half of the "core X11" chapter. The TL;DR is that the vast majority of apps are now rendered on the client and most window managers are compositing. This means that the flows look like this: 1. X server reads input. 2. X server sends input to the window manager. 3. The window manager maps the input to a window and sends it back to X. 4. The X server sends it to the clients. 5. The client re-renders and sends it's buffer to the X sever. (Unsyncronized) 6. The X sever sends the new buffers to the window manager. 7. The window manager composites the desktop and sends the result back to the X server. 8. The X server displays the buffer. The TL;DR is that the X server just does inefficient IPC and some top level I/O. Basically all of the rendering is done in the clients or window manager. So Wayland attempts to improve on this model, highlights are: 1. Well designed IPC interface and async/hotplug baked in. 2. Remove the X server intermediary. 3. Actually add frame metadata to allow avoiding tearing. 4. Switch to a more declarative approach for most APIs. For example actually having the concepts of full-screen, modals, popups and screensavers. This fixes issues like using volume keys while a context menu is open and many others. 5. Provide the ability to have capability-based security for things like reading other application's outputs and inputs. The top level I/O management have been moved into libraries as much as possible. Output is mostly managed by the regular graphics APIs and kernel DRM and input is managed by libinput. Of course you don't have to use these libraries, but they are pretty commonly used. People get upset that there are now N compositors, but in X most window managers were compositors anyways, it hasn't really changed this equation. There were also lots of optional extensions so window-manger compatibility was never perfect.

charcircuit 3y ago

>But with Wayland, who does the physical rendering? The application renders to a texture. The compositor takes all of the textures from windows and composites them into a single texture that will then get displayed. > This responsibility is all now dumped on the window manager? No, the window manager manages the windows and giwen the compositor information on how it should composite.

kevincox 3y ago

For the full picture I think https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44 is still a pretty good overview of why X11's design doesn't really apply well to modern usage. Particularly the second half of the "core X11" chapter. The TL;DR is that the vast majority of apps are now rendered on the client and most window managers are compositing. This means that the flows look like this: 1. X server reads input. 2. X server sends input to the window manager. 3. The window manager maps the input to a window and sends it back to X. 4. The X server sends it to the clients. 5. The client re-renders and sends it's buffer to the X sever. (Unsyncronized) 6. The X sever sends the new buffers to the window manager. 7. The window manager composites the desktop and sends the result back to the X server. 8. The X server displays the buffer. The TL;DR is that the X server just does inefficient IPC and some top level I/O. Basically all of the rendering is done in the clients or window manager. So Wayland attempts to improve on this model, highlights are: 1. Well designed IPC interface and async/hotplug baked in. 2. Remove the X server intermediary. 3. Actually add frame metadata to allow avoiding tearing. 4. Switch to a more declarative approach for most APIs. For example actually having the concepts of full-screen, modals, popups and screensavers. This fixes issues like using volume keys while a context menu is open and many others. 5. Provide the ability to have capability-based security for things like reading other application's outputs and inputs. The top level I/O management have been moved into libraries as much as possible. Output is mostly managed by the regular graphics APIs and kernel DRM and input is managed by libinput. Of course you don't have to use these libraries, but they are pretty commonly used. People get upset that there are now N compositors, but in X most window managers were compositors anyways, it hasn't really changed this equation. There were also lots of optional extensions so window-manger compatibility was never perfect.