HW accelerated Xwayland rendering for Nvidia merged(gitlab.freedesktop.org)
gitlab.freedesktop.org
HW accelerated Xwayland rendering for Nvidia merged
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587
282 comments
I'm definitely not in hurry to switch from X11 (it's good enough for my use cases) but this is an important step to enable a mass migration to Wayland. I'll give it a try as soon as screen sharing and video conferencing work out of the box for NVidia. Meet, Skype, Slack, etc. If a customer of mine use something that doesn't work on Wayland I have to keep using X11.
Man, I wish it was just that.
Using Qt apps under Gnome on Wayland can break in weird ways (e.g. in one case I saw popup menus opening in weird places or disappearing entirely). Meanwhile, because window decorations under Gnome are client side, the behaviour is weird and inconsistent (double-click on a Gnome titlebar and it maximizes, but double click on a Qt app titlebar and it doesn't).
So maybe switch to KDE? Unfortunately, the idea of a "primary" display simply doesn't exist in KDE on Wayland, which is a major regression for multi-monitor setups. And that's setting aside that KDE on Wayland still crashes on a very regular basis.
Under Gnome I've also seen apps like Guake that simply don't work properly due to either bugs in the compositor or limitations in the Wayland protocol (I'm still not sure which), so you need to find workarounds in those cases.
In general this leads to distros not enabling Wayland by default in clients and toolkits, even if Wayland is the default display server. For example, on Debian (testing), both Firefox and QT require special environment variables to be set depending on your setup. If you don't set them, those applications just use Xwayland and you lose things like fractional scaling. Force the use of Wayland and you end up with a lot of the issues I mention above.
Wayland is really coming along. When it works, it's smooth as butter and works great! Heck, I'd love to use it if only for fractional scaling support. But a lot of things are still very broken and it's still gonna take a while for things to mature.
Using Qt apps under Gnome on Wayland can break in weird ways (e.g. in one case I saw popup menus opening in weird places or disappearing entirely). Meanwhile, because window decorations under Gnome are client side, the behaviour is weird and inconsistent (double-click on a Gnome titlebar and it maximizes, but double click on a Qt app titlebar and it doesn't).
So maybe switch to KDE? Unfortunately, the idea of a "primary" display simply doesn't exist in KDE on Wayland, which is a major regression for multi-monitor setups. And that's setting aside that KDE on Wayland still crashes on a very regular basis.
Under Gnome I've also seen apps like Guake that simply don't work properly due to either bugs in the compositor or limitations in the Wayland protocol (I'm still not sure which), so you need to find workarounds in those cases.
In general this leads to distros not enabling Wayland by default in clients and toolkits, even if Wayland is the default display server. For example, on Debian (testing), both Firefox and QT require special environment variables to be set depending on your setup. If you don't set them, those applications just use Xwayland and you lose things like fractional scaling. Force the use of Wayland and you end up with a lot of the issues I mention above.
Wayland is really coming along. When it works, it's smooth as butter and works great! Heck, I'd love to use it if only for fractional scaling support. But a lot of things are still very broken and it's still gonna take a while for things to mature.
I run GNOME/Wayland on my host and do 100% of my computing inside fully-virtualized VMs running xfce, an actually useful desktop environment. In this way, GNOME 3 actually excels because it's completely void of features and is thus mostly invisible.
Why do that rather just run Xfce?
All of the things sister comment listed and more.
* Compartmentalization
* Layered defense
* Windows is not allowed to touch my bare metal
* Having development images for work, play, etc.
* Easy migration
* Configuring multiple separate environments from one control node
* Accessing my virtual machines over the wire using QEMU on my laptops
* Being able to take a system crash without losing other running contexts.
* Maintaining host-level logical volume management and snapshots while guests retain a simplified partioning layout, with separate images for easy migration of `/home` and `/usr/local`
* Advanced firewall configurations
etc.
* Compartmentalization
* Layered defense
* Windows is not allowed to touch my bare metal
* Having development images for work, play, etc.
* Easy migration
* Configuring multiple separate environments from one control node
* Accessing my virtual machines over the wire using QEMU on my laptops
* Being able to take a system crash without losing other running contexts.
* Maintaining host-level logical volume management and snapshots while guests retain a simplified partioning layout, with separate images for easy migration of `/home` and `/usr/local`
* Advanced firewall configurations
etc.
* Company image
* Snapshots
* Portability
* Isolation
Just a few things i could come up with as valid reasons someone would want to do this.
* Snapshots
* Portability
* Isolation
Just a few things i could come up with as valid reasons someone would want to do this.
Out of interest are you doing this using Qubes? And why?
I used to, but my requirements evolved out of Qubes and I ended up replicating most of the Qubes environment over KVM.
Are you using alternatives to Qubes tools such as the secure clipboard (qvm-copy-to-vm), or just using a lower security setup?
I have some of my own tooling in place, for example with secure clipboard, I have disabled clipboard sharing between VMs and instead wrote host-level ssh+xclip scripts which I hotkeyed.
By primary display do you mean new app windows are created there? If so you can use window rules to force windows to be created on a particular screen.
You could put different windows on particular screens or just punt everything to the desired primary monitor.
This functionally is also available in i3wm/sway as for_window and as a stand alone application under x called devilspie2.
You could put different windows on particular screens or just punt everything to the desired primary monitor.
This functionally is also available in i3wm/sway as for_window and as a stand alone application under x called devilspie2.
It's a pretty common feature. Windows, Gnome/X11 and KDE/X11 all have the concept of a "primary" monitor. I believe macOS does as well.
The idea is that things like the status bar, top bar, dock, etc, appear on the primary monitor unless configured otherwise.
Similarly, new windows preferentially open on the primary monitor.
This is existing functionality on all of these desktop environments.
In a multi-monitor setup, you designate a monitor as the primary monitor and the desktop automatically "does the right thing" even if you remove and reattach the primary display.
KDE on Wayland loses this functionality. The primary monitor is whichever monitor is detected first with no way to control it through configuration. The only workaround is to disable your secondary screen and then re-enable it, and you have to do that every time the desktop launches or the display configuration changes, which is a deal-breaker if you dock/undock regularly (or when the display server crashes).
Might there be hacky workarounds that partially fix some of these issues? Maybe. But it's a major functional regression and I'm not willing to invest that effort (especially, again, given the stability issues).
BTW, Gnome on Wayland preserves this functionality. But unfortunately, as I mentioned, Qt + Gnome leads to a whole host of other issues.
The idea is that things like the status bar, top bar, dock, etc, appear on the primary monitor unless configured otherwise.
Similarly, new windows preferentially open on the primary monitor.
This is existing functionality on all of these desktop environments.
In a multi-monitor setup, you designate a monitor as the primary monitor and the desktop automatically "does the right thing" even if you remove and reattach the primary display.
KDE on Wayland loses this functionality. The primary monitor is whichever monitor is detected first with no way to control it through configuration. The only workaround is to disable your secondary screen and then re-enable it, and you have to do that every time the desktop launches or the display configuration changes, which is a deal-breaker if you dock/undock regularly (or when the display server crashes).
Might there be hacky workarounds that partially fix some of these issues? Maybe. But it's a major functional regression and I'm not willing to invest that effort (especially, again, given the stability issues).
BTW, Gnome on Wayland preserves this functionality. But unfortunately, as I mentioned, Qt + Gnome leads to a whole host of other issues.
Logically you would just put the same dock on both monitors and tell it to move all new windows to DP-2 (or wherever), open an issue on their bug tracker asking for this feature to be reinstated and explaining why, and move on. This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result.
In my opinion primary monitor is conflating 2 settings that perhaps ought to both exist in an easier to use that windows rules.
Open new windows on ____ selected from monitor with mouse cursor, same window as focused application, a selected monitor with the default being same monitor as focused application.
Always show panel in place of any other bar yes/no. Unchecked by default. You can have a panel on each monitor and put things of your choosing in each panel or even have a panel on top and below on the same monitor if you like. So what happens if you have a panel on your primary monitor 1 and also on your secondary monitors 2 and 3? Say you unplug the laptop and monitor 3 becomes the only monitor.
The most obvious and simple thing would be to show the same things on all 3 including showing a taskbar for the windows just on that particular monitor so that when you undock you can still do the same things. Windows does this for example the only difference is which bar has the tray.
The most theoretically correct would seem to be allowing you to set different bars for different configurations but this would be complicated and perhaps little used.
What I've suggested would be to give you the ability to set a primary bar that is always displayed hiding any secondary bars that normally appear on that display.
In my opinion primary monitor is conflating 2 settings that perhaps ought to both exist in an easier to use that windows rules.
Open new windows on ____ selected from monitor with mouse cursor, same window as focused application, a selected monitor with the default being same monitor as focused application.
Always show panel in place of any other bar yes/no. Unchecked by default. You can have a panel on each monitor and put things of your choosing in each panel or even have a panel on top and below on the same monitor if you like. So what happens if you have a panel on your primary monitor 1 and also on your secondary monitors 2 and 3? Say you unplug the laptop and monitor 3 becomes the only monitor.
The most obvious and simple thing would be to show the same things on all 3 including showing a taskbar for the windows just on that particular monitor so that when you undock you can still do the same things. Windows does this for example the only difference is which bar has the tray.
The most theoretically correct would seem to be allowing you to set different bars for different configurations but this would be complicated and perhaps little used.
What I've suggested would be to give you the ability to set a primary bar that is always displayed hiding any secondary bars that normally appear on that display.
> This wouldn't so much be a hacky workaround as using a built in feature that achieves the same result.
But there's already a built-in feature in KDE/X11 for this. It's just broken in Wayland. It's a feature regression, plain and simple.
But there's already a built-in feature in KDE/X11 for this. It's just broken in Wayland. It's a feature regression, plain and simple.
So ask them to put it back?
I think you're missing the entire point of my comment.
I'm not saying these things can't be resolved! They probably will be, eventually. I have every confidence that some day, KDE on Wayland will restore this now-missing feature.
I'm simply saying, through my personal laundry list of bugs and regressions, that Wayland is a long way off from ready for prime-time due to a wide range of issues that go well beyond the oft cited, very well-trod issue of the lack of screen sharing.
That's it.
And I genuinely look forward to the day those gaps are closed and I can use Wayland full time!
I just have a feeling that won't be until 2023 at the earliest.
I'm not saying these things can't be resolved! They probably will be, eventually. I have every confidence that some day, KDE on Wayland will restore this now-missing feature.
I'm simply saying, through my personal laundry list of bugs and regressions, that Wayland is a long way off from ready for prime-time due to a wide range of issues that go well beyond the oft cited, very well-trod issue of the lack of screen sharing.
That's it.
And I genuinely look forward to the day those gaps are closed and I can use Wayland full time!
I just have a feeling that won't be until 2023 at the earliest.
I'm pretty sure Wayland is never the problem, it's always the user. If no one used Wayland, it would run exactly as designed!
I have a feeling it will be 20never as I sit in front of my machine running i3wm version whatever in 2029.
I'd imagine this as far as things like docks are concerned? But the idea that I have to write specific windowing rules just to use my computer suggests this has a long way to go. It should 'just work' out of the box.
Just work doesn't mean it just works as you personally desire. It means just works in a consistent predictable fashion that is suitable for use not desirable for your taste or matching behavior on windows.
Personally I expect windows to show up on the same monitor as the currently focused window or the cursor and having it pop to a primary monitor would be from my perspective a defect. I would have to test but I think that outside of gnome this is actually how the majority of linux environments work out of the box.
You don't have set a windows rule in the settings gui just to use your computer. You have to set a windows rule in the settings gui for your computer to work in the fashion that you prefer. That you regard this setting as essential doesn't mean that it actually is just that you strongly prefer it.
Personally I expect windows to show up on the same monitor as the currently focused window or the cursor and having it pop to a primary monitor would be from my perspective a defect. I would have to test but I think that outside of gnome this is actually how the majority of linux environments work out of the box.
You don't have set a windows rule in the settings gui just to use your computer. You have to set a windows rule in the settings gui for your computer to work in the fashion that you prefer. That you regard this setting as essential doesn't mean that it actually is just that you strongly prefer it.
> When it works, it's smooth as butter and works great
Come on, Wayland was released 12 years ago! And it still has all kinds of problems that don't make it qualify even for beta software. I'm highly skeptical that Wayland will ever be as useful as X11 is right now.
Come on, Wayland was released 12 years ago! And it still has all kinds of problems that don't make it qualify even for beta software. I'm highly skeptical that Wayland will ever be as useful as X11 is right now.
In all fairness, my experience is that most of the issues are in the broader ecosystem at this point.
Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work.
And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem.
So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.
Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work.
And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem.
So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.
The perspective that wayland is just a protocol and doesn't need to address real issues is why it has so many of them to start with.
That I completely agree with.
The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc.
To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example.
Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc.
To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example.
Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, probably because they saw pipewire was maturing.
Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want.
The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.
Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want.
The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.
I've heard all the excuses.
None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization.
After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place.
I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.
None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases, or worse, to make those use cases someone else's problem (e.g. screen sharing), thereby creating fragmentation in the ecosystem due to a lack of standardization.
After all, it's pretty rich to blame Gnome or KDE for "[deciding] to do something different" when Wayland was very deliberately designed to offer no standard for how to do the thing in the first place.
I'd actually prefer it was unintentional, as that would imply simple oversight. If it was intentional, that implies deliberately bad design choices that have gotten us to the semi-broken place we are right now; a place we're only finally getting out of as other people (e.g. the PipeWire folks) step in to cover up the spike-filled holes that Wayland has left behind.
> None of it changes the fact that Wayland was either intentionally or unintentionally designed to exclude extremely common software use cases
The wayland protocol is multi-layered, with the core being deliberately only used for displaying content in recrangles properly. That’s it. But it also allows for querying the capabilities of the compositor with versioning, making extensions possible. There was a recent Show HN submission with this site: https://wayland.app/protocols/
The not-yet-core extensions doesn’t create fragmentation, actually there is a decent cooperation behind the 3-4 major compositor “backends” on everything, and ultimately they all settle on the same thing. Also, it’s a bit generous to say that fragmentation is somehow the fault of Wayland, when it has always been a problem in linux desktops.
Also, why do you think adding screen recording into wayland would have been great? It is a complex problem with audio syncing, not-necessarily display-related programs accessing streams and the like, so it seems relevant only on a surface level. Pipewire is the good layer to handle it. And prebaking some API without pipewire being ready would have been just stupid. It is/will be supported everywhere (there is a portal frontend already for gnome, sway and I believe plasma as well).
The wayland protocol is multi-layered, with the core being deliberately only used for displaying content in recrangles properly. That’s it. But it also allows for querying the capabilities of the compositor with versioning, making extensions possible. There was a recent Show HN submission with this site: https://wayland.app/protocols/
The not-yet-core extensions doesn’t create fragmentation, actually there is a decent cooperation behind the 3-4 major compositor “backends” on everything, and ultimately they all settle on the same thing. Also, it’s a bit generous to say that fragmentation is somehow the fault of Wayland, when it has always been a problem in linux desktops.
Also, why do you think adding screen recording into wayland would have been great? It is a complex problem with audio syncing, not-necessarily display-related programs accessing streams and the like, so it seems relevant only on a surface level. Pipewire is the good layer to handle it. And prebaking some API without pipewire being ready would have been just stupid. It is/will be supported everywhere (there is a portal frontend already for gnome, sway and I believe plasma as well).
I'm pretty sure the goal is Linux with a single tightly coupled official ui with no extensions or themes with the single point of configurability will be an accent color.
This to be part of a monolithic identical system where different distros are only different in terms of default software installed and logo and the entire os is read only and not user serviceable.
Look up rethinking how we put systems together by leonart poetering and comments from gnome devs about disabling theming to improve brand awareness or arguing about the folly of letting users muck up their work with the horror of extensions.
This to be part of a monolithic identical system where different distros are only different in terms of default software installed and logo and the entire os is read only and not user serviceable.
Look up rethinking how we put systems together by leonart poetering and comments from gnome devs about disabling theming to improve brand awareness or arguing about the folly of letting users muck up their work with the horror of extensions.
These aren't excuses, there are no other parties at play here. Weston was the first implementation. GNOME and KDE were the next implementations. They could have chosen to copy Weston's implementation, thus making those parts "standard" but they didn't. That's the way it played out. The way you're talking about it makes it sound like there was some outside force designing Wayland and convincing the other designers to exclude screen sharing, when it wasn't like that at all. You also seem to be suggesting that they could have designed everything in hindsight perfectly before the implementations even existed, I hope I don't need to point out why it doesn't work like that.
You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.
You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire. The fragmentation here is because it's taken a lot of effort to redesign these core components. Ideally this would all be done already, but it takes time.
> You're also talking as if Pipewire is some outside thing that was developed in reaction to Wayland, when as far as I know, the plan with those implementations was always to delegate some tasks to Pipewire.
Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.
Given that Wayland was first released in 2008 and the first commit to the PipeWire project was in 2015, I'm quite confident at this point that you're rewriting history to support your position.
You misunderstand, it was only Weston that was started in 2008, and it had screenshots back then. I'm talking about those other implementations, they didn't really stabilize and start aiming to have feature parity until a few years ago, and they decided not to copy Weston's screenshooting mechanism.
Weston being the reference implementation for the protocol, my point stands and you're now picking nits.
> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers
https://www.x.org/wiki/Development/Documentation/Security/
The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007.
The Wayland devs themselves say "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." https://wayland.freedesktop.org/faq.html#heading_toc_j_5
They just didn't want to.
https://www.x.org/wiki/Development/Documentation/Security/
The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007.
The Wayland devs themselves say "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X." https://wayland.freedesktop.org/faq.html#heading_toc_j_5
They just didn't want to.
XACE is basically an extension of SELinux into userspace for X11. Given that today Fedora/RHEL are the only distros that enable SELinux out of the box, such an approach would have been doomed to failure (or doomed to provide a product differentiator for RHEL in the best case) - not to mention the sheer joy and excitement that debugging SELinux AVC denials would produce for end users and desktop application developers.
https://www.freedesktop.org/software/XDevConf/x-security-wal...
(Wayland's "buffer exchange and update models" won't provide security on their own without any improvement on the input side)
https://www.freedesktop.org/software/XDevConf/x-security-wal...
(Wayland's "buffer exchange and update models" won't provide security on their own without any improvement on the input side)
> Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers.
Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole?
Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
I'm working with i3 (on X, obviously). Perhaps I'm diluted but my experience is that users of this setup are happy about their setup and love the system they use.
I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
Sway is in top-up form and is basically just i3 on wayland. Even the config is largely compatible, so do give it a try, if you haven’t (recently)!
I tried it not long ago. It's ok, took me some time to overcome some issues but got it to work, then, when I started actually working I met the same issues regarding screenshots, remote control/screen sharing and decided to stay with i3 while I can.
There's plenty of ways to securely multiplex Ethernet devices. You don't give your web server read access to all TCP ports being used by other services for example. You only let it open the HTTP ports. There are of course ways for debuggers to escape this and intercept all TCP packets sent by the kernel, but those require elevated privileges.
If you don't have any users you will soon find yourself without developers so it is in fact quite relevant.
That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...
So I can't log my own keystrokes on Wayland? Anti feature.
If you have root access to your own system, or read access to /dev/input, then it's trivial to deploy a keylogger. No need for Wayland to get involved there. You can't log keys through the Wayland socket because that socket is intended to be accessible to sandboxed programs.
So to be clear you want such a program to be implemented to be running as root in a way that the user can't individually control its just another root daemon that the user may or may not be aware of.
craftinator wanted a way to log his/her own keyboard events.
Of course a custom extension can also be created for this use-case, in which way the compositor can allow/deny access for keypresses to specific windows. But to be honest a central hot-key manager where apps can register new bindings (and with compositor managed multiple bindings resolution instead of the ad hoc way under X) would be a great target.
Of course a custom extension can also be created for this use-case, in which way the compositor can allow/deny access for keypresses to specific windows. But to be honest a central hot-key manager where apps can register new bindings (and with compositor managed multiple bindings resolution instead of the ad hoc way under X) would be a great target.
That's one way to do it, it's probably not the best way but it would work if you were planning to sidestep Wayland security completely. You could make it user controllable with dbus and then make a GUI to talk to it.
> Maybe someone will figure out a good way to do this but I wouldn't hold my breath.
Android and iOS and Browsers these days already have figured out something for those kind of things - they ask for permission.
Android and iOS and Browsers these days already have figured out something for those kind of things - they ask for permission.
The usual place those permission dialogs have gone is the flatpak portal, which is separate from Wayland. Someone would have to implement it there.
> Wayland, itself, is just a protocol
That is the root of the problems IMO. The thing is, this design decision had made the ecosystem a lot harder to grow than X11/xorg.
That is the root of the problems IMO. The thing is, this design decision had made the ecosystem a lot harder to grow than X11/xorg.
Maybe it has made is slower to grow, but harder? Now we have several dominant Wayland implementations including wlroots, Mutter, and KWin (the latter is still getting there from what I've heard). This is already 3x the number of dominant implementations of X11. Compositor developers can choose to use an existing implementation that suits their needs, or to develop one from scratch (that is compatible by implementing the same Wayland protocol). I think making Wayland just a protocol has made it easier to grow.
Dominant compositor implementations – the dominant wayland implementation is libwayland :) About the only serious alternative is the Rust one – the crate has a native mode. (but you still have to use the libwayland backend if you want to do GL because of how Mesa's EGL impl is tied to… yeah, lol, hard problems here :D)
But seriously, the "competition" between these compositors is awesome. This is like web standards again. Testing your client across different compositors reveals bugs (either in them, or in your client) and everything evolves together in standard ways. With the single Xorg server, everything got completely ossified, if anyone wanted to rewrite a full "production ready" X11 server they'd have to be bug-compatible with Xorg.
But seriously, the "competition" between these compositors is awesome. This is like web standards again. Testing your client across different compositors reveals bugs (either in them, or in your client) and everything evolves together in standard ways. With the single Xorg server, everything got completely ossified, if anyone wanted to rewrite a full "production ready" X11 server they'd have to be bug-compatible with Xorg.
I take it you don't remember X11 when it was 12 years old. Wayland looks quite good in comparison.
I think, based on the responses to your comment, that your comment is quite wrong. It seems X11 was completely functional at the time, which Wayland is definitely not at this time.
It’s not that hard to understand...
Wayland is a protocol. If you have a few badly implemented browsers, is the web protocol bad?
Also, it is questionable at best to state that Wayland compositors doesn’t work. Gnome is quite stable and with pipewire everything just works. Sway is similarly a stable software.
Also, it is questionable at best to state that Wayland compositors doesn’t work. Gnome is quite stable and with pipewire everything just works. Sway is similarly a stable software.
> It’s not that hard to understand... Wayland is a protocol. If you have a few badly implemented browsers, is the web protocol bad?
Did you read the comment I was responding too? It had already conflated the two. However, in the spirit of not being petty, I ignored the conflation and decided to address the real issue, that implementations of Wayland are not stable after 12 years, while X was actually stable after about 8.
Did you read the comment I was responding too? It had already conflated the two. However, in the spirit of not being petty, I ignored the conflation and decided to address the real issue, that implementations of Wayland are not stable after 12 years, while X was actually stable after about 8.
In practice I do not care about the difference between wayland compositors and the wayland protocol. When I say “wayland sucks” what I mean is that every time I have tried any “wayland” desktop or WM, it has not worked for my workflow and has tons of bugs and missing features. I do not care whether this is because of the protocol or some other reason.
Random example: in Sway, Chrome and all Electron apps have blurry text on displays with scaling other than 1.0. Every time I try “wayland” (or whatever term you would prefer I use), there is some show stopping bug like this.
I feel like the conversations here usually go like this, with people just talking past each other:
A: “X11 is going away, time to switch to Wayland!”
B: “Okay, but last time I tried it, it didn’t work for me because <list of reasons>”.
A: “No no no, you don’t understand, that’s not Wayland’s fault, it’s a compositor issue.”
B: “Well, whatever the issue is, I’d like to keep using X.”
A: “But X is going away! It’s deprecated!”
Random example: in Sway, Chrome and all Electron apps have blurry text on displays with scaling other than 1.0. Every time I try “wayland” (or whatever term you would prefer I use), there is some show stopping bug like this.
I feel like the conversations here usually go like this, with people just talking past each other:
A: “X11 is going away, time to switch to Wayland!”
B: “Okay, but last time I tried it, it didn’t work for me because <list of reasons>”.
A: “No no no, you don’t understand, that’s not Wayland’s fault, it’s a compositor issue.”
B: “Well, whatever the issue is, I’d like to keep using X.”
A: “But X is going away! It’s deprecated!”
> Random example: in Sway, Chrome and all Electron apps have blurry text on displays with scaling other than 1.0.
That’s literally because of X. Both of them run by default in XWayland, but chrome do have wayland support already (but has to be enabled), and electron also have since being built on chrome, but most versions out there are not built with that version I believe.
Also, noone says you SHOULD change. Feel free to use whatever you want. But saying wayland suck, when you didn’t even use goddamn wayland for evaluating it just “sucks”...
That’s literally because of X. Both of them run by default in XWayland, but chrome do have wayland support already (but has to be enabled), and electron also have since being built on chrome, but most versions out there are not built with that version I believe.
Also, noone says you SHOULD change. Feel free to use whatever you want. But saying wayland suck, when you didn’t even use goddamn wayland for evaluating it just “sucks”...
> That’s literally because of X
I don’t care — that was the whole point of my comment.
> Also, noone says you SHOULD change
Yes they do! People are saying all the time that X is deprecated and going away, and we need to switch to Wayland.
If other people want to use Wayland, it of course doesn’t bother me; I just hope it never becomes the standard and pushes out X, which works fine for me.
I don’t care — that was the whole point of my comment.
> Also, noone says you SHOULD change
Yes they do! People are saying all the time that X is deprecated and going away, and we need to switch to Wayland.
If other people want to use Wayland, it of course doesn’t bother me; I just hope it never becomes the standard and pushes out X, which works fine for me.
> Yes they do! People are saying all the time that X is deprecated and going away, and we need to switch to Wayland.
You can continue to run on eg. Linux 3.* if you so wish. And X is a stable software, it will continue to work reliably in the foreseeable future, even without active maintenance.
You can continue to run on eg. Linux 3.* if you so wish. And X is a stable software, it will continue to work reliably in the foreseeable future, even without active maintenance.
X was 1984. X11 was 1987. Twelve years later in 1999, it worked just fine.
Even before that. I remember installing X11 on PCs in 1995. And it worked much earlier than that on UNIX workstations.
Then again, was there even an alternative back then?
to give you an idea of 1999, I was running Quake 3 on Linux with official Nvidia Riva TNT support and X11.
X11 also ran fine in 1995. Granted, I think fvwm2 was probably state of the art for window managers at the time. From '95 to almost '97 or '98 I stuck pretty much in 80x25 or 80x40 text console. Not because X11 didn't work, but more so because xterm really sucked and the only apps you would use in X11 anyway were Netscape, Gimp or xv (image viewer). Gtk+ also did not exist, so everything was ugly Motif or Tcl/Tk.
Oh, and... there was always talk of replacing X11. Even in the '90s. People have been talking about replacing X11 nearly as long as X11 has been around, sadly.
X11 also ran fine in 1995. Granted, I think fvwm2 was probably state of the art for window managers at the time. From '95 to almost '97 or '98 I stuck pretty much in 80x25 or 80x40 text console. Not because X11 didn't work, but more so because xterm really sucked and the only apps you would use in X11 anyway were Netscape, Gimp or xv (image viewer). Gtk+ also did not exist, so everything was ugly Motif or Tcl/Tk.
Oh, and... there was always talk of replacing X11. Even in the '90s. People have been talking about replacing X11 nearly as long as X11 has been around, sadly.
1995 the state of the art WM was probably GWM which was fully programmable in a Lisp dialect. You could even draw your window decorations in Lisp using various primitives. It was never widely used though.
Sorry, I meant X. Wrote X11 out of habit. But X11 is a version of X, so I still think the relevant date is 1984 and in 1996 I was still writing modelines in my X conf file... and at least with Wayland you don't have to worry about a misconfiguration frying your monitor.
Wayland (and X11, and any other modern display system) will absolutely fry non-multisync monitors. Those were common in 1996.
Hardware has just improved enough that we don't need to care.
This isn't wayland vs X11.
X11 is terrible for other reasons, but let's not give wayland credit for hardware improvement.
Hardware has just improved enough that we don't need to care.
This isn't wayland vs X11.
X11 is terrible for other reasons, but let's not give wayland credit for hardware improvement.
As another comment notes this is more due to EDID and multisync monitors: hardware and protocol improvements in consumer electronics.
X was actually okay in 1996 on the proprietary Unixes with their proprietary graphics card and proprietary monitors. (At least on HPUX, Solaris, and Irix). Linux and the *BSDs had some catching up to do primarily in hardware support and autoconfiguration. But they did so quite rapidly.
X was actually okay in 1996 on the proprietary Unixes with their proprietary graphics card and proprietary monitors. (At least on HPUX, Solaris, and Irix). Linux and the *BSDs had some catching up to do primarily in hardware support and autoconfiguration. But they did so quite rapidly.
The Wayland protocol was released 12 years ago. Compositors have only really been implementing it within the last few years.
>Using Qt apps under Gnome on Wayland can break in weird ways
Same on sway. I think the relevant bug report is this [1] but there is no traction and the patch doesn't really work. Qt5 is probably not going to receive any attention now too, so I'm not holding my breath.
[1] https://bugreports.qt.io/browse/QTBUG-87303
Same on sway. I think the relevant bug report is this [1] but there is no traction and the patch doesn't really work. Qt5 is probably not going to receive any attention now too, so I'm not holding my breath.
[1] https://bugreports.qt.io/browse/QTBUG-87303
Oh hey, a link to my bug report :) someone else in the thread mentioned that the KDE devs have patches for Qt that unfuck the menus, and they're included in Arch Linux now or something..?
Upd: well, that problem doesn't seem to be fixed there, still no constraints are set on the kde/5.15 branch
Upd: well, that problem doesn't seem to be fixed there, still no constraints are set on the kde/5.15 branch
Maybe this is a Gnome issue? I've been using sway as my main driver for 2 (?) years now and I don't encounter any of the issues that you see. I'm running with firefox and most other apps forced to wayland and was actually surprised how easy it was.
The main issues I encounter are about screen sharing. At the moment it does not work for wayland apps (i.e. wayland apps don't show up in the share this). Supposedly there is a way around it, but I've not yet needed to investigate. The other issue is OBS not working (I guess also because of screensharing). And the third issue is some weird bug in Zoom, where if I open the participant or chat window, it becomes extremely laggy. So much so that I can't really type in the chat window because there is such a strong lag, that I finished typing before the word appears. Similarly the video feed becomes choppy.
One other issue was that Pycharm was having issue opening some menus/windows but that seems to have been fixed now.
The main issues I encounter are about screen sharing. At the moment it does not work for wayland apps (i.e. wayland apps don't show up in the share this). Supposedly there is a way around it, but I've not yet needed to investigate. The other issue is OBS not working (I guess also because of screensharing). And the third issue is some weird bug in Zoom, where if I open the participant or chat window, it becomes extremely laggy. So much so that I can't really type in the chat window because there is such a strong lag, that I finished typing before the word appears. Similarly the video feed becomes choppy.
One other issue was that Pycharm was having issue opening some menus/windows but that seems to have been fixed now.
> Maybe this is a Gnome issue?
Definitely a Gnome issue.
Definitely a Gnome issue.
> Maybe this is a Gnome issue?
I actually listed a range of issues. Some are in Gnome. Others are in KDE. Yet others are in the toolkits (e.g. the Qt popup menu problem). And still others are in the applications themselves (e.g. Firefox has a whole menu of Wayland-specific bugs).
I actually listed a range of issues. Some are in Gnome. Others are in KDE. Yet others are in the toolkits (e.g. the Qt popup menu problem). And still others are in the applications themselves (e.g. Firefox has a whole menu of Wayland-specific bugs).
I had a ton of issues with QT menus until the latest patches from KDE hit Arch's QT packages. Fixed them
Ooh! Interesting! Will look at these. So far I've reported a couple Qt bugs, well, they got priorities but no fix so far:
https://bugreports.qt.io/browse/QTBUG-87303
https://bugreports.qt.io/browse/QTBUG-87332
If KDE patches actually make menus work okay, that's great. I've been wondering how KDE deals with the bugginess of the wayland QPA, turns out the answer's simple and not KDE-exclusive, nice.
upd: seems like no popup constraint adjustment is set on the kde/5.15 branch. Hopefully there are other improvements though…
https://bugreports.qt.io/browse/QTBUG-87303
https://bugreports.qt.io/browse/QTBUG-87332
If KDE patches actually make menus work okay, that's great. I've been wondering how KDE deals with the bugginess of the wayland QPA, turns out the answer's simple and not KDE-exclusive, nice.
upd: seems like no popup constraint adjustment is set on the kde/5.15 branch. Hopefully there are other improvements though…
There was an update for OBS recently, which sounds like it fixed the Wayland issues.
https://feaneron.com/2021/03/30/obs-studio-on-wayland/
https://feaneron.com/2021/03/30/obs-studio-on-wayland/
I like sway a lot, but I also encountered many bugs with its implementation. For example, it's drag and drop and focus switching randomly breaks when interacting with Xwayland windows. It also breaks resume/suspend if you have multiple GPUs. I finally went back to pure X11 and everything just works and is snappy. I miss the Wayland tear-free experience though.
The focus switching thing should be fixed in the new 1.6 version
Pipewire will solve I believe the last major blocker for wayland. I believe OBS already has a pipewire-aware version, and both firefox and chrome (with a bit of tinkering in settings) supports it.
I dread the day when I will be forced to switch since there is nothing like EXWM for Wayland and it's hard to see how such a thing could be implemented.
I don't care for "smooth" or "every pixel is perfect" so to me the trade-offs are all negative.
I don't care for "smooth" or "every pixel is perfect" so to me the trade-offs are all negative.
There are more traditional window manager type compositor, you might be able to find something more to your tastes in this list...
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
As a happy Openbox user, I'm planning on trying Waybox first I think. Waiting for the next Debian release though.
EXWM does some special stuff though. It maps X11 windows in a way that they appear to be Emacs buffers and are managed as such. It also optionally captures certain input from them so that Emacs sequences (for example stuff prefixed by C-x) still work as usual. All this is done in a very granular way to maintain the illusion. So for example if I hit "b" after "C-x" or while the Emacs minibuffer is active then it goes to Emacs but otherwise it goes to the application. And generally it works very well, I've been using it for many years.
To do this in Wayland I imagine we'd need to have Emacs act as the compositor and that sounds a bit too crazy... Or perhaps some kind of a proxy-compositor could be used that could be fully driven by Emacs using an rpc protocol. Is there such a thing out there?
To do this in Wayland I imagine we'd need to have Emacs act as the compositor and that sounds a bit too crazy... Or perhaps some kind of a proxy-compositor could be used that could be fully driven by Emacs using an rpc protocol. Is there such a thing out there?
Sway is based on wlroots, which basically implements everything needed for a compositor, making creating “only a wm” similarly easy as it was under X. So I’m sure it can be done.
The proxy-compositor over RPC sounds workable. This is how the Nyxt browser[1] interfaces its Common Lisp runtime with WebKit.
[1]: https://nyxt.atlas.engineer/article/technical-design.org
[1]: https://nyxt.atlas.engineer/article/technical-design.org
Ubuntu 21.04 is enabling by default, so I bet loads of issues will bubble up there.
The very conservative nature of Ubuntu packaging really holds back things getting fixed in my opinion. It’s hard to have a feedback loop when the biggest desktop distro ends up being super far behind. I get why but I would love an opt-in “rolling release” repo for Ubuntu, as silly as that seems
The very conservative nature of Ubuntu packaging really holds back things getting fixed in my opinion. It’s hard to have a feedback loop when the biggest desktop distro ends up being super far behind. I get why but I would love an opt-in “rolling release” repo for Ubuntu, as silly as that seems
Switch to Debian unstable? No, it's not quite Ubuntu, but it's a rolling, deb-based release.
I understand this position, not wanting to be a first mover is noble, but most of the complaints about "Linux Desktop" (hiDPI screens for example) are solved with wayland, so ultimately I prefer if we don't make the switch so painful. (python3 for example).
Ultimately my experience after almost a decade using desktop Linux is use the most common configuration.
Ubuntu desktop, default desktop and config.
Because Linux desktop is already fringe. If you use uncommon options on a fringe OS, you're going to spend lots of time debugging problems. I just like my tools to work.
I'll be sticking with X11 until wayland becomes the default in some future LTS release.
Ubuntu desktop, default desktop and config.
Because Linux desktop is already fringe. If you use uncommon options on a fringe OS, you're going to spend lots of time debugging problems. I just like my tools to work.
I'll be sticking with X11 until wayland becomes the default in some future LTS release.
Long time Linux (and therefore X11) user here. I'm not much of a programmer, more of a techy end user.
I have read of the supposed benefits of Wayland, but from what I can percieve, the cons (too numerous to mention, but mostly breaking a billion useful things that X has had for some time) seem to out weigh the pro. Yes, the pro. Fractional scaling.
I don't like actively cheering for something to fail, but I really don't get it. X11 is in no way broken enough to justify such a huge change, and I'm concerned that the KDEs and Gnomes of the world are going to ramrod the thing through regardless.
I have read of the supposed benefits of Wayland, but from what I can percieve, the cons (too numerous to mention, but mostly breaking a billion useful things that X has had for some time) seem to out weigh the pro. Yes, the pro. Fractional scaling.
I don't like actively cheering for something to fail, but I really don't get it. X11 is in no way broken enough to justify such a huge change, and I'm concerned that the KDEs and Gnomes of the world are going to ramrod the thing through regardless.
Fractional scaling is kind of the most visible thing today. But to be clear, there’s a lot of benefits to wayland.
Mostly the issues could be hacked around. But let’s be absolutely clear with this: it is hacking around the issue.
Problem: tearing, solvable with double buffering, maybe.
Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program. Solvable by running a mini X11 instance for each program.
Problem: Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)
Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features. Especially as the client may not be on the same machine as the server.
Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
Mostly the issues could be hacked around. But let’s be absolutely clear with this: it is hacking around the issue.
Problem: tearing, solvable with double buffering, maybe.
Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program. Solvable by running a mini X11 instance for each program.
Problem: Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)
Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features. Especially as the client may not be on the same machine as the server.
Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
I’d like to emphasize a major aspect that makes the switch a non-brainer: SECURITY.
The “good old days” of unencrypted Internet, where everyone could see your cookies, are no longer acceptable; the same is true of X11.
With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.
With Wayland, each app only sees their own pixels.
With X11, screen locking is pure hackery that doesn’t always protect the locked pixels and… login password.
Traditionally, you are meant to trust that process boundaries on Linux are sacredly secure, which is why Spectre was a big deal. But in practice, that is only true under Wayland.
The “good old days” of unencrypted Internet, where everyone could see your cookies, are no longer acceptable; the same is true of X11.
With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.
With Wayland, each app only sees their own pixels.
With X11, screen locking is pure hackery that doesn’t always protect the locked pixels and… login password.
Traditionally, you are meant to trust that process boundaries on Linux are sacredly secure, which is why Spectre was a big deal. But in practice, that is only true under Wayland.
X11 is also just a protocol and you can implement it securely and expose access control through extensions. In fact it already exists (XACE) just nobody is using it.
XACE is basically an extension of SELinux into userspace for X11. Given that today Fedora/RHEL are the only distros that enable SELinux out of the box, such an approach would have been doomed to failure (or doomed to provide a product differentiator for RHEL in the best case) - not to mention the sheer joy and excitement that debugging SELinux AVC denials would produce for end users and desktop application developers.
https://www.freedesktop.org/software/XDevConf/x-security-wal...
https://www.freedesktop.org/software/XDevConf/x-security-wal...
Exactly! It astonishes me that Wayland folks think that replacing the whole graphics stack is somehow easier than using an X extension that already exists. Really speaks to the profound immaturity of the project.
My god, those "wayland folks" were the same people developing X. They were not some unrelated people pushing an agenda. It's always fascinating to see all the arm chair experts saying things how things ought to be done without ever having written a X extension or anything of that sort.
So the fact that someone was a developer of X, means their resilient to following some agenda or non objective opinion? There's a really famous and often quoted talk about X vs Wayland from one of those developers and it was clearly made in a way to present Wayland in a better light by purposely portraying X11 in a bad way, for example by leaving out crucial details. Like in one example they picked on the slow startup time of applications and attributed it to the blocking calls made to X.org, without even mentioning that asynchronous alternatives are not only available, but toolkits like Qt were already using them exclusively at that time. The verdict of course was that X11 is broken and fixing that is almost impossible.
X11 was designed to everything like OS, it's display server, gui library, font manager, printing server and more, X11 was ment to be like qt or gtk, you tell it that you want to display input and it will draw it for you, the issue now it that basically every app now display every window as one bitmap, because we do not want to use 98% of the x11. Also why do you think there wasn't much development activity in X for years now? There is so much wrong with it's state that nobody wants to work with it. It's like talking: why someone would like to use rust or go or c# when we have cobol? why not just write cobol extension?
I'm not really sure what you're getting at. Like I never said there's no point in using or developing Wayland. I was addressing the statement, that Wayland was build by former X11 developers, which supposedly makes them purely objective authorities. Of course, that's not the case as, can be seen by the example I gave.
No, you're arguing a strawman. What I'm saying is, if you have never even tried writing an X extension, likely never properly looked at the X protocol (let alone it's implementation) you have no leg to stand on to make technical criticism of the people who did the work and then decided it was too much work and build something else.
And, have you written a Wayland extension and a X11 extension and learned the difference? No? Then why should we listen to you?
There isn't really much difference. It's about the same amount of work either way to ship an extension.
In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.
In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.
In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.
In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.
The question was related to the relative difficulty of replacing the whole graphics stack vs. patching in support for an X extension that has existed for longer than Wayland. One of these things is far, far less work than the other.
As someone who has done both, I respectfully disagree.
> With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
Can you elaborate?
This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
Can you elaborate?
This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.
In X11, every client is equal.
In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.
There is more information here: https://phabricator.kde.org/T4449#192501
In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.
There is more information here: https://phabricator.kde.org/T4449#192501
Leaving aside for the moment that this policy is only a partial protection against a malicious client, the same policy could well be implemented in X11. (The window manager is not fully equal.)
At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).
People actively chose not to do this and instead delayed progress by at least a decade.
Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.
At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).
People actively chose not to do this and instead delayed progress by at least a decade.
Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.
X12 is simply called Wayland.
Again, long time Linux user and this really doesn't tell me why Wayland is good, it tells me that the Linux ecosystem is getting frog-boiled into accepting the same sort of frightfully dumb practices that the other operating systems have been doing for years? How did we get to a place where I have to pit the security of some of my apps against other apps?
“With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.
”With Wayland, each app only sees their own pixels.”
Out of curiosity, if this is true, how are screenshots / screen recorders implemented? Do they require some special permissions? And if this is the case, why wouldn’t any app be able to acquire these special permissions?
”With Wayland, each app only sees their own pixels.”
Out of curiosity, if this is true, how are screenshots / screen recorders implemented? Do they require some special permissions? And if this is the case, why wouldn’t any app be able to acquire these special permissions?
This is currently why a lot of people are complaining screen recorders do not work.
There are solutions to this, which allow finer grained access to screen recording in future, but there are a couple of competing standards right now.
There are solutions to this, which allow finer grained access to screen recording in future, but there are a couple of competing standards right now.
You said Xorg is a network system twice and I don't think you did enough research once. Wherein client and server are local it doesn't doesn't communicate via the network stack. The problem you imagine exists only in your imagination not reality.
I don't care if xorg runs as root and I don't need to run an instance of xorg per application I simply install software from trusted sources and haven't managed to get malware between 2003 and now. I also didn't have issues with tearing in 2003 and I don't now.
Generally speaking QT and GTK and other toolkits must concern themselves with the details of X others concern themselves with QT or GTK as they would under wayland. It is extremely likely that all players in the overall ecosystem who never had to specifically worry about X in many years have had more issues, work, and tears from wayland development than they would have had for the remainder of the next century with X.
This is nearly entirely about presenting a saner stable base to improve the work for a tiny number of people actually developing the graphics stack in Linux to build upon and unfortunately they made poor design decisions at the start that have led to it taking 12 years and still not being ready for prime time in some ways.
After doing the necessary research to understand the topic you could construct another post about the shortcomings of X that is actually factually correct but it would still be beside the point. Wayland would still be a poor work that squandered a lot of the opportunity of a clean slate despite its authors being in perhaps the best position possible to do so. In 20 years Linux if it exists on the desktop will be a weird opaque overengineered system that works when it works and is impossible for an end user to understand why it is misbehaving when it doesn't.
On the bright side due to package management the windows solution of pave over the install and start over could probably be configured to automatically reinstall all your software for you!
I don't care if xorg runs as root and I don't need to run an instance of xorg per application I simply install software from trusted sources and haven't managed to get malware between 2003 and now. I also didn't have issues with tearing in 2003 and I don't now.
Generally speaking QT and GTK and other toolkits must concern themselves with the details of X others concern themselves with QT or GTK as they would under wayland. It is extremely likely that all players in the overall ecosystem who never had to specifically worry about X in many years have had more issues, work, and tears from wayland development than they would have had for the remainder of the next century with X.
This is nearly entirely about presenting a saner stable base to improve the work for a tiny number of people actually developing the graphics stack in Linux to build upon and unfortunately they made poor design decisions at the start that have led to it taking 12 years and still not being ready for prime time in some ways.
After doing the necessary research to understand the topic you could construct another post about the shortcomings of X that is actually factually correct but it would still be beside the point. Wayland would still be a poor work that squandered a lot of the opportunity of a clean slate despite its authors being in perhaps the best position possible to do so. In 20 years Linux if it exists on the desktop will be a weird opaque overengineered system that works when it works and is impossible for an end user to understand why it is misbehaving when it doesn't.
On the bright side due to package management the windows solution of pave over the install and start over could probably be configured to automatically reinstall all your software for you!
After a few years of wondering about the "why," I find this comment very illustrating; it feels like Wayland is one of many Linux related efforts (like Gnome and KDE) that are not particularly interested in a high level of interoperability and/or long term durability. Instead, the goal is more in the direction of trying to make their preferred way of things more dominant in the ecosystem. Now, if those efforts are actually good at it then more power to them. But most of the time, that doesn't happen, and I think it harms the Linux ecosystem, one that I am a fan of, overall.
How does it harm the ecosystem to place the fundamental abstraction of the goddamn DISPLAY server over something that actually was created after GPUs was a thing?
The X server is maxed out, or as a core maintainer said, you can only apply this many lipstick to a pig. It is fundamentally broken. But the X api is not, it will be supported forever in terms of XWayland. Which is a net win, we get proper graphics, and apps will be backward compatible.
The X server is maxed out, or as a core maintainer said, you can only apply this many lipstick to a pig. It is fundamentally broken. But the X api is not, it will be supported forever in terms of XWayland. Which is a net win, we get proper graphics, and apps will be backward compatible.
> It is fundamentally broken.
The Wayland developers disagree with you:
https://wayland.freedesktop.org/faq.html#heading_toc_j_5
"It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.
The Wayland developers disagree with you:
https://wayland.freedesktop.org/faq.html#heading_toc_j_5
"It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.
The problem with X11 was never that you can't add things to it, the problem is that you can't remove things from it.
First, this isn't true - watch the youtube the other person in this thread put where he tells a story about how they deleting about 1/3 of the code (15:19), but secondly even if they didn't, why is that a problem?
Breaking user's applications isn't actually a virtue.
Breaking user's applications isn't actually a virtue.
https://www.youtube.com/watch?v=GWQh_DmDLKQ
Just watch it.
Just watch it.
Did you watch and understand it? This presentation is nothing but a highly one-sided and subjective talk, which gladly bends the truth or leaves out crucial details to get a good laugh from the audience.
Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it:
So either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part.
Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode.
*updated benchmark results with the actual results from hyperfine (10 runs each)
Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it:
Weston + Chromium (Wayland mode): 731.3 ms ± 39.4 ms
Sway + Chromium (Wayland mode): 688.2 ms ± 22.7 ms
Sway + Chromium (XWayland): 667.2 ms ± 16.6 ms
X.org + i3 + Chromium: 661.3ms ± 17.2 msSo either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part.
Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode.
*updated benchmark results with the actual results from hyperfine (10 runs each)
The video is quite old. And I think you should add a compositor on top of i3 to measure the same thing.
The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
With X.org + i3 + picom (GLX backend, animations and vsync enabled) I get: 665.8 ms ± 19.3 ms
So it doesn't seem to have any significant influence either.
So it doesn't seem to have any significant influence either.
Thanks for benchmarking, but as I mentioned, this was/is not a significant problem that would give way for Wayland. What I wrote in the second part of my comment is.
If you have enough permissions to intercept keystrokes in X via network monitoring then most likely you have enough permissions to intercept keystrokes in wayland e.g. by ptrace.
You're not using TCP for local X, it's all Unix domain sockets and SHM. Hard to get any faster on Linux.
One could certainly implement feature emulation to preserve backward compatibility with evolving hardware. Or just deprecate feature, X over network was pretty much broken for a long time.
Not saying Wayland isn't an improvement over X but a lot of supposed limitations of X are often misrepresented and exaggerated.
You're not using TCP for local X, it's all Unix domain sockets and SHM. Hard to get any faster on Linux.
One could certainly implement feature emulation to preserve backward compatibility with evolving hardware. Or just deprecate feature, X over network was pretty much broken for a long time.
Not saying Wayland isn't an improvement over X but a lot of supposed limitations of X are often misrepresented and exaggerated.
Also, all the other “problems” with X have been solved for years. (No tearing, no root X1q on my box, in particular)
I very much agree with what you wrote. I'll just add a comment:
> Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.
For example: When I switched, an unexpected bonus I experienced was that my touchpad's behavior got orders of magnitude better. So I googled around a bit, and it turns out that almost all touchpad improvements just happen to occur on Wayland because the people who are interested in that aren't interested in wading through the X swamp in order to implement their stuff. (I mean, have you looked at the X code? Oh dear, oh dear, it's a daunting thing!)
> Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.
For example: When I switched, an unexpected bonus I experienced was that my touchpad's behavior got orders of magnitude better. So I googled around a bit, and it turns out that almost all touchpad improvements just happen to occur on Wayland because the people who are interested in that aren't interested in wading through the X swamp in order to implement their stuff. (I mean, have you looked at the X code? Oh dear, oh dear, it's a daunting thing!)
> This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.
This is something I don't understand about Wayland. How is it possible that something that is supposed to be much easier and more attractive for developers after TEN+ years of development still has so many issues ?
This is something I don't understand about Wayland. How is it possible that something that is supposed to be much easier and more attractive for developers after TEN+ years of development still has so many issues ?
The protocol had been in development for that long, most compositors for a few years, and clients change their implementation up to their own schedule.
I see it as a “failing” of the bazaar way of development, linux can’t just say we now use this API. So there is an inherent not enough user on the new API to bother porting, and due to not enough user it is not as streamlined/stable, and you have a vicious circle. But I have to say the issues with wayland are heavily overstated, and I think it is out of this cycle, and is getting quite a bit of steam.
I see it as a “failing” of the bazaar way of development, linux can’t just say we now use this API. So there is an inherent not enough user on the new API to bother porting, and due to not enough user it is not as streamlined/stable, and you have a vicious circle. But I have to say the issues with wayland are heavily overstated, and I think it is out of this cycle, and is getting quite a bit of steam.
On the other hand, a bunch of X11 issues were just listed, and X has existed three times as long. Some issues are architectural and thus probably not solvable, some are just persistent annoyances that must be difficult to fix and likely will not get fixed because X11 has so little active development anymore. X has enough issues that a good portion of the community said, "we've got to fix this". And frankly, I've used software from multi-billion dollar corporations that gives me more trouble in a day than Wayland does in a month.
Just a note: It is due to libinput, which as far as I know can be used with X as well, but I haven’t personally done so.
Libinput is not a Wayland thing, and it's actually the recommended solution on X11.
> Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)
I am quite sure that there is something wrong with your system if your X clients run through the IP stack by default.
I am quite sure that there is something wrong with your system if your X clients run through the IP stack by default.
So, I see and understand these arguments in theory -- but, and I don't think I'm alone, none of them are actually pressing?
I'm running Openbox/Xubuntu on a 4K monitor, doing some awesome equivalent-of-4-monitors work, then playing all the steam games I want with the Proton and the decent AMD GPU, all under X. "Font size is a little weird sometimes" is my only gripe?
Put differently, I understand "hacking around the issue" criticism in theory -- but if you applied that sort of purity to, say, web programming -- step one would be, okay, first get rid of Javascript, an idea that I really do like in theory, but I know it's not happening.
I'm running Openbox/Xubuntu on a 4K monitor, doing some awesome equivalent-of-4-monitors work, then playing all the steam games I want with the Proton and the decent AMD GPU, all under X. "Font size is a little weird sometimes" is my only gripe?
Put differently, I understand "hacking around the issue" criticism in theory -- but if you applied that sort of purity to, say, web programming -- step one would be, okay, first get rid of Javascript, an idea that I really do like in theory, but I know it's not happening.
I find it personally a bit hilarious - Wayland has been Going To Be Great Soon for over a decade.
I've never even had a reason to want to run it.
But I'm sure it'll be great, any day now.
I've never even had a reason to want to run it.
But I'm sure it'll be great, any day now.
Maybe actually trying it and adding something to the discussion would be better?
I find Wayland is great already for my usage, and has been for the last two years. If Xorg works for you and Wayland doesn't, that's perfectly fine too.
Don't get me wrong - I would love to not deal with certain X warts. (I see substantially fewer warts than other people do, but that's just me.)
It just seems Wayland's combination of technical requirements and political entanglements make it a sort of Zeno's Project, doomed to asymptotically approach peoples' expectations and desires, but never reach them.
It just seems Wayland's combination of technical requirements and political entanglements make it a sort of Zeno's Project, doomed to asymptotically approach peoples' expectations and desires, but never reach them.
>I find it personally a bit hilarious - Wayland has been Going To Be Great Soon for over a decade.
So? The same has been the case for desktop Linux in general, for 2 decades.
So? The same has been the case for desktop Linux in general, for 2 decades.
Desktop linux actually worked pretty well in 2003 for my purposes. I started on Fedora Core 1. I burned a dvd hit the magic key to select a boot target booted it up told the installer what time zone I was in and what disks it could use and such details and rebooted after a while.
Wine sucked and there was less software existed but it was perfectly possible to do the normal tasks one did with a computer.
Wine sucked and there was less software existed but it was perfectly possible to do the normal tasks one did with a computer.
Back on my IBM 386/75MHz (yes, really), linux could only boot at 25MHz, yet its desktop environment was faster, prettier and more featureful than Windows @75MHz
Edit: I guess it was a 486 in a 386 motherboard. Windows was definitely slower at 75MHz than Linux at 25MHz though:
http://ps-2.kev009.com/sandy55/Interposer/386_upgrade.html#R...
Edit: I guess it was a 486 in a 386 motherboard. Windows was definitely slower at 75MHz than Linux at 25MHz though:
http://ps-2.kev009.com/sandy55/Interposer/386_upgrade.html#R...
> So? The same has been the case for desktop Linux in general, for 2 decades.
Some of us have been running Linux desktops for over two decades. Nothing more fun than setting Modelines manually for your VESA card:
* https://en.wikipedia.org/wiki/XFree86_Modeline
Some of us have been running Linux desktops for over two decades. Nothing more fun than setting Modelines manually for your VESA card:
* https://en.wikipedia.org/wiki/XFree86_Modeline
My Gentoo/Xfce multiple monitors with Nvidia has been great for at least 10 years.
Linux Desktop is Great. Wayland is still in the process of becoming great (I think it's making good progress too)
Linux Desktop is Great. Wayland is still in the process of becoming great (I think it's making good progress too)
Linux desktop has been perfectly fine for at least 1.5 of those decades.
From what I gather its a chicken and egg issue. Wayland would get more attention and development if it had more users. It would have more users if it had more feature development. Although a lot of the bigger gaps are closed or closing now. OBS now works on Wayland as of 03/30/2021 and Fedora plans to ship Wayland as the default.
Fedora Workstation (i.e. GNOME) has already been shipping with Wayland by default. What's new is that Fedora KDE is also going to ship with Wayland by default.
Reference: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPl...
Reference: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPl...
> Fractional scaling is kind of the most visible thing today.
And also perfectly possible with X11 because the pitch information is exposed via the Xrandr extention
> Problem: tearing, solvable with double buffering, maybe.
Solved since ages. Just enable Tearfree in your Xorg.conf. That also shows how great X11 really is. It allows you the choice to turn it on or off. Because Tearfree comes at a cost of latency.
> Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
OpneBSD solved that two decades ago. Also it perfectly possible on Linux to run X11 as non-Root.
> Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program.
This is a feature not a bug. The security paradigm is blacklisting (which means sandboxing untrusted apps) instead of whitelising (which means locking everything up and only allow the compositor to do stuff). Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.
> Problem: Xorg is a network system, meaning it is very inefficient.
X11 runs even on 386's and beats Wayland in every performance metric, especially latency. After 13 years of development only some compositors come close to X11's performance.
> Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features.
Backwards compatibility is a major feature even 40 year old Software runs on current Xorg which is an impressive feat. As for the "hardware features": DRI3 uses the exact same buffer sharing mechanism as the major Wayland compositors do. Wayland offers zero advantage in exploited Hardware features. On the contrary X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
> Overall, wayland is a good clean slate, it’s been in development a long time.
It is a clean slate, but a very bad one. The wrong philosophy ("every frame is perfect") and the wrong abstractions ("everything in the universe is a buffer made of RGB values") make it a major step backwards in computer graphics on Unix/Linux.
And also perfectly possible with X11 because the pitch information is exposed via the Xrandr extention
> Problem: tearing, solvable with double buffering, maybe.
Solved since ages. Just enable Tearfree in your Xorg.conf. That also shows how great X11 really is. It allows you the choice to turn it on or off. Because Tearfree comes at a cost of latency.
> Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
OpneBSD solved that two decades ago. Also it perfectly possible on Linux to run X11 as non-Root.
> Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program.
This is a feature not a bug. The security paradigm is blacklisting (which means sandboxing untrusted apps) instead of whitelising (which means locking everything up and only allow the compositor to do stuff). Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.
> Problem: Xorg is a network system, meaning it is very inefficient.
X11 runs even on 386's and beats Wayland in every performance metric, especially latency. After 13 years of development only some compositors come close to X11's performance.
> Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features.
Backwards compatibility is a major feature even 40 year old Software runs on current Xorg which is an impressive feat. As for the "hardware features": DRI3 uses the exact same buffer sharing mechanism as the major Wayland compositors do. Wayland offers zero advantage in exploited Hardware features. On the contrary X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
> Overall, wayland is a good clean slate, it’s been in development a long time.
It is a clean slate, but a very bad one. The wrong philosophy ("every frame is perfect") and the wrong abstractions ("everything in the universe is a buffer made of RGB values") make it a major step backwards in computer graphics on Unix/Linux.
> perfectly possible with X11 because the pitch information is exposed via the Xrandr extention
Only the "Windows" kind of scaling where the app works in non-scaled, real pixels and does everything by itself. Not the "Apple" kind of scaling that Wayland supports, where you have logical pixels backed by 2x/3x/… the physical pixels. (Like many things Apple does, this was invented for good reasons. Positioning a window to be on both a 1x and a 2x monitor just works with that kind of scaling, without the app ever having to consider the displays it touches.)
> Solved since ages. Just enable Tearfree in your Xorg.conf.
That's a driver-specific hack that kinda maybe works sometimes. Sometimes you need to juggle compositor options combined with that and nothing works anyway.
> X11 runs even on 386's and beats Wayland in every performance metric, especially latency.
Any composited X11 desktop is slower than a Wayland one, with the Xorg server acting as a bloated IPC broker in between the compositor and the client.
Yeah, you can get really low latency if you just don't composite at all. Go back to Windows 95 if you think that's acceptable :)
> X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
I'm sure pretty much all production Wayland compositors use the cursor layer. wlroots for sure does. (But I don't think it's a big deal under heavy load, there the problem is the display server even processing the mouse events at all first.)
Weston goes further and can use HW layers for actual surface compositing when possible. wlroots is going to gain that power soon-ish with libliftoff.
> The wrong philosophy ("every frame is perfect")
Again, feel free to use Windows 95.
For anyone used to current commercial desktop and mobile UIs, any imperfect frames are unacceptable, artifacts like tearing make your system look like a complete joke. Apple computers didn't show imperfect frames since the early early 2000s PowerPC era. Not matching that is a complete shame.
Only the "Windows" kind of scaling where the app works in non-scaled, real pixels and does everything by itself. Not the "Apple" kind of scaling that Wayland supports, where you have logical pixels backed by 2x/3x/… the physical pixels. (Like many things Apple does, this was invented for good reasons. Positioning a window to be on both a 1x and a 2x monitor just works with that kind of scaling, without the app ever having to consider the displays it touches.)
> Solved since ages. Just enable Tearfree in your Xorg.conf.
That's a driver-specific hack that kinda maybe works sometimes. Sometimes you need to juggle compositor options combined with that and nothing works anyway.
> X11 runs even on 386's and beats Wayland in every performance metric, especially latency.
Any composited X11 desktop is slower than a Wayland one, with the Xorg server acting as a bloated IPC broker in between the compositor and the client.
Yeah, you can get really low latency if you just don't composite at all. Go back to Windows 95 if you think that's acceptable :)
> X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
I'm sure pretty much all production Wayland compositors use the cursor layer. wlroots for sure does. (But I don't think it's a big deal under heavy load, there the problem is the display server even processing the mouse events at all first.)
Weston goes further and can use HW layers for actual surface compositing when possible. wlroots is going to gain that power soon-ish with libliftoff.
> The wrong philosophy ("every frame is perfect")
Again, feel free to use Windows 95.
For anyone used to current commercial desktop and mobile UIs, any imperfect frames are unacceptable, artifacts like tearing make your system look like a complete joke. Apple computers didn't show imperfect frames since the early early 2000s PowerPC era. Not matching that is a complete shame.
> logical pixels backed by 2x/3x/… the physical pixels.
This is not fractional scaling. Fractional scaling has to be done by the application itself (even on Wayland).
> That's a driver-specific hack
It is not a hack. It is a solution and a very good one because DDX drivers can make use of vendor specific 2D acceleration and therefore achieve much better latency with the tearfree option on X11 than Wayland ever will where everything runs through the 3D pipeline by default.
> Any composited X11 desktop is slower than a Wayland one
If you enable Tearfree you don't need a compositor if the driver works properly. Of course X11 compositors with fancy blur effects have bad performance. I always turn them off.
> Go back to Windows 95 if you think that's acceptable :)
Why don't you switch to Android? Android already does everything that Wayland fans want and better.
> I'm sure pretty much all production Wayland compositors use the cursor layer.
I get severe mouse stuttering on high CPU or GPU load. A problem that was solved on X11 20 years ago. I have no idea what wlroots really does but it does it definitely wrong.
> Go back to Windows 95 if you think that's acceptable :)
The value of X11 is the ecosystem and platform it provides. If you want Linux with a compositor switch to Android. There you also have your sandboxing and whatnot. Don't turn the Linux Desktop into a Phone OS. As Desktop OS I genuinely prefer Windows 95 over Android.
> Apple computers didn't show imperfect frames since the early early 2000s PowerPC era.
Ever used OS X on those? They are barely usable because of severe lag and stuttering. But yeah the frames were so perfect that most people decided to switch back to MacOS 9 to do real work.
This is not fractional scaling. Fractional scaling has to be done by the application itself (even on Wayland).
> That's a driver-specific hack
It is not a hack. It is a solution and a very good one because DDX drivers can make use of vendor specific 2D acceleration and therefore achieve much better latency with the tearfree option on X11 than Wayland ever will where everything runs through the 3D pipeline by default.
> Any composited X11 desktop is slower than a Wayland one
If you enable Tearfree you don't need a compositor if the driver works properly. Of course X11 compositors with fancy blur effects have bad performance. I always turn them off.
> Go back to Windows 95 if you think that's acceptable :)
Why don't you switch to Android? Android already does everything that Wayland fans want and better.
> I'm sure pretty much all production Wayland compositors use the cursor layer.
I get severe mouse stuttering on high CPU or GPU load. A problem that was solved on X11 20 years ago. I have no idea what wlroots really does but it does it definitely wrong.
> Go back to Windows 95 if you think that's acceptable :)
The value of X11 is the ecosystem and platform it provides. If you want Linux with a compositor switch to Android. There you also have your sandboxing and whatnot. Don't turn the Linux Desktop into a Phone OS. As Desktop OS I genuinely prefer Windows 95 over Android.
> Apple computers didn't show imperfect frames since the early early 2000s PowerPC era.
Ever used OS X on those? They are barely usable because of severe lag and stuttering. But yeah the frames were so perfect that most people decided to switch back to MacOS 9 to do real work.
> Fractional scaling has to be done by the application itself (even on Wayland).
No, fractional is handled by applications just rendering at 2x and getting downscaled to 1.5x or whatever.
Yeah, the "Windows" way looks sharper on fractional, but the "Apple" downscaling is easier to handle and it looks fine – there were iPhones that did everything like that.
> DDX drivers can make use of vendor specific 2D acceleration
Ah, I remember Intel's various native 2D accelerations (UXA, SNA) – each with its own unique horrific bugs (artifacts all over the screen, all text turning into junk), all eventually sorta deprecated in favor of glamor (OpenGL) with the generic modesetting driver.
There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.
> Ever used OS X on those? They are barely usable because of severe lag and stuttering.
I have an iBook G4 :) Leopard runs perfectly smoothly. Yeah, the very first generation of hardware when OS X was just introduced wasn't ready. The next one was.
No, fractional is handled by applications just rendering at 2x and getting downscaled to 1.5x or whatever.
Yeah, the "Windows" way looks sharper on fractional, but the "Apple" downscaling is easier to handle and it looks fine – there were iPhones that did everything like that.
> DDX drivers can make use of vendor specific 2D acceleration
Ah, I remember Intel's various native 2D accelerations (UXA, SNA) – each with its own unique horrific bugs (artifacts all over the screen, all text turning into junk), all eventually sorta deprecated in favor of glamor (OpenGL) with the generic modesetting driver.
There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.
> Ever used OS X on those? They are barely usable because of severe lag and stuttering.
I have an iBook G4 :) Leopard runs perfectly smoothly. Yeah, the very first generation of hardware when OS X was just introduced wasn't ready. The next one was.
> There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.
It's even more fun when your realize no GPU in the last decade has shipped 2D acceleration capabilities. Wayland uses 3D acceleration because that's what GPUs offer, because that's what the other platforms exclusively offer now.
It's even more fun when your realize no GPU in the last decade has shipped 2D acceleration capabilities. Wayland uses 3D acceleration because that's what GPUs offer, because that's what the other platforms exclusively offer now.
> The security paradigm is blacklisting [...]. Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.
This is absolutely not a good solution. Even if you audited all your software enough to consider it trusted (which is unlikely if you're not a purist - see IDEs, browsers, widevine, Docker ...), it does not guarantee anything is secure. Anything that receives input from the outside might be vulnerable to an RCE. If you're running it under a different user or in a jail, the impact is limited - unless it can access your X server, in which case it can simply log everything you type and escalate.
Jailing an app is basically impossible under X. Yes, you can use Zephyr, but you're not going to be able to watch a video there and you're WM integration is going to be miserable as well. And realistically you'd really need to jail most apps.
X11 might work for a lot of things, but blacklisting is absolutely not a superior approach.
This is absolutely not a good solution. Even if you audited all your software enough to consider it trusted (which is unlikely if you're not a purist - see IDEs, browsers, widevine, Docker ...), it does not guarantee anything is secure. Anything that receives input from the outside might be vulnerable to an RCE. If you're running it under a different user or in a jail, the impact is limited - unless it can access your X server, in which case it can simply log everything you type and escalate.
Jailing an app is basically impossible under X. Yes, you can use Zephyr, but you're not going to be able to watch a video there and you're WM integration is going to be miserable as well. And realistically you'd really need to jail most apps.
X11 might work for a lot of things, but blacklisting is absolutely not a superior approach.
> it does not guarantee anything is secure.
Indeed. But looking at the state of the average Wayland compositor right now I trust all of my X11 software more than I trust Wayland. Especially when X11 and most clients have been battle tested for up to 35 years.
Besides that, you can also use Xpra for sandboxing which has better desktop integration.
Indeed. But looking at the state of the average Wayland compositor right now I trust all of my X11 software more than I trust Wayland. Especially when X11 and most clients have been battle tested for up to 35 years.
Besides that, you can also use Xpra for sandboxing which has better desktop integration.
[deleted]
> X11 is in no way broken enough to justify such a huge change
Oh it absolutely is. The entire design of X11 is broken and a barrier to how applications & drivers actually work.
There's a reason that literally everyone else switched away from an X11-style model to a Wayland-style one. That is, MacOS, Windows & Android are all Wayland-style compositor designs. This was the major transition that Microsoft did from Windows XP to Windows Vista.
This is part of the reason that things like video playback in browsers on Linux is just awful. What browsers (or really any modern UI stack) want is just a system compositor that speaks buffers and transactions. Transactions are important to synchronize composition changes and content changes - for example, when you scroll a webpage with a video in it. It's better for power if the video is in a system composition layer, as then it can use a hardware overlay plane instead of being GPU composited (reduces power consumption). But then you need the browsers updated rendering of the scroll position to be synchronized with that composition update. This type of capability is standard on all major platforms at this point.
You can do this everywhere, except on X11. Possibly doable with extensions, but at that point your "extensions" are "completely change everything about the base X11 design & promises" as X11's base design & promises specifically don't provide anything like this.
X11's fundamental design is completely wrong & backwards. That's why a clean slate is necessary. Yes this migration is painful (see Windows Vista), but if it was actually pushed it would be a short term pain and the ecosystem would come out the other side healthier than it started (see Windows 7)
Oh it absolutely is. The entire design of X11 is broken and a barrier to how applications & drivers actually work.
There's a reason that literally everyone else switched away from an X11-style model to a Wayland-style one. That is, MacOS, Windows & Android are all Wayland-style compositor designs. This was the major transition that Microsoft did from Windows XP to Windows Vista.
This is part of the reason that things like video playback in browsers on Linux is just awful. What browsers (or really any modern UI stack) want is just a system compositor that speaks buffers and transactions. Transactions are important to synchronize composition changes and content changes - for example, when you scroll a webpage with a video in it. It's better for power if the video is in a system composition layer, as then it can use a hardware overlay plane instead of being GPU composited (reduces power consumption). But then you need the browsers updated rendering of the scroll position to be synchronized with that composition update. This type of capability is standard on all major platforms at this point.
You can do this everywhere, except on X11. Possibly doable with extensions, but at that point your "extensions" are "completely change everything about the base X11 design & promises" as X11's base design & promises specifically don't provide anything like this.
X11's fundamental design is completely wrong & backwards. That's why a clean slate is necessary. Yes this migration is painful (see Windows Vista), but if it was actually pushed it would be a short term pain and the ecosystem would come out the other side healthier than it started (see Windows 7)
> X11 is in no way broken enough to justify such a huge change
And why do you think you have sufficient knowledge on the topic to assume that? I do assume you have not read the source code of the X server, isn’t it a bit “cocky” to state such a statement, which is in opposition to what the actual X maintainers say, who actually created wayland? It’s not like a project from nothing, it was created with the shortcomings of X in mind.
And why do you think you have sufficient knowledge on the topic to assume that? I do assume you have not read the source code of the X server, isn’t it a bit “cocky” to state such a statement, which is in opposition to what the actual X maintainers say, who actually created wayland? It’s not like a project from nothing, it was created with the shortcomings of X in mind.
> in opposition to what the actual X maintainers say, who actually created wayland?
[citation needed]
[citation needed]
First off, a 45 minute long video isn't much of a citation. Where, exactly, are you citing?
Secondly, this isn't the first time I've had people point to this same video. It doesn't actually say what you claim it says. It says the creator of Wayland worked on X (though actually his core focus was DRI2, which btw, is not X), and the one individual speaker in that video worked on X a long time ago (specifically his focus was on keyboard input).
Their claim is more "X is redundant" than "X is hopeless". They're wrong, of course, the video makes absurd claims like "nobody uses core X11". Maybe they don't since they work in niches, but in the real world, plenty of people do... and that's the part of the X server nobody actually complains about. Even Wayland are perfectly OK with that part! (See retaining it in XWayland. When these wayland devs complain about Xorg their focus is usually on the driver side. Well, hate to break it to them, drivers are always ugly. See the link we're commenting on, if Wayland actually works on all the devices Xorg works on, it'll be just as ugly.)
Secondly, this isn't the first time I've had people point to this same video. It doesn't actually say what you claim it says. It says the creator of Wayland worked on X (though actually his core focus was DRI2, which btw, is not X), and the one individual speaker in that video worked on X a long time ago (specifically his focus was on keyboard input).
Their claim is more "X is redundant" than "X is hopeless". They're wrong, of course, the video makes absurd claims like "nobody uses core X11". Maybe they don't since they work in niches, but in the real world, plenty of people do... and that's the part of the X server nobody actually complains about. Even Wayland are perfectly OK with that part! (See retaining it in XWayland. When these wayland devs complain about Xorg their focus is usually on the driver side. Well, hate to break it to them, drivers are always ugly. See the link we're commenting on, if Wayland actually works on all the devices Xorg works on, it'll be just as ugly.)
How about the actual technical details in the video? With a compositor on top of X, what purpose does X actually serve other than being an unnecessary complicated IPC layer that duplicates many of the messages?
Also, there have been another HN post with “X is abadonware” or similarly titled, which was written by another X maintainer. But feel free to check the mailing list as well looking at activity.
Also, there have been another HN post with “X is abadonware” or similarly titled, which was written by another X maintainer. But feel free to check the mailing list as well looking at activity.
> With a compositor on top of X
I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway.
And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.
I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway.
And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.
> I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
Have you tried watching a video in full screen?
> But even if you do, the compositor only does one job: layer graphics
Yes, and this small little detail is not solved by X, but Wayland.
> Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc.
And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it.
> I love the way the presenter claims the specs are impossible but I managed to implement them
What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere.
And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.
Have you tried watching a video in full screen?
> But even if you do, the compositor only does one job: layer graphics
Yes, and this small little detail is not solved by X, but Wayland.
> Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc.
And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it.
> I love the way the presenter claims the specs are impossible but I managed to implement them
What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere.
And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.
> Have you tried watching a video in full screen?
Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway?
You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy.
The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker.
> X’s APIs are globally broadcasted
No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it.
> What part of it?
Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server.
And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works.
That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc.
(Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!)
wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)
Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway?
You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy.
The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker.
> X’s APIs are globally broadcasted
No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it.
> What part of it?
Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server.
And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works.
That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc.
(Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!)
wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)
Well, I can continue on listing problems with X. How about HDPI? Or mixed HDPI? I’m sure some things can be retrofitted, but I still don’t see why should we continue with a protocol not planned for/with modern hardware in mind.
Also, regarding network transparency. As you note, most apps are no longer network transparent, and remote window streaming can be much better solved with modern compressions/encoding. It doesn’t have to be part of the core protocol, the latter should only concern itself with displaying rectangles on the screen. Everything else can be built on top of it.
Also, while in itself not a good argument, both MacOS and windows use a compositor since forever.
Also, regarding network transparency. As you note, most apps are no longer network transparent, and remote window streaming can be much better solved with modern compressions/encoding. It doesn’t have to be part of the core protocol, the latter should only concern itself with displaying rectangles on the screen. Everything else can be built on top of it.
Also, while in itself not a good argument, both MacOS and windows use a compositor since forever.
2 year wayland (sway) user here. Every time anything is posted here about wayland, I read about some people's crazy issues. Karma brings them all out of the woodwork, I guess.
If message boards like HN are where you're getting this impression, just beware of sample bias. Remember that everyone on Fedora and/or KDE has been running wayland for literal years. That is a lot of users, and not enough complaints to make them consider reverting.
Fwiw here's my counter anecdata:
I'm on arch with swaywm, meaning my system is in no way "out of the box". I have gone back to X from time to time, and... it drives me crazy. Everything is blurry, it takes an hour off my battery time, and it FEELS laggy and unresponsive. Oh, and the experience of installing anything involves 5 extra packages (automatically included, at least) to work around X stuff. God help you if you want to configure an input method; it goes through AT LEAST 2 layers. For some input methods (touchscreens, i'm looking at you), you have brittle hacks like one layer is just reading the debug log of another. Anyway every settings change you make requires restarting your whole WM, and probably fiddling with several 3rd party tools to understand and make it easier... no thanks.
Even when I could only screen share between xwayland apps, and I really tried to go back, I couldn't stomach it. The wayland experience for me is just so much better across so many dimensions. I can only imagine what it's like for my friends who use OOTB setups and aren't even aware they're on Wayland.
If message boards like HN are where you're getting this impression, just beware of sample bias. Remember that everyone on Fedora and/or KDE has been running wayland for literal years. That is a lot of users, and not enough complaints to make them consider reverting.
Fwiw here's my counter anecdata:
I'm on arch with swaywm, meaning my system is in no way "out of the box". I have gone back to X from time to time, and... it drives me crazy. Everything is blurry, it takes an hour off my battery time, and it FEELS laggy and unresponsive. Oh, and the experience of installing anything involves 5 extra packages (automatically included, at least) to work around X stuff. God help you if you want to configure an input method; it goes through AT LEAST 2 layers. For some input methods (touchscreens, i'm looking at you), you have brittle hacks like one layer is just reading the debug log of another. Anyway every settings change you make requires restarting your whole WM, and probably fiddling with several 3rd party tools to understand and make it easier... no thanks.
Even when I could only screen share between xwayland apps, and I really tried to go back, I couldn't stomach it. The wayland experience for me is just so much better across so many dimensions. I can only imagine what it's like for my friends who use OOTB setups and aren't even aware they're on Wayland.
X11 is a security nightmare. It is absolutely broken enough to justify a huge change.
Installing random software off the internet or from a market that developers have direct access to poison is a security nightmare that isn't much fixed by wayland.
Allowing smoking between barrels of gunpowder is different than in an open space.
Wayland is a necessary part of security, but not sufficient.
Wayland is a necessary part of security, but not sufficient.
It's security theater. If I can run a process on your machine under your user account, you can bet I can keylog you, X11 or no.
Try it. You can’t unless you’ve found some exploit in a given wayland compositor.
Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
Here are a few ways off the top of my head that don't require exploiting Wayland or gaining access to the `input` group (or whatever group owns the /dev/input/* events), using nothing more than a local shell under your user account:
* Using ptrace(2) to hook into your running processes and grabbing key data that way
* Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application
* Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root.
* Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1].
Come back when you understand the problem.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
* Using ptrace(2) to hook into your running processes and grabbing key data that way
* Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application
* Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root.
* Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1].
Come back when you understand the problem.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
What is not clear about necessary but not sufficient? Of course sandboxing is necessary, but graphics is a deliberate hole in a sandbox. If that hole is unsecure, the whole thing is.
How does X help here?
How does X help here?
X already solves this particular input hole with the XACE extension. No need to replace the whole graphics stack when the X server is already capable of addressing this issue.
XACE doesn't solve it. As mentioned elsewhere, that's dependent on SELinux. The idea with Wayland is to make things more secure everywhere, and not just on systems that have a particular LSM.
Wrong. XACE is independent of SELinux and LSMs. It's just a protocol for writing plugins to X servers that filter which events X clients can see.
That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
It's not wrong, it's not FUD, and that doesn't change anything. The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture... which is what they had to do in Wayland anyway. XACE isn't really built for anything besides MAC either, so it's inadequate for doing anything that isn't an LSM. It also has a problem where new hooks need to be added for every new X extension, and that didn't happen so now it's outdated. In Wayland that entire concept was replaced with a single API function to do generic traffic filtering.
It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
Unless you are using different vms for isolation it's all open barrels of gunpowder all the time.
I agree with you in general, but even if you use jailed apps in X, they can keylog. It can be solved with nested X sessions, but that would only add yet another hacky patch.
The issue is X11 as we know it has no developers left. If nobody is around to maintain it, the world will move on, no ramrod necessary. More info: https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
There are plenty of developers left. It is just release management refuses to make new releases.
I suppose that theory is possible. A proxy for developer availability might be to check the primary mailing list of xorg for the full month of march: https://lists.x.org/archives/xorg-devel/2021-March/thread.ht.... There wasn't much directly related to xorg-xserver itself. As a point of comparison, here is March for QEMU: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/thr...
After years of misleading propaganda about how X11 is "deprecated" now I would expect no less. Besides maybe the main communication channel for development is somewhere else.
Most developer activity related to Linux graphics is in dri-devel, it's been like this for quite a while. The X development channels have been mostly dead outside of discussion of XWayland. I doubt you'll see anyone starting any major new features in X.
There are still some active PRs
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Someone is trying to get multi-touch support merged, but is waiting for a review.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Someone is trying to get multi-touch support merged, but is waiting for a review.
I hope someone comes along to review those, but I don't see there being much interest in it.
If this lie helps you sleep at night.. The reality is out there, why don’t you have a look?
There are reasons, many times those reasons are obvious to whomever is actually implimenting the changes but not to others outside of it. The reasons have been highlighted hundreds of times and unless there's actual arguments against those reasons the discussion of "I don't like wayland" is a distractive circle that ignores the content of the original post.
It's an old story.
A conservative rewrite, that amends those things experience has shown were mistakes but were always retained for compatibility, is rare, since the impulse to rewrite is revolutionary in nature. A rewrite is treated as an opportunity to remake the world in a new image (with a new set of mistakes to uncover).
A conservative rewrite, that amends those things experience has shown were mistakes but were always retained for compatibility, is rare, since the impulse to rewrite is revolutionary in nature. A rewrite is treated as an opportunity to remake the world in a new image (with a new set of mistakes to uncover).
AIUI rewriting X wouldn't be much use anyway, because the problem is mostly in the protocol not the actual codebase implementing the protocol.
The problem here is that a lot of stuff X does relies on horribly unsafe (mis)features of X. And of course wayland had to break compatibility with those things.
If the user wants to do X which involves increased danger to the user giving users a way to tell the system that app X has the privilege of doing X but not allowing all applications to do X is potentially viable but telling users you don't need to do X anymore is a much harder sale.
It needn't be a prompt users will quickly be prompted to click yes to it could easily be an option in settings or at communicated at install time.
It needn't be a prompt users will quickly be prompted to click yes to it could easily be an option in settings or at communicated at install time.
The main thing that has me cheering Wayland on is that it seems like the only, really viable, path forward for the Linux desktop environment. The developers of X11, and more or less the rest of the Linux community, decided that X11 wasn’t the best path to take into the future. So X11 is treated like a legacy technology. It will keep getting patched and will be supported for the foreseeable future but it’s hard to see anyone wanting to invest a lot of effort innovating and moving the tech forward when everyone agrees there’s no future in it. I’m not aware of any frameworks that are really competing with Wayland for the next generation.
There will be stumbling blocks as with any new technology, especially one that interrelates with so many systems but Waylands core architecture seems to be solid.
Personally, I’m still using I3 and don’t see many immediate benefits to switching over to Sway (the Wayland fork of I3). I am cheering Wayland on though and making the switch is somewhere on my todo list. What other path forward is there for desktop Linux?
There will be stumbling blocks as with any new technology, especially one that interrelates with so many systems but Waylands core architecture seems to be solid.
Personally, I’m still using I3 and don’t see many immediate benefits to switching over to Sway (the Wayland fork of I3). I am cheering Wayland on though and making the switch is somewhere on my todo list. What other path forward is there for desktop Linux?
> Sway (the Wayland fork of I3)
Minor clarification: Sway is an i3-compatible wayland compositor written from scratch, not a fork.
Minor clarification: Sway is an i3-compatible wayland compositor written from scratch, not a fork.
The fact that XWayland's "performance should be roughly on-par with native X11" probably solidifies rather than weakens the position of X11 as the de facto display protocol.
If everything that uses X11 today can be used on top of XWayland without any modification and without performance loss, this means that a lot of pressure stemming from the need to switch to speaking Wayland instead of X11 is lifted in a certain sense.
Or am I missing something?
If everything that uses X11 today can be used on top of XWayland without any modification and without performance loss, this means that a lot of pressure stemming from the need to switch to speaking Wayland instead of X11 is lifted in a certain sense.
Or am I missing something?
First of all, nobody cared to hack on X/Xorg. The project was seriously understaffed.
Second, it ended a pile of hacks upon hacks.
Those two reasons have to be added on top of the other benefits of Wayland (or any other modern re-arch of X).
Second, it ended a pile of hacks upon hacks.
Those two reasons have to be added on top of the other benefits of Wayland (or any other modern re-arch of X).
> mostly breaking a billion useful things that X has had for some time
This is always the case when there is some widely used legacy tech, but it shouldn't stop us from trying to move forward, or we'll never get better things.
I've personally switched to using wayland on my main laptop and am very happy with it. I was using X before and was getting incredibly bad screen tearing when using i3, I tried every recommendation I could find (double buffering, running a compositor, etc) and nothing helped, but Sway on wayland fixed it for me and its been running flawlessly for the last 9 months. I have no plans of going back to X anytime. The only thing I use X for is playing Windows games with Proton (which this HW acceleration change might even fix, if the laptop had an nvidia gpu, but alas, it does not).
This is always the case when there is some widely used legacy tech, but it shouldn't stop us from trying to move forward, or we'll never get better things.
I've personally switched to using wayland on my main laptop and am very happy with it. I was using X before and was getting incredibly bad screen tearing when using i3, I tried every recommendation I could find (double buffering, running a compositor, etc) and nothing helped, but Sway on wayland fixed it for me and its been running flawlessly for the last 9 months. I have no plans of going back to X anytime. The only thing I use X for is playing Windows games with Proton (which this HW acceleration change might even fix, if the laptop had an nvidia gpu, but alas, it does not).
> but it shouldn't stop us from trying to move forward,
Wayland means moving backwards. It has the complete wrong philosophy and abstractions. If "sway" runs flawlessly for you you are not doing much with your computer at all. I can't work without my fine tuned synaptics driver configuration and without my over the years grown and perfected scripts using xdotool, dmenu, xsel, xcape, xcalib and many other tiny but useful x-tools.
Wayland means moving backwards. It has the complete wrong philosophy and abstractions. If "sway" runs flawlessly for you you are not doing much with your computer at all. I can't work without my fine tuned synaptics driver configuration and without my over the years grown and perfected scripts using xdotool, dmenu, xsel, xcape, xcalib and many other tiny but useful x-tools.
So because it doesn't work for your workflow of scripts that rely on X, wayland is a step backwards and I must not be using my computer for much? Get over yourself.
> fine tuned synaptics driver configuration
My touchpad, touchscreen and apple magic trackpad work great for me, so this isn't a problem for me.
> fine tuned synaptics driver configuration
My touchpad, touchscreen and apple magic trackpad work great for me, so this isn't a problem for me.
Wayland is power-user hostile. If all you do is watching cat videos all day long Wayland will be great for you.
Well, it actually do allows watching videos at all without tearing everywhere, which was not possible on X without a compositor.
And once again you are making completely erroneous assumptions about my computer use.
For those who skim the headline and wonder if this is about nouveau or the proprietary binary driver: it's the latter (which might also be why it's newsworthy).
Now we just have to wait ... for the actual driver. It's quite interesting how this was validated and merged all without a sample for testing.
Nvidia still have some way to go with their driver policy, but them contributing in an attempt to become a normal citizen of the Linux ecosystem is a sign that the "fuck you" days may finally be coming to an end which, as the owner of a laptop with an Nvidia chip, gives me a sense of relief.
As far as I know this is all still based on their non-standard EGLstreams platform, but they are working on a Vulkan allocator that supposedly fixes the issue and some contribution activity indicates that they may finally support GBM, which would make Nvidia cards "just work" without any special treatment, which I would of course prefer.
Nvidia still have some way to go with their driver policy, but them contributing in an attempt to become a normal citizen of the Linux ecosystem is a sign that the "fuck you" days may finally be coming to an end which, as the owner of a laptop with an Nvidia chip, gives me a sense of relief.
As far as I know this is all still based on their non-standard EGLstreams platform, but they are working on a Vulkan allocator that supposedly fixes the issue and some contribution activity indicates that they may finally support GBM, which would make Nvidia cards "just work" without any special treatment, which I would of course prefer.
Actually EGLstream is the standard (albeit proposed by nVidia) while gbm is an API specific to some Linux drivers.
EGLStreams may be popular in some areas, but all other graphics drivers support GBM.
On Linux.
EGLStreams is the actual Khronos standard (https://www.khronos.org/egl) as such existing on Windows, QNX and others.
EGLStreams is the actual Khronos standard (https://www.khronos.org/egl) as such existing on Windows, QNX and others.
Being a Khronos standard doesn't mean it exists anywhere.
EGLStreams doesn't exist on Windows, as Windows doesn't have any EGL at all. Similarly while EGL is used on Android, Android doesn't support EGLStreams and probably won't as the functionality already exists & EGL is on the way out long-term as Vulkan adoption picks up.
With all that said, EGLStreams is probably also not going to get adoption on most platforms as it's pretty terrible & inferior to what most platforms already have. Which is, on most platforms you can work directly with buffers instead of being forced into a specific point to point pipe (Android's HardwareBuffe or iOS/Mac's CVPixelBuffer)
EGLStreams doesn't exist on Windows, as Windows doesn't have any EGL at all. Similarly while EGL is used on Android, Android doesn't support EGLStreams and probably won't as the functionality already exists & EGL is on the way out long-term as Vulkan adoption picks up.
With all that said, EGLStreams is probably also not going to get adoption on most platforms as it's pretty terrible & inferior to what most platforms already have. Which is, on most platforms you can work directly with buffers instead of being forced into a specific point to point pipe (Android's HardwareBuffe or iOS/Mac's CVPixelBuffer)
EGLStreams is on its way out for desktop Linux too, since NVIDIA is working on adopting GBM for the next driver series and is working in Mesa to prepare for that: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/99...
At least Windows has EGL incl streams for some scenarios (related to WSL’s graphics stack mainly).
On more embedded scenarios that I’ve worked on (Qt w/ EGLFS), it’s quite popular too.
On more embedded scenarios that I’ve worked on (Qt w/ EGLFS), it’s quite popular too.
[deleted]
How convenient. I bought an 6700XT (overpriced, crappy, and not yet supported) a couple weeks ago as soon as they were released. Having used Nvidia for Linux, I thought AMD would play much nicer. That was far from true, but maybe because the 6700XT is yet to be fully supported in the kernel.
That being said, I'm now enjoying wayland. Gnome apps already supports wayland natively. The rendering is smooth, no tearing and no issues. I think the transition to Wayland will be faster than many here are predicting.
That being said, I'm now enjoying wayland. Gnome apps already supports wayland natively. The rendering is smooth, no tearing and no issues. I think the transition to Wayland will be faster than many here are predicting.
I bought a 5700XT back when it was first released. It would crash my entire system randomly, it was so bad I had to shelve it for a while and put my old GPU back in. It took a good few months for the amdgpu driver to work out the kinks, but now it runs fine. In the future I’ll definitely avoid buying GPUs less then 6 months old for use on Linux, and will diligently search for “model# crash|bugs|glitch|unstable linux|wayland” before pulling the trigger.
I've had a 6800XT running upstream mesa, kernel and linux-firmware and it basically just works. Play proton and native games with pretty good FPS.
Haven't compared it against windows, because haven't felt the need. I'm sure some functionality/perf is missing though.
Haven't compared it against windows, because haven't felt the need. I'm sure some functionality/perf is missing though.
6800XT are supported in the latest Kernet but 6700XT are, unfortunately, not.
I died on that hill many times, Linux people don't like if you criticise AMD because they're open and NVIDIA isn't so they're evil.
Your 6700 XT might not be fully supported, but my 5500 XT is and was been causing kernel panics since I bought it one year ago. I got tired of posting the same drm bug report as reference but it's one of the 3 most commented and open for a couple years now.
It's painfully obvious that the Linux driver team at NVIDIA is underbudgeted and completely ignored, so I'm happy Wayland comes for them as well and I can continue to use their high end cards and not be relegated to tried-and-tested-and-painfully-old AMD cards on Linux, at least until they sort their day 1 support for new cards.
Your 6700 XT might not be fully supported, but my 5500 XT is and was been causing kernel panics since I bought it one year ago. I got tired of posting the same drm bug report as reference but it's one of the 3 most commented and open for a couple years now.
It's painfully obvious that the Linux driver team at NVIDIA is underbudgeted and completely ignored, so I'm happy Wayland comes for them as well and I can continue to use their high end cards and not be relegated to tried-and-tested-and-painfully-old AMD cards on Linux, at least until they sort their day 1 support for new cards.
This is a very interesting development for those of us in the CUDA space who work on Linux!
I had thought Wayland was not ever likely to be supported by nVidia, but something clearly has changed.
I had thought Wayland was not ever likely to be supported by nVidia, but something clearly has changed.
Nvidia has a difference in how they implement their driver that would have required a number of players to each implement support for NVIDIA separately from other hardware because NVIDIA wants to directly use a lot of code it uses on other platforms on Linux.
Unfortunately due to the misdesign of Wayland each graphical environment must write code to more directly interface with hardware instead of that being a layer above that. This means in current context it is vastly easier if NVIDIA bends on this issue however they also have the least incentive because most of their money isn't earned on the Linux Desktop.
People seem to suppose that somehow hardware vendors owe Linux users support and support in the fashion that would be desirable as if somehow not supporting the standards that others do is somehow wronging those developers and users but a private company in fact doesn't owe said developers or users ANY support of any kind.
Unfortunately due to the misdesign of Wayland each graphical environment must write code to more directly interface with hardware instead of that being a layer above that. This means in current context it is vastly easier if NVIDIA bends on this issue however they also have the least incentive because most of their money isn't earned on the Linux Desktop.
People seem to suppose that somehow hardware vendors owe Linux users support and support in the fashion that would be desirable as if somehow not supporting the standards that others do is somehow wronging those developers and users but a private company in fact doesn't owe said developers or users ANY support of any kind.
Well, then that company can expect to continue seeing middle fingers :)
Intel and AMD, the arch-rivals they are, coexist and collaborate on the kernel stack and Mesa. Even embedded companies join in (see Broadcom hiring Eric Anholt to make V3D a thing for the RPi4, even Qualcomm vaguely supporting Freedreno and Arm starting to show some kind of interest in Panfrost IIRC). Microsoft is in for virtualization and GL-on-D3D.
None of these vendors "owe anybody anything" yet they've joined the party. Turns out sharing is beneficial for everyone.
Intel and AMD, the arch-rivals they are, coexist and collaborate on the kernel stack and Mesa. Even embedded companies join in (see Broadcom hiring Eric Anholt to make V3D a thing for the RPi4, even Qualcomm vaguely supporting Freedreno and Arm starting to show some kind of interest in Panfrost IIRC). Microsoft is in for virtualization and GL-on-D3D.
None of these vendors "owe anybody anything" yet they've joined the party. Turns out sharing is beneficial for everyone.
> Unfortunately due to the misdesign of Wayland
It has nothing to do with wayland, it is due to linux not wanting to provide a stable API for drivers, deterring binary blobs (successfully). As for whether this latter thing is good or bad is subjective.
It has nothing to do with wayland, it is due to linux not wanting to provide a stable API for drivers, deterring binary blobs (successfully). As for whether this latter thing is good or bad is subjective.
A desktop environment under x doesn't concern itself with graphics drivers.
You can use wlroots to have a similarly abstract view of the underlying.
Nonetheless, X itself is broken, it could not have been done otherwise.
Nonetheless, X itself is broken, it could not have been done otherwise.
Is what has changed maybe that XWayland has been refactored out of core X, making it easier to support without dealing with the huge X codebase? Or maybe it's been in the works for a while and everything's just landing at once.
Support is inevitable, Wayland is staged to replaced X11, all major distros have it in their roadmap (if not already default on stable).
> Wayland is staged to replaced X11
Wayland can't possibly replace X11, it's got a fundamentally different (I'd even say broken or even malicious) design. If anything, some Wayland compositors may emerge as dominant desktop environments, but this would be a dark day for power users, if it would mean not being able to switch to an actually friendly design, as currently offered by Xorg.
Wayland can't possibly replace X11, it's got a fundamentally different (I'd even say broken or even malicious) design. If anything, some Wayland compositors may emerge as dominant desktop environments, but this would be a dark day for power users, if it would mean not being able to switch to an actually friendly design, as currently offered by Xorg.
Then I encourage you to take up leadership to get some development going on the bare metal xorg server. Odds are, within a year or two, it will need serious patches to keep working with up to date kernels, mesa, and nvidia drivers.
The kernels policy is not to break userspace and RHEL 8 which still supports X is 2 years into a 10 year support term.
Also nvidia still provides drivers for 18 year old hardware for x under solaris
If you want the current version built this year for Linux instead of the legacy version you will have to move up 2010 hardware though.
I find it quite amusing that proponents of insert technology here seem to come in 2 stripes.
A) Those who believe new thing is superior and think you ought to try it
B) People smugly stating that you must move to new thing because the other options are going away see wayland systemd gnome.
It reminds me of a supervisor at a telecom support center who gleefully explained that the new system would hang up on people who kept mashing zero on the automated phone menu that preceeded getting to a person to make you go through it.
He didn't understand that people didn't want to use the new automated process because in general such systems are crappy and confusing.
Also nvidia still provides drivers for 18 year old hardware for x under solaris
If you want the current version built this year for Linux instead of the legacy version you will have to move up 2010 hardware though.
I find it quite amusing that proponents of insert technology here seem to come in 2 stripes.
A) Those who believe new thing is superior and think you ought to try it
B) People smugly stating that you must move to new thing because the other options are going away see wayland systemd gnome.
It reminds me of a supervisor at a telecom support center who gleefully explained that the new system would hang up on people who kept mashing zero on the automated phone menu that preceeded getting to a person to make you go through it.
He didn't understand that people didn't want to use the new automated process because in general such systems are crappy and confusing.
New software doesn’t get better just because it is new, but it is short-sighted to not evaluate (or evaluate on not enough context) a possibly better solution.
The very people working on X decided to continue development on Wayland, do you think they would got with an inferior solution?
Yes, I do. I very much believe that the Wayland architectural decisions are motivated by non-technical reasons (look at who pays them, and who stands to benefit by controlling the majority of commits across the whole fd.o stack).
Well, you can imagine some evil behind everything if you wish..
Or just look at a technical video about it: https://www.youtube.com/watch?v=GWQh_DmDLKQ
I don’t see these conteos regarding linux, especially goddamn desktop with the minuscule user share. It is literally a hobby thing for some graphics enthusiasts without any sort of money. Yeah sure, red hat or whatever..
Or just look at a technical video about it: https://www.youtube.com/watch?v=GWQh_DmDLKQ
I don’t see these conteos regarding linux, especially goddamn desktop with the minuscule user share. It is literally a hobby thing for some graphics enthusiasts without any sort of money. Yeah sure, red hat or whatever..
Except, I've seen this same exact song and dance routine played out already with systemd. Some RedHat developers make a thing no one wants to use, so they tightly couple many orthogonal concerns into one giant hairball, and they go on a road show to get a few crucial players (like GNOME and ConsoleKit, which was deprecated by the systemd devs) to hard-depend on it so distros have to choose between using the hairball or losing something that was entirely unrelated. It's a great play by RedHat, because now things are so interdependent that you need full-salaried developers working full-time on it, since the cognitive overhead required to understand how everything interacts now precludes a loosely-connected network of part-time volunteers from maintaining it themselves.
Oh, and this whole affair has the obnoxious side-effect of stirring up all the /r/linuxmasterrace dipshits into a feeding frenzy that spills over onto HN, where they scramble over themselves to spam everyone who dares disagree with the same half-assed links and excuses.
Oh, and this whole affair has the obnoxious side-effect of stirring up all the /r/linuxmasterrace dipshits into a feeding frenzy that spills over onto HN, where they scramble over themselves to spam everyone who dares disagree with the same half-assed links and excuses.
Or how about systemd actually providing features not found in its predecessors at all and it does solve system init and service life cycle management?
Do you think that the majority of the debian team that voted democratically multiple times on the issue voted purely because... Red Hat? Come on, it is ridiculous. I hope you are not as blind when it comes to real-life politics, because denying reality to this degree is dangerous.
Do you think that the majority of the debian team that voted democratically multiple times on the issue voted purely because... Red Hat? Come on, it is ridiculous. I hope you are not as blind when it comes to real-life politics, because denying reality to this degree is dangerous.
You don't think that Debian choosing systemd had anything to do with things regarded as core components like gnome being tied to same and not wanting to maintain a fork of the same functionality?
Accusing the other side of an argument of being deluded doesn't foster useful discussion.
Accusing the other side of an argument of being deluded doesn't foster useful discussion.
Interestingly enough the much smaller gentoo maintainers managed to package gnome without systemd..
It depends on dbus not systemd and that is replaceable module.
It depends on dbus not systemd and that is replaceable module.
Just because you don't see the politics at work doesn't mean that it doesn't happen. Thanks for proving my point about /r/linuxmasterrace, btw.
The kernel can choose to not support new hardware with old interfaces. If the X11 can't interface with new hardware, that's game over. No broken userspace necessary.
Choosing not to support said interfaces would be the biggest breakage of userspace in 3 decades of Linux history. Such a course of action is nowhere specified by the people who would be responsible. As best I can see you have constructed it from whole cloth from suppositions that seem to be ill considered.
Edit: To be clear breaking user space is when a change happens in the kernel level wherein software that used to work no longer works because the public interface presented differs. If you have evidence that this is actually going to happen other than your own misunderstandings please link it.
Edit: To be clear breaking user space is when a change happens in the kernel level wherein software that used to work no longer works because the public interface presented differs. If you have evidence that this is actually going to happen other than your own misunderstandings please link it.
There is a lot of detail about this in the kernel docs:
https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#ope...
The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.
I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).
The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.
I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).
Does it specifically mention the kernel breaking X? One would think that would be the topic of discussion years before anyone actually did it.
I don't think the kernel guarantees that if X runs against Linux today, then it will run against the same X on new kernels on new hardware in perpetuity. It's more along the lines of, "if I one calls the read syscall with parameters a, b, c, it won't suddenly require a 4th parameter, or demand they be in a, c, b order."
Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.
Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.
To be clear in the Wayland fetishists fantasies they wouldn't need to convince people to all switch to wayland circumstances would foreclose on any further debate in reality all players have an incentive to keep existing software working.
If one calls the _ syscall with parameters a b and c it won't suddenly require a 4th or demand they be in a c b order is literally what makes X11 continue working against newer kernels. Providing new functionality wherein if you don't call foo before calling _ with a b and c it fails to perform its function would be functionally the same as changing the order of parameters it would be breaking user space.
I don't see how you could possibly lawyer yourself past that, I don't see that the adults in the room who have to support customers in rhel 8 through 2029 can do anything but keep doing minimum work to keep x and the kernel playing nicely. I don't see how nvidia is going to go from supporting hardware for 10-18 years even on niche hardware to dropping support for X so quickly. I also don't see how you can meaningfully talk about the kernel dropping support for X without basing your discussion on actual kernel developers who logically would talk about kernel foo will be the last to support X probably years before it actually happens. I'm totally sure that python 2 -> 3 took over a decade after it was a completely suitable replacement but we will totally manage to replace X before its replacement is fully baked and the kinks worked out.
In short the whole premise is completely and totally premature wishful thinking by people who want their own way. I'll pour one out for X when its actually and in fact dead.
If one calls the _ syscall with parameters a b and c it won't suddenly require a 4th or demand they be in a c b order is literally what makes X11 continue working against newer kernels. Providing new functionality wherein if you don't call foo before calling _ with a b and c it fails to perform its function would be functionally the same as changing the order of parameters it would be breaking user space.
I don't see how you could possibly lawyer yourself past that, I don't see that the adults in the room who have to support customers in rhel 8 through 2029 can do anything but keep doing minimum work to keep x and the kernel playing nicely. I don't see how nvidia is going to go from supporting hardware for 10-18 years even on niche hardware to dropping support for X so quickly. I also don't see how you can meaningfully talk about the kernel dropping support for X without basing your discussion on actual kernel developers who logically would talk about kernel foo will be the last to support X probably years before it actually happens. I'm totally sure that python 2 -> 3 took over a decade after it was a completely suitable replacement but we will totally manage to replace X before its replacement is fully baked and the kinks worked out.
In short the whole premise is completely and totally premature wishful thinking by people who want their own way. I'll pour one out for X when its actually and in fact dead.
Not sure what have I missed but how is X window system a "friendly design"?
Friendly compared to Wayland. X Windows offers many features that the designers of Wayland decided to exclude to keep their protocol simple, and for some security theatre reasons. But this simplicity is deceptive, as it means that implementing all the excluded features, and deciding on relevant interfaces, is left to the Wayland compositors. This is the reason "Wayland" (or, more correctly, Wayland compositors) still miss many important features that are
* expected by users of X11, Windows, or Mac
* expected by power users
* needed by the visually impaired
And it is also the reason why the Wayland ecosystem is destined for horrible fragmentation of interfaces, features and implementations.
Another consequence is that the X11 model of having the possibility of easily making a window manager to one's liking is not possible with Wayland, as compositors are monstrous beasts compared to window managers.
I also wrote about all this in some of my previous comments, e.g. there was a large thread here: https://news.ycombinator.com/item?id=24886074
EDIT: there's another perspective to this that I didn't express very well, so here are some quotes from Arch BBS:
By user neosix:
> You can't send keystrokes, move mouse, move windows, you can't even get active window. And all that because of security?
> But guess what it's not safe walking down the street, something can kill you, so let's just stay in the house and never go out again :)
By user Trilby:
> While I place a very high value on security and well designed software, the strategy of saying "you shouldn't want to do that" is not a sane policy. Yet this has been the approach of wayland from the start. Can you have a system panel? No, you should not want to have one. Can you have one client talk to another client? No, you should not want to do this. Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive: here, watch a cat video.
Emphasis mine.
* expected by users of X11, Windows, or Mac
* expected by power users
* needed by the visually impaired
And it is also the reason why the Wayland ecosystem is destined for horrible fragmentation of interfaces, features and implementations.
Another consequence is that the X11 model of having the possibility of easily making a window manager to one's liking is not possible with Wayland, as compositors are monstrous beasts compared to window managers.
I also wrote about all this in some of my previous comments, e.g. there was a large thread here: https://news.ycombinator.com/item?id=24886074
EDIT: there's another perspective to this that I didn't express very well, so here are some quotes from Arch BBS:
By user neosix:
> You can't send keystrokes, move mouse, move windows, you can't even get active window. And all that because of security?
> But guess what it's not safe walking down the street, something can kill you, so let's just stay in the house and never go out again :)
By user Trilby:
> While I place a very high value on security and well designed software, the strategy of saying "you shouldn't want to do that" is not a sane policy. Yet this has been the approach of wayland from the start. Can you have a system panel? No, you should not want to have one. Can you have one client talk to another client? No, you should not want to do this. Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive: here, watch a cat video.
Emphasis mine.
> Can you have a system panel? No, you should not want to have one.
Yes you can, wlroots has an extension for that, that will work on every “niche” wm based on it. You could not really get a system panel to work on plasma and gnome as well on X.
> Can you have one client talk to another client?
It is way too vague (generally, what does it have to do with the display manager? Pipes, IPC, dbus), but if it means something like drag’n’drop, it is supported.
> Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive
This is just utterly stupid.
Yes you can, wlroots has an extension for that, that will work on every “niche” wm based on it. You could not really get a system panel to work on plasma and gnome as well on X.
> Can you have one client talk to another client?
It is way too vague (generally, what does it have to do with the display manager? Pipes, IPC, dbus), but if it means something like drag’n’drop, it is supported.
> Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive
This is just utterly stupid.
> Wayland compositors) still miss many important features that are
> * expected by users of X11, Windows, or Mac
Windows & Mac have been in a compositor-only world for over a decade now. They are firmly in a wayland-style world, not an X11-style one. Android, too, has only ever had a wayland-style world.
The only thing that exists like X11 is X11. So nobody on Windows or Mac will be expecting anything like it.
> * expected by users of X11, Windows, or Mac
Windows & Mac have been in a compositor-only world for over a decade now. They are firmly in a wayland-style world, not an X11-style one. Android, too, has only ever had a wayland-style world.
The only thing that exists like X11 is X11. So nobody on Windows or Mac will be expecting anything like it.
That's not a Wayland problem. The features you're asking for are probably still there but they're implemented at a different spot in the stack instead of trying to stuff everything into the same protocol like in X11. This is actually done to reduce fragmentation. Make a service its own daemon with a dbus interface or something like that, and then it can run the same on X or on any Wayland compositor.
In my experience it's actually the simplicity of building window managers in X11 that's misleading. It's easy to get something up and running that lets you move windows around, but to build a full desktop that does everything you'd expect is a giant task, and X11 only really gets in the way of that.
In my experience it's actually the simplicity of building window managers in X11 that's misleading. It's easy to get something up and running that lets you move windows around, but to build a full desktop that does everything you'd expect is a giant task, and X11 only really gets in the way of that.
> That's not a Wayland problem.
Exactly, "not a Wayland problem". That's the problem with Wayland, nothing is a Wayland problem.
> Make a service its own daemon with a dbus interface or something like that
I don't know if I should cry or laugh at this.
Exactly, "not a Wayland problem". That's the problem with Wayland, nothing is a Wayland problem.
> Make a service its own daemon with a dbus interface or something like that
I don't know if I should cry or laugh at this.
Not sure why you'd laugh or cry. Dbus is just an example. You can use another mechanism to build another daemon, it doesn't have to be built on anything in particular. I'm just saying, if you expect that Wayland is going to solve every problem you had with your desktop, you're setting yourself up to be disappointed. It solves a few specific problems. You can solve the other problems in ways that reduce fragmentation, but you'll have to look in other places.
> solve the other problems in ways that reduce fragmentation
> look in other places
There's a contradiction here. How do you expect to avoid fragmentation if adding additional protocols alongside Wayland is required? I mean, obviously there won't be just one protocol. This idea is actually a common joke, there's even an XKCD on the topic.
> look in other places
There's a contradiction here. How do you expect to avoid fragmentation if adding additional protocols alongside Wayland is required? I mean, obviously there won't be just one protocol. This idea is actually a common joke, there's even an XKCD on the topic.
You misunderstand. In both situations, you're making a new protocol. The only difference is you'd be making your own thing instead of adding new packet types to Wayland. And why add new packet types to Wayland if the thing you're trying to do can be done outside the Wayland socket? Best example is Pipewire and screensharing. People ask for screensharing in Wayland but it makes a lot more sense to have it in Pipewire because it can handle all the other tasks related to video streaming like format negotiation and compression. It works headless and independent of any compositor, the fact that it can also be used to do screensharing is a benefit of its design.
It's certainly much friendlier to write programs for.
Yeah, but why would anyone want to write programs? Oh, wait...
Yep, totally inevitable; in just another 12 years it'll be totally prod-ready ;)
Couldn't you use the Nvidia card for CUDA and just have an AMD card for the display. It's a little dumb having two graphics cards, you need a spare PCI slot and graphics cards are expensive (but you could just get a cheap old and used card, if it's just for your desktop environment).
I'm asking because it seems like no one relying on Nvidia card for number crushing and who want Wayland seem to have opted to just get a second card.
I'm asking because it seems like no one relying on Nvidia card for number crushing and who want Wayland seem to have opted to just get a second card.
The top CUDA cards don't even do display. Anyway tons of CPUs have a good-enough on-die GPU that you can use for display in a pinch.
In a pinch if you only want one display.
This new is actually a bigger step torward Wayland from Nvidia:
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-G...
It seems that Nvidia finally is moving away from the GBM madness.
It seems that Nvidia finally is moving away from the GBM madness.
What's GBM?
It's the buffer management part of wayland. Nvidia never implemented it and pushed for egl streams instead. This means that compositor have to implement two paths, gbm (wayland), egl stream (nvidia propriatory only).
Nitpick, but it is actually part of the kernel. X server also uses it, but there was no problem because nvidia could release a binary patch for it to use their proprietary thingy. It is not possible with the many wayland compositor so it became an apparent problem with wayland.
It is explicitely part of the wayland protocol https://wayland-book.com/introduction/high-level-design.html
From your link:
“There are many distinct software components in desktop ecosystem. There are tools like Mesa for rendering (and each of its drivers), the Linux KMS/DRM subsystem, buffer allocation with GBM, the userspace libdrm library, libinput and evdev, and much more still. [...]
libinput Like libdrm abstracts the DRM subsystem, libinput provides the userspace end of evdev.”
“There are many distinct software components in desktop ecosystem. There are tools like Mesa for rendering (and each of its drivers), the Linux KMS/DRM subsystem, buffer allocation with GBM, the userspace libdrm library, libinput and evdev, and much more still. [...]
libinput Like libdrm abstracts the DRM subsystem, libinput provides the userspace end of evdev.”
[deleted]
Apparently a Mesa driver API for buffer management.
That link seems to imply they embracing GBM by implementing a backend for it.
You're absolutely right, got confused between egl stream and gbm
This is all very sad.
One would think that A. D. 2021 a program implementing one abstraction upon another abstraction wouldn’t have to care about the actual hardware it’s running on.
But in the actual fact we have GUI programs containing quirks for graphic chips, and userland programs deeply concerned with what kind of filesystem they are writing to.
One would think that A. D. 2021 a program implementing one abstraction upon another abstraction wouldn’t have to care about the actual hardware it’s running on.
But in the actual fact we have GUI programs containing quirks for graphic chips, and userland programs deeply concerned with what kind of filesystem they are writing to.
Already on Phoronix:
https://www.phoronix.com/scan.php?page=news_item&px=Xserver-...
https://www.phoronix.com/scan.php?page=news_item&px=Xserver-...
Since I switch to Wayland on Ubuntu 20.04 my laptop works significantly better. I don't get random hickups and slowdowns. Screen sharing works fine (at least on zoom which is what I tried, and only on the .deb package, not the snap one). I am aware it's not as mature as X but I'm looking forward to watching Wayland grow.
Tangential: some say that Wayland has inherently higher latency due to its design (because vsync is always on?)
Is that true?
Is that true?
vsync always on doesn't have to translate to higher latency.
On NVIDIA/Windows, the recommended setting for lowest latency is VSYNC+GSYNC enabled.
https://blurbusters.com/gsync/gsync101-input-lag-tests-and-s...
On NVIDIA/Windows, the recommended setting for lowest latency is VSYNC+GSYNC enabled.
https://blurbusters.com/gsync/gsync101-input-lag-tests-and-s...
Yes, but there is work in progress to fix this:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
Well, higher than non-composited, non-vsynced X11 (but yes there are fun solutions like trying to render at the end of a frame to let the clients run ahead). But any reasonable major DE was doing compositing, and even minimal WM enthusiasts typically ran xcompmgr/compton/whatever because we're not in the Windows 95 era. Comparing to that, Wayland is much better, with direct async communication between the client and compositor, instead of Xorg acting as a glorified IPC broker that can get busy processing stuff…
It is a shame that Nvidia is not supporting nouveau more.
Will that really solve anything though?
I spent the whole Friday evening and night trying to figure out, why my Mouse does not work plugged into a USB port on my Thunderbolt 3 Dock connected to my laptop with a Nvidia GPU.
Turns out it was Nvidia’s driver fault all along. This happened now so often to me, that for the next times I will just always first look whether the Nvidia driver has some bug, before I try to figure out something myself.
I spent the whole Friday evening and night trying to figure out, why my Mouse does not work plugged into a USB port on my Thunderbolt 3 Dock connected to my laptop with a Nvidia GPU.
Turns out it was Nvidia’s driver fault all along. This happened now so often to me, that for the next times I will just always first look whether the Nvidia driver has some bug, before I try to figure out something myself.
When would this filter through to distros?
The next major XWayland release will likely be in about half a year, but they're considering putting it into a point release.
The most likely answer is next version or the one after that depending on how they'll do the release (Ubuntu just released so there are a few months available for the next version in their 6 months schedule, it'll definitely be in the next LTS).
Source: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
The most likely answer is next version or the one after that depending on how they'll do the release (Ubuntu just released so there are a few months available for the next version in their 6 months schedule, it'll definitely be in the next LTS).
Source: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
But this requires the proprietary driver? I don't see how this will be included in any of the major distributions such as Debian or Fedora.