Some interesting Linux industry news for you here, as the long road towards Wayland by default everywhere is taking another big step with Red Hat Enterprise Linux (RHEL) removing the Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases.
From their announcement by developer Carlos Soriano Sanchez posted November 27th:
We want to recognize the significant effort all these organizations and individuals have made, especially the rest of the upstream community, without whom this project would never be so mature. This effort gave us the confidence to first make Wayland default for most use cases in RHEL 8, followed up with the deprecating of Xorg server in RHEL 9, with the intention of its removal in a future release. Earlier this year (2023), as part of our RHEL 10 planning, we made a study to understand Wayland’s status, not only from an infrastructure perspective, but also from an ecosystem perspective. The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we’re on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025.
With this, we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning to a Wayland ecosystem. It’s important to note that “Xorg Server” and “X11” are not synonymous, X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
Red Hat and their engineers have their fingers in many pies across the Linux space, so this is a pretty big move, and one they say will enable them to "tackle problems such as HDR, increased security, setups with mixed low and high density displays or very high density displays, better GPU/Display hot-plugging, better gestures and scrolling, and so on" — which of course will end up benefiting everyone because that's how open source works.
Have you fully switched over to Wayland yet?
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
Quoting: tohurThe reason you turn Vsync off is input lag.. granted you don't notice it in most games but fast paced games you need Vsync off because in competitive games even moderate lag will get you killed. GNOME doesn't allow for you to turn it off in wayland and trust me in wayland you want Vsync off because with it on the lag is terrible.. for my preferred games GNOME is bad bad LMAO.. in KDE wayland there is a setting to allow screen tearing aka turnk off vsync for full screen apps aka games. the overall gaming experience is better on KDE
I said it before, but whole turn vsync off for input lag idea is like couple decades or more old and is in practice outdated.
It originates from the time when everyone had 60 Hz displays. Those who worry about input lag today don't use such displays, so with adaptive sync and 144 Hz display (or even more) having tearing above monitor refresh rate range is of little value, because you won't notice much of a difference.
If you have 60 Hz monitor still - then yeah. So it's useful that KDE supports such scenario, but less useful than how it sounds.
Last edited by Shmerl on 7 December 2023 at 11:26 pm UTC
1 Likes, Who?
Quoting: ShmerlQuoting: tohurThe reason you turn Vsync off is input lag.. granted you don't notice it in most games but fast paced games you need Vsync off because in competitive games even moderate lag will get you killed. GNOME doesn't allow for you to turn it off in wayland and trust me in wayland you want Vsync off because with it on the lag is terrible.. for my preferred games GNOME is bad bad LMAO.. in KDE wayland there is a setting to allow screen tearing aka turnk off vsync for full screen apps aka games. the overall gaming experience is better on KDE
I said it before, but whole turn vsync off for input lag idea is like couple decades or more old and is in practice outdated.
It originates from the time when everyone had 60 Hz displays. Those who worry about input lag today don't use such displays, so with adaptive sync and 144 Hz display (or even more) having tearing above monitor refresh rate range is of little value, because you won't notice much of a difference.
If you have 60 Hz monitor still - then yeah. So it's useful that KDE supports such scenario, but less useful than how it sounds.
bruh you clearly haven't compared GNOME vs KDE in this regard.. the Input lag in shooters and the such is bad enough it is noticeable lol. plenty of recent bug reports/ feature request out there to prove it is an issue now
0 Likes
Quoting: tohurbruh you clearly haven't compared GNOME vs KDE in this regard.. the Input lag in shooters and the such is bad enough it is noticeable lol. plenty of recent bug reports/ feature request out there to prove it is an issue now
I think Gnome's input lag has nothing to do with refresh rate, they just didn't optimize their own compositor for lower latency unlike KWin developers did. I.e. besides refresh rate delaying drawing, input lag can be caused by simply compositor doing any stuff before it's ready to draw. If you have too much of that - you'll have lag.
So yeah, Gnome might have such issue, but adding tearing won't help it if they don't optimize what they aren't doing efficiently, that's my point.
Last edited by Shmerl on 7 December 2023 at 11:41 pm UTC
0 Likes
Quoting: ShmerlQuoting: tohurbruh you clearly haven't compared GNOME vs KDE in this regard.. the Input lag in shooters and the such is bad enough it is noticeable lol. plenty of recent bug reports/ feature request out there to prove it is an issue now
I think Gnome's input lag has nothing to do with refresh rate, they just didn't optimize their own compositor for lower latency unlike KWin developers did. I.e. besides refresh rate delaying drawing, input lag can be caused by simply compositor doing any stuff before it's ready to draw. If you have too much of that - you'll have lag.
So yeah, Gnome might have such issue, but adding tearing won't help it if they don't optimize what they aren't doing efficiently, that's my point.
input lag from vsync has squat to do with refresh rate honesly but is more noticable on certain refresh rates.. Vsync just naturally adds input lag regardless if you notice it or not. Honestly I feel like for me its only noticeable on high refresh rates as I play my games at 144hz
Last edited by tohur on 8 December 2023 at 12:35 am UTC
0 Likes
Quoting: tohurinput lag from vsync has squat to do with refresh rate honesly
It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.
Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.
There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/
Here is a useful diagram:
I think using Vulkan mailbox present mode above the monitor refresh rate is similar to what AMD means by "enhanced sync".
Last edited by Shmerl on 8 December 2023 at 12:45 am UTC
0 Likes
Quoting: ShmerlQuoting: tohurinput lag from vsync has squat to do with refresh rate honesly
It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.
Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.
There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/
Here is a useful diagram:
Which is why for me KDE trumps GNOME as Freesync works out the box on wayland. Last time I tried gnome don't think freesync worked thus the bad experience on top of using vsync
0 Likes
KDE supports it better, yeah. Except some scenarios where cursor breaks it, which I think is being addressed at Wayland protocol level before compositors will fix it. But Gnome just doesn't seem to focus on gaming use cases in general, so it takes them forever to add any adaptive sync support.
Last edited by Shmerl on 8 December 2023 at 12:53 am UTC
Last edited by Shmerl on 8 December 2023 at 12:53 am UTC
0 Likes
slaapliedje Dec 8, 2023
Quoting: tohurInput lag can be caused by a whole host of other things, outside of what software you're using even. There's a spreadsheet out there somewhere detailing all of the input lag of just using specific game pads versus another set of gamepads. I've never had any issues with input lag on gaming myself, though that could be because I'm too old to notice. But then if I don't notice, does it matter if it's there? It's like a fart you don't smell.Quoting: ShmerlQuoting: tohurinput lag from vsync has squat to do with refresh rate honesly
It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.
Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.
There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/
Here is a useful diagram:
Which is why for me KDE trumps GNOME as Freesync works out the box on wayland. Last time I tried gnome don't think freesync worked thus the bad experience on top of using vsync
Amusingly, the main reason I flip between gnome/kde right now is because File-roller is broken as far as being able to drag / drop files into Nautilus at the moment (something about the transition to a new GTK or something is lagging behind). So when I am attempting to copy software over to a CF card for my DOS/Win9x machines, I flip to KDE. This is where I don't really notice any difference whether I'm using wayland or xorg, gnome or kde. I guess if I were bored stiff, I could run some benchmarks on some games to see if Wayland+KDE or Wayland+Gnome or Xorg+KDE or Xorg+Gnome can inch out a few more FPS here or there, or have less lag... but frankly don't give a crap. I've listed the reasons why Wayland 'doesn't quite work for me yet' and that I still need Xorg for over and over again.
I've said many times over, there should be a DE somewhere in between KDE and Gnome. Gnome seems to go for the simplistic, get out of your way desktop environment, and has some useful little quirks in it. KDE goes for the 'give you all the options you could ever think of, and 10x more that you couldn't, because someone else on the internet thought it up.' approach. Both approaches are valid, but I think there would be a lot to say about a DE that could hit right in the middle of that. Or even if KDE could figure out a 'simplified' way.
I used to prefer Gnome over KDE because GTK had cooler themes / and felt less like Windows. Now Gnome just reminds me of macOS, which I have learned to despise :P
0 Likes
Quoting: slaapliedjeQuoting: tohurInput lag can be caused by a whole host of other things, outside of what software you're using even. There's a spreadsheet out there somewhere detailing all of the input lag of just using specific game pads versus another set of gamepads. I've never had any issues with input lag on gaming myself, though that could be because I'm too old to notice. But then if I don't notice, does it matter if it's there? It's like a fart you don't smell.Quoting: ShmerlQuoting: tohurinput lag from vsync has squat to do with refresh rate honesly
It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.
Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.
There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/
Here is a useful diagram:
Which is why for me KDE trumps GNOME as Freesync works out the box on wayland. Last time I tried gnome don't think freesync worked thus the bad experience on top of using vsync
Amusingly, the main reason I flip between gnome/kde right now is because File-roller is broken as far as being able to drag / drop files into Nautilus at the moment (something about the transition to a new GTK or something is lagging behind). So when I am attempting to copy software over to a CF card for my DOS/Win9x machines, I flip to KDE. This is where I don't really notice any difference whether I'm using wayland or xorg, gnome or kde. I guess if I were bored stiff, I could run some benchmarks on some games to see if Wayland+KDE or Wayland+Gnome or Xorg+KDE or Xorg+Gnome can inch out a few more FPS here or there, or have less lag... but frankly don't give a crap. I've listed the reasons why Wayland 'doesn't quite work for me yet' and that I still need Xorg for over and over again.
I've said many times over, there should be a DE somewhere in between KDE and Gnome. Gnome seems to go for the simplistic, get out of your way desktop environment, and has some useful little quirks in it. KDE goes for the 'give you all the options you could ever think of, and 10x more that you couldn't, because someone else on the internet thought it up.' approach. Both approaches are valid, but I think there would be a lot to say about a DE that could hit right in the middle of that. Or even if KDE could figure out a 'simplified' way.
I used to prefer Gnome over KDE because GTK had cooler themes / and felt less like Windows. Now Gnome just reminds me of macOS, which I have learned to despise :P
Yes thats true input lag can because by many things but in my case I think its a mixture of being locked to using Vsync and not having proper Freesync support in GNOME on wayland and the games I tend to play I notice the lag thus why KDE is just better in this regard. Honestly haven't liked GNOME since they have started down the path of mimicking Apple/macOS in every way possible.. the good, bad and the ugly.
Also KDE does have it in the plans to make a simplified settings app and just app settings in general for folks that just want the out the box experience and basic customization.. and have the rest the settings toggled on with a advanced toggle or something... Theres an Youtuber thats a KDE dev that talked about it some months back on one of his videos
Last edited by tohur on 8 December 2023 at 4:21 am UTC
0 Likes
slaapliedje Dec 8, 2023
Quoting: tohurThere apparently are ways to enable Freesync within Xorg... I know G-Sync worked when I had nvidia. All three of my monitors support GSync but according to xrandr, only one of them supports Freesync. Wayland requires the DE apparently to enable it?Quoting: slaapliedjeQuoting: tohurInput lag can be caused by a whole host of other things, outside of what software you're using even. There's a spreadsheet out there somewhere detailing all of the input lag of just using specific game pads versus another set of gamepads. I've never had any issues with input lag on gaming myself, though that could be because I'm too old to notice. But then if I don't notice, does it matter if it's there? It's like a fart you don't smell.Quoting: ShmerlQuoting: tohurinput lag from vsync has squat to do with refresh rate honesly
It has a lot to do with that I'd say. If refresh rate is low (60 Hz) and compositor waits for vertial sync, you'll notice lag. Tearing means compositor doesn't wait and draws even if it will result in jagged image, so you'll see updates before the full refresh cycle even happens, which in practice means lower latency (lag). That kind of scenario benefits from enabling tearing.
Scenario when your refresh rate is 144 Hz and more reduces the period of blanks low enough that you don't notice anything even if compositor waits for it. But more importantly, you need to have adaptive sync (VRR) in order to avoid unnecessary waits. That's an improvement of the old style vsync.
There was a thread about it here: https://www.gamingonlinux.com/forum/topic/5185/
Here is a useful diagram:
Which is why for me KDE trumps GNOME as Freesync works out the box on wayland. Last time I tried gnome don't think freesync worked thus the bad experience on top of using vsync
Amusingly, the main reason I flip between gnome/kde right now is because File-roller is broken as far as being able to drag / drop files into Nautilus at the moment (something about the transition to a new GTK or something is lagging behind). So when I am attempting to copy software over to a CF card for my DOS/Win9x machines, I flip to KDE. This is where I don't really notice any difference whether I'm using wayland or xorg, gnome or kde. I guess if I were bored stiff, I could run some benchmarks on some games to see if Wayland+KDE or Wayland+Gnome or Xorg+KDE or Xorg+Gnome can inch out a few more FPS here or there, or have less lag... but frankly don't give a crap. I've listed the reasons why Wayland 'doesn't quite work for me yet' and that I still need Xorg for over and over again.
I've said many times over, there should be a DE somewhere in between KDE and Gnome. Gnome seems to go for the simplistic, get out of your way desktop environment, and has some useful little quirks in it. KDE goes for the 'give you all the options you could ever think of, and 10x more that you couldn't, because someone else on the internet thought it up.' approach. Both approaches are valid, but I think there would be a lot to say about a DE that could hit right in the middle of that. Or even if KDE could figure out a 'simplified' way.
I used to prefer Gnome over KDE because GTK had cooler themes / and felt less like Windows. Now Gnome just reminds me of macOS, which I have learned to despise :P
Yes thats true input lag can because by many things but in my case I think its a mixture of being locked to using Vsync and not having proper Freesync support in GNOME on wayland and the games I tend to play I notice the lag thus why KDE is just better in this regard. Honestly haven't liked GNOME since they have started down the path of mimicking Apple/macOS in every way possible.. the good, bad and the ugly.
Also KDE does have it in the plans to make a simplified settings app and just app settings in general for folks that just want the out the box experience and basic customization.. and have the rest the settings toggled on with a advanced toggle or something... Theres an Youtuber thats a KDE dev that talked about it some months back on one of his videos
0 Likes
Patreon
PayPal
See more from me