Wayland in 2021(shibumi.dev)
shibumi.dev
Wayland in 2021
https://shibumi.dev/posts/wayland-in-2021/
145 comments
> A unified way to change applications settings.
This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings
> because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots.
So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.
I don't get this point. You can still use Cairo or similar graphic libraries on wayland too.
This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings
> because the X server takes care of most of the stuff. ... , unless using a big library like wl_roots.
So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.
I don't get this point. You can still use Cairo or similar graphic libraries on wayland too.
> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case.
In the X11 case, relations are:
wm - user - X11
(Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.)
In the Wayland case, the relations are:
user - wm/compositor - wl_roots
(Users choose wm, wm developers choose to use wl_roots to implement wm features instead of doing it themselves, but that is just internal implementation issue of that wm and wm developers are responsible for wm behavior/bugs including ones inherited from wl_roots.)
There is big difference in responsibility w.r.t. users in Xserver vs wl_roots case.
In the X11 case, relations are:
wm - user - X11
(Users choose to use Xserver and WM independently, if there is a bug in Xserver, then it is outside of responsibility of WM developers.)
In the Wayland case, the relations are:
user - wm/compositor - wl_roots
(Users choose wm, wm developers choose to use wl_roots to implement wm features instead of doing it themselves, but that is just internal implementation issue of that wm and wm developers are responsible for wm behavior/bugs including ones inherited from wl_roots.)
That's actually a good thing! If the bug is in X, then the WM developers are powerless against it. If it is in wlroots, then something can be done about it. Since it's a library, it should be possible to roll out a bugfix at a faster pace than the X server. Worst case you fork and bundle wlroots, leave behind a pull request to the main project, and move on.
> This is not true anymore even on X. Also, if you use GNOME or KDE, both of them has unified settings
That's why I said Wayland and the modern desktop in general.
> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X server. If I'm sloppy and my wm dies, it's not going to take down the whole desktop with it, contrary to a Wayland compositor.
> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.
Of course, but the rendering happens on the client (with client-side fonts, images, etc.) instead of the server, which makes the protocol use a lot of bandwidth.
That's why I said Wayland and the modern desktop in general.
> So you are fine with X server takes care of most of the stuff, but not fine with wl_roots do the same thing?
You're kind of right: conceptually it's not much different, except that a wm is not a full-fledged server, but simply a client talking to the X server. If I'm sloppy and my wm dies, it's not going to take down the whole desktop with it, contrary to a Wayland compositor.
> A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps.
Of course, but the rendering happens on the client (with client-side fonts, images, etc.) instead of the server, which makes the protocol use a lot of bandwidth.
Just think for a minute, entire industry abandoned xrdb and drawing primitives in X11 applications, even XOrg developers decided to ditch these features, they've started Wayland because they could not fix X11.
Either you are unbelievably smarter or you know nothing.
Either you are unbelievably smarter or you know nothing.
Maybe I know nothing, but it quite common that the technically superior solution don't get a lot of adoption and eventually dies.
- I've never seen xrdb used outside of terminal configuration
- You have to link against X11, dwl (dwm for Wayland) implemented in 2500 LOC [1]
Plan 9 /dev/draw is simpler yet, somehow it was not reason against X11.
[1] https://github.com/djpohly/dwl
- You have to link against X11, dwl (dwm for Wayland) implemented in 2500 LOC [1]
Plan 9 /dev/draw is simpler yet, somehow it was not reason against X11.
[1] https://github.com/djpohly/dwl
All the old X apps used xrdb, to some degree. I think of xclock, xbiff, xditview, xcalc, bitmap, etc.
Everyone stopped using xrdb more than twenty years ago, same things for drawing primitives.
I understand the wish some seems to have for things to never change. It's probably very comforting but things have to move with their time or they will be left behind.
I understand the wish some seems to have for things to never change. It's probably very comforting but things have to move with their time or they will be left behind.
I'm not saying applications should continue to use or go back to xrdb. I'm pointing out the fact that having unified configuration system is very useful and I'm disappointed Wayland didn't pick up this idea.
Wayland reflects status quo. Truly desired missing features are reimplemented — screenshots, screensharing, networking. Try to make a change, maybe you'd find out this feature is not that useful.
I'd better think why .Xresources never catched up. For example, I've downloaded Gnome theme. It contains some CSS files, a lot of images and some rc files. Or check about:config, chrome://flags/ — no images there, but interface is so much nicer than a list in man pages and plain text editing.
I'd better think why .Xresources never catched up. For example, I've downloaded Gnome theme. It contains some CSS files, a lot of images and some rc files. Or check about:config, chrome://flags/ — no images there, but interface is so much nicer than a list in man pages and plain text editing.
> - I've never seen xrdb used outside of terminal configuration
Terminal and Emacs are the two I'm using it for.
Terminal and Emacs are the two I'm using it for.
> The simplicity of the window managers, hotkey daemons and other X clients. You can implement a functional wm in a few hundred lines of C[1] because the X server takes care of most of the stuff. In comparison a compositor has much more work to do and it's difficult to implement one, unless using a big library like wl_roots.
This sounds like they simply extracted some of the work X used to do into an external library. That sounds like an excellent choice with no particular downside IMO?
This sounds like they simply extracted some of the work X used to do into an external library. That sounds like an excellent choice with no particular downside IMO?
Why is a library any better? Not even disagreeing; I can't see why to prefer either approach.
The beauty of free software is that X will always be there for anyone who wants it, just like you can still get great distros without systemd.
I don’t know how I feel about Wayland. On the one hand it’s being made by x11 devs so I think they more than anyone else know why they would need to start from scratch over improving x11. On the other hand, moving away from x breaks so many things and I haven’t heard anyone singing it’s praises yet about how happy they are to use it.
I understand apps are breaking because they relied on features of x that were security risks but it doesn’t seem like Wayland provides a safe or convenient alternative to the way apps were doing things before.
I wonder if it will ever reach the adoption level of x11
I understand apps are breaking because they relied on features of x that were security risks but it doesn’t seem like Wayland provides a safe or convenient alternative to the way apps were doing things before.
I wonder if it will ever reach the adoption level of x11
I am a happy Wayland user, and have been for a long time. There are many more out there. You don't often hear us because we don't spend every waking hour shitting on Xorg and praising Wayland for how good it is (maybe we should?)
>I wonder if it will ever reach the adoption level of x11
It will, considering that Xorg is effectively no longer maintained and its developers have switched to working on Wayland protocols long ago, which they have stated on multiple occasions.
Somehow I doubt that the loudmouths you often hear will step up to maintain X.
>I wonder if it will ever reach the adoption level of x11
It will, considering that Xorg is effectively no longer maintained and its developers have switched to working on Wayland protocols long ago, which they have stated on multiple occasions.
Somehow I doubt that the loudmouths you often hear will step up to maintain X.
What is the process to become a release manager for X11 without forking it? I assume you can't just walk in there and say "I'll do that".
I assume it starts with showing you’re up to it by putting in the work. You don’t need to be the release manager to contribute patches.
You fork it and your fork becomes the mainly used one is how it normally happens.
Who would risk stability? And what is the issue with forking? ffmpeg/libav, openssl/libressl managed fine. No fork is the symptom.
The other forks you are mentioning are a completely different problem because there were inherent philosophical differences among developers.
X11 just needs "a release" so that package maintainers and distros can push updates. If you fork it you only make things worse.
X11 just needs "a release" so that package maintainers and distros can push updates. If you fork it you only make things worse.
Just needs a release that could contain bugs, could contain exploits. And current maintainers are not going to risk? I'm typing on X11 system, and it works, proving previous maintainers got it right.
I am fine if active developers make a fork, prove its worth, some distributions adopting it, finally fork merged into base with new leadership.
> and I haven’t heard anyone singing it’s praises yet about how happy they are to use it
As is often the case, people are much quicker to go to forums to complain about issues than to sing praises so I'm here to add a data-point trying to balance the scale.
I've been using Wayland for a few years now and it does everything I need it to do. I understand that everyone has different needs and maybe it doesn't work for everyone, but then again, neither did X11.
Some of the things that work out of the box in Wayland which didn't work in X11:
- proper HiDPI and mixed DPI support (e.g.: you can finally move windows from one screen to another in mixed DPI setups and everything scales properly)
- variable refresh rates/FreeSync (for all apps and all screens)
- no more tearing
- no more hot-plugging issues
As is often the case, people are much quicker to go to forums to complain about issues than to sing praises so I'm here to add a data-point trying to balance the scale.
I've been using Wayland for a few years now and it does everything I need it to do. I understand that everyone has different needs and maybe it doesn't work for everyone, but then again, neither did X11.
Some of the things that work out of the box in Wayland which didn't work in X11:
- proper HiDPI and mixed DPI support (e.g.: you can finally move windows from one screen to another in mixed DPI setups and everything scales properly)
- variable refresh rates/FreeSync (for all apps and all screens)
- no more tearing
- no more hot-plugging issues
Besides security concerns, mixed-DPI setups are such a major pain point with X11 that many people who use a laptop with additional screens would probably switch to Wayland just for that alone. That's a large demographic.
Do any desktop system handle mixed DPI well?
I mainly use Linux so I don't know, but one of my work laptops have windows on it and it freaks out every time I connect it to a 4k monitor.
At least in linux I can use triggers and xrandr [1] to manage it even if it's not pretty, never figured out how to do it automatically in windows.
Edit: I am using KDE/Qt apps for 99% of my gui stuff. Gnome etc might be worse.
[1] http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/#therandrway
I mainly use Linux so I don't know, but one of my work laptops have windows on it and it freaks out every time I connect it to a 4k monitor.
At least in linux I can use triggers and xrandr [1] to manage it even if it's not pretty, never figured out how to do it automatically in windows.
Edit: I am using KDE/Qt apps for 99% of my gui stuff. Gnome etc might be worse.
[1] http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/#therandrway
> Do any desktop system handle mixed DPI well?
MacOS handles it very well, moving a window from a high-DPI display to a low-DPI display works perfectly.
I'm not sure about how Windows handles mixed-DPI, but it handles DPI changes mostly OK. I only access my Windows machines via RDP, so sometimes they get a high-DPI display and sometimes they get a low-DPI one. Apart from one program (there are per-program settings available in Windows to help fix scaling issues) everything seems to handle it fine.
MacOS handles it very well, moving a window from a high-DPI display to a low-DPI display works perfectly.
I'm not sure about how Windows handles mixed-DPI, but it handles DPI changes mostly OK. I only access my Windows machines via RDP, so sometimes they get a high-DPI display and sometimes they get a low-DPI one. Apart from one program (there are per-program settings available in Windows to help fix scaling issues) everything seems to handle it fine.
IIUC the macOS approach is functional but not perfect. I believe it renders all apps at a high resolution (higher than the highest attached display), then the compositor downscales them to the display. This means that apps are using more resources to render and are unable to render pixel-perfect.
I believe that on Wayland the apps are told the scaling factors of the monitors that they are on (or the compositor can scale them if they don't want to switch resolution or are across multiple monitors).
AFAIK apps can't work around this very easily (if at all).
I believe that on Wayland the apps are told the scaling factors of the monitors that they are on (or the compositor can scale them if they don't want to switch resolution or are across multiple monitors).
AFAIK apps can't work around this very easily (if at all).
IME mixed DPI under Windows is a mixed bag, with behavior varying on an app to app basis. For instance Telegram (Qt) can’t deal with being moved from one screen to the other and will look either tiny or huge, but most Win32 and WinUI apps work just fine.
This distinction doesn’t exist on macOS for the most part, even “foreign” UI libraries will appear the correct size when changing screens.
This distinction doesn’t exist on macOS for the most part, even “foreign” UI libraries will appear the correct size when changing screens.
Anecdotally both macOS and Windows have handled mixed DPI just fine for me.
> Do any desktop system handle mixed DPI well?
This works today out-of-the-box in Wayland as long as the applications are Wayland native (e.g.: not being run through XWayland).
This works today out-of-the-box in Wayland as long as the applications are Wayland native (e.g.: not being run through XWayland).
This is a major pain with the current generation of Electron apps, but luckily the newest version supports Wayland.
HiDPI is also in the works for XWayland, but it looks complicated and still a few months out.
HiDPI is also in the works for XWayland, but it looks complicated and still a few months out.
Windows handles it perfectly (anecdotal). Not sure what do you mean by freaking out.
Probably how the scaling is off while you drag windows from/to hidpi displays. The scaling is only adjusted once the pointer moves to the other display.
At least that's how it was for me when I used a high dpi display (160 dpi) 2 yrs ago. (I switched back to 90dpi at some point, so they might have improved it by now)
At least that's how it was for me when I used a high dpi display (160 dpi) 2 yrs ago. (I switched back to 90dpi at some point, so they might have improved it by now)
Mac OS X handles this by rendering everything at some insane resolution and the scaling just before displaying
That only applies for non-integer scales. If you run at clean 2x or 3x everything is drawn at native scale, unless the app doesn’t support HiDPI in which case it’s drawn at 1x and scaled up.
This explains why non integer looks so good.
Works perfectly on Wayfire and I assume Sway.
I briefly tried out Gnome and KDE, with the former "meh" (no fractional scaling, scaling glitches when dragging between displays) and the latter garbage (couldn't find scaling settings at all, so nothing is readable on the laptop display).
Widows is between "okay" and "nice" (somewhat fractional scaling, glitches between displays, some wrong scalings, but it's rare).
I haven't tried macOS yet, but expect it to be flawless, like or slightly better than the experience on Wayfire.
I briefly tried out Gnome and KDE, with the former "meh" (no fractional scaling, scaling glitches when dragging between displays) and the latter garbage (couldn't find scaling settings at all, so nothing is readable on the laptop display).
Widows is between "okay" and "nice" (somewhat fractional scaling, glitches between displays, some wrong scalings, but it's rare).
I haven't tried macOS yet, but expect it to be flawless, like or slightly better than the experience on Wayfire.
Fwiw, System Settings -> Display has the per-screen scale settings.
My wife got a 4K desktop screen for her FHD laptop a few months ago and it made us switch her system to Plasma's Wayland session. Mixed DPI works fine, also dynamically (i.e. dock/undock).
My wife got a 4K desktop screen for her FHD laptop a few months ago and it made us switch her system to Plasma's Wayland session. Mixed DPI works fine, also dynamically (i.e. dock/undock).
KDE scaling settings are pretty obviously in the Display Settings page so I'm going to say that one is user failure.
This is not the fault of X11 since it exposes all necessary data via the xrandr extention[1]. It is just toolkits like Gtk that choose to ignore that information on X11 but not on Wayland.
1.: http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
1.: http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
> I don’t know how I feel about Wayland.
Me neither. On the one hand I switched over 2 years ago and it worked fine for the most part, there a still a few things missing. One of the things were headless displays and it seems like there will be something like that in GNOME 40 - though probably experimental.
What bothers me most is that innovation is so difficult. Everything needs to be standardized first and then implemented in all different desktops like KDE and GNOME each in their own way. And this process is extremly slow. Back in the Xorg days many cool programs were made by independent users (for sceensharing, automation etc.). Writing a new Desktop or porting over one from X is almost impossible, were it not for wlroots. I wonder if we are not sacrificing too much in the name of security (OK an evil program can not keygrab and control other windows, but it can still read all my SSH keys etc.).
Me neither. On the one hand I switched over 2 years ago and it worked fine for the most part, there a still a few things missing. One of the things were headless displays and it seems like there will be something like that in GNOME 40 - though probably experimental.
What bothers me most is that innovation is so difficult. Everything needs to be standardized first and then implemented in all different desktops like KDE and GNOME each in their own way. And this process is extremly slow. Back in the Xorg days many cool programs were made by independent users (for sceensharing, automation etc.). Writing a new Desktop or porting over one from X is almost impossible, were it not for wlroots. I wonder if we are not sacrificing too much in the name of security (OK an evil program can not keygrab and control other windows, but it can still read all my SSH keys etc.).
If Wayland doesn’t replace X11, then something else needs to show up, or we drop the idea of a Linux/BSD desktop. X11 is pretty much abandoned as this point. It’s only a few RedHat engineers who are doing minor patches and no one want to manage the future releases.
There are still contributors and maintainers. Just release management "decided" that X11 is now deprecated.
I've been running Wayland for a few years now, and while I wouldn't say I've had a _perfect_ experience, I don't think I've had a time when logging out and trying an X session worked any better.
X has always had niggles, which I don't miss.
So right now, it's very much at the same level as many other system features: consistently works, and maybe the reason I'm not singing its praises more loudly is because I've come to take that for granted.
X has always had niggles, which I don't miss.
So right now, it's very much at the same level as many other system features: consistently works, and maybe the reason I'm not singing its praises more loudly is because I've come to take that for granted.
> I haven’t heard anyone singing it’s praises yet about how happy they are to use it
to benefit from every feature one has to run current software, as the ecosystem catches up. And as others write, AMD/Intel gfx have a better time than if you're on Nvidia.
Wayland as of writing has my use-cases covered: hw accelerated video decode in Browsers (FF and Chrome), Browser screensharing (via pipewire) and via VNC (conveniently surfaced to gnome-settings if gnome-remote-desktop is present). Most current distributions do not carry all necessary packages in their defaults last I checked, so one had to have some interest and flip one or two browser config flags.
to benefit from every feature one has to run current software, as the ecosystem catches up. And as others write, AMD/Intel gfx have a better time than if you're on Nvidia.
Wayland as of writing has my use-cases covered: hw accelerated video decode in Browsers (FF and Chrome), Browser screensharing (via pipewire) and via VNC (conveniently surfaced to gnome-settings if gnome-remote-desktop is present). Most current distributions do not carry all necessary packages in their defaults last I checked, so one had to have some interest and flip one or two browser config flags.
> I haven’t heard anyone singing it’s praises yet about how happy they are to use it.
I'm no expert on either X11 or Wayland. But I can tell you that happy people are usually silent while unhappy people are noisy.
I'm no expert on either X11 or Wayland. But I can tell you that happy people are usually silent while unhappy people are noisy.
> they more than anyone else know why they would need to start from scratch over improving x11.
That's not what they actually say though:
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. "
Again, they literally say "It's entirely possible". They just didn't want to.
That's not what they actually say though:
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. "
Again, they literally say "It's entirely possible". They just didn't want to.
> ... over improving x11
They have literally been improving X11 for several decades.
They have literally been improving X11 for several decades.
Does ibus work seamlessly in Wayland yet? As a person who regularly needs to input French, Chinese, and Japanese, besides English, I tried Wayland in Kubuntu 20.04 and a non-working ibus was a complete showstopper for me.
What's with IBus and IBus-centric IME switching being sub-optimal for better part of past decade or so[1], yet being pushed from non-CJK regions? Usually I don't even GNOME and just go with whatever fcitx plays with, so not an issue for me, not angry or anything but curious what's happening "up there" consistently[2][3][4].
1: https://cpplover.blogspot.com/2013/10/ibus-15_21.html
2: https://uwabami.junkhub.org/log/20210224p01.html#p01
3: https://uwabami.junkhub.org/log/20210312.html
4: https://lists.debian.or.jp/pipermail/debian-devel/2021-Febru...
1: https://cpplover.blogspot.com/2013/10/ibus-15_21.html
2: https://uwabami.junkhub.org/log/20210224p01.html#p01
3: https://uwabami.junkhub.org/log/20210312.html
4: https://lists.debian.or.jp/pipermail/debian-devel/2021-Febru...
ibus works with Gnome out-of-the-box. On sway/wlroots, you will have more luck with fcitx. I don't know which tool works best with KDE.
Why, in Wayland, support of some basic features has to do with what DE or TWM you use? It is not like this in X11 and it seems there is more adherence to the UNIX philosophy in X11.
Because Wayland is a display service protocol. It's not responsible for secure message passing between desktop applications: that's the DE's business. Just because DEs used X11 as an insecure inter-process message passing agent doesn't mean it's a good design or even make sense.
There's no "Wayland" that could implement a generic way of handling input. Wayland is an extensible set of protocols with several implementations.
Handling input is an integral part of what a compositor does, and it's not an easy problem to solve when said input doesn't map linearly to text.
Input methods in particular are not something that X11 "solves" at all: Under X every toolkit implemented their own way of handling complex input methods. XIM existed, but it was limited and only there for compatibility with ancient applications.
There are Wayland protocols for complex input methods too. Gnome's gone all-in and integrated ibus with their own compositor, so that obviously works, but Gnome also benefits a lot from distributions like Fedora making sure it works: everything is set up correctly out-of-the-box if you use Gnome. However, more niche implementations like Sway have to deal with a lower level of integration because there's no distribution that's built around Sway to create a full desktop environment.
Handling input is an integral part of what a compositor does, and it's not an easy problem to solve when said input doesn't map linearly to text.
Input methods in particular are not something that X11 "solves" at all: Under X every toolkit implemented their own way of handling complex input methods. XIM existed, but it was limited and only there for compatibility with ancient applications.
There are Wayland protocols for complex input methods too. Gnome's gone all-in and integrated ibus with their own compositor, so that obviously works, but Gnome also benefits a lot from distributions like Fedora making sure it works: everything is set up correctly out-of-the-box if you use Gnome. However, more niche implementations like Sway have to deal with a lower level of integration because there's no distribution that's built around Sway to create a full desktop environment.
Wouldnt it be the other way around?
X11 isnt adhering to the UNIX philosophy because it does everything under the sun.
Wayland gives some tasks to the compositor.
[deleted]
It's not a Wayland problem, ibus does not work in KDE even on X11.
It should work on Kubuntu and X11, but I remember that the installation and configuration process (or at least the documentation) is a bit lacking. Make sure you also install the ibus-[input method] package. If you don't the ibus preferences still allows you to add a chinese/japanese input method, but it doesn't actually do anything. You might also want to restart your x11 session after that.
Uh? I've been using ibus with mozc for Japanese input on KDE for the past 3 years.
Do you use ibus input methods only?
In my case, I wanted to keep my configured xkb keyboard layouts + I wanted to be able to use ibus in parallel for CJK.
Ok, there must be a problem with *my* KDE setup: when I try to disable KDE keyboard layouts, KDE does not persist changes to the next session: when I log in next time, KDE keyboard layouts are enabled again and interfere with ibus.
In my case, I wanted to keep my configured xkb keyboard layouts + I wanted to be able to use ibus in parallel for CJK.
Ok, there must be a problem with *my* KDE setup: when I try to disable KDE keyboard layouts, KDE does not persist changes to the next session: when I log in next time, KDE keyboard layouts are enabled again and interfere with ibus.
Same for me. been using ibus-pinyin for a few years
A project to keep an eye on, to replicate 'autotype' support offered by many password managers, is wlrctl¹. A popular alternative is ydotool², but brings some additional risks the operator might not be comfortable with.
¹https://git.sr.ht/%7Ebrocellous/wlrctl
²https://github.com/ReimuNotMoe/ydotool
¹https://git.sr.ht/%7Ebrocellous/wlrctl
²https://github.com/ReimuNotMoe/ydotool
re:ydotool. More than risks, I would say the author constantly changing things without testing and breaking the tool is what made me stop using it. I wrote my own version using evdev and never looked back.
Could you post a link to it? Ive been using ydotool for a while, its not working 100% reliably though.
It's not public. I don't really open source most of the tools I write for myself because there's basically no incentive to do so.
If this was 20 years ago, when I was kind of starting with Linux, I would love it: lots of possibilities and customisation.
But the truth is that I don't have time for all that in 2021. When XFCE supports Wayland and I get a good experience out the box, I may stop using X11.
But the truth is that I don't have time for all that in 2021. When XFCE supports Wayland and I get a good experience out the box, I may stop using X11.
The author uses Pipewire with WebRTC in Chrome, very cool.
Pipewire is showing up all over the place. I've been reading a little about it, but I finally got a comfortable setup of jackd and pulseaudio and am worried it might interfere with my stable setup.
Am I being paranoid?
Pipewire is showing up all over the place. I've been reading a little about it, but I finally got a comfortable setup of jackd and pulseaudio and am worried it might interfere with my stable setup.
Am I being paranoid?
Yes. I currently run it besides Pulse for screen sharing and there are no issues. I haven't replaced Pulse yet because it didn't work right away, but plan to try again eventually because Pipewire supports HFP, the less terrible Bluetooth headset profile.
Bluetooth support alone would be worthy of the pain of switching. Thank you.
The next version of fedora uses pipewire instead of pulse audio. From all the people I have seen test it, they said it works much better than pulse.
I'm testing it now. Fixed my USB audio issues. Much better than pulse.
I've replaced pulse with pipewire and that has been seamless. The experience is generally determined by how well the distro supports moving from one to the other rather than any maturity issues with pipewire.
I've retained jackd instead of using pipewire's implementation because I don't think the pipewire version supports transport control or timecode.
I've retained jackd instead of using pipewire's implementation because I don't think the pipewire version supports transport control or timecode.
It's not perfect but mostly works.
Is it still the case that Nvidia drivers don't work with Wayland?
The question is flawed, but I get what you mean.
Wayland the protocol has very little to do with graphics drivers (it's just about getting window content to compositors). It's just that the display server (X server or wayland compositor) uses a set of agreed upon kernel APIs (DRI) to render and display things on the screen, which Nvidia refuses to fully implement (GBM vs.EGLStreams). The X server has extra code to support this, but many wayland compositors don't. Semi-recently Nvidia (in the form of Erik Kurzinger) has started contributing such special treatment code to Gnome and KDE. A major hold out is wlroots, the maintainer of which refuses special handling code for proprietary components (https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html), but recently there has been a 3rd party contribution for an EGLStreams backend.
Additionally the Xwayland team are right in the middle of merging code to allow specific acceleration of XWayland windows and Nvidia and the wlroots team are working on building a new memory allocation solution based on Vulkan that will hopefully finally solve the EGLStreams debacle once and for all.
So: It kind of works and is improving fairly rapidly.
Wayland the protocol has very little to do with graphics drivers (it's just about getting window content to compositors). It's just that the display server (X server or wayland compositor) uses a set of agreed upon kernel APIs (DRI) to render and display things on the screen, which Nvidia refuses to fully implement (GBM vs.EGLStreams). The X server has extra code to support this, but many wayland compositors don't. Semi-recently Nvidia (in the form of Erik Kurzinger) has started contributing such special treatment code to Gnome and KDE. A major hold out is wlroots, the maintainer of which refuses special handling code for proprietary components (https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html), but recently there has been a 3rd party contribution for an EGLStreams backend.
Additionally the Xwayland team are right in the middle of merging code to allow specific acceleration of XWayland windows and Nvidia and the wlroots team are working on building a new memory allocation solution based on Vulkan that will hopefully finally solve the EGLStreams debacle once and for all.
So: It kind of works and is improving fairly rapidly.
Yes, but the patch by Erik Kurzinger from Nvidia may soon be merged [1].
It still requires changes to Nvidia's proprietary drivers that I think have not been done, but it maybe that this year it will be settled.
Edit: Also it maybe that the Ubuntu choosing Wayland maybe what pushed the Nvidia forward? [2]
[1]: https://www.omgubuntu.co.uk/2021/01/ubuntu-21-04-will- use-wayland-by-default
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
It still requires changes to Nvidia's proprietary drivers that I think have not been done, but it maybe that this year it will be settled.
Edit: Also it maybe that the Ubuntu choosing Wayland maybe what pushed the Nvidia forward? [2]
[1]: https://www.omgubuntu.co.uk/2021/01/ubuntu-21-04-will- use-wayland-by-default
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
The short version is "it depends". Essentially, each separate Wayland compositor needs to add support for the nvidia driver (or the driver needs to support more standardized APIs).
Gnome and KDE support Wayland on nvidia hardware (though it's a bit rough around the edges). Wlroots (and therefore Sway) doesn't because they don't want to have a separate code-path for one driver which doesn't want to support standards and because the APIs the driver does support wouldn't work well with the code model of wlroots.
Gnome and KDE support Wayland on nvidia hardware (though it's a bit rough around the edges). Wlroots (and therefore Sway) doesn't because they don't want to have a separate code-path for one driver which doesn't want to support standards and because the APIs the driver does support wouldn't work well with the code model of wlroots.
Nvidia works with wlroots if you use nouveau and not the proprietary drivers.
As much as I appreciate Noveau, it's not really practically usable with recent cards (due to Nvidias faults!).
It's probably not relevant in the long term anyway. I expect desktop Nvidia usage on Linux to pretty much plummet while their driver remains a blob. The trend is negative for them already.
So I fully support wlroots developer's approach to it - show Nvidia to the door until they come back with upstreamed driver.
So I fully support wlroots developer's approach to it - show Nvidia to the door until they come back with upstreamed driver.
I don't expect them to ever work properly. Basically, if you care about good Wayland user experience and proper desktop integration, you should be using AMD or Intel GPU already.
Waiting for Nvidia to fix this mess is pointless. Nvidia will be DOA as long as they refuse to upstream their driver or to support Nouveau to begin with. And they didn't show any interest for years.
Waiting for Nvidia to fix this mess is pointless. Nvidia will be DOA as long as they refuse to upstream their driver or to support Nouveau to begin with. And they didn't show any interest for years.
For Nvidia this is not a mess; they support X for their supported use-cases and that's just it, and X works pretty much perfectly for me now, even PRIME is essentially issue-less. I give them a lot of credit for making Nvidia GPUs in laptops on Linux as viable as on Windows.
PRIME is working for you? How? I couldn't get it working at all. Are there any guides for this?
This chapter of the NV driver manual details how: https://download.nvidia.com/XFree86/Linux-x86_64/460.56/READ...
On Turing and later, you can also enable this: https://download.nvidia.com/XFree86/Linux-x86_64/460.56/READ... to totally turn off the dGPU when not in use.
On Turing and later, you can also enable this: https://download.nvidia.com/XFree86/Linux-x86_64/460.56/READ... to totally turn off the dGPU when not in use.
It is a complete mess due to their inability to properly support kernel interfaces. Their driver is a blob and it's the source of all their problems with integration. Nothing stopped them from upstreaming it a long time ago but they prefer keeping the mess to doing things right.
PRIME doesn't work because they only implemented it half way. After decades of not implementing anything that is. I call such level of support complete garbage.
PRIME doesn't work because they only implemented it half way. After decades of not implementing anything that is. I call such level of support complete garbage.
There's not a lot of options in the workstation space other than NV drivers on X11. As long as nouveau continues sending illegal instructions to cards and crashing Quadros on startup, it's a non-starter. Xeons don't include a GPU, so you'll need to add an RX 2100 to the system instead of another A100 or RTX Titan. It can be done, but I don't see RX 2100s having a place in our machines anytime soon.
The best option if you need modern Linux desktop is to ditch Nvidia and to switch to AMD.
For compute as well? Maybe once ROCm is actually supported by their newest cards, but this two-year lag on compute support does not inspire confidence. Neither Navi nor Big Navi are supported -- the last card with ROCm support is Vega.
Will a little stupid, you could add an AMD card to your workstation and use that to drive your display. Then use the Nvidia card for compute only. That would also free up some memory and compute resources on the Nvidia card.
You can even get an old model of the AMD card. It only need to run the desktop stuff, so you can buy a five year old used card.
You can even get an old model of the AMD card. It only need to run the desktop stuff, so you can buy a five year old used card.
Support is better in latest cards, but they are still lagging behind for scenarios like Blender and etc.
For compute, you don't need the desktop, so the Wayland vs X11 debate is moot.
I dunno... Blender, video editing, etc. usually require a desktop.
That's not what it is mostly used for, i.e. ML-like workloads.
OpenCL (that's what Blender, DaVinci Resolve, etc use for their acceleration) is a layer above ROCm, and it runs. Not very nicely, but it does and is supposed to receive more attention in future.
Also, you can still use one gpu for desktop and other for compute.
OpenCL (that's what Blender, DaVinci Resolve, etc use for their acceleration) is a layer above ROCm, and it runs. Not very nicely, but it does and is supposed to receive more attention in future.
Also, you can still use one gpu for desktop and other for compute.
Nvidia have been extremely bad to work with in the past (hasn't Linus said something about this?), but their recent efforts are giving me some hope. They seem somewhat interested in supporting the Linux desktop nowadays.
I don't think they are interested a lot more. Same glacial pace of support. I don't expect it to improve until their driver will be in the upstream kernel.
There was some brief announcement about some kind of open sourcing news a while ago which could be it, but nothing came out of that.
So you can still apply the take of Nouveau developers themselves - simply use AMD.
There was some brief announcement about some kind of open sourcing news a while ago which could be it, but nothing came out of that.
So you can still apply the take of Nouveau developers themselves - simply use AMD.
Easier said than done, given it's nearly impossible to buy AMD GPUs at the moment (and has been for a while now)
I believe with the 470 driver series that's coming out soon things are looking a lot better[1][2].
[1] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...
[2] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...
[1] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...
[2] https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...
Not exactly. I m successfully using Fedora SilverBlue with proprietary nvidia in Wayland. In the official docs it's not supported but Mutter (from Gnome) has the pieces in place to do so. However I don't use anything too specialised that would force me back to Xorg. For example I did revert to Xorg while I played around with lutris a bit. Still as long as distro maintainers don't declare official support, be ready to expect surprises.
It works but the experience was suboptimal. Usable but much slower than x11.
Nvidia is basically dead at this point, no support for standards that have been around for years. And now they are including malware in their cards to slow down unapproved calculations.
> Nvidia is basically dead at this point
As of this morning's Nvidia's market cap ($320B) is bigger than AMD's ($100B) and Intel's ($255B).
As of this morning's Nvidia's market cap ($320B) is bigger than AMD's ($100B) and Intel's ($255B).
CUDA is an industry standard, and AMD's lack of support is why NVIDIA enjoys a monopoly in the deep learning community.
It's proprietary. People being vendor-locked into a proprietary thing doesn't mean everyone can or should support it.
Is this due to CUDA being a technically superior product, or is it just that it's entrenched?
OpenCL/AMD is a usable and mature platform, right?
OpenCL/AMD is a usable and mature platform, right?
OpenCL as implemented by AMD is definitely not very usable.
AMD themselves aren’t really committed to OpenCL given the state of their OCL 2.x drivers and went to their own AMD-only path (ROCm/HIP), which is broken... (and only supported on a single gen of customer GPUs today, Vega) It doesn’t even work on RDNA or RDNA2 officially today.
AMD themselves aren’t really committed to OpenCL given the state of their OCL 2.x drivers and went to their own AMD-only path (ROCm/HIP), which is broken... (and only supported on a single gen of customer GPUs today, Vega) It doesn’t even work on RDNA or RDNA2 officially today.
I've been told that OpenCL is in a whole different league than CUDA due to a worse API and much smaller ecosystem.
I have, however, seen attempts to use Vulkan for compute. Could that be a viable way forward?
I have, however, seen attempts to use Vulkan for compute. Could that be a viable way forward?
I'd say OpenCL is a pretty good API, it's just that because it's in C and it allows for quite fine-grain control, it takes a bit of orchestration to get anything off the ground. If you want more convenience, there are a few wrappers for it, in various languages.
It's true that its ecosystem is sadly lacking.
It's true that its ecosystem is sadly lacking.
Using Vulkan for compute is still a much worse developer experience, it isn't really a reasonable alternative.
Still waiting for KWin to support adaptive sync and then I'll be switching to the Wayland session.
I am on Arch + Gnome for 3 years now and tried Wayland again this year and experienced too many broken things (Screen.so screensharing, Fireshot screencapture, I think CopyQ clipboard manager too) and had to switch back to X11. This article shows it is still not ready for the masses, yet.
Flameshot for screencapture and the standard gnome extension clipboard manager work pretty well for me on Wayland.
Cant say anyting about screensharing with Screens.so. Zoom works though.
Ive been a happy Wayland user since 2017 or 2018, not entirely sure.
Cant say anyting about screensharing with Screens.so. Zoom works though.
Ive been a happy Wayland user since 2017 or 2018, not entirely sure.
Not a single screenshot
Here you go: https://kurisu.shibumi.dev/share/img-2021-03-27-21-02-41.png
This is a screenshot from my current system.
* btw it's my first post on ycombinator lol..
This is a screenshot from my current system.
* btw it's my first post on ycombinator lol..
Of what would you possibly want a screenshot here?
It is about the under the hood plumbing so take any screenshot from the last years, copy it and write "this is what it looks like under wayland".
It is about the under the hood plumbing so take any screenshot from the last years, copy it and write "this is what it looks like under wayland".
I like to see what other people have crafted for their own usage. Sometimes, I find a clever use of monitor real estate that would make my life easier.
I adopted most of my tools by looking at other people setups and customizing them to my use case.
I adopted most of my tools by looking at other people setups and customizing them to my use case.
Unsure if this is a low key jab at Wayland breaking screenshot tools ...
The book has no pictures?
It's sway. So that's what it looks like.
And the content is much deeper than showing off the color scheme you chose.
It's sway. So that's what it looks like.
And the content is much deeper than showing off the color scheme you chose.
I was really looking forward to Wayland, when I moved to Linux. It was then said to be right around the corner. That was six years ago. If the current state of Wayland is as bare-bones as depicted in the article, it's just sad. And as there is no support for OBS on the horizon, it's a non-topic for me. And I never liked X11 to begin with...
Yes, there is: Through Pipewire (xdg-desktop-portal), wlr-screencopy (wlrobs) or a virtual webcam (wf-recorder) :-)
Pipewire has the brightest future long term, but wlrobs seems to be the easiest to get started with if "Wayland" means wlroots based compositor (Sway, Wayfire, etc) in this instance.
Pipewire has the brightest future long term, but wlrobs seems to be the easiest to get started with if "Wayland" means wlroots based compositor (Sway, Wayfire, etc) in this instance.
OBS is working already with wlrobs.
https://hg.sr.ht/~scoopta/wlrobs
https://hg.sr.ht/~scoopta/wlrobs
Thanks for the link.
If you are looking for an alternative status bar that works with sway, you can use my fork of yagostatus :)
https://github.com/denysvitali/yagostatus
https://github.com/denysvitali/yagostatus
I'm using https://github.com/greshake/i3status-rust which also works well with Sway.
I currently use i3status-rust. with a lot of custom blocks, with X. I'm thinking of switching to Sway. Did you have any config problems?
Not that I can think of, but obviously it depends on what your blocks are doing. I remember having trouble with the backlight block, but I fixed that upstream a long time ago, so it should not be a problem for you anymore.
For reference, my config is at: https://github.com/majewsky/devenv/tree/master/i3status-rust (as a bunch of single-purpose snippets, the actual config file is obtained by concatenating `common/.toml` and `$HOSTNAME/.toml`)
For reference, my config is at: https://github.com/majewsky/devenv/tree/master/i3status-rust (as a bunch of single-purpose snippets, the actual config file is obtained by concatenating `common/.toml` and `$HOSTNAME/.toml`)
It's possible to also configure bemenu with BEMENU_OPTS env variable. I usually create wrapper script in my local bin path however, as that method will work universally with any program.
I'm not switching to Wayland. It simply doesn't do anything for me. It also doesn't function with many of the GPUs I use.
Can I run applications transparently over the network yet?
You can run applications over the network with (edit: waypipe, not pipewire, I mix up the names every time), which works quite well. Technically it's not "transparent", but it isn't on X either because pretty much 0 UIs today draw themselves using X11 primitives, they just draw their own buffer and get X to display it.
[deleted]
This isn't really an answer to your question, but under Gnone3+Wayland "ssh -X" works as you might expect. Which amazed me at first, because I wasn't expecting it.
Turns out it's because most applications are X11, Wayland supports X11 applications via XWayland, and X is doing network transparency like it always does.
Turns out it's because most applications are X11, Wayland supports X11 applications via XWayland, and X is doing network transparency like it always does.
I don't think network transparency is a goal for Wayland. X11 network transparency was awesome in the late 80s and early 90s. In many universities, there would be rooms of X11 terminals that connected to the "big machines" in the server rooms- and you could have each of your applications, even even the window manager itself, all being run on different machines.
This made sense when an institution would license software for their big iron, and when desktop computers weren't nearly as powerful as they eventually became during the 90s.
But most people gave up on it right around the time that Netscape Navigator, with its very bitmap-heavy UI gained traction. The X protocol really wasn't designed around this. Extensions helped, but not enough.
I bet the vast majority of people using X11 today have never run a remote X11 client.
This made sense when an institution would license software for their big iron, and when desktop computers weren't nearly as powerful as they eventually became during the 90s.
But most people gave up on it right around the time that Netscape Navigator, with its very bitmap-heavy UI gained traction. The X protocol really wasn't designed around this. Extensions helped, but not enough.
I bet the vast majority of people using X11 today have never run a remote X11 client.
- A unified way to change applications settings. All old X apps used to read the X resources database (xrdb): you could set a global color scheme, fonts, window geometry and what not, all in one place using a simple but powerful text format.
- The simplicity of the window managers, hotkey daemons and other X clients. You can implement a functional wm in a few hundred lines of C[1] because the X server takes care of most of the stuff. In comparison a compositor has much more work to do and it's difficult to implement one, unless using a big library like wl_roots.
- A base graphics API based on drawing primitives like the original X, SVG or Cairo, rather than just bitmaps. This would make writing a simple application without importing huge frameworks feasible again. Also sending the drawing calls over the network would probably be less bandwidth intensive.
[1]: https://github.com/vardy/aphelia