GNOME's Wayland Session Shows Potential For Better Battery Life Than With X.Org

[reba]

Regarding switching between Wayland and X11 in conjunction with KDE Plasma:
I regulary switch between both, in the same uptime-cycle.

It is possible and with a bit of kill-ing it works reliably.
I disabled (and soon to remove) sddm as it gets in the way because it spawns an X11 server itself and does not (for me) provide anything worthwile:
I boot up to the console and run one of the two shell scripts to either start an X11 or a Wayland Plasma session.
Then I logout of this session, drop back to the console and log in into the other, if I want to.

The reason for this is I usually run the Wayland session but because of the Nvidia-dGPU in this laptop I have to switch to X11 to be able to use it (hope NVIDIA gets it support in a row in a timely manner), usually for gaming.
It is also possible to not enable the Nvidia dGPU and run the X11 session on the AMD iGPU.

In short: it is possible and I switch regulary between X11 Plasma and Wayland Plasma, sometimes often a day, without a reboot in between.
So it's more like three possible sessions:
- AMD Wayland Plasma (daily driver; this also spawns an XWayland in the background because kwin does so)
- AMD X11 Plasma (has its uses, for when needing an X11 session without needlessly enabling the NVIDIA dGPU which just burns Watts)
- NVIDIA X11 Plasma (when gaming so the X server is started on this GPU).

[oiaohm]

So, in order a user could apply Wayland session in PLASMA it has to enter in wayland session the first time assuming its hardware is compliant to wayland. If the user switch to X11 is still able to enter Wayland session again (always in PLASMA)?

The answer is maybe at this stage and that is the problem. Issue here is X11 server has X11 drivers been the plasma running in X11 and plasma running as wayland has direct. So yes hardware can be X11 and Wayland compliant but switching backwards and forwards is not going to work due to the fact to the KDE X11 compositor/windows manager and KDE Wayland Compositor the details about the hardware are being presented differently.

Its really simple to forget X11 server provides a layer of abstraction from the hardware. Yes this layer of abstraction result information about the hardware not appearing the same. So plasma running wayland can record settings that match direct hardware but when applied on X11 abstraction does not work when you apply those settings due to abstraction and the reverse can be true as well the X11 abstraction can have you setting stuff ways to suite it that don't suit direct hardware.

As of Chrome and Firefox, how do these browsers switch to wayland and x11recognizing the two different graphical systems?

Userspace applications mostly don't have the same problem. They are normally not need all the details X11 compositor use or Wayland compositor use. This is like 99.9 percent of your desktop applications really not recording that much information about the platform they are on so more adapt to what they see the next time they start.

This is a problem that will be solved in time as people work out what settings that have to be marked as direct hardware or X11 only.

[Azrael5]

The switch backwards and forwards issues between wayland and X11 will be fixed at some point. Please note issues its not a single fault. Some of those faults are hardware combination dependant. So as people hit the issues and report them they are being progressively fixed.

The not there yet is that the are still new issues turning up and existing issues open that are being fixed. The rate if new issues causing this problem is decreasing with time. So moving in the right direction and will get there some time could be 6 months out could be a year or 2. This is just one of those things that we cannot 100 predict.

There are also known issue with SDDM doing stupid things as well. Those issue are also being worked on being fixed.

So, in order a user could apply Wayland session in PLASMA it has to enter in wayland session the first time assuming its hardware is compliant to wayland. If the user switches to X11 is still able to enter Wayland session again (always in PLASMA)?

As of Chrome and Firefox, how do these browsers switch to wayland and x11recognizing the two different graphical systems?
At this point two different operating systems of the same one, the first one based on Wayland and the other on X11 would not solve the switching problem? As example, Fedora based on Wayland and Fedora based on x11, Kde Neon based on wayland and Neon based on x11. Most of the limitations, in the transitional phase is due to the necessity to match non-wayland with wayland by xwayland. A clear separation could simplify the program development above all now that wayland operating systems seem to be ready.

[oiaohm]

Will be this issue fixed?

The switch backwards and forwards issues between wayland and X11 will be fixed at some point. Please note issues its not a single fault. Some of those faults are hardware combination dependant. So as people hit the issues and report them they are being progressively fixed.

The not there yet is that the are still new issues turning up and existing issues open that are being fixed. The rate if new issues causing this problem is decreasing with time. So moving in the right direction and will get there some time could be 6 months out could be a year or 2. This is just one of those things that we cannot 100 predict.

There are also known issue with SDDM doing stupid things as well. Those issue are also being worked on being fixed.

[Azrael5]

I guess you did not try a clean account. Plasma does run into problems with X11 setting causing Wayland to fail to start. Yes it also runs into the reverse where you have a Wayland settings from running Plasma and you attempt to run back on X11 and now X11 Plasma fails to start and is throwing you back to SDDM. Yes this is KDE Plasma known issue.

Ideal world you would be able to switch between X11 and Wayland modes with the same user account but we are not there yet.

Will be this issue fixed?

[t.s.]

First of all, this depends on the display type.
Rule of thumb:
Monitor --> 'Full' color range
HDTV --> 'Limited' color range

Now, the evil devil called nVidia makes changing this setting dead-easy via GUI.
However, everyone else can enjoy some quality time with their PC to try to change this setting, especially so on Wayland:

https://www.onetransistor.eu/2021/08/hdmi-picture-quantization-range-linux.html

So, what are you waiting for?
Go on, spent some well deserved time with your PC this holiday season.
Cheers!

For now, I just go use Plasma X11. Problem solved.

[Vistaus]

Please note installer created account in some cases is not clean. Some distributions wayland does not work with the installer created account and you spin up a new user and it magically works.

Yes relatively clean or installer created relatively clean are not clean. I have also run into a few cases with X11 where things have been a little strange until I created a new clean user and worked out installer had done something stupid in the installer created user with some distributions.

New user doesn't solve the issue, in both instances.

[oiaohm]

Vulkan is removing inefficiencies of the aforementioned shading, texturing, and lighting process.

And all those fixes are neutral between Wayland, X11 and MS Windows.... Something that Steffo has missed is how many operations these days that just bypass X11/Wayland/MS Windows output management. Of course every operation that bypasses means there is less to performance gain with.

[Myownfriend]

Surprisingly, until today Wayland is not that much faster than X.Org. Actually I thought we would have gains around 30% - 50%, when I heard the first time about Wayland and its promises.
Maybe the architecture and code has to mature 5 more years?

I'm pretty sure that most of these games are being run through XWayland. Even then, Gnome's Wayland backend could be ten times faster than it's X11 backend and it may not result in 30-50% gains in a game.

The majority of a game's frame time is taken up by shading, texturing, and lighting a complex world at high resolutions. The time spent sending the finished frame to the compositor is the smallest fraction of that time.

That I was talking about and it wouldn't had been that unrealistic, see Vulcan vs. OpenGL.

Vulkan is removing inefficiencies of the aforementioned shading, texturing, and lighting process.

[oiaohm]

That I was talking about and it wouldn't had been that unrealistic, see Vulcan vs. OpenGL.

The reality here is it is unrealistic for wayland to speed stuff up massively. In most cases it will be under 10 percent.

Remember opengl and vulkan basically bipass X11 and Wayland for 99.9% of all operations. Please note that 99.9% is on the low side number and its not just a number I have pulled out head. If you perform a trace of all operations by applications using opengl and vulkan you see 99.9+ going straight to hardware by buffers without touching the X11 or Wayland bits.