A response to the "Boycott Wayland" article

Link to article: gist.github.com/…/9feb7c20257af5dd915e3a9f2d1f227…

This OUTDATED article gets posted all the time. The full story is the guy is a massive FreeBSD fan so he is trying to convince more people to keep on using Xorg because he wants to make sure it isn’t abandoned. Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries.

Let’s go through the article point by point:

Wayland is broken by design:
  • A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.
  • You cannot do a lot of things: What, like allowing Windows to see your keystrokes, which makes developing a keylogger absolutely trivial?
  • There is not /usr/bin/wayland: Yes, because Wayland is a set of protocols, which a bunch of projects can implement as few or as many of, as they see fit, thus avoiding the issue of “unmaintainable mess” that has plagued Xorg for years.
  • It offloads work to the window manager: Again, yes, that’s a part of its structure: do the protocols, then let the compositor implement them. That way, you have multiple implementations running simultaneously that are well integrated with their window managers and thus more efficient and performant. It also means that when a compositor suffers from too much cruft, we can just make a new one, while application developers wouldn’t really have anything to change because if their application works on Wayland, then it works on different compositors (unless it is made specifically for GNOME, or specifically for wlroots, like wlr-randr)

…so what works on DE 1, doesn’t necessarily work on DE 2: True, because oftentimes, it doesn’t need to. Not implementing features can lead to a more lean and streamlined software solution. However, sometimes features are necessary and only implemented in some compositors. This usually happens because the universal solution is not ready. KDE are often known to do this with Plasma and KWin.

  • Wayland breaks screen recording applications: Correction: The following screen recording applications were not built to support Wayland (because Wayland is new to them or they just decided not to, or they were either too busy or too irresponsible enough to realise Wayland is coming, and has been for over 10 years. In defence of the devs, they probably wanted to make sure Wayland will become stable enough, but it has been the default even on Debian for many years now, so…

In terms of the applications, I’m not aware of many of them, and for this sort of application, I’m sire alot of work is required to change the graphical backend, so I understood that some smaller projects gave up, but OBS has been working on Wayland for quite a while. Is it perfect? I don’t think so, but back when Brodie Robertson was using Hyprland, he was recording his videos using OBS. This article is quite outdated.

  • Wayland breaks screen sharing applications:

As the update shows, Jitsi now does work on Wayland.

Zoom only seemed to work on gnome, BUT if you open up the Link to the zoom issue and read through the comments, there is clearly a person that clearly states that they changed /etc/os-release from PureOS to debian and it worked for them, all because of some pointless limitations enforced by the Zoom developers. As the person posting the issue states “Currently, the zoom application has put an arbirtrary restriction on screensharing so it ONLY works on GNOME, when the api being used works on all wayland desktops.” Read that again. It’s a pointless restriction put there by the Zoom team because they couldn’t be bothered to test anything non-GNOME.

And the last issue is a problem with the article writer’s own appimage. I don’t know about that one.

  • Wayland breaks automation software

As stated IN YOUR FACE, it is an application that works on X11 only. Yes, Wayland is not made to use such applications, but it doesn’t mean they can’t exist. Every heard of ydotool (remember that name)? Now you have.

Next up, we have 3 issues about GNOME and KDE global menus (1 for GNOME, 2 for KDE). From the little I know about global menus and using these projects, as well as considering that they are both incredibly stable on Wayland and Fedora KDE will be dropping Xorg completely, I think it’s safe to assume these issues have probably been fixed. Please correct me if I’m wrong.

  • Wayland breaks AppImages that don’t ship a special QT plugin: Great! Just ship the plugins then! Problem solved! Also, quote from the article: “However, there is a workaround: “AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode” (see below).”
  • Wayland breaks Redshift: Once again, a program built for Xorg doesn’t always work on Wayland. Especially if it works with the compositor, like a colour temperature control application, or a wallpaper setter. The article quotes that “Redshift does not support Wayland since it offers no way to adjust the color temperature” which is not true, as proven by Redshift alternatives like Gammastep.
  • Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure, but Hyprland has not allowed that to stop them from implementing a solution where you can choose keys that will be passed on to the application. Boom, problem solved. Unfortunately, it doesn’t seem to be implemented anywhere else, as far as I know.
  • Wayland does not work for XFCE: Come back to me in late 2024 after XFCE 4.20, which will introduce Wayland support, has been released. Also, wiki.xfce.org/releng/wayland_roadmap
  • Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.
  • Wayland does not work properly on Intel hardware: Again, I’m using AMD, so I can’t confirm or deny this, but considering the Intel drivers are open source, and I’ve heard about many, many improvements made on the Intel side of things, I think it would be reasonable to assume it has been fixed.

Edit: As multiple Intel users have pointed out in the comments, there seem to be no issues on Wayland with Intel hardware.

  • Wayland prevents GUI applications from running as root: This one has been crossed out as the article writer admits there is a solution
  • Wayland is biased towards Linux and breaks BSD: Arguments seem valid, and I’m guessing, are correct. This one is likely true and will remain so for the foreseeable future.

Edit: And yet, it seems that there are Wayland compositors for FreeBSD, so the above might only be true for OpenBSD and others.

  • Wayland complicates server side decorations: From what I’ve heard, this is true, mainly something to do with some GNOME agenda, as the article states. I think that one is true.
  • Wayland breaks windows raising/activating themselves: The linked issue is closed and seems to be resolved. There is a mention of a WIP protocol at the time (2019) that woukd fix this. I had difficulty following the discussion, but I think this has been fixed.
  • Wayland breaks RescueTime: Because RescueTime depends on X11-only tools like xprop.
  • Wayland breaks window manager: What you’re describing is Wayland breaking X11-only tools for doing various tasks in a window manager. They are X11 tools, so of course they don’t work on Wayland. I’m not sure if there are alternatives, but I’d guess there probably are. I know for a fact that Xrandr has alternatives like wlr-randr and kanshi for wlroots.
  • Wayland requires {instert WM here} to implement Xorg-like functionality:Yes, it does.

Quote from article: "As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. "

DEs: GNOME, KDE, MATE, XFCE, Cinnamon, Budgie, Enlightenment, and recently even Pantheon have either announced to start work on, have started work on, or already support Wayland.

Window managers: Qtile is doing it. Xmonad wants to hire a dev to do it. Dwm has a spiritual successor called dwl. i3 has a drop-in replacement called sway. Openbox has 2 spiritual successors called labwc and waybox. Now you might notice one of the biggest WMs is missing on here: AwesomeWM, which is such a shame. The Awesome devs have said they would be okay with someone taking on that challenge (which has already been attempted, as evidenced by the existence of way-cooler), but it seems that they wouldn’t do it themselves.

As for the projects mentioned in the article, (JWM, TWM, XDM, IceWM) they are too small and obscure, and will likely fade away with Xorg.

  • Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol I don’t know about that one, ao I’ll assume it is still the case. Edit: Ignoring the fact that the link is broken, it basically just links to a docs change where skipTaskbar is marked as unsupported on Linux. Link: github.com/electron/electron/pull/33226
  • Wayland breaks NoMachine NX The link points to a page that has this marked as “SOLVED, Released in version 8” so I’m guessing it has been solved.
  • Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

Edit: As pointed out by some people in the comments, there are also alternatives to xclip like wl-clipboard.

  • Wayland breaks SUDO_ASKPASS: That link seems to point to the way this issue has been resolved so I don’t see your point.
  • Wayland breaks X11 atoms: I lack knowledge on the topic so will assume this to be a valid argument
  • Wayland break games: I’m 99% sure you can disable Vsync??? But I’m not a gamer. Also, WINE on Wayland is getting better and better. Soon enough, I hope the subpar performance will become better performance (when compared to Xorg)
  • Wayland breaks xdotool: Well, yes. There is ydotool, but you’re looking for a 1-to-1 replacement and I’m not sure if ydotool fits the bill for that.
  • Wayland breaks xkill: Well, yes. Again. It is an X application, so of course it does. Though for some reason I remember it working once on wayland. Must have been an xwayland app, or maybe I’m just misremembering this.
  • Wayland breaks screensavers: Yeah, that seems to be the case.
  • Wayland breaks setting the window position: That is a WIP for Plasma, not sure about any other projects, so assume true for anything else.
  • Wayland breaks color management: Not anymore. That is being actively worked on.
  • Wayland breaks DRM leasing: While not rhat familiar with the issue, my understanding of the topic is the article is correct: not all compositors support it.
  • Wayland breaks in-home streaming: Not familiar with this, so will assume true.
  • Wayland breaks NetWM/EWMH: Yeah, that seems to be the case.
  • Wayland breaks window icons: Yeah, that seems to be the case, as said in the article, when no .desktop files are used.

And that concludes my response to this article based on my fairly limited knowledge on the topic. If I got anything wrong, please, please let me know. As you can see my knowledge is quite limited, and as such, any corrections (preferably backed up with evidence) would be appreciated

yum13241,

Add screensavers or take X11 out of my cold, dead hands. I don’t use a CRT but still like screensaver since it prevents me from having to wait 5 years for my screen to turn on.

dukatos,

Found AOC user :)

yum13241,

Wdym AOC

dukatos,

AOC monitor. It takes ages to wake up.

yum13241,

Nah. I’m using the built in monitor on my craptop.

jokeyrhyme,
@jokeyrhyme@lemmy.ml avatar

Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure

Not disagreeing at all, but I’d like to add some information here to support your correction

There’s a GlobalShortcuts portal ( flatpak.github.io/xdg-desktop-portal/docs/-… ), and this is implemented for hyprland in xdg-desktop-portal-hyprland ( github.com/hyprwm/…/hyprland.portal#L3 )

So, technically, there is nothing in the wayland collection of protocols that supports global keyboard shortcuts, but (along with lots of other supporting functionality), this is addressed via the collection of portal APIs

As it happens, KDE already supports the GlobalShortcuts portal: invent.kde.org/plasma/…/kde.portal#L3

Any desktop can provide an implementation of the GlobalShortcuts portal, and any app can adopt it as required (although if it’s implemented within popular toolkits/frameworks, then app developers won’t have to even think about it)

Here are related tracking issues:

dan,
@dan@upvote.au avatar

I’m pretty familiar with Linux server management, but haven’t ran Linux on the desktop in a very long time (I still remember the days of XFree86, which was the predecessor to X.org). If I install a mainstream desktop distro today (Ubuntu, Mint, whatever is popular now), does it come with X11 or Wayland out-of-the-box?

eskimofry,

Depends on which out-of-the-box DE support it

Ullebe1,

Depends on which DE in which version it is using, but anything with recent Gnome (Fedora, Ubuntu) will. Not sure if KDE distros generally default to it, and for more niche DEs the answer is probably “no”, unless it was explicitly made for Wayland.

LeFantome,

I think GNOME is the only Wayland-first DE at the moment. KDE may go Wayland-only with Plasma 6 next year.

Most other environments are still X for the moment though most of the major ones are starting to at least implement Wayland.

There are Wayland only options like Hyperland, Sway, and Velox now too.

dramaticcat,

deleted_by_author

    •
    TheGrandNagus,

    Been on it since 2016. No issues.

    Cope and seethe.

    malgredecanard,

    Yeah, people are trying to make Wayland work so hard… Thanks to the open source community behind it but let’s be honest: Wayland is badly designed and coded.

    After 10 years I can still not share my screen easily, always need to switch to X11.

    Wayland are for little hobbyist kids who want to have fun with Linux, not people who need to do actual stuff.

    If Wayland was doing half of the work it should be doing then we would adopt it. But it’s just bad software and brining all of Linux down with it.

    Communist,
    @Communist@lemmy.ml avatar

    Wayland is not poorly designed or coded, screensharing works perfectly as long as the apps properly support wayland.

    That’s not a problem with waylands design or code, that’s a problem with apps design or code, the thing you may want to take issue with is the notion that we could change things like this while still being poorly supported generally.

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    Wayland isn’t coded at all, it’s a protocol, so clearly you know nothing.

    gayhitler420,

    I didn’t read any of that but Wayland doesn’t work with xscreensaver so I’m not gonna switch to it.

    MiddledAgedGuy,

    Just :s/x/w/g on every bit of source code and recompile wscreensaver.

    gayhitler420,

    Lol at how controversial that comment was.

    mnglw, (edited )

    all of these arguments are great and all but as an enduser: I just want things to work

    I don’t care about the why’s or hows. A lot of these arguments explain and justify breakage

    I am an enduser. I expect things to work, specifically I expect the programs I already use to continue working. I expect to lose no functionality

    If they don’t work, then clearly its broken. If I lose functionality, Wayland clearly wasn’t ready

    BaumGeist,

    As someone once said: “The Technical Merits of Wayland Are Mostly Irrelevant”

    lukas,
    @lukas@lemmy.haigner.me avatar

    But Wayland’s technical merits are relevant in a subtle way. Wayland is maintainable. Xorg isn’t. That’s it, the single most important technical merit. Everyone works on Wayland. Nobody works on Xorg. If people decide to use X11 today, their issues are wontfix with the solution to use Wayland instead. They can’t fix the issues themselves because X11 is an unmaintainable mess. Xorg is on life support with the only purpose to serve Xwayland.

    mnglw,

    for the end user, that is irrelevant

    BaumGeist,

    They hated her for she spoke the truth. We (DIY people) hate to acknowledge that not everyone sees value in investing as much time and energy into perfecting their workspaces as the nerds have, and would rather have their tools Just Work™ so they can get to work on the projects they do care about. I say this as someone who still gets frustrated and argumentative when my friends say they prefer spyware-ridden OSes that remove control from the end-user because they don’t require end-user micro-management to maintain and work.

    X vs Wayland might as well be Grub vs rEFInd or systemd vs SysVinit to most end-users: it matters from a technical perspective, but most people just want something that will allow them to go about their business without sinking hours into getting the “correct” option to work. And it’s important to remember that we all fall on either side of this divide with some aspects of our life, even if it’s not computer-related. How often do we agonize over finding the “correct” pipe wrench when our sink is leaking, despite what the plumbing nerds would criticize you for using? Do you sink hours into picking the right books on conflict resolution when you argue with your spouse, or do you post on AITA and hope they give good advice? Do you agonize over having all the right utensils and ingredients so you can eke out the most subtle flavors from your cooking, or do you use the pan that you got at the local superstore?

    mnglw,

    I’m not a she but otherwise yes I agree

    BaumGeist,

    For the four groups enumerated in the article, this still is not important. It may affect them in ways they are unaware of, but you will not be able to change their minds using technical arguments at this point if they have not already been convinced by the wealth of information and support that is readily available.

    isVeryLoud,

    Wayland is ready for most people. You’re free to keep using X11 if your use case isn’t covered yet.

    lukas, (edited )
    @lukas@lemmy.haigner.me avatar

    If they don’t work, then clearly its broken.

    Protocols are fine. Clients may speak one or another protocol. But protocols aren’t broken when clients designed to speak one protocol fail to speak a different protocol. It’s like saying English is broken because my friend only knows German, except English is Wayland, German is X11 and my friend is clients. Wayland is always ready to listen to clients that speak Wayland.

    flying_sheep,
    @flying_sheep@lemmy.ml avatar

    Yeah, especially the argument about Wayland compositors taking down all apps with them when they crash: that’s just bad, no need to sugarcoat that.

    A better argument would be that it’s not true: KWin keeps Qt apps alive, and they’re working on extending that to all apps. As a result, in the only crash I’ve experienced, I only lost my Firefox window, and zero data as all my tabs and form entry values got restored when I started it again.

    crypto,

    @theshatterstone54 > "Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries."

    Not so. FreeBSD is 100% Linux compatible and has Linux Kernel emulation built in. Wayland support is also built in to FreeBSD. FreeBSD is a much superior operating system compared to Linux. But the FreeBSD team only cares about the server aspects and really does not care about a graphical desktop. They tend to use Macs.

    FreeBSD Documentation Portal

    The state of Linux Desktop interface is a schizophrenic flustercuck with far too many cooks spoiling the stew. They're not just spoiling the stew; they're pooping in it. And a bunch of noveu-riche trust-fund baby nerds think this is cool. They don't give a rat's ass about the end user being able to get work done. They would rather we all waste our time filing bug reports rather than getting things done.

    bitwolf, (edited )

    Nvidia works on Wayland now. And in 6.6 the noveou will support reclocking on 2xxx+

    Games also work fine under Wayland. Either with gamescope or kwin.

    Mutter works well but they haven’t yet merged vrr support so you have to get that separately.

    michaelmrose, (edited )

    Nvidia appeared fairly buggy as of nvidia 535 and kernel 6.3 with both sway and Plasma 5.27. Notably of all the possible choices for Wayland support ONLY KDE in relatively recent releases supports proper scaling of apps using xwayland which are apt to be a thing for a while now. This is a huge point in KDE’s favor despite loving the idea of an i3 like experience with sway.

    If prior experience bears out plasma 6.0 will be buggy as fuck and 6.2 will be excellent.

    Nouveau has NEVER been a particularly good choice and its primary developer just resigned www.phoronix.com/news/Nouveau-Maintainer-Resigns I wouldn’t pin my hopes on it in the future becoming usable. I sure as hell wouldn’t say its a useful choice NOW because you suppose it may become so in the future. I’d rather look at nvidias official open source effort.

    If I had a crystal ball to look in I bet it would say a lot of folks with existing Nvidia hardware are best off sticking with X11 in 2023 but looking again at KDE’s wayland session in 2024.

    Although do bear in mind people using stable distros like Ubuntu/Mint/Debian will be a lot longer seeing new useful features pushed out.

    bitwolf, (edited )

    I always interpreted that as a factor of the Plasma team being willing to offer compatibility for things that broke the freedesktop spec.

    Whereas Gnome / Mutter for example appear to believe that if they don’t strictly follow spec it’ll perpetuate the fragmentation.

    I tend to side with the latter perspective but use KDE + kwin on my desktop for gaming for Wayland + vrr (it’s amazing how smooth and responsive this is). Gnome really shines on the notebook form factor so I use it there.

    PseudoSpock,
    @PseudoSpock@lemmy.dbzer0.com avatar

    NVidia user here, it most certainly is not working well. My external monitor for my laptop is getting black boxes shadowing the kde menu and most of my windows on that screen, and often block boxes trailing the mouse.

    Holzkohlen,

    I now have perfect wayland setup with a Nvidia GPU. I just use my AMD Apu as main gpu and the nvidia one as secondary GPU. The DE runs on Amd and games run on Nvidia. Thanks for nothing Nvidia, making me work around your bs.

    michaelmrose,

    Doesn’t that drastically limit your monitor support like to ONE?

    MonkderZweite, (edited )

    A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.

    I still would have preffered a modular approach, where compositor, window manager, server/mouse+keyboard are plugable. Well, it’s probably possible with Wayland, but the ecosystem is not there yet.

    umbrella,
    @umbrella@lemmy.ml avatar
    • Wayland breaks in-home streaming: Not familiar with this, so will assume true.

    False. Sunshine works perfectly on Wayland, and last I checked Steam’s in-home streaming works fine on AMD/Intel, it’s an nvidia driver thing.

    Jaxseven,
    @Jaxseven@beehaw.org avatar

    The only thing I can’t get working on Sunshine on Wayland is a visible mouse cursor. Makes streaming Baldur’s Gate 3 with a cursor a pain.

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

    Thats a Sunshine issue, happens to me on both Wayland and X.

    Try disabling hardware cursor on your respective DE, it fixed the issue on my machine.

    slembcke,

    Wayland is great! Except for all list of not-a-bugs that I’d like to see fixed. Still, I’m not going back to X, so take that how you will.

    What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly.

    Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

    A lot of this is slowly (painfully?) changing, and the adversarial nature is a bit frustrating. Wayland fixes so many little things that I find it well worth it though, and I say that as a game developer frustrated by many of the core design decisions.

    domi, (edited )
    @domi@lemmy.secnd.me avatar

    Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

    I would like them to keep that behaviour. At least make it an option or allow whitelisting certain applications. Nothing I hate more in an OS than windows stealing focus without asking.

    turbowafflz,

    Focus stealing is one of the worst things in the world, I am so glad I haven’t had to deal with it since I switched to wayland. (Except for stupid firefox tabs stealing focus from other tabs, that still happens obviously and happened to me during a test for my university and almost invalidated my score)

    GnuLinuxDude,
    @GnuLinuxDude@lemmy.ml avatar

    Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private.

    I do like that. I have encountered a number of bullshit things like HR mindless training videos (ok, the fourth time I’ve seen this guy contemplate accepting a bribe… I get it. Don’t accept bribes! Leave that shit to Clarence Thomas) or ad playbacks that refuse to proceed unless they are focused. It’s annoying as hell. The problem you point out also sounds really annoying.

    Zamundaaa,

    What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly

    Please don’t make up what “Wayland core folks” think. You don’t know it, and your claims are waay off.

    It’s not about security. It was intended to allow the compositor to throttle apps to improve efficiency… Which of course in practice doesn’t work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.

    As for why that hasn’t been fixed yet, it’s not as big of a problem anymore:

    • Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
    • toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
    • xdg shell now contains a flag for apps to know to inhibit rendering because they’re hidden. That doesn’t guarantee that presentation won’t otherwise block though
    • a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan

    Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

    That’s not even close to how activation works on Wayland, and no, it’s not just a security thing, it’s a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can’t cover up what you’re working on just cause they need to show you an ad or an “important” pop up question or whatever. If it doesn’t work for a specific app, make a bug report about it to the app.

    slembcke,

    A bit of a zombie thread, but I’m not making anything up here. The blocking issue gets discussed a lot in gamedev circles, and there are issue threads that have been locked by folks with the power to do so because they just said “no”. One of them (Maybe Sebastian Wick? I don’t remember… doesn’t really matter) gave verbatim that use case where a video service they use would stop playing videos when the browser was in the background, and that is why they won’t report . Maybe they weren’t a “core” developer, but they had the ability to say “no” and end the discussion thread.

    As for it being not a problem anymore, it still occurs even on Fedora 39. The 1 second present timeout still only works for XWayland, and that’s… not a great solution. Also, realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does. We are already supporting multiple rendering APIs, and combining that with multiple UI libraries just to get a window to draw a triangle into is a combinatorial explosion. Last I remember reading from the SDL folks, they were waiting for the functionality to appear in Wayland before they could implement it, and they weren’t expecting anything to change soon either. Speaking personally, my current game project is single player so I can just pave over the timing issues when they come up:

    Long frame detected: 6463.731931 ms. Skipping ahead!

    The most frustrating part to me is much more meta. You get discussions with other game devs that have heard about this stuff and they continue to think that supporting Linux is just way too much work. Sometimes they are right, but rarely for the right reasons it seems. I believe in the glorious Wayland future… I just wish it would get here a bit faster. ;) On the other hand, if we rushed it and botched it then it would never arrive at all I suppose. (sigh)

    As for how window activation works, you got me there. I just heard other people discussing that one, but it did explain why on Wayland I would just get “Firefox is ready” notifications when opening links instead of just showing me the page like X did. Though I’m quite happy that it’s gone now in Fedora 39. Progress is good!

    Zamundaaa,

    The 1 second present timeout still only works for XWayland

    Oof, I thought the corresponding MR for Wayland was merged… But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|

    realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does

    SDL does handle it, but only for OpenGL; it can’t do anything about Vulkan. GLFW doesn’t do anything about it either, so that is pretty annoying.

    I believe in the glorious Wayland future… I just wish it would get here a bit faster

    Don’t we all. Let’s hope the current upstream approach to fix this issue gets somewhere sooner than later…

    possiblylinux127,

    Wayland works very well for me. I can’t say the same for X

    merthyr1831,

    Sadly, this is going to be preaching to the choir. Wayland has its faults but if it truly was an inferior approach compared to X then someone would’ve forked X or spawned a totally new project. Turns out it takes time, money, and developer power that simply isn’t coming into X or any competing standard. Wayland is “good enough” to be the next standard and that’s how it’ll be for the foreseeable future.

    If a BSD fan really thinks X is pivotal to BSD’s future, then maybe BSD will need to consider forking it and fixing it, but I’m sure the real solution will just be supporting Wayland on BSD too.

    michaelmrose,

    For most of its 15 year history implementations have been woefully and obviously insufficient. Nobody forked X because nobody needed to. Its feature complete and has been for a long time and there was nothing wrong with using X while Wayland implementations see progressive improvement.

    LeFantome, (edited )

    Not only is nobody forking X but many people are building Wayland compositors.

    Listening to the detractors, you get the impression that Wayland is a failure and / or that X may still be the better choice.

    Then you realize the only people still working on X are paid by enterprise distros with long-term support obligations. All the toolkit people have moved to Wayland. The major desktop environments have shifted to Wayland. All the “new” window managers are for Wayland.

    Wayland is already supported on BSD ( FreeBSD at least ).

    The actual developers have spoken and Wayland has won.

    skullgiver, (edited )
    @skullgiver@popplesburger.hilciferous.nl avatar

    deleted_by_author

    •
    PseudoSpock,
    @PseudoSpock@lemmy.dbzer0.com avatar

    That is a myth! Please stop spreading it.

    Cpo,

    Man. That is a fair and well thought over response.

    I appreciate this! Articles like this is what I’m on lemmy for!

    Because calling your post a response would not do it justice enough. An article indeed.

    ♥️

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