Whenever I think of X or Wayland it always makes me think of what the Windows code must be like. What secret monolithic struggles have the Windows devs secretly been fighting with for the past 30 years that nobody will ever appreciate?
I don't really understand how one engineer working full-time on Xorg, two weeks of QA, two months for a feature, etc. should be even remotely considered a burden to a company as large as Red Hat.
> Customer with expectations that are difficult to match. e.g., using xorg modesetting you had tearing, which is not acceptable for e.g. digital signage. Intel-drv driver had tearfree, but then new hw didn't work. Solving took more than 2 months. This is standarized in Wayland.<p>I'd like to know more about this one.<p>I mean, suppose the digital signage hardware/software supported OpenGL GPU-accelerated rendering. In that case how would Xorg tearing/tearfree matter? The software is just rendering using OpenGL so Xorg vs. Wayland shouldn't make any difference. IIRC some game dev mentioned this once, how their game is just using a toolkit doing full-screen accelerated rendering-- the underlying display server didn't really make a difference.<p>If I'm right, then the signage hardware must have been using non-accelerated path under Xorg.<p>That leaves me wondering:<p>* is most modern digital signage running without any GPU acceleration?<p>* does software rendering work well enough under Wayland to deliver smooth animation for professional use cases on underpowered hardware?<p>I'm just having trouble thinking of digital signage constraints that need high-enough framerate that Xorg was a problem, but also low enough that software rendering was feasible.
I'm afraid it's too easy to characterize things as too hard and expect people to believe it.<p>Protocols can be versioned, there's no reason Xorg can't become more of a compositor itself.<p>I'd like to see someone describe ame compare building simple and medium complexity GUIs in both Xorg and Wayland. Maybe I'll do it myself if there's some interest or ideas for test targets.
Recent and related:<p><i>Red Hat Enterprise Linux 10 Plans for Wayland and Xorg Server</i> - <a href="https://news.ycombinator.com/item?id=38440607">https://news.ycombinator.com/item?id=38440607</a> - Nov 2023 (160 comments)
What does this mean?<p>Is this saying xorg server is dead?<p>I don't understand - there must be virtually infinite (relatively speaking) software built around xorg.<p>Is there an official announcement of the death of xorg or something?
Yeah, this makes sense to me. One problem that open source has is like a million fractured efforts for the same wheel. It can lead to a million half-baked solutions instead of maybe just a few solid options. I know it has pros, too, but in many ways it would be easier if there were less projects and more people contributing to main projects.
Xenocara works right under OpenBSD and HyperBola GNU/Linux. It works on legacy devices and newer ones. Security? Use separate accounts for work and entertainment. Don't run untrusted crap. If any, use an UXterm with the keyboard locking option in the menus and do the sensitive stuff there.
>One thing I saw in comments about the removal of xorg server is that some might not see how much work is/was to maintain xorg server. I understand is hard to see from outside, but maintaining xorg server with the standards we have in RHEL is not a small beast<p>So you choose a big beast to maintain because "it's cool".<p>And, btw, which standards do you have in RHEL ? (Some years ago fvwm was removed. The feeling at that time it was that fvwm ate to few memory, that's why it was removed)
I guess I'll repeat something I kind of wondered in the other thread - if xwayland works, including in rootful mode, is it practical to just polish it a tiny bit and ship a... xorg-server-shim package or however is easiest, that acts as a drop-in replacement and just runs on top of Wayland? I've been playing with this on my local machine, and running cage[0] with xwayland seems to mostly[1] just work - you run cage, you run an X11 window manager on it using xwayland, and then you ignore the underlying Wayland stuff and run X11 programs, including things like xdotool or such that don't really work in a mixed environment.<p>The advantage is that you <i>can</i> have it both ways - users who are ill served by Wayland can keep running an <i>effectively</i> pure X11 environment, but ex. graphics drivers only need to support Wayland.<p>EDIT: Oh hey, it looks like Puppy Linux actually did exactly this, including using cage: <a href="https://github.com/puppylinux-woof-CE/woof-CE/pull/2265">https://github.com/puppylinux-woof-CE/woof-CE/pull/2265</a><p>[0] <a href="https://www.hjdskes.nl/projects/cage/" rel="nofollow noreferrer">https://www.hjdskes.nl/projects/cage/</a><p>[1] Not 100% - there's some weirdness with keyboard configuration, and of all things xscreensaver-settings wouldn't run, even though everything else I ran worked just fine.
Just 9 years to go before Wayland’s replacement protocol is revealed, going by the X11 timeline.<p>Or, in the next year or two, going by the Xfree86/Xorg timeline.<p>It’ll be interesting to see whether the (inevitable) Wayland or X11 compatibility layer is the more-heavily-used one in that future system.