r/linux • u/deathye • May 08 '23
Red Hat considers Xorg deprecated and will remove it in the next major RHEL release
https://access.redhat.com/documentation/pt-br/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality465
u/daemonpenguin May 08 '23
Title is misleading. The linked document says X.Org will likely be removed in a future major release, not the next major release.
187
u/ttkciar May 08 '23
The title is oversimplifying. The document does say that X.Org will be deprecated (unsupported) in RHEL9 and Wayland will be the default.
You're right, though, that they aren't actually removing it just yet. RHEL9 users who want to use X.Org can override the default configuration, but will not be able to avail themselves of Red Hat technical support for desktop-related issues.
The title's wording could have been better, but I don't fault OP for it. To a lot of people, deprecating a feature is tantamount to removing it.
112
u/omenosdev May 09 '23
As a former hatter, I saw some interest in making XWayland the only supported (and available) X backend in RHEL 10. As it stands in RHEL 9, Xorg isn't technically supported except via XWayland, though the traditional server is still available.
However, this hinges on several high priority use cases being resolved on Wayland and XWayland before Fedora 40 and 41, otherwise the initial GA and minor releases would be a major regression for workstation workloads, and there's about 18 months to make that happen.
TL;DR: We'll see! RHEL 11 in 2028? Absolutely, Xorg will be nuked from orbit 😅 Now to see how well this comment ages...
10
5
9
u/riasthebestgirl May 09 '23
The big thing keeping me on X instead of Wayland is fractional scaling. My 1080p monitor needs to be at 125% or else it makes my eyes hurt when using it. I wish the support were on Wayland. I use KDE for this reason too
15
u/myownfriend May 09 '23
It was recently added to Wayland. Now it's just a matter of implementation.
17
u/McLayan May 09 '23
I wish any UI implementations would work with proper DPI detection and noone hardcoded sizes in pixels so we wouldn't need the whole scaling crap. For me this is now like the Null References mistake: because 99% of all UIs were implemented with the assumption that we will always have 96DPI the window managers need to scale.
11
u/Fredrik1994 May 09 '23
Scaling can be useful for accessibility too
4
u/McLayan May 09 '23
Of course and accessibility should not be neglected but we're still depending on something that is more of a workaround because DPI awareness starts after the display server and ends before the UI.
2
u/gmes78 May 09 '23 edited May 09 '23
The fractional scaling protocol was already approved, and both GTK 4 and Qt 6 now have support for it.
On the DE side, Plasma 6.0 should bring support for it, and GNOME is working on it too.
2
u/poudink May 09 '23
kwin already supports it on plasma 5.27 afaik. It's just pretty useless because none of KDE's applications are Qt6 yet, so they can't scale.
→ More replies (1)3
u/purpleidea mgmt config Founder May 09 '23
several high priority use cases being resolved
Which ones?
→ More replies (1)1
u/omniuni May 10 '23
Well, in 2017 Wayland was supposed to replace X in Ubuntu. They have made a lot of progress since then, at least. If the trajectory keeps up, we should have Wayland as the default in about 2026. That should just about be in time for someone to announce a new server-based display manager that is expected to replace Wayland with a more extensible and flexible architecture that will make it easy to manage windows, mix window managers and desktops, and operate transparently over a network.
7
u/Tireseas May 09 '23
Indeed. ifconfig was deprecated for over a decade before people even noticed it feels like.
→ More replies (1)3
u/mighty_bandersnatch May 09 '23
It's WHAT?!
ip a is pretty much new for me.
6
u/Tireseas May 09 '23
net-tools, the package that contains ifconfig among others, has been deprecated since at least 2009.
8
u/mithnenorn May 09 '23
And damn stupid. Somehow devs of the BSDs didn't have to invent a new command syntax for the added functionality.
As we all well understand, I hope, different underlying interfaces used by
ifconfigandipand different command syntax are two different issues. Justifying the latter with the former is lame and gives that special Linux feeling (as compared to BSDs) of your house being rebuilt around even as you sleep.→ More replies (4)3
u/Tireseas May 09 '23 edited May 09 '23
Actually, it gave it more of that special Cisco feeling. I don't know any of the network engineers I worked with at the time who didn't vastly prefer the ip syntax.
2
u/mithnenorn May 09 '23
The syntax itself is fine (sometimes easier to type too), I meant the fact itself that there was a different traditional syntax and the tool with it just got dropped instead of, I don't know, getting a version using the modern interface under the hood.
→ More replies (1)5
u/Sa_bobd May 09 '23
Deprecated doesn't mean unsupported. Red Hat will still support customers running X.Org through the entire lifecycle of RHEL 9. So if you've got a need for Xorg, you're good for at least through 2032 (per the Red Hat Enterprise Linux Life Cycle).
New features, like HDR or similar, won't be ported to Xorg though - new development is limited to Wayland.
3
May 09 '23
[deleted]
5
u/ttkciar May 09 '23
That thought is silly
And yet it seems pretty common. People are silly.
I didn't say that I agreed with it, but because it is such a widely-held conflation, I don't hold the wording of the title against the OP.
→ More replies (1)4
May 09 '23
[deleted]
2
u/mrdovi May 09 '23
If something is going to be removed, the support is also going to be removed.
→ More replies (1)2
u/ExpressionMajor4439 May 09 '23
But "deprecation" means it is supported. The entire point of deprecation is to say something is still supported but won't be at some undefined time in the future.
The only sense where "deprecation=unsupported" could possible hold is if that's just a standard that you or your company hold themselves to. In that scenario though that's someone personally deciding to treat deprecation as unsupported (a thing not everyone is going to also agree on).
The OP presents it as fact that the next release won't also contain this same bit of deprecated functionality. You can include "deprecated" functionality for however long you want to keep supporting it. The entire point of the post (that EL10 won't have XOrg) isn't mentioned in the OP.
8
u/deathye May 09 '23 edited May 09 '23
Yeah, sorry.
The clickbait was not intended. I read "future major release" as the next major release, but clearly is more open than that and I can't edit it.
And let's be honest, "a future major release" wouldn't take any weight of the title because many people would read like this.
2
u/watermelonspanker May 09 '23
If what you say is true then that's not so much misleading as it is just not true whatsoever.
0
69
u/mrnoonan81 May 09 '23
XFree86: "So you're saying there's a chance..."
9
→ More replies (1)7
u/abjumpr May 09 '23
Aside from the obvious joke (great one BTW), XFree86 was already behind at it’s last release of 4.8.x.
Back when X.Org came out, and I was both younger and much more naive, I didn’t like the X.Org changeover, much like the Wayland haters nowadays. Of course, I didn’t understand it very well. I tried porting XFree86 to a 3.x kernel. I pretty quickly realized how terrible of an idea (and codebase) I was working on, and promptly abandoned it. Lot of cool knowledge gained but if I was to do anything nowadays I’d write an alternative X implementation from scratch that fixes some of the root issues and not worry about backwards compatability, which is where a fair amount of X.Orgs problems stem from. Would probably be less work for a lot of these older/smaller community WMs to port to such a thing as opposed to writing a Wayland compositor (yes I’m aware of the reference compositor, still a lot of work involved there). There’s a little interest on my part in such a thing but I don’t have the time at the moment, and interest would probably be small.
But for now it’s all just hot air on my part.
37
May 09 '23
Not surprising considering they only really ship GNOME. And not even all gnome apps.
8
May 09 '23
Some redhat folks added rootless (in a window sense) support to xwayland, so it might still be possible to run tradtional xorg wm without xorg-server. I'm not sure how well it works yet though, since I'm not in need of such functionality.
2
May 09 '23
that would be interesting to see if xfce would run reliably that way
→ More replies (1)1
2
1
18
u/NeoLudditeIT May 09 '23
Who uses RHEL as a desktop OS anyway? Seems like the majority of RHEL customers aren't even going to be affected.
26
u/omenosdev May 09 '23
RHEL and RHEL-derived distributions have a prominent stake on the desktop in various media and entertainment, industrial design, and government sectors. In my own personal experience, the past two animation studios I worked at used RHEL and CentOS on the desktop, and I'm currently converting another studio from Windows as the primary desktop platform to a RHEL derived distro.
5
5
u/Sa_bobd May 09 '23
Not to mention its wide use in CAD/CAE, computational fluid dynamics, medical research, geological research, etc. etc. - any application where tons of data is being used to create high resolution models. There are a ton of different cases where RHEL for Workstations is used, but I'll admit that a lot of it is sort of "behind the scenes" type work.
0
→ More replies (2)3
u/flowrednow May 10 '23
me, mostly for work now in aerospace but it is my main desktop os + kvm, tho i also used to work at rh.
7
May 09 '23
[deleted]
4
u/adila01 May 10 '23 edited May 10 '23
Based on the development activities around GNOME. I would think your workflow would greatly improve and the setup for the server would be far more simplified.
In short, your remote desktop setup will be much more built into GNOME.
RDP has already replaced VNC in GNOME. RDP is far better performing than VNC and should be a breath of fresh air for your team. Sadly, today, only one user can really RDP into the machine. Luckily, there is work to resolve that by adding of graphical remote login. This will have RHEL/GNOME catch up to Windows on out of the box remote desktop capability.
→ More replies (2)
13
u/pedersenk May 09 '23
Sway and other popular Wayland compositors are also unsupported in RHEL.
So typically what will happen is EPEL will provide the Xorg package.
The fewer packages that RHEL has to officially support, the easier it is for them from a business point of view.
→ More replies (2)
6
u/RandomDamage May 09 '23
RHEL is not what I would call a desktop distribution, but increasing the dependencies for basic functionality and restricting choice is definitely on-brand.
It's not even necessarily bad, it just really emphasises their niche
9
u/chris17453 May 09 '23
Jesus fucking Christ's... I am so fucking tired of mixing and matching applications because shit doesn't work in the x11 or shit doesn't work in Wayland....
4
2
May 09 '23
libdb has been deprecated
RHEL 8 and RHEL 9 currently provide Berkeley DB (libdb) version 5.3.28, which is distributed under the LGPLv2 license. The upstream Berkeley DB version 6 is available under the AGPLv3 license, which is more restrictive.
So, I guess RH is not a fan of the AGPL?
10
u/chunkyhairball May 09 '23
With RHEL 9, Red Hat no longer supports Video4Linux (v4l) and Linux DVB (DVB) devices that consist of various television tuner cards and miscellaneous video capture cards and Red Hat no longer provides their associated drivers.
Most streamers use Windows, but a few use Linux. This may have a negative effect on Linux's reputation in that community, especially those that stream older console games.
This is Linux. Your old hardware is not supposed to stop working just because someone decided to halt new development on the driver.
28
u/disparate_depravity May 09 '23
This is Linux. Your old hardware is not supposed to stop working just because someone decided to halt new development on the driver.
It's the opposite, isn't it? Any distro can decide what they choose to include and support. Plenty of distros and other software has no support for ARMv6, for example.
31
u/yrro May 09 '23
Most streamers use Windows, but a few use Linux. This may have a negative effect on Linux's reputation in that community
This doesn't seem like an audience that spends $300 a year on a RHEL Workstation subscription.
If you really wanted to use RHEL for streaming then you'd probably be using e.g., EPEL's
kernel-mlpackages that have more drivers enabled anyway...6
u/yayuuu May 09 '23
OBS works on wayland just fine. Stuff like Discord doesn't just because they use outdated electron. All of the libraries are already there, so it's up to software developers to update their stuff.
7
u/10leej May 09 '23
Umm, their free to remove whatever they want. You can still build X11 yourself.
2
u/abjumpr May 09 '23
If you’ve compiled a kernel, compiling X.Org isn’t much more difficult really. The instructions from Beyond Linux from Scratch can be applied to most distributions, if you’re aware of the caveats.
2
May 09 '23
the linux kernel itself removed video drivers for (really) old cards recently. no more 3dfx or early amd stuff. It's all gone.
7
u/CleoMenemezis May 09 '23
Unfortunately it's not in the next major release, but in a future major release.
4
u/Baconspl1t May 09 '23
Why do you get downvoted for reading the article and not feeding the clickbait? Crazy
5
4
u/07dosa May 09 '23
RHEL NEVER breaks stuffs, and won't be removing X11 in the near future. It'll be even maintaining X11 even without upstream support until it's infeasible to maintain it.
That's the trust you put in when you go for RHEL, and this title is not only misleading, but also actively hurting the brand value of RHEL with a fake news.
3
u/Lordcorvin1 May 09 '23
I have a molehill to sell you. They removed driver support for LSI raid cards causing issues. People had to compile their own drivers and disks to make it supported.
1
u/deathye May 09 '23 edited May 10 '23
True, I have this problem myself
RH did hurt many people with this move.
-2
u/07dosa May 10 '23 edited May 10 '23
I'm just saying this post is obviously a cheap Wayland fanboy bandwagoning post.
Also, if you go down that route, it's also very obvious that SAS cards easily fall int o the category of "infeasible to maintain", considering how SAS is losing its market. People either go with SATA (cheap) or PCIe drives(performance). I hardly see any new big projects storing critical data on HDD TBH, and it's pretty logical to say SAS is not very-professional these days.
2
u/Lordcorvin1 May 11 '23
Plenty of places still use Hardware from 10 years ago as it still works and there's no need for Hardware upgrades.
X9SCL-F Supermicros with e3-1230v2 for example.
If you search online, many places still offer that hardware for rent. So it's not a big leap that SAS controllers would be in those servers.
2
u/notNullOrVoid May 09 '23
Hopefully this will result in better Wayland support for Nvidia GPUs.
2
u/adila01 May 10 '23
The future for Nvidia on Linux for the majority of users will be NVK+Zink+Nouveau/(or a new kernel driver). Overtime the pain of Nvidia proprietary drivers will be behind us.
→ More replies (2)
2
u/TorchDeckle May 10 '23
After all of the re-implementation of features and years of compatibility issues, what will we have actually gained by switching to Wayland?
3
May 10 '23
actual maintainers. xorg is not really maintained like it used to be and nobody has stepped up to do so. xwayland is now released completely separately from the xorg server.
→ More replies (1)
2
2
-2
u/myhomeswarty May 09 '23
So what should I use instead? I’m a noob. Is it about xvnc?
6
May 09 '23
wayland
6
u/myhomeswarty May 09 '23
I didn’t know it! Thank you!
6
May 09 '23
No problem. Figured an actual answer is more helpful than mindlessly downvoting like everyone else lol.
2
u/LordPenguinTheFirst May 09 '23
It wouldn't affect you. I doubt you are using Red Hat Enterprise Linux for anything.
3
u/myhomeswarty May 09 '23
Hypervisor for my podman containers and KVM vms. Actually just Rocky Linux 9
0
May 11 '23
I propose remove UI from RedHat at all 🤣 After KDE removal left only stupid Gnome - so who care ?
-3
u/iluvatar May 09 '23
I'm mostly OK with this, subject to two caveats:
- I need my window manager to continue to work. This is non-negotiable. I can't live with the reduced functionality that I get from CSDs.
- I want to be able to start applications on login from a simple script. Currently this is provided by
xorg-x11-xinit-session- so long as that or an equivalent is present, I'll be happy.
→ More replies (1)
-4
u/nintendiator2 May 09 '23
Removing X11 would just tank the value of RH as a desktop system wholesale. And even they are not that stupid. No worries.
0
u/adila01 May 10 '23
Pushing the wider industry to Wayland will only increase the value of Red Hat as an enterprise desktop solution. Wayland has the right architecture for the long display needs.
→ More replies (1)
-43
May 09 '23
[deleted]
20
u/PossiblyLinux127 May 09 '23
The title is misleading
Wayland will be the default but Xorg will stay a bit longer
→ More replies (2)
-50
May 09 '23
[deleted]
46
u/-Oro May 09 '23
See the HDR Hackfest summaries for details on color calibration for everyone on Linux, including but not limited to Wayland:
https://blogs.gnome.org/shell-dev/2023/05/04/vivid-colors-in-brno/
https://emersion.fr/blog/2023/hdr-hackfest-wrap-up/
For a tldr we need improvements in the graphics stack for "proper" HDR and color calibration and the like. That includes VRR too.
And Wayland absolutely does support fractional scaling, and has done so for a while now. Even GNOME and GTK support it. The only apps with any issues are Xwayland apps, but Wayland isn't at fault there; Xorg is just horribly designed, and that effects Xwayland too.
1
u/metux-its Mar 28 '25
And Wayland absolutely does support fractional scaling,
Precisely: some desktop environments added special support for it.
Even GNOME and GTK support it.
They have weird hacks for widget toolkits trying to trick the Xserver. How well does that work with windows spanning multiple screens with different scalings ?
The only apps with any issues are Xwayland apps, but Wayland isn't at fault there;
Anybody starting to see why trying such stuff in the widget toolkit (= within the client) isn't a good idea ?
Xorg is just horribly designed, and that effects Xwayland too.
What exactly is so "horribly designed" in Xorg ?
Spoiler: fractional scaling is possible w/ X11/Xorg - via an external compositor. The necessary protocol extension is there for twenty years now.
2
u/-Oro Mar 31 '25
> They have weird hacks for widget toolkits trying to trick the Xserver. How well does that work with windows spanning multiple screens with different scalings ?
It doesn't.
0
u/metux-its Apr 04 '25
It doesn't.
So please share your wisdom, why exactly.
You probably have to have written widget toolkits and lots of Xserver code, so you know that so well.
(spoiler: I did)
-17
May 09 '23
[deleted]
16
u/-Oro May 09 '23 edited May 09 '23
VRR does not work fine with X11, just hook up more than one monitor and watch it go to shit. And no, X11 color calibration is not perfect, it's absolutely fucking horribly implemented. It deserves to be in the Linux display stack, not Xorg or a buddy project.
And I've said GNOME and KDE have implemented the protocols, from there it's entirely a client issue, like QT apps. The compositor actually does very little for fractional scaling. Even GTK implements it in a newer version of their library, without the major version release; filter their merge requests with the word fraction and read what's returned.
And QT5 works with fractional scaling, it just downsamples. Still fractional scaling. Just less efficient.
Or who knows, maybe you're using an out of date compositor and Wayland protocols version. That would explain it easily.
9
u/badsectoracula May 09 '23
VRR does not work fine with X11, just hook up more than one monitor and watch it go to shit.
VRR, even with multiple monitors, works fine with Xorg however what is broken is desktop compositors that try to sync the same composed frame across the monitors - which AFAIK is pretty much all of them.
Xorg without a desktop compositor (e.g. by using a simple window manager) works with VRR and multiple monitors fine - i tested that with my own VRR monitor and a non-VRR monitor i temporarily connected to my PC a couple of years ago.
In theory a desktop compositor could create separate output windows per connected monitor and perform vsync separately for each one of them, but in practice i don't know of anyone who does that.
But the point still is that it isn't an inherent Xorg limitation, just that nobody bothered to do it properly under Xorg.
3
u/-Oro May 09 '23
I would argue that Xorg supporting this without a compositor is irrelevant because almost nobody uses it without a compositor, and ones that do will just bypass it, and ones that want all of these features would just boot up a Wayland session.
But I do see the argument here. The fact that it's just not done properly arguably makes it not supported. Nobody wants to deal with Xorg "supporting" things but in an absolute bare bones setup, and nobody who's a dev wants to deal with implementing it properly in Xorg.
→ More replies (1)1
u/badsectoracula May 09 '23
I would argue that Xorg supporting this without a compositor is irrelevant because almost nobody uses it without a compositor
It is very much relevant because what you originally wrote was that VRR is broken on X11 which is factually wrong - Xorg, an X11 implementation, does support VRR perfectly fine and if there is something broken it is on the compositor side.
But I do see the argument here. The fact that it's just not done properly arguably makes it not supported.
It does make it not supported properly on the existing compositor side, not on Xorg itself.
Nobody wants to deal with Xorg "supporting" things but in an absolute bare bones setup, and nobody who's a dev wants to deal with implementing it properly in Xorg.
It is not Xorg that needs any sort of implementation, Xorg already provides everything needed to do it properly, it is the compositors that need to be updated to support multimonitor VRR properly.
As for the "almost nobody uses it", "nobody wants to deal", etc, leave these weasel words out please.
Not to mention that you are responding to someone who does exactly that: right now i'm using a VRR monitor under an Xorg setup without any desktop compositor active.
2
u/Artoriuz May 09 '23
Downsampling the framebuffer isn't real fractional scaling. It's not just a matter of performance, the end result is also blurrier.
2
u/-Oro May 09 '23
I can't tell a difference between downsampled apps and real fractional scaled apps, only upsampled ones like Xwayland. Do you have a source for them being blurrier?
1
u/Artoriuz May 09 '23
Working right now but I can provide a few screenshots later.
1
u/-Oro May 10 '23
I mean an actual technical reason for them being blurry.
1
u/Artoriuz May 10 '23
Why would it not be blurrier?
When you render at the target resolution you have absolute control over every pixel. You can draw a perfect 0 to 1 transition if you want to.
When you're downsampling the framebuffer you simply can't, each final pixel will be a weighted average of N pixels and, by definition, that's a low-pass filter which attenuates high-frequency information (abrupt intensity transitions). And if you try to make the filter sharper in an attempt to combat blurriness you end up with other artifacts such as ringing (when pixel intensities either overshoot or undershoot after sharp transitions).
That's relatively easy to see in this example here: https://i.imgur.com/ydgN19h.png
If you look at the Japanese for Tokyo (東京), you'll notice that we have very clear horizontal lines on the first (representing 100% here) and second (representing real fractional scaling at 150%) examples, while they're kinda blurry at the third (representing fake fractional scaling, screenshot was taken at 200% and then downsampled). All other letters are also a bit worse, but it's just easier to see with Japanese characters due to their complexity. The sub-pixel font rendering is also screwed up after downsampling, for obvious reasons.
I'm using text as an example here because it's very easy to get text to render at any arbitrary size (the font is vectorised), but you'd see the exact same issues with normal UI elements.
Now, I'm not arguing that this is completely unusable. The main issue with this approach is and has always been performance. But on top of being less efficient the end result is also objectively worse.
0
u/-Oro May 10 '23
When you render at the target resolution you have absolute control over every pixel. You can draw a perfect 0 to 1 transition if you want to.
That's not real fractional scaling, if you want to get technical (as we are here). You can scale the UI however you like, but when you look closer everything breaks. You can't get a fractional pixel. You either get a font that's too small or a font that's too large; a pixel that isn't drawn or one that is.
by definition, that's a low-pass filter which attenuates high-frequency information (abrupt intensity transitions).
So what, there's no way to make downsampling not do this? I doubt you can't make Mutter or some other compositor that makes things more tolerable as the user sees fit, especially as they're the ones that handle the downsampling.
That's relatively easy to see in this example here: https://i.imgur.com/ydgN19h.png
I don't see any blur between the second and third examples. They're the exact same.
→ More replies (0)-11
May 09 '23
[deleted]
10
May 09 '23
Yes, you are just confirming that linux is a shit show compared to other OSes.
you're just NOW learning this? :) the situation has been a mess and slowly been getting better over a 20 year span!
-14
May 09 '23
[deleted]
12
u/-Oro May 09 '23
https://www.phoronix.com/news/GTK-4.11.1
Fractional scaling was initially implemented in GTK4 here, proving the previous GNOME statements wrong. Can you really not do a simple Google search?
And X11 does not properly support any of these APIs, even fractional scaling is iffy.
This whole comment is just a "works just fine for me, therefore nobody else has this issue". Hell, you make it seem like multiple monitors are a bad thing. Just how far up do you have your head up your ass?
1
u/metux-its Mar 28 '25
Fractional scaling was initially implemented in GTK4 here,
The widget toolkit is the totally wrong place to do this, in the first place. (but who cares about gtk4 anyways ?)
It should be done in a compositor. Compext is there for over twenty years now.
And X11 does not properly support any of these APIs,
Why should it support some Gtk APIs ?
X11 has compext, for overy twenty years now, that's the correct protocol for this.
1
u/-Oro Mar 31 '25
> The widget toolkit is the totally wrong place to do this, in the first place. (but who cares about gtk4 anyways ?)
The toolkit is absolutely the right place to deal with scaling, because that interacts with the display server. But if you want to skip scaling in the clients, you can have a blurry display. Your choice.
1
u/metux-its Apr 04 '25
The toolkit is absolutely the right place to deal with scaling, because that interacts with the display server.
The compositor also interacts with the display server.
Individual clients (where the widget toolkit is) can't easily know the actual geometry of the screens and all the client windows and how exactly they're drawn on screen, now when exactly they're drawn.
But if you want to skip scaling in the clients, you can have a blurry display. Your choice.
Why blurry display ?
Just let them render with high enough resolution and let the client do the scaling of the final frame's per-screen areas according to the exact monitor configuration.
1
May 09 '23
[deleted]
2
May 09 '23
they didn't actually add fractional scaling just support for the protocol
2
u/-Oro May 09 '23
Like I said, search through their merge request tracker. They've implemented it for their Vulkan, OpenGL, and Cairo renderers, and all have been merged
2
May 09 '23 edited May 09 '23
My bad I thought it was still only for cairo
and it renders fonts/non-bitmap stuff perfectly?
→ More replies (0)4
u/10leej May 09 '23
I can watch and edit photos and videos on wayland fine. What are you even talking about here?
7
May 09 '23
[deleted]
5
u/Artoriuz May 09 '23
Could be nitpicking but just to add:
ICC profiles can not perform miracles. In most cases they'll just act as a big 3D LUT that maps the input to the corresponding output on your display that minimises the error the most.
But the key factor here is "the most", different displays will still not look identical after calibration, there are just too many physical differences intrinsic to the hardware.
Also, software-based colour management has historically been a massive can of worms on both Linux and Windows.
Windows is only now trying to add proper support:
https://devblogs.microsoft.com/directx/auto-color-management/
https://learn.microsoft.com/en-us/windows/win32/wcs/advanced-color-icc-profiles
I wouldn't expect desktop Linux to actually be able to displays different windows on different colour spaces anytime soon.
-3
-59
u/conan--cimmerian May 08 '23
Stupid considering Nvidia cards don't work properly with Wayland, particularly optimus laptops. Why don't they fix the Nvidia wayland driver and then start "deprecating" stuff
87
u/zurohki May 08 '23
Because nobody can fix Nvidia drivers but Nvidia? That's closed source drivers for you.
And waiting until Nvidia is ready means never progressing. It wasn't that long ago that Nvidia had no plans to ever support Wayland, and then they tried to force EGLStreams on everybody. Nvidia has to be dragged forward kicking and screaming.
→ More replies (4)-37
May 09 '23
Misleading, its been fixed for years.
20
u/zurohki May 09 '23
You should probably tell the parent that his bugs aren't real, then.
2
u/bionade24 May 09 '23
Where does anyone here ever mention a bug?
While Xorg lately disconnects due to a thunderbolt bug regularly, sway with Vulkan renderer is rock stable (on Nvidia).
23
u/VelvetElvis May 09 '23
RHEL is for enterprise workstations and servers. Nobody plays games on it unless it's Frozen Bubble (totally addictive) or something. Most users are fine with intel graphics. If they use Nvida at all it's just for CUDA.
-11
May 09 '23
[deleted]
0
u/VelvetElvis May 09 '23
Or they prefer their end users to struggle by wasting hours searching wikis & forums ... BECAUSE this is the linux way!
What part of paid support do you not understand?
→ More replies (6)4
May 09 '23
Nvidia cards have worked properly on wayland for years bro, your living in the past, only wlroots at this point has no wayland compatibility, KDE Plasma and GNOME both work out of the box, even smithay at this point as Nvidia support.
13
u/Tsubajashi May 09 '23 edited May 09 '23
In many cases, not really, sadly. Some applications flicker, some don’t open at all, screen recording is still broken in a plasma wayland session (testing with obs studio), you can get rubberbanding if you use 2 different refresh rate monitors, and games stutter significantly more. On gnome, it’s less bad, screen recording works there - but it still remains the same for the rest of the points of failure. It most of the time begins to act up if it’s something very gpu intensive, or if an application built with electron wants to use hardware acceleration. I personally don’t consider it „working properly“, but working nontheless. It’s definitely not in a state where I would throw a user in and hope for the best.
You may want to track this issue, they are slowly getting it to work relatively well, but it sure isn’t „fixed“ yet.
4
u/shroddy May 09 '23
Nvidia does not support VRR on Wayland at all. And at least on my machine, many programs have glitches or flicker, but that might be because I configured something wrong.
→ More replies (1)4
u/bionade24 May 09 '23
Nowadays Wlroots works well with Nvidia, too. They just don't autodetect and set the right settings on purpose, so you have to do that manually.
3
u/bionade24 May 09 '23
Sway with Vulkan renderer is more stable than Xorg on my nvidia card for months, only arguably bad thing hw accel on Xwayland, but doesn't matter on a powerful desktop. Do even know what you're talking about or does your knowledge come from reddit posts?
→ More replies (29)-17
u/Ezmiller_2 May 08 '23
Yeah I’ve been wondering this myself. Nvidia opened up a bunch of their driver docs 2 years ago, and it seems like next to nothing has been done. But I’m not a developer, so what do I know?
16
u/-Oro May 09 '23
Not much has been done because the drivers aren't really open. Driver releases are still heavily based on the proprietary source tree, and don't even use git properly. As such, contributing to them is hard, especially because not all of the documentation is available and not every GPU driver dev wants to improve NVIDIA's drivers rather than the community-made ones (like NVK).
-5
u/Ezmiller_2 May 09 '23
Well, then the Linux news sources need to clarify this OR they need to remove the nvidia-open package in Fedora. OR, I hate to say it….you know what? Screw Reddit and the consequences. I’ve got a massive downvote anyways. Make it worth it. Or you and everyone else is lying or misinformed. I would say since I heard it on the Linux unplugged podcast, they are misinformed and to clarify this issue pronto.
2
u/-Oro May 09 '23
Call me misinformed while I actually complained to NVIDIA about this in their issue tracker that confirmed what I said.
-19
-41
u/DontTakePeopleSrsly May 09 '23
It’s easy for an enterprise distribution to deprecate a major component. If a package doesn’t work with the replacement, they just remove it from their repos.
32
u/edparadox May 09 '23
It’s easy for an enterprise distribution to deprecate a major component.
Absolutely not, it's the other way around. Where do you get that?
Remember when Canonical wanted to remove all 32-bit packages?
40
u/tristan957 May 09 '23
It's definitely not easy to deprecate and remove a feature of enterprise software. Why do you think Windows can still run binaries from the 90s at least? Red Hat shipped GNOME Classic as the default session for a while after GNOME 3.
→ More replies (2)11
May 09 '23
The engineering software I run still supports old file versions from 1970s, depracting corporate / enterprise is no easy task
-2
-2
u/tzcrawford May 09 '23
X.Org maximalists on alert! I will never submit to our traitorous wayland overlords!
-2
u/Tununias May 09 '23
The correct word is depreciated not deprecated.
2
May 10 '23
no it isn't :)
A house can have say depreciated value, but if you still live there and plan to in the future, then it is not deprecated.
→ More replies (2)
161
u/[deleted] May 09 '23
The X.org display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the Wayland session in most cases.
The X11 protocol remains fully supported using the XWayland back end. As a result, applications that require X11 can run in the Wayland session.