KDE's Nate Graham On X11 Being A Bad Platform & The Wayland Future

Well known KDE developer Nate Graham is out with a blog post today outlining his latest Wayland thoughts, how X11 is a bad platform, and the recent topic of “Wayland breaking everything” isn’t really accurate.

“In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported yet”. This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore. For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on. It’s all happening!”

Nate’s Original Blog Post

danielfgom,
@danielfgom@lemmy.world avatar

Undoubtedly Wayland is the way forward and I think it’s a good thing. However I wouldn’t piss all over X because it served us well for many years. My LMDE 6 still runs X and probably will for the next 2 years at least because both the Mint Team and Debian team don’t rush into things. They are taking it slow, testing Wayland to make sure no-one’s system breaks when they switch to Wayland.

This is the best approach. Eventually it will all be Wayland but I never understood why this is such an issue. Like any tech it’s progress, no need for heated debates. It’s just a windowing system after all.

chitak166,

Eh, I always discredit people when they say X is bad.

It’s been around for over 20 years. That kind of longevity should be praised.

Omega_Jimes,

I love Wayland until I don’t. I honestly don’t think about it, it gets out of my way and my system is stable, until I go to use something like scrcpy that just doesn’t work at all. Luckily, the amount of things that straight up don’t work is shrinking.

Dio9sys,

It’s super impressive to see Wayland having its big breakthrough moment. I remember reading about Wayland 10 years ago and worrying it was going to end up as a dead project.

taanegl,

Wayland on an Intel iGPU runs flawlessly and has for several years. However, that’s a matter of drivers. AMD is in the forefront regarding having dGPU support, while NVIDIA is playing catch-up.

In any case, the future is bright.

danny801,
@danny801@lemmy.world avatar

deleted_by_author

    •
    wreckage,

    input-leap will but it’s still in development

    mlg,
    @mlg@lemmy.world avatar

    Nvidia on Wayland moment

    Gaming on wayland moment

    Battery/Usage on wayland moment

    KDE devs making gestures only available on wayland because memes (there is literally a 3rd party github script to achieve the same thing on X11)

    X11 being reliable because Xorg devs aren’t stupid

    My real issue with Wayland is that it took like 15 years to become acceptably usable. I’ll switch once XFCE moves over in several years, but until then, there is no incentive for worse performance and non exitestent support.

    ExLisper,

    Exactly. For 10 years the groupthink was that Wayland doesn’t offer anything interesting and X is just fine. Now suddenly everyone who’s still using X is stupid. Amazing what couple of memes can do.

    yukijoou,

    it’s that wayland wasn’t ready, and now is ready. it took a long time, because building a new protocol like that takes a while if you want to do it well, and lots of coordination between many people. it still has issues, but they’re being adressed. slowly, because x11 was full of half-assed solutions done quickly, and they don’t want that to happen again

    dreugeworst,

    X11 being reliable because Xorg devs aren’t stupid

    Not gonna disagree with the rest of what you said, but the Xorg devs and Wayland devs are mostly the same people

    chitak166,

    They’ve been working on the same software for 20+ years?

    Woah.

    tetris11,
    @tetris11@lemmy.ml avatar

    It’s not about reliability though, X11 is hard to maintain and the devs themselves feel burned out. Wayland at least offloads some of that burden to the desktops

    yukijoou,

    X11 being reliable because Xorg devs aren’t stupid

    xorg devs are wayland devs. nowadays, most of the people that used to work on xorg now work on wayland. they’re not stupid, they realised that x11 is too dated for modern systems (see asahi linux) and now are working on a replacement

    sherlockholmez, (edited )

    Wayland doesn’t support Nvidia GPUs yet

    I’m sorry, my bad, I was unaware.

    Nvidia GPUs don’t support Wayland yet. As Linux Torvalds would say, “NVidia, Fuck You”

    SquigglyEmpire,

    “Wayland” doesn’t support any GPU’s, it’s the job of each GPU driver to support Wayland (and Nvidia’s now does).

    iopq,

    I’ve switched to Wayland on my Nvidia GPU and I’m taking the FPS hit. OBS crashes when I run a wine game on x11

    sherlockholmez, (edited )

    Yup, but my external monitor stuttered insufferably, so I still stuck with X11. Didn’t try OBS but Wine worked like a charm.

    TheGrandNagus,

    *Nvidia didn’t support Wayland

    jodanlime,
    @jodanlime@midwest.social avatar

    This is the big thing that all these Nvidia comments miss. It’s not up to Wayland to support a given GPU. Nvidia is actively hostile to Linux users. If you aren’t making money with cuda there are zero reasons to choose Nvidia on a Linux machine over the competition. I’ve been on Wayland for almost a decade now and there’s no way I’m going back to X at this point.

    https://arstechnica.com/information-technology/2012/06/linus-torvalds-says-f-k-you-to-nvidia/

    gnumdk,
    @gnumdk@lemmy.ml avatar

    Fuck You NVIDIA

    Kristof12,
    @Kristof12@lemmy.ml avatar

    Nouveau is functional… Probably

    tiziodcaio, (edited )

    My nVidia GPU works with the propietary driver

    cobra89,

    Uh reading the article, pretty sure the author would phrase it as “Nvidia GPUs don’t support Wayland yet” and that author would be absolutely right.

    walthervonstolzing,
    @walthervonstolzing@lemmy.ml avatar

    FWIW, I’m typing this on the latest GNOME, on wayland, on nvidia proprietary drivers; and it works just fine — EXCEPT for suspend & resume, which is annoying to be sure; but on 2 screens with different refresh rates & different dpi ratios I at least don’t run into some of the weird behavior I do run into using X11.

    I used to be an Xfce purist; but this particular setup is even less taxing on the GPU (GTX 970) compared to Xfce’s standard compositor (around 20W on light usage, vs. 35+W); & and the font rendering is slighly better, which is a huge factor AFAIC.

    theshatterstone54,

    Hey there, what tool do you use to find power usage? Thanks

    walthervonstolzing,
    @walthervonstolzing@lemmy.ml avatar

    Hi; I rely on nvidia-smi mostly; but the nvidia-settings gui app also shows temperatures & wattage (though that app might be x11-only).

    leopold,

    Oh boy, 102 comments. Knowing Phoronix, I bet those are a treat to read.

    IverCoder, (edited )

    Fourteen pages of comments within a day of posting in Phoronix? Grab your popcorn guys 🍿

    loopgru,

    Anecdote, I know, but for my use cases, Wayland just isn’t there yet- I wind up with far more random bugs and less battery life. I don’t pretend to know why, I’m a pleb non-developer, but until that’s resolved I’m still stuck on X. I’d love to use the new shiny thing of The Future™, but not at the cost of stability and usability.

    vox,
    @vox@sopuli.xyz avatar

    Wayland nearly doubled my battery life lol

    dRLY,
    @dRLY@lemmy.ml avatar

    I think that given how frequently this argument is brought up (and it is of course true about it not being completely there yet) so this is just my opinion on the situation (and I am not a dev so I am fine with being wrong and corrected). It is kind of needed for more projects/distros to start actively using it. As a lot of the stuff kind of needs the band-aid ripped off to start forcing it to get there faster at this point. Otherwise it just keeps being held back as people on the coding end of things will keep focusing on X11 issues instead of getting things ready for Wayland.

    Kind of like the conundrum of mobile OSes that aren’t Android or iOS. It is hard to get people/companies to even try the new OS because the lack of apps (specifically the most common ones used by the most people). But app devs don’t want to spend time re-building or starting new apps for an OS that isn’t being used (or on devices people are buying). So at a certain point it needs both sides to interact and make progress. The OS needs the apps more at this point, and getting feedback and data from those devs makes it known where things are and aren’t working. But it is also true the devs for the apps might end up finding out the OS is actually easier to work with compared to what they have been doing/dealing with on Android/iOS.

    Getting a replacement for X11 has been needed for a long time as the OSes and features keep needing something new to better work for how computers have advanced. And it isn’t something that many devs would want to take on given how easy it is to just use what is already known. Since Wayland has finally gotten to the point it is now, it is time for more devs to start learning/moving to the new thing to get attention to the stuff that they need. The hardest part is this in between period for users as it can and will cause random issues (like the ones you have seen). Stability is important, but Linux is great because there will always be distros and projects that keeping the old thing running well is the main objective. So we are in some great times for the new to be pushed hard so it can become the stable future needed.

    nix,

    Been trying to think of a term for this issue. It’s not quite chicken or egg. But both sides need the other side to incentivize them. If one gets going the other will follow, but they’re waiting for each other. Like some sort of collaborative standoff.

    FiskFisk33,

    Soo support for something like synergy would be great!

    loutr,
    @loutr@sh.itjust.works avatar

    Input Leap (fork of a fork of synergy) supports Wayland under gnome, although it seems there are a few bugs remaining.

    corsicanguppy,

    Input Leap

    Thank you for this information.

    FiskFisk33,

    I’ll watch that project with great interest!

    mnglw, (edited )

    fucking what synergy doesn’t work on Wayland? welp. I use that daily and no, that’s not optional, its rather critical for my setup

    DumbAceDragon,
    @DumbAceDragon@sh.itjust.works avatar

    Really looking forward to the day nvidia drivers properly support wayland. Getting tons of bugs, stutters, and general usability issues with plasma wayland on my 3060. X11 just works on the other hand, even with multiple monitors running at different refresh rates (something a friend of mine said X11 doesn’t work well with). But I want all the nice benefits wayland offers.

    Quackdoc, (edited )
    @Quackdoc@lemmy.world avatar

    Really glad probonopd is doing this, X11 is dying but wayland isnt ready to replace it, so it’s nice to have this

    EDIT, paste didn’t work github.com/…/wayland-x11-compat-protocols

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    Read the article, specifically the part mentioning where X11 is going and distributions that aren’t fedora.

    Quackdoc,
    @Quackdoc@lemmy.world avatar

    woops my bad, I mean to link this github.com/…/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    Also read the article (as in the original blog post) about that repo.

    Quackdoc,
    @Quackdoc@lemmy.world avatar

    I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.

    IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    And that’ll shake out in the time it takes for X11 to go away. I get what you’re saying, although I don’t share your opinion about portals from a user perspective: I’m just happy that Firefox finally uses the Plasma file picker.

    Quackdoc,
    @Quackdoc@lemmy.world avatar

    I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.

    I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.

    I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.

    PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.

    I partially agree about the focus on containers/sandboxes. Yes, it makes sense to criticize that something designed for a different use case results in different trade-offs. But on the other hand, are the use cases really that different? We’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?

    Otherwise I don’t know enough about the standards to comment there, you’re probably right!

    Quackdoc,
    @Quackdoc@lemmy.world avatar

    I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.

    The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.

    we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?

    sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)

    ikidd,
    @ikidd@lemmy.world avatar

    Wayland has fixed so many head-scratching issues I would get running 6 monitors on 2 GPUs under X11. I’d often end up with missing monitors, placed in wrong spots that I’d have to rearrange every reboot until an update would come through that would fix it again for a few months, then all over again.

    Since I moved to wayland, everything just works. When it doesn’t, it’s not a display server issue, it’s something physical. I just had a couple monitors fail to show up and thought “oh hell, it’s back to this, eh”. But I open the tower, seat the offending GPU better, and everything comes up like normal, and all the screens are in the right position, it just remembers.

    Anyone that thinks X11 is still superior probably runs on a laptop with a single screen.

    Still,
    @Still@programming.dev avatar

    man it crazy I switched to Wayland on my laptop and docking to 3 monitors just worked on Wayland and it would remember all my monitors settings

    I hand like 2 or 3 scripts setup to try and manage that on x11

    lemmyvore,

    I mean I’m fully with you on the fact screen autodetect isn’t stellar on X but there’s no need to exaggerate with “2 or 3 scripts”. It’s one xrandr command.

    lemmyvore,

    And I’m sure all the other people using 6 monitors on 2 GPUs at the same time will appreciate it.

    Seriously, how common is such a scenario that you’d even mention it in this context?

    bruhduh,
    @bruhduh@lemmy.world avatar

    Ultra wide for cheap is one of uses

    LeFantome,

    3 monitors is probably a lot more common than you think.

    people_are_cute,
    @people_are_cute@lemmy.sdf.org avatar

    I have, unironically, never seen anyone using three monitors together on a PC in my life.

    aBundleOfFerrets,

    A lot of people that run three monitors got all three from a thrift store for $8

    SkyeStarfall,

    Seriously? That’s my home setup, and a lot of my friends also have 3 monitors.

    I’m surprised you don’t know anyone who has three monitors. It’s common for tech-y people.

    bufalo1973, (edited )
    @bufalo1973@lemmy.ml avatar

    Main work + secondary work (docs, output, …) + sensors/debug/multimedia

    meekah,
    @meekah@lemmy.world avatar

    Ive seen several devs do that, and also some of my gaming friends have 3 monitors.

    I barely know anyone who only has a single display. Most people I know have one high refresh rate monitor, and one office monitor for discord and the likes.

    UdeRecife,
    @UdeRecife@literature.cafe avatar

    Hello! Nice to meet you. I know and love your kind. One monitor is pretty standard, so I have a lot of friends just like you.

    Yup, 3 monitors user here. I guarantee it’s not that uncommon.

    (And yes, I’m still running X11)

    iopq,

    Two monitors with different refresh rates is very common. Think laptop connected to a bigger monitor.

    pineapplelover,

    I have 2 75hz and a 240hz. It’s been alright for me on kde and x11. Although, I do want to give this Wayland thing a shot after hearing it being brought up so many times

    PixxlMan,

    Since it’s probably reasonably rare it’s a good demonstration of the stability of Wayland. It makes sense to mention it imo

    IHeartBadCode,
    @IHeartBadCode@kbin.social avatar

    Over on Nate's other blog entry he indicates this:

    The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible

    And I think this is something people tend to forget. X11 as a protocol is complex and writing an implementation of it is difficult to say the least. Because of this, we've all kind of relied on Xorg's implementation of it and things like KDE and GNOME piggyback on top of that. However, nothing (outside of the pure complexity) prevented KWin (just as an example) implementing it's own X server. KWin having it's own X server would give it specific things that would better handle the things KWin specifically needed.

    Good parallel is how crazy insane the HTML5 spec has become and how now pretty much only Google can write a browser for that spec (with thankfully Firefox also keeping up) and everyone is just cloning that browser and putting their specific spin to it. But if a deep enough core change happens, that's likely to find its way into all of the spins. And that was some of the issue with X. Good example here, because of the specific way X works an "OK" button (as an example) is actually implemented by your toolkit as a child window. Menus those are windows too. In fact pretty much no toolkit uses primitives anymore. It's all windows with lots and lots of text attributes. And your toolkit Qt, Gtk, WINGs, EFL, etc handle all those attributes so that events like "clicking a mouse button" work like had you clicked a button and not a window that's drawn to look like a button.

    That's all because these toolkits want to do things that X won't explicitly allow them to do. Now the various DEs can just write an X server that has their concept of what a button should do, how it should look, etc... And that would work except that, say you fire up GIMP that uses Gtk and Gtk has it's idea of how that widget should look and work and boom things break with the KDE X server. That's because of the way X11 is defined. There's this middle man that always sits there dictating how things work. Clients draw to you, not to the screen in X. And that's fundamentally how X and Wayland are different.

    I think people think of Wayland in the same way of X11. That there's this Xorg that exists and we'll all be using it and configuring it. And that's not wholly true. In X we have the X server and in that department we had Xorg/XFree86 (and some other minor bit players). The analog for that in Wayland (roughly, because Wayland ≠ X) is the Compositor. Of which we have Mutter, Clayland, KWin, Weston, Enlightenment, and so on. Which that's more than just one that we're used to. That's because the Wayland protocol is simple enough for these multiple implementations.

    The skinny is that a Compositor needs to at the very least provide these:

    • wl_display - This is the protocol itself.
    • wl_registry - A place to register objects that come into the compositor.
    • wl_surface - A place for things to draw.
    • wl_buffer - When those things draw there should be one of these for them to pack the data into.
    • wl_output - Where rubber hits the road pretty much, wl_surface should display wl_buffer onto this thing.
    • wl_keyboard/wl_touch/etc - The things that will interact with the other things.
    • wl_seat - The bringing together of the above into something a human being is interacting with.

    And that's about it. The specifics of how to interface with hardware and what not is mostly left to the kernel. In fact, pretty much compositors are just doing everything in EGL, that is KWin's wl_buffer (just random example here) is a eglCreatePbufferSurface with other stuff specific to what KWin needs and that's it. I would assume Mutter is pretty much the same case here. This gets a ton of the formality stuff that X11 required out of the way and allows Compositors more direct access to the underlying hardware. Which was pretty much the case for all of the Window Managers since 2010ish. All of them basically Window Manage in OpenGL because OpenGL allowed them to skip a lot of X, but of course there is GLX (that one bit where X and OpenGL cross) but that's so much better than dealing with Xlib and everything it requires that would routinely require "creative" workarounds.

    This is what's great about Wayland, it allows KWin to focus on what KWin needs, mutter to focus on what mutter needs, but provides enough generic interface that Qt applications will show up on mutter just fine. Wayland goes out of its way to get out of the way. BUT that means things we've enjoyed previously aren't there, like clipboards, screen recording, etc. Because X dictated those things and for Wayland, that's outside of scope.

    corsicanguppy,

    The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it.

    So there’s a Wayland hope for systemd-afflicted boxes and their cults.

    SaltySalamander,
    @SaltySalamander@kbin.social avatar

    You anti-systemd folks are so insufferable.

    fxdave, (edited )

    That’s my problem with this. It tries to be a desktop display server protocol without unifying all desktop requirements. Sure, X11 is old and have unnecessary things that aren’t relevant anymore, however, as someone who builds their own DE, (e.g.: tiling window managers) I see it as the end of this masterrace. Unless everybody moves to wlroots. Flameshot, for example, is already dealing with this, having at least 5 implementations only for linux, and only wlroots and x11 are standards.

    Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE. But as you said DEs can implement it simply. Let’s say wlroots will implement this but others can decide otherwise. And for those the app won’t run.

    Another example, that affects my app personally, is the ability to query which monitor is the pointer at. Wayland doesn’t care having these so I doesn’t care supporting wayland. And I"m being sad about this because X is slowly fading away so new apps will not run on my desktop.

    Moreover with X11 I could write my own hotkey daemon in my lanuage of choice, now I would have to fork the compositor.

    Do I see it wrong?

    barsoap,

    Also, imo, having windows in windows is useful when you want to use your favourite terminal in your favourite IDE.

    The wayland way to do that is to have the application be a compositor, they made sure that nesting introduces only minimal overhead. And that ties in with the base protocol being so simple: If you only need to deal with talking to the compositor you’re running on, and to the client that you want to embed, a wayland compositor is indeed very small and lean. Much of the codebase in the big compositors deals with kms, multiple monitor support, complex windowing logic that you don’t need, etc.

    Oh and just for the record that doesn’t mean that you can’t undock the terminal: Just ask the compositor you’re running on for a second window and compose it there. You can in principle even reparent (client disconnecting from one compositor and connecting to the other) but I think that’s only standardised for the crash case there’s no standard protocol to ask a client to connect to another compositor. Just need to standardise the negotiation protocol, not the mechanism.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20975616 bytes) in /var/www/kbin/kbin/vendor/symfony/http-kernel/Profiler/FileProfilerStorage.php on line 171

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 10108264 bytes) in /var/www/kbin/kbin/vendor/symfony/error-handler/ErrorRenderer/HtmlErrorRenderer.php on line 339