I read about history of Linux, X and Wayland and now I can't wait until EVERYONE will switch to Wayland.

I read about history of Linux, X and Wayland and now I can't wait until EVERYONE will switch to Wayland. The year when that happen would be year of Linux desktop. Wayland is literally the best thing that could happen to Linux desktop and I surprised how long did it take for developers to put up with X bullshit.

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 1 month ago
    Anonymous

    cope harder troony, you need at least another 30 years for a stable and useful for gaming desktop experience, stay mad

    • 1 month ago
      Anonymous

      >for a stable and useful for gaming desktop experience
      I've switched to KWin Wayland because Xorg was shitting itself under high load in my multi-monitor configuration with SAME refresh rate. Now that I have 165 Hz display there's no way for me to use X.

    • 1 month ago
      Anonymous

      What are you on about? Wayland IS the preferred windowing system for gaming under Linux.

      • 1 month ago
        Anonymous

        >99% of gaming under Linux is through wine
        >wine only has experimental support for wayland in unstable branch
        hmmm

        • 1 month ago
          Anonymous

          The wine-wayland patchset is a great measure of real developor buy-in to wayland. It's worked on solely by a collabora employee (Alexandros Frantzis) because the wine devs refused to do it themselves, as running wine natively on wayland has literally no benefits.

    • 1 month ago
      Anonymous

      >troony
      https://gitlab.freedesktop.org/xorg/lib/libxtrans

      • 1 month ago
        Anonymous

        >https://gitlab.freedesktop.org/xorg/lib/libxtrans
        lmao

  2. 1 month ago
    Anonymous
  3. 1 month ago
    Anonymous

    Fedora is forcing the migration, we need a Devuan like distro for Xsisters.

  4. 1 month ago
    Anonymous

    >forced vsync
    >forced compositor on
    Cuck display server

    • 1 month ago
      Anonymous

      >forced vsync
      I had tearfree on Xorg because without it image tears like as
      >forced compositor on
      Active compositing was a workaround for moronic X architecture. Wayland compositors do compositing the proper way like any other sane display server would do.

      • 1 month ago
        Anonymous

        DRI3 + Present extension compositing in X11 is pretty much the same as wayland compositing

        • 1 month ago
          Anonymous

          If it would be the same you couldn't disable it on X

          nice bait.
          > Wayland
          It sadly sucks, for it does not consider the level of abstraction it is dealing with, instead going for the insane path of restricting and limiting behaviour (for desktop this is completely nonsensical, maybe for kiosk it could work), what resulted in a crippled protocol that every implementation had to deal with its bullshit providing incompatible fixes. It's sucks to port, it sucks to provide compatibility layers (it's a LOT easier with xorg), and as it expands to be minimally usable it becomes more and more like xorg (because it's basically xorg crippled and with the addition of a few more problems).
          > best thing that could happen to Linux desktop
          Mir was a better try at it

          It's funny to see schizos that are shitting on Wayland but praising Mir at the same time.

          • 1 month ago
            Anonymous

            > but praising Mir at the same time
            Because it's literally a better attempt at writing a display server to replace Xorg. Wayland is more fitting for kiosk use, but for desktop is completely nonsensical

          • 1 month ago
            Anonymous

            Being able to disable the compositing completely is good. I did a performance test of x11 (dwm with no compositor) vs wayland (with hyprland) and wayland had a lot of stuttering that x11 didn't which is probably because of the compositing vsync timing.

  5. 1 month ago
    Anonymous

    x11 is dead. wayland is the future.

  6. 1 month ago
    Anonymous

    nice bait.
    > Wayland
    It sadly sucks, for it does not consider the level of abstraction it is dealing with, instead going for the insane path of restricting and limiting behaviour (for desktop this is completely nonsensical, maybe for kiosk it could work), what resulted in a crippled protocol that every implementation had to deal with its bullshit providing incompatible fixes. It's sucks to port, it sucks to provide compatibility layers (it's a LOT easier with xorg), and as it expands to be minimally usable it becomes more and more like xorg (because it's basically xorg crippled and with the addition of a few more problems).
    > best thing that could happen to Linux desktop
    Mir was a better try at it

    • 1 month ago
      Anonymous

      >insane path of restricting and limiting behaviour (for desktop this is completely nonsensical
      are you running everything as root on your desktop?

      • 1 month ago
        Anonymous

        It does that on the [bold]same abstraction[/bold] level, again for desktop this is completely nonsensical (no wonder it stayed 100% useless for so long and even now is extremely crippled and with insane problems)

      • 1 month ago
        Anonymous

        That comparison doesn't work. Wayland is like having a linux desktop except you always run as a regular user and you dont even have the option to use root. Wayland would actually be useful if it had a root user equivalent.

        • 1 month ago
          Anonymous

          honestly, desktop systems lack good mobile-like isolation for untrusted apps (i.e. all of them; who the hell is that random person from Nebraska??)
          I don't care if it can pwn my system for root access; I care whether it can pwn my system for my documents when it doesn't have anything to do with documents.
          supply chain is the most vulnerable vector currently

          >Right now I have a few issues that will probably take a few years to fix
          You can thank all those morons who hate Wayland and keep insisting on using X. In the end you have new display servers that lack some features now because of a small feedback and old display server that lacks other features and will never have them because it's a pile of old shit nobody wants to touch.

          yeah sure haters are to blame, telling lies about ideal software is what hinders its development.
          (are you genuinely moronic?)

          • 1 month ago
            Anonymous

            Thats what flatpak tries to solve. It can only access other files if you open the file picker and select the file, in which case the file becomes accessible to the flatpak. If it tries to access a common path, such as ~/.config then that is actually another path that is specific to that application

  7. 1 month ago
    Anonymous

    >now I can't wait until EVERYONE will switch to Wayland.
    imagine caring what software other people use, holy loser

  8. 1 month ago
    Anonymous

    Wayland is just X crossdressing.
    >uses drm-kms apis like Xorg
    >uses libdrm like Xorg
    >uses libinput like Xorg
    It can't ever be the future because every architectural improvement goes to Xorg as well. It can only ever have a subset of Xorg features because it's hamstrung by an asinine security model, which protects against imaginary exploits, and is bypassed anyway by dbus to implement basic desktop features like global copypaste, screenshots, screenrecord etc

    • 1 month ago
      Anonymous

      >in order to make X11 work, first we must rebuild the universe

      • 1 month ago
        Anonymous

        That's the problem with wayland. Because nothing was changed at a really fundamental level and they only made general display server functionality independent of Xorg, wayland is just a gigantic collabora scam. They reinvented the theory of the wheel and convinced compositor maintainers to do the actual reinvention of the wheel for them.

        >Wayland is just X crossdressing.
        >uses drm-kms apis like Xorg
        >uses libdrm like Xorg
        >uses libinput like Xorg
        That's actually modern Xorg crossdressing as Wayland. All this shit was created in spite of Xorg and modern Xorg is just a proxy between X clients and kernel apis.
        You had mode setting in X, now it's in kernel, you had input handling in X, now it's in evdev and libinput, you had indirect rendering with X specific DDX drivers and now you have DRI. Ditching Wayland is just the next logical step.

        That's a roundabout way of saying wayland has no reason to exist because the fundamental problems of Xorg were resolved a decade ago, independent of either project. The features that wayland offers over Xorg are a security model that doesn't work, mouse events taking down the server, latency from mandatory compositing and variable sync that breaks on cursor movement because of how wayland does modesetting.

        • 1 month ago
          Anonymous

          >the fundamental problems of Xorg were resolved a decade ago
          Fundamental Xorg problem was existence of X11. Wayland fixed that.
          >independent of either project
          DRI, libinput and mode settings could be viewed as Wayland development in the large scope
          >and variable sync that breaks on cursor movement because of how wayland does modesetting.
          Are you high or something?

          • 1 month ago
            Anonymous

            I notice you didn't deny the rest wayland troony. How many posts ITT from you can we expect this time?
            https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154#note_1385760
            https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_1284481

          • 1 month ago
            Anonymous

            NTA but I'm sorry, why does the software have to worry about this? Isn't the cursor hardware rendered and updated as fast as possible?

          • 1 month ago
            Anonymous

            see
            https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_897546

          • 1 month ago
            Anonymous

            and

          • 1 month ago
            Anonymous

            and

            This must be a joke right? HW cursors have been with us for the last 40 years and I don't remember a window manager, even the PlayStation 2 linux distribution, failed to repaint hw cursor at max speed. Maybe windows 3.1? Literally don't remember.

            Now how does wayland fail to smoothly move cursor around? HOW?

          • 1 month ago
            Anonymous

            HW cursors haven't been with us for a long time. It's only been with you for 40 years because you're using a 35 years old display server.

          • 1 month ago
            Anonymous

            >xorg fork began 2004
            >first release in 2005
            >modern xorg defined by DRI2 in 2008
            >wayland project began in 2007
            >first _stable_ release in 2012
            Why do they always lie?

          • 1 month ago
            Anonymous

            see
            https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_897546

            [...]
            This must be a joke right? HW cursors have been with us for the last 40 years and I don't remember a window manager, even the PlayStation 2 linux distribution, failed to repaint hw cursor at max speed. Maybe windows 3.1? Literally don't remember.

            Now how does wayland fail to smoothly move cursor around? HOW?

            You're all morons, this has nothing to do with Wayland but rather with Atomic KMS and the fact that holy shit you can't refresh cursor at higher framerate with VRR on because you're limited with application framerate. This "problem" is also not solved on Windows and exists only when you enable VRR in desktop mode which no sane person would do.

          • 1 month ago
            Anonymous

            >this has nothing to do with Wayland
            Wayland specifies atomic modesetting and Xorg doesn't. Xorg has had atomic disabled by default for years exactly because of this issue and others.

          • 1 month ago
            Anonymous

            Explain to me why my cursor lags when I switch to wayland?

          • 1 month ago
            Anonymous

            Because you're full of shit? I've just tried Terraria (which should be "unusable" on KDE with VRR according to these posts) with locked 60 fps and I can't understand what seemed to be an issue. Game works just like it would work with 60 fps.

          • 1 month ago
            Anonymous

            >those frametimes
            kek

          • 1 month ago
            Anonymous

            What are you laughing at? This is how Mangohud fps lock works.

          • 1 month ago
            Anonymous

            Maybe on wayland kek.

          • 1 month ago
            Anonymous

            >wayland cursor lags because anon is full of shit
            No it's because your protocol is shit, Drew. A person being full of shit has nothing to do with a lagging HW cursor.

          • 1 month ago
            Anonymous

            Maybe on wayland kek.

            Ok I took the bait to see if I actually got use to "lagging cursor" on Wayland and on X11 everything would be smooth. Well, on Xorg VRR just wasn't working even after huge frickery with xorg.conf.d like enabling variable refresh rate and async flip pages or whatever this shit is called. And even with 165 Hz refresh rate of display cursor of 60 fps game doesn't behave any smoother.
            Anyway, back to Wayland I guess where everything works. Xtrannies could stay at their broken display server and maybe make some commits in that spaghetti code to make VRR work this time.

          • 1 month ago
            Anonymous

            >filename
            >totally different mangohud conf
            lmao

          • 1 month ago
            Anonymous

            After switching back to KWin Wayland not only VRR worked out of the box (which was expected), but cursors was much smoother and Terraria now working at solid 60 fps when on Xorg there was problem with framerate.

            I've disabled fps_limit because I remembered that Terraria can't go higher than 60 fps. But it didn't improved miserable framerate on Xorg while on Wayland game runs flawlessly. There's reason why everyone recommend Wayland for gaming despite all that FUD about hardware cursors coming from IQfytards. In order to say that you don't have these

            I notice you didn't deny the rest wayland troony. How many posts ITT from you can we expect this time?
            https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154#note_1385760
            https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_1284481

            see
            https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/44#note_897546

            and

            you need to make proper VRR support, lol.

          • 1 month ago
            Anonymous

            >filename
            Why do you keep larping?

          • 1 month ago
            Anonymous

            >she don't know about IQfyX

          • 1 month ago
            Anonymous

            >unix time for last year goes from 167 to 170
            >filenames all 168
            try again.

          • 1 month ago
            Anonymous

            What kind of autism is that?

          • 1 month ago
            Anonymous

            >that spiky framerate graph
            >gets rekt by "every frame has to be perfect" meme
            Fricking kekswhnr

          • 1 month ago
            Anonymous

            Well, since it's VRR monitor every frame is indeed perfectly synced

          • 1 month ago
            Anonymous

            >This "problem" is also not solved on Windows
            Windows has hardware cursors, like Xorg and unlike Wayland

          • 1 month ago
            Anonymous

            > Wayland fixed that
            It has almost all the Xorg demerits with a few of its own and fixes almost nothing

    • 1 month ago
      Anonymous

      >Wayland is just X crossdressing.
      >uses drm-kms apis like Xorg
      >uses libdrm like Xorg
      >uses libinput like Xorg
      That's actually modern Xorg crossdressing as Wayland. All this shit was created in spite of Xorg and modern Xorg is just a proxy between X clients and kernel apis.
      You had mode setting in X, now it's in kernel, you had input handling in X, now it's in evdev and libinput, you had indirect rendering with X specific DDX drivers and now you have DRI. Ditching Wayland is just the next logical step.

      • 1 month ago
        Anonymous

        That just shows how good x11 and xorg is. Wayland is married to drm unlike x11, and it will outlive wayland.

        • 1 month ago
          Anonymous

          >Wayland is married to drm unlike x11
          And that's a good thing. You can convince developers of new hardware to make both drm and DDX drivers, I'm sure they would be eager to do that, just like Asahi team

          • 1 month ago
            Anonymous

            You dont have to make both. Developers can choose to only make drm and it will work on x11 as well. But drm might not be how linux looks like in 10-20 years. It's also linux specific so only OS' that emulate linux behavior work with wayland.

        • 1 month ago
          Anonymous

          Being able to disable the compositing completely is good. I did a performance test of x11 (dwm with no compositor) vs wayland (with hyprland) and wayland had a lot of stuttering that x11 didn't which is probably because of the compositing vsync timing.

          You're contradicting yourself. All modern applications are using direct rendering and modern X is just proxy between clients and kernel. If you take away DRM and don't provide DDX drivers then you'll end up with not functioning display server.
          It's not the Wayland which is married to DRM, it's the compositors. If there would be any new APIs in graphics stack compositor developers could rewrite their compositors while maintaining Wayland compatibility. In case of Xorg it took ages and 3 instances of DRI to glue on top of default indirect rendering of X and nobody is going to write new glue code for X.

          • 1 month ago
            Anonymous

            >All modern applications are using direct rendering and modern X is just proxy between clients and kernel
            In other words
            >All modern applications are using direct rendering and modern wayland is just proxy between clients and kernel

          • 1 month ago
            Anonymous

            Wayland doesn't stand in between clients and kernel like X do, so it's not a proxy. Again, DRI works on X because of tons of glue code. You don't need that glue code for Wayland compositors.

          • 1 month ago
            Anonymous

            >Wayland doesn't stand in between clients and kernel like X do
            Wayland doesn't do it, because wayland is an imaginary construct. Wayland compositors do what you're pretending X does with DRI3.
            >tons of glue code
            Unlike
            >I want to screenrecord
            >call dbus to call pipewire to record the window and call dbus to send the output to screenshare program

          • 1 month ago
            Anonymous

            >Wayland compositors do what you're pretending X does with DRI3.
            Wayland compositors doesn't do what X does with DRI3 because they're designed around direct rendering and they don't have such concept as indirect rendering.
            >call dbus to call pipewire to record the window and call dbus to send the output to screenshare program
            And in the end you'll have much more efficient screen recording because of zero-copy, while you'll still have to copy data even when using xshm.

          • 1 month ago
            Anonymous

            X supporting indirect rendering (disabled by default) does not magically stop it doing direct rendering with DRIx.

            >in the end you'll have much more efficient screen recording
            *implemented differently on every compositor because "it's just a protocol bro"

          • 1 month ago
            Anonymous

            X supporting indirect rendering (disabled by default) does not magically stop it doing direct rendering with DRIx.

            >in the end you'll have much more efficient screen recording
            *implemented differently on every compositor because "it's just a protocol bro"

            >Wayland compositors
            inherently sit between the rendered frame(s) and the composited frame and unlike X compositors are not optional.

          • 1 month ago
            Anonymous

            >xshm
            This isn't mandatory.
            https://github.com/w23/obs-kmsgrab

          • 1 month ago
            Anonymous

            Lmao, so what's your problem with screen sharing on Wayland then if you're using kmsgrab anyway, lol?

          • 1 month ago
            Anonymous

            Nothing. The point is that wayland is a joke with no reference implementation of any protocol, almost no stable protocols and every contentious protocol (see VRR and HDR/Color management) being implemented as per-compositor hacks with zero chance of being upstreamed.

          • 1 month ago
            Anonymous

            >complains about screen sharing on Wayland
            >"what's your problem with screen sharing on Wayland"
            >"nothing"
            Wayland haters are real schizos lol

          • 1 month ago
            Anonymous

            >And in the end you'll have much more efficient screen recording because of zero-copy
            I have no stake in this argument, but using the word "efficient" to describe anything dbus-related is laughable. And even if it wasn't, it's still Win32-tier unpleasant to work with.

          • 1 month ago
            Anonymous

            That's not what im saying. Im saying that x11 is flexible enough that if drm doesn't exist in the future then it wont break x11 itself. Wayland protocols (and desktop portal + pipewire) rely on drm.
            >And in the end you'll have much more efficient screen recording because of zero-copy, while you'll still have to copy data even when using xshm.
            x11 also supports zero copy, except in x11 it's not drm specific. It's an abstraction and it has function to get platform specific native handle. Thats how every sane system works.

  9. 1 month ago
    Anonymous

    X is bad (like whole Linux graphics stack) and Wayland is an even worse replacement

  10. 1 month ago
    Anonymous

    It's good, butter-smooth and all, but I can't switch until all apps work well with it; I'd rather leave Linux entirely if the morons will leave me no choice.
    Right now I have a few issues that will probably take a few years to fix:
    >XWayland apps can't restrict themselves to sRGB because XWayland isn't color aware, so my fancy monitor is useless
    >VCGT theoretically works in either sRGB or Rec. 2020, but the colors are all wrong
    >no way to calibrate the display tablet, so the stylus doesn't match the cursor position at the edges and is offset due to slight parallax, making it hard to draw with fine ink
    >no way to calibrate the monitor
    >forced vsync adds latency and my brush lags badly behind the stylus on a display tablet
    >NVIDIA not supporting implicit sync, Wayland not supporting explicit sync (no, I don't fricking care about your advice to switch to anything else, frick off)
    >only the bloated KDE and a couple of tiled WMs support it well, more choice is needed
    >wine doesn't have good support yet, I depend on it whether I like it or not

    • 1 month ago
      Anonymous

      >Right now I have a few issues that will probably take a few years to fix
      You can thank all those morons who hate Wayland and keep insisting on using X. In the end you have new display servers that lack some features now because of a small feedback and old display server that lacks other features and will never have them because it's a pile of old shit nobody wants to touch.

      • 1 month ago
        Anonymous

        >xorg is why wayland doesn't have features
        unimaginable cope. wayland lacks features because wayland-protocols is pay-to-play. nothing gets merged until a corporate user pays the extortion fee, then suddenly wayland xml "devs" are willing to do a 180 on core design constraints (every frame is perfects, total window isolation etc).

  11. 1 month ago
    Anonymous

    I didn't know gayland had shill protocol

  12. 1 month ago
    Anonymous

    Everyone sane has already been using Wayland.

    • 1 month ago
      Anonymous

      not*

  13. 1 month ago
    Anonymous

    Don't care. Didn't ask. Just installed fvwm in some production environment machines.

  14. 1 month ago
    Anonymous

    I don't exactly know the underneaths of either protocols/implementations, but they're seem to be thesis and antithesis to each other. X being local network-stack oriented with no fricks given to malevolent agents inside the net, Wayland being local user and thinking the computer's permanently infected so it should restrict access to key features.
    Imo the display seever should not be restricted in what it can give, but frick network access. If i get this whole debate right.

  15. 1 month ago
    Anonymous

    b***h please, by default a popup window in Wayland can't stay on top of all other windows unless you specifically told it to do so.

  16. 1 month ago
    Anonymous

    But how is Wayland on Nvidia these days?
    The switch won't happen until Nvidia supports it.

    • 1 month ago
      Anonymous

      xwayland doesn't support explicit sync and wayland doesn't have the protocol to make it work for that either. So if you run xwayland application everything flicker like crazy, frames are repeated etc. If you try to run some application in wayland native mode then they crash a lot (such as vscode, firefox, etc).

      • 1 month ago
        Anonymous

        The major thing on 545 is XWayland apps and games are flickering like mad due to the lack of support for explicit sync. So, no switch.
        There are minor things as well, like no support for hardware gamma, app profiles, sRGB clamp and many other little features.

        Shame.
        Minor issues or performance hits I could live with but flickering is terrible.

    • 1 month ago
      Anonymous

      The major thing on 545 is XWayland apps and games are flickering like mad due to the lack of support for explicit sync. So, no switch.
      There are minor things as well, like no support for hardware gamma, app profiles, sRGB clamp and many other little features.

  17. 1 month ago
    Anonymous

    Ok, I'm tired of trying understanding. What's the damn deal with Wayland? Already have used both and I can't understand why one is better than another

  18. 1 month ago
    Anonymous

    waysisters...

    • 1 month ago
      Anonymous

      >Nvi...
      Didn't read

      • 1 month ago
        Anonymous

        It also happens on amd. I tested yesterday and on x11 it's butter smooth.

  19. 1 month ago
    Anonymous

    Actually Wayland is working great on Nvidia Turing+. All you have to do is uninstall Nvidia proprietary driver and remove nouevau from blacklist.

Comments are closed.