You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.
>You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.
When it finally got added, the PR was like a 2-300 lines.
And was added after they rewrote everything for the new GTK version when there're functional patches adding thumbnails to previous versions. (Which were rejected/ignored because they didn't feel good.) A situational very in parallel to Xorg/Wayland if consider: https://news.ycombinator.com/item?id=46382940.
> It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding.
My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.
They do have a reference implementation: weston and libweston but as far as I know, third parties don't use. They implement all their own functionality. Weston is confined more as a prototype.
If the issues are trivially resolved, why did the authors of X decided to abandon X? If the issues could be resolved, why were they not resolved?
I am using wayland for more than 5 years now, it just works. X did not. Xscreensaver/lock screens on Qubes are still broken.
What features is Wayland the protocol missing to allow supporting Xfce?
Even when you are national-state-level target, there are easier ways to grab the screen.
For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.
Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.
However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.
I am not sure what you saw, but on regular Linux processes of the user can spy on each other anyway. In any case, X had the concept of untrusted clients basically forever but nobody cared to invest even the small amount of work necessary to make it work well because nobody thought it would make a different. That this was later used as a major argument against X convinced me that this is not at all about technology.
Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do, soon any old user process will no longer be able to read any other process’s memory. I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.
I agree. My point was only that this hole can easily be patched in X as well. So the argument was essentially "we do not bother to patch it with X, so we must rewrite X".
I care about being able to use the same password between the display manager, tty and lock screen auth. Yet, I cannot.
I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.
What? My screensaver password is the same as my login.
> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.
"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"
No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.
> What? My screensaver password is the same as my login.
It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.
Kristian Høgsberg, for example, was a Red Hat employee. Then he worked at Intel, where it appears he continued work on Wayland? So Red Hat and Intel at least? People are being paid full-time to work on Wayland, so those companies.
By now I am not sure if these posts can stil be given the benefit of the doubt or are just dishonest. Who were the developers pushing wayland because of their employers? Kristian Høgsberg (who was a significant xorg developer, because people always deny that wayland was written by xorg guys) originally developed wayland in his free time, it then became a freedesktop project (I would argue not a group run by corporates).
The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.
In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.
So instead of repeating this accusation, maybe actually give some evidence?
I didn't think my explanation implied how you interpreted it.
I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
> I didn't think my explanation implied how you interpreted it.
>
> I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.