Hacker News Reader

Comment by yoz-y | Hacker News Reader

> Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.

I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.

Edit: Thanks for pointing out that Xorg is actually much older. My argument indeed doesn't hold.

View on HN

Ahh, 2004 is when Xorg forked off of XFree86, but XFree86 had already been going on since 1991, and already that was an implementation of X which already existed since 1984, and you can trace back even further than that if you want. It’s been a long ride home.

Xorg development largely halted circa 2008 though, since then most of the "Xorg" features have been deleting code in X and moving it to Mesa/libdrm/the kernel.

Wayland's latest release "mostly contains bug fixes and minor protocol updates." [0]. That is ~12 months worth of changes. Pretty similar to 1.18. It isn't like the protocol is a hotbed of massive changes, it looks largely complete according to the release notes.

[0] https://lists.freedesktop.org/archives/wayland-devel/2021-Ja...

> I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.

Xorg is a fork of Xfree86, which was released in 1991 (https://en.wikipedia.org/wiki/XFree86).

X as a display server is over three decades old, the popular incarnation in the nineties being XFree86, which devs abandoned in 2004 to form Xorg due to licensing issues. Most of the code itself really is ancient.

Xorg was kind-of forked from a working solution (XFree) whereas wayland started from scratch.

> Xorg is 16 years old

Xorg is a fork of Xfree86 which started in 1991 but feature parity minus the cruft has been reached years ago. Some people disagree about what is cruft however.

For example, I view 90% of the list in the posted articles to be minor softwares relying on undesirable behaviour and unwilling to adapt (the remaining 10% being misrepresentation of actually solved issues listed in bad faith). The original author would obviously disagree.

Then again, I consider X.org to be and always have been completely unusable. How can people accept to use a display manager with constant screen tearing is beside me.

Screen sharing seems a critical feature to enough people to rise well above mere “minor feature” if the goal is to replace Xorg. That was probably true 12 months ago, but definitely true 8 months ago.

If the goal is to have a different display protocol that a significant fraction of the possible user base can’t reasonably use as their root display because it provides yet another way in which “Linux isn’t ready for this to be the year of the desktop”, that’s a perfectly reasonable aim, but it seems like Wayland is targeting replacing X, in which case supporting screen sharing (and recording) is probably not an ignorable “minor feature degradation”.

Wayland definitely supports screen capture.

Can you write an application which uses screen capture on Wayland, and which works equally well regardless of compositor?

If not, then Wayland doesn't support screen capture. Individual compositors might, but asking developers to implement five separate screen capture protocols is a big ask.

You can. The standard is new, but it exists, and now works on Gnome, KDE and wlroots based compositors https://wiki.archlinux.org/index.php/PipeWire (read past the intro paragraph to where it talks about the various backends available)

> How can people accept to use a display manager with constant screen tearing is beside me.

I never even noticed it, and I never quite understood what people are on about with this. I had to go to YouTube to watch a demo video to see what it really looks like. And if I try it, then yes, I suppose I see some tearing if I move a window and pay close attention to it. But I never even noticed on my own, and am not bothered by it in the slightest.

Would it be better without it? Sure. But the amount of effort to eliminate what I experience as basically a non-issue is a poor trade-off IMO.

Same here on all points, including Youtube. I always envisioned some kind of critical graphics failure from the way people talk about it. Maybe my standards are too low.

Maybe it's overhyped, but tearing does make me feel like I'm using an amateur OS, especially when I'm using X for some weeks and then hop over to wayland or Mac or Windows, and the picture looks stable.

Tearing can be a gigantic issue when you have full screen videos or render games. However as far as I could find these are caused by the KDE/Gnome/etc. compositor not running in sync with the screen refresh rate. Find a way to bypass the compositor(KDE options to disable it, GNOME with full screen windows, or tell the X window to override the compositor) and it goes away. Its easy to lob all problems on X but whats next? Did it also cause 9/11?

I'm not familiar with the internals enough to know if you're right about tearing being the compositor's fault, though I'd be quite surprised if disabling the compositor resulted in less tearing. But I do know that I experienced tearing using compton with i3 (though much less than i3 with no compositor).

If Gnome, KDE and compton all manage to get compositing wrong on X, and yet every wayland compositor manages to get it right, then maybe it is a problem with X, even if there is some arcane way to fix the issue.

> though I'd be quite surprised if disabling the compositor resulted in less tearing

I have been running OpenGL based applications on KDE for some time and the answer to tearing was always disabling the compositor in the desktop settings or just overriding the compositor related redirect state of the window. OpenGL tends to sync against vblank anyway so I don't find it surprising that rendering directly to the final output buffer instead of an off screen buffer that is at the mercy of the compositor helps.

It's especially noticeable with fast-moving videos or games.

I never noticed it in that either. I played plenty of action games on my Linux machine twenty years, going back all the way to many hours I spent with the Loki port of Unreal Tournament, and I've watched plenty of videos in the last twenty years as well: but it just never registered for me. Maybe I'll notice it now that I know what to look for, but I'm the kind of person who is pretty happy with 1080p (or even 720p) too, so I suppose my brain is just not very good at picking up these kind of visual things, or something.

Yes, tearing is visible in fast-moving videos or games (when run in windowed mode), but video players or games usually run full-screen, where tearing does not happen (as applications can do vsynced doublebuffering), so usually it is not an issue.

I consider tearing a feature. Tearing is an unavoidable consequence of writing to the front buffer, and writing to the front buffer is required if you want the minimum latency possible. If you write to the front buffer, then so long as the part of the screen you're updating is below the raster position you'll see it that same display frame. If you write to the back buffer and then wait for vsync to swap buffers and avoid tearing then you won't see it until the next display frame. I value latency more than aesthetics, so I never use a compositor or Xorg's TearFree feature.

The goal of Wayland is "every frame perfect", which means I consider it broken by design. I want imperfect frames right away, not perfect frames later.

In an ideal world that would be an option to toggle. I can see use-cases/occasions for both "fast&nearly_perfect" and "slow&pixel-perfect"

> How can people accept to use a display manager with constant screen tearing is beside me.

I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.

How often does it actually happen to you, and under which circumstances?

Personally I've been using computers since 1995, (Windows and Linux) and I practically never encounter screen tearing. And this is on a wide variety of hardware. Spread evenly over intel, nvidia, and AMD.

The rare times I did encounter it, was only on one PC with an ancient nvidia graphics card (running Arch linux, bspwm). And it would only ever (if even) happen right before a restart after updating the nvidia drivers.

>> I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.

>> How often does it actually happen to you, and under which circumstances?

It happens every time I Watch a video on X, which is really annoying. It also happens when dragging large windows on my 4k. Wayland is fantastic in this regard.

> How often does it actually happen to you, and under which circumstances?

Scrolling, moving windows, resizing windows, approximately constantly.

Then you haven't switched on Full Composition Pipeline on your nvidia card (if you're using nvidia that is).

I've been enjoying silky smooth Xorg and video for a very, very long time.

> How can people accept to use a display manager with constant screen tearing is beside me

That's solved by using a compositing window manager such as Compton.

You don't even need a compositor. Just activate Force Full Composition Pipeline if you have an nvidia card.

see: https://imgur.com/a/lDfObqw

It's in the advanced settings.

Silky smooth Xorg web browsing and video at no extra compositor cost.

Or `Option "TearFree" "on"` in your xorg.conf for AMD users. Might even be the default by now.

Thank you so much for this! I've been looking for a solution in picom config for way, way too long.

You're welcome.

Frankly I have no idea why it's not enabled by default.

That's also solved by using Wayland with Gnome 3 which comes by default and doesn't require me to tweak anything.

No, that does not solve the issue. Not using a compositor definitely makes tearing worse, on top of a number of other things, but even with a compositor, you'll get tearing on X, at least using intel graphics.

My notebook is using Intel graphics and there's definitely no screen tearing nowadays on X.org with compositing enabled.

Screen tearing for me has been a thing of the past for years now - just switch on "Force Full Composition Pipeline" on your Nvidia card and hey presto, no more tearing.

In 25 years I've never noticed any screen tearing on a variety of hardware. I'm sure it's happened but it's never been a noticeable issue

Is this really a problem for people?

Yes. Even scrolling a long page (like this HN thread) in a web browser can easily produce it. Can be very, very annoying.

Reply on news.ycombinator.com