Live data from Hacker News

X12: Requirements for a successor to the X11 protocol (2013)

x.org

111–120 of 318 posts

Re: X12: Requirements for a successor to the X11 protocol (2013)

#111
post #82
post #81

Earlier quoted context omitted.

Wayland uses linux’s gpu abstraction (drm) to work and that’s it. If it fails to work than linux also does, so your setup has some issues.

I have to disable hardware compositing on X11 to get a reliable desktop (and HW rendering in individual apps like firefox). I'm not sure if something similar is possible on Wayland.

That doesn’t depend on the protocol, I think most implementations can simply choose a so-called “dumb” backend instead of hardware composition.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#112

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve anything (except an excess of glue)" (shell scripts for sysvinit vs declarative unit files for systemd; X11 apps that can do almost anything, vs the privileged compositor for wayland), to a model of "we wanted things to just work without having to install glue, so we integrated more functionality people wanted, if you want to swap it out you have to swap out the whole thing and keep up enough with all the other features people want" (e.g. you have to actually get the things you want into unit file directives, or get the features you want into the compositors people use; or you have to build a completely separate compositor or a separate init).

That's a tradeoff. For my part, I'm thrilled that so many more things just work out of the box; however, it's discouraging for people whose features aren't covered yet, since they have to go work on integration rather than writing a specialized tool and encouraging people to glue that tool in. But the benefit of that is that once something is integrated, it just works, with no glue required.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#114

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going.

And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#115

Haven't we been through this fiasco of trying to replace X11 with X12 about a dozen times in the last several decades? Just go onto Y0. https://donhopkins.medium.com/the-x-windows-disaster-128d398...

Yes, and who remembers "Y" from I think 20 to 25 years ago :)

Re: X12: Requirements for a successor to the X11 protocol (2013)

#116
post #102
post #10

Earlier quoted context omitted.

I'm not up to date on the Linux desktop ecosystem. In what sense is Wayland struggling?

Dudemanguy wrote about its deficiencies 2022-06-11 [0], ex lack of feature parity with X11 and self imposed limitations like only allowing integer scaling (ie to get 1.5 scaling, it uses x3/x2 scaling). For some perspective, consider checking other hn reader reactions to this post [1]. [0] https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-x... [1] https://news.ycombinator.com/item?id=31752760

Fractional scaling was recently merged.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

Re: X12: Requirements for a successor to the X11 protocol (2013)

#117

Earlier quoted context omitted.

The choices of architecture seem to reflect different priorities, there are things that the Wayland architecture does better than X and vice versa, aren't there? Hard to say X11 is ahead architecturally if you pick features that Wayland may not consider important. I've seen commentary from people who have worked intimately on both protocols and implementations of both who consider Wayland to have the better architect…

> I've seen commentary from people who have worked intimately on both protocols and implementations of both who consider Wayland to have the better architecture. For those interested in details: https://www.youtube.com/watch?v=GWQh_DmDLKQ

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.

A few key points:

1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.

2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.

3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.

4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.

5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.

6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!

Re: X12: Requirements for a successor to the X11 protocol (2013)

#118

Earlier quoted context omitted.

Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good ideas, along with a bunch of functionality that isn't there yet. Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing. I think systemd and Wayland are actually opposit…

> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.

I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years.

I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure some command to run which talks to Discord over an IPC solution to start sharing my voice when I press my push to talk button and stop when I release the push to talk button? But "global hotkeys should be configured on a system basis, not an application basis" seems to be the reigning philosophy, despite being incredibly user and developer hostile.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#119

X is almost 40yo, stable, reliable, difficult to maintain. Wayland is 15yo, barely usable. Any old timers remember 1999 when X was 15? Wayland is like IPv6 of desktops

More like the aptly named "Duke Nukem Forever" of the desktop.

https://en.wikipedia.org/wiki/Development_of_Duke_Nukem_Fore...

Re: X12: Requirements for a successor to the X11 protocol (2013)

#120
post #21
post #5

Mind that the page describes a hypothetical update to X. In practical terms, Wayland is X12.

That's quite a stretch, Wayland and X (any X, 11 or hypothetical 12) are so vastly different that calling Wayland "the new X" is like calling Quartz "X for macOS".

It's not as far fetched as you'd think. My understanding is that Wayland is a result of X11 developers going together to design a new protocol based on the thoughts and ideas they've had for an "X12" throughout the decades.
Post reply on HN