81–90 of 228 posts
Earlier quoted context omitted.
Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.
What about Emacs? That's the usecase I care about. Until I can get Emacs to manage my Wayland windows ala EXWM, I'm sticking to X.
Earlier quoted context omitted.
It's a damper on development of new WMs and DEs, too. I have ideas for my own desktop I'd like to explore at some point, and if I do it'll almost certainly be X11 based initially because it's so much more quick and easy to wrap one's head around and get the iteration loop up and running with. I'm not anti-Wayland and I think X11 has enough issues that it's worth transitioning over to something better but this is a cr…
The xserver may not be completely dead either: https:/github.com/X11Libre/xserver
I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill.
For what it’s worth, I’ve been moving all my machines to lxde.
Apparently, I accidentally switched back to a compositor free desktop without noticing. High framerate, vsync/tear-free and high dpi work fine. So does fractional scaling, but I disable it.
Personally, I’d rather these hypothetical x11 devs focused on reverse engineering hdmi vrr (blocked by lawyers at the moment), and HDR / expanded color spaces.
Earlier quoted context omitted.
X11 can't do different hz on different screens. If you have a dual screen setup where one screen is 165 hz and the other is 60 you're SOL.
Works fine for me with 144/120 with the second as 60.
Earlier quoted context omitted.
You only need a single implementation that exposes an API for running a WM as an extension. I don't really get why would it be a good idea to somehow mandate a specific architecture design from the standard.
[flagged]
Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.
When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
Earlier quoted context omitted.
Well, that's exactly what the article is about. Wayland put all together into one process I order to avoid unnecessary context switch. This protocol aims to keep the performance advantages of Wayland without giving up on separation of graphics c server and window manager.
I was responding to this comment in the article and wondering about the historical context: > Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.
The fact that Wayland can't just substitute out pluggable WMs without changing a bunch of other unrelated infrastructure is IMO one of the biggest user-facing losses relative to X11. Anybody who is working to improve that is doing god's work as they say.
Honestly, probably the best Linux GUI stack would look like a root Wayland server (not running as root ofc), inside which are nested a per-user Wayland servers (which can be switched between rendering to a monitor or offscreen for a remote login), inside which is nested an X11 server (which is freed from having to care about hardware), inside which runs a normal window manager.