> Stuff like switch to Wayland takes decades because of this split.
My understanding is the switch to Wayland has taken ages because basically everyone who thought it would be a "quick" thing vastly underestimated the number of stakeholders they would need to get on board with the change and how much work would need to go into making those people consent to switching.
They underestimated and had no idea what people are doing with their computers.
Wayland removed many features and use cases from X11 because they thought no one used them. This is what happens when isolated developers without market research make the shots I suppose.
Originally libinput did not even offer a way to disable mouse acceleration as they thought no one would ever do that — anyone who plays video games would obviously laugh at this notion since the præcision required for many video games is completely compromised by the floaty feel of m.a., but they don't play them I suppose.
Talking with many of the Wayland devs reveals their ignorance, this would be fine if they were willing to listen, but at this point it has clearly become an issue of tribalism and because they probably heard it so many times they simply become defensive now as admitting it this point would be admitting defeat an that they were wrong, with pride on the line they continue to insist that one does not “need” these features because the compositor can provide everything, yet no compositor exists that does and it would be madness to expect any to.
It is so frustrating dealing with anti-wayland anti-systemd anti-anything that changes the 30 year old status quo and makes linux actually alive instead of bitrotting on old computers..
Wayland is a display server - xorg started out as one as well, but it got extended to such an extant that at one point it contained a printing service as well. Wayland goes back to the base problem - how to display a window on a/many screens - and solves it splendidly. And leaves the rest to the actual desktop environment because it is not display related. UNIX phylosophy is not all that sexy when it is actually useful is it?
But wayland developers were clever enough to add a proper extension management system so a client can query what is available and use what’s given.
Does implementing wayland by multiple DEs consist of some duplicate work? Sure.
Should we not refactor all the technical debt that accumulated over DECADES to the point where a new hardware was introduced? I think the answer is no.
And I’m not sure which group is tribalist, the ones who blindly hate on something because - surprisingly - without work there would be nothing, or those who make the new thing usable.
Only insofar that the same developers work on the hardware and input drivers for both, and even frequently share code with one another, libinput also works with Xorg of course, and logind's mechanism for starting an unprivileged compositor was backported to Xorg as well.
However, the original designers of the X11 protocol no longer even work on X for the most part, and some of them are dead.
And even with the hardware it was inherited, it is true that the developer of libinput was the maintainer of synaptics, but he did not originally designed it, and found useless many of it's features that he was forced to maintain for backwards compatibility — with libinput hwas free to drop them, and initially did, but after many complaints has yielded to bring some of them back.
synaptics and all the Xorg input drivers are really quite configurable allowing one to even edit the transformation matrix used for pointer acceleration directly, or to manually control the size of the touchpad scroll region, or configure rather præcisely via what criteria palm detection works — Hutterer originally removed this from libinput and considered it unnecessary overkill, but has later restored much of it after complaints, finding that many users indeed used and configured this.
Yeah, Wayland is mostly a regression for my use cases: client-side decorations, breaking screen recording/sharing etc. I know there are theoretical issues with the X security mode, but this replacement is a classic case of “security” producing something that’s basically useless for what people use the software for.
Also, because X works over a socket, it’s language-agnostic in a way that a library just can’t be: libraries like CLX allow Common Lisp graphical applications with no dependency on a C library.
> I know there are theoretical issues with the X security mode, but this replacement is a classic case of “security” producing something that’s basically useless for what people use the software for.
I keep reminding people that one of the most known models for security is "confidentiality, integrity and availability".
If it isn't available your security is still somehow broken however well one scores on confidentiality.
Wayland security is not broken. Its just a single piece in a much longer term goal that spans many components. Linux was not designed for the current era where users run untrusted and borderline malicious programs regularly. While wayland may secure the desktop, there are 20 other places where programs can scoop up your data.
It looks useless now but without every part being fixed individually it will be impossible to create a secure linux desktop that runs proprietary applications.
Tbh I'd much rather fight this on the front of "let's not need to run untrusted and borderline malicious programs regularly" than breaking the free world in order to make it possible.
That fight was long long lost. We will never ever make things like video games open source. But we can sandbox them. Even open source tools could do with being sandboxed.
I don't see why this is an issue. The user still has full power to do anything and its is only programs which are restricted. Under the new model, instead of a tool just grabbing your screen, it must now make a request to the OS which will show a popup asking if you want to allow access and if you accept the program can continue as it would have before.
The issue I have with wayland is that it just continues to fragment the Linux desktop ecosystem, and it moved things to the toolkit that just don’t make sense there: I don’t want my window decorations to depend on whether the app is built with Qt or Gtk. I don’t want projects like McClim ( https://common-lisp.net/project/mcclim/ ) to depend on C code to communicate with the windowing system, etc.
So for window decorations, it's up to the app developer if they want to implement special behavior for client side decorations or not. If they do, there's nothing your toolkit or window manager can really do about it, you have to show the client's window decorations or you will lose functionality. Wayland has little to do with that.
About depending on C code, Wayland is pretty much the same as X11 there. If you don't want to use libwayland, you can write your own implementation of the wire protocol.
You didn't say hardware acceleration initially. If you need hardware acceleration you will have to link against Mesa/OpenGL for direct rendering anyway, which is a giant C library, so yeah the dependency on external C is somewhat unavoidable there under any windowing system.
If you consider linking against libGL and libEGL to be okay but not libwayland then there actually is a workaround: forget the EGL wayland platform and have your custom wayland implementation use the EGL GBM platform. There's some extra code you have to write here but unless something changed that I missed, the same problem exists with Xlib if you try to use the EGL X11 platform, or if you want to use direct rendering in GLX. (Mesa's libEGL/libGLX links against libX11 and expects to get a structure with the C ABI. Keep in mind if you are using GLX calls in that CLX library, you are probably not getting direct rendering, you would have to do a similar thing and reimplement the DRI2/DRI3 path from Mesa in your toolkit or application)
> That fight was long long lost. We will never ever make things like video games open source.
I don't share your pessimism.
Yes, it is harder to exploit users with [FLO] software; so there is less profit to be made; and that will discourage some companies from making it. But I can easily imagine that with a modest income from donations, a project like [Black Mesa] would be happy to make their game open source. Also yes, most software projects today cannot make a living off of donations. But there's no inherent reason this has to be so. People have shown they are willing to pay money for software; in principle, it is ["just"] a matter of redirecting that money from proprietary software to FLO software. And yes, solving the free-rider problem is a very ambitious "just".
But addressing a collective action problem like this requires a coordination mechanism, and the [existing crowdfunding platforms] don't have that. So, I am actively working on one that does — [Snowdrift.coop] — and am not yet ready to throw in the towel.
> But we can sandbox them. Even open source tools could do with being sandboxed.
I agree, but I don't think the operating system is the right level of abstraction to do this. Sandboxing is complex. Implementing it in the OS pushes that complexity on every program, which makes tinkering much harder. I absolutely do not want to have to deal with sandboxing and permission prompts in my .bashrc aliases and shell scripts. I write shell scripts to make my life easier by automating common actions, and having to set flatpak/SELinux type permissions every time I do that would defeat the purpose, or at least substantially raise the bar for how much friction is required before I turn to a script. Writing a simple program on Android/Linux is soo much more work than writing one for GNU/Linux, and soo much less accessible.
Also, we already have an excellent application sandboxing platform for running untrusted and borderline malicious programs — the web. The result of that sandboxing is incredible complexity which makes it a herculean task to develop a web browser. That's a real shame; I'd love to see the "web of documents" split off from the "web of applications" (e.g. to a different protocol, like gopher). I don't want to see desktop environments go the same way. When I install and run a program natively, I am indicating that I trust it and want to leave the restrictions and complexity of the web sandbox behind.
I do see a case to be made for a sandboxing tool for graphical applications specifically. Because building a GUI is already a lot of work compared to writing a CLI, so the relative effort to handle permissions, etc is not as large. But this should be built into and enforced by the packaging tool (e.g. flatpak permissions), not the operating system. And, to bring this discussion back on topic, not by the display manager.
Here's a concrete example: I use Mumble for voice chat. I use push-to-talk. [PTT on Wayland] doesn't work, because the display server only sends keyboard events to the client that has focus. You can look at the linked issue and see all the complexity that results. So for now I am still running X. Yes, there are workarounds. No, I don't want to have to deal with them. Not having to deal with them is the kind of nice thing we can't have if we accept sandboxing by default, rather than sandboxing only the few programs that we cannot trust to run directly on our machines.
I mean, if you are a dev who has devoted an enormous amount of your efforts into making a replacement for the stuff that displays all the stuff from all the other GUIs, seems like the identity function would be recording the shit you're displaying. The fact that OBS doesn't yet work under Wayland makes me wonder if sufficient (or any) dogfooding is going on.
It'd be like if in the 90s you still couldn't easily compile code from inside Emacs. It's a smell.
On X11, a client can view the contents of any arbitrary window, simulate input, read input — this is necessary obviously for screen sharing applications; though one can argue that maybe a permission model needs to exist to allow some clients to run with lower privileges — the funny thing is that it does; it's called te XSECURITY extension, it's very easy to use, and seldom used for whatever reason though SSH uses it whenever it can.
On Wayland, no client can do such things, but many clients such as screen sharing tools, profiling tools, and whatever else that needs to simulate input and read surfaces obviously needs to.
Wayland developers simply say “It must be built into the compositor”, but no compositor can be expected to provide all that, and no compositor does.
The reason XSECURITY is not used is because it's not a real client API and it breaks applications. All it can do is force certain protocol requests to error out or return garbage data. In wayland the security method has moved towards asynchronously showing a dialog asking for permission. It's not feasible to modify the X11 protocol to have it do that without causing more breakage in applications.
>no compositor does
This is not correct. GNOME's compositor actually does support screen sharing, sharing of individual surfaces, and simulated input. And I'm not entirely sure what you mean by profiling tools, can you elaborate?
If you're noticing something that seems strange like that I would say do a thorough check to make sure you don't have some misinformation, there's a lot of bunk that goes around on social media. OBS is working but is not fully tested yet: https://github.com/obsproject/obs-studio/pull/2484/
What's the relevance of the open bug report to what I wrote?
For the record:
* I'm running Debian bullseye
* I'm running Gnome version 3.38.2
* I'm running OBS installed from apt: version 26.0.2+dfsg1-1+b1 (64 bit)
Given a poster on this thread boldly claims that "Wayland is already done and ready," I'd say my setup is more than recent enough to test whether that claim is indeed usable in practice.
Lo and behold, when I run OBS I get a blank screen staring back at me.
If I log back in with Gnome running under X11, OBS works just fine.
It's wonderful that the issue is being addressed, and I thank you for your work on it. But my point is that Wayland+OBS working together is a litmus test. The fact that the two are just beginning to play well is a big red light to me switching away from X11 any time soon.
Anyway, that "done and ready" quote is really the source of my frustration. If I have to set an arbitrary timeout after a "loaded" event to get it to work properly, "loaded" is a probably misnomer.
If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo.
Screensharing/recording works on wayland (that is, there are extensions supporting it). Clients are slower to adapt, but once stable chromium does, a major pain point in client availability will be solved (I mean electron apps)
> If we measure readiness by having every application ported over to wayland, then it will never come - but it is not a useful metric imo.
We're talking about two different things.
You're talking about whether Wayland devs are ready for other devs to start leveraging their work.
I'm talking about whether any Wayland-based distro is ready for a stable release. Clearly none are if a best-in-class screen recorder just gained the ability in a dev branch to recorder the screen under Wayland.
Ubuntu understands what I'm talking about-- 20.04 is not Wayland-based, and I doubt it took look for them to make that decision.
Whether best-in-class applications run correctly under Wayland is a perfectly reasonable and practical metric for Wayland's current value to users.
Well, it is a difficult question as linux is a bazaar-style ecosystem and while apple can change something fundamental at a whim, every significant change in linux will result in a split of the community (with different ratios) and the ‘winner’ will slowly swallow the other. But still then, noone has the incentive in open-source to start porting their app (and usually, since the new thing will be a smaller community at first, it creates a negative feedback loop) - fortunately those that depend on frameworks more often than not can simply be started in wayland mode and no change is required by the maintainer.
For more special clients (like a screen reader) you will need more time as these programs require special handling by the compositor so one has to create an extension for that and a/some DE should implement it then. It will take some time and maybe some niche program that relied heavily on the X implementation will never be ported, or will have to be recreated with wayland in mind (I mean those scripting little programs that read what is under the cursor and the like)
Also, most DEs have really good backwards compatibility thanks to xwayland - because frankly some app will never be ported. (Also, accessibility is unfortunately quite the last thought on even paid platforms - and last I heard it was not all that great to begin with on linux)
You need to use that PR (and the right capture plugins) if you want native Wayland support, it's not merged yet. If you'd like to help move things along, please help test from git. I can give you more info on how to do this if you'd like. Even if this is merged it may be a while before it lands in debian testing.
It's not just stakeholders, it's because instead of one Xorg doing everything, each compositor now has to implement similar things. So efforts are spread across all existing compositors instead of being concentrated. That slowed down progress tremendously.
I'm all for Wayland transition, but things could benefit from concentrated efforts for sure.
They went that way for a reason, though. All the Xorg window managers (Mutter, KWin, etc) largely became behemoth projects in their own right to fill holes in X that could not be easily fixed universally. Since those projects were already faux display managers the X devs that started Wayland wanted to avoid that duplication again.
I get the reason, but it doesn't help that spreading of the effort slowed down the progress almost to a crawl. There is still no adaptive sync in KWin on Wayland and it's not going to appear soon as far as I understand.
The major compositors don't seem to be having issues managing their own implementations so I don't see the issue. wlroots seems like the ideal tool for building your own DE/WM
My understanding is the switch to Wayland has taken ages because basically everyone who thought it would be a "quick" thing vastly underestimated the number of stakeholders they would need to get on board with the change and how much work would need to go into making those people consent to switching.