XWayland 22.1 RC1 Released With DRM Leasing, Other Improvements

[phoronix]

Phoronix: XWayland 22.1 RC1 Released With DRM Leasing, Other Improvements

The race is on for delivering XWayland 22.1 in time for the spring Linux distribution releases with at least Fedora Workstation 36 expected to carry this updated package for allowing X11 clients to work atop Wayland compositors...

https://www.phoronix.com/scan.php?page=news_item&px=XWayland-22.1-RC1-Released

[kmansoft]

HiDPI scaling still not merged?

[MastaG]

HiDPI scaling still not merged?

This and HDR 10-bit support are things that should have been available for a long time.
But it seems that so many layers (e.g. kernel, wayland protocol, desktop compositor, xwayland, drm/gbm libraries etc) require negotiating and settling down on a certain standard or way on how to implement something... which always takes years and years...

Look for example at the Gnome MR for implementing the "handle mouse cursor its own independent thread" thing.
It works now, but mouse movement is still tied to the refresh rate for drawing the cursor, because the DRM cursor plane can't be updated and drawn on its own, taking away smooth mouse movement when having a VRR setup (at least that's how I understood it).
So another change to kernel the API is required for having smooth mouse movement, even when doing VRR.

I just whish some things could be done faster... but I'm not working on them, so I shouldn't complain lol :P

[slagiewka]

Still no HiDPI... Fundamentals being neglected like this is kind of killing the Wayland hype. Is VR in Linux bigger than HiDPI use?

BTW. Again, they call it Xwayland, not XWayland phoronix

[Myownfriend]

Still no HiDPI... Fundamentals being neglected like this is kind of killing the Wayland hype. Is VR in Linux bigger than HiDPI use?

It's a matter of one being more complicated than the other. You could work on the HiDPI stuff if you want.

[oiaohm]

BTW. Again, they call it Xwayland, not XWayland phoronix

https://wayland.freedesktop.org/xserver.html Sorry you are in fact wrong and right at the same time. Depending on what party its either XWayland or Xwayland or xwayland all three are correct in different contexts.

Yes even inside the xwayland(lower case is the project name) source code the comments change between all 3. Yes Xwayland is technically wrong for the project as well.

[ANNOUNCE] xwayland 22.0.99.901 (aka Xwayland 22.1.0 rc1)

Yes the top the release notes people did not look at to see that the true project name is xwayland. When you are talking about XWayland in reference to the wayland protocol stuff it is XWayland.

Yes Xwayland think start of sentence/line capitalisation or proper noun capitalisation but those capitalisation is not in fact the project name.

Yes the freedesktop XWayland is technically "X on Wayland" compacted by removing the on and the two spaces what is still a valid description for xwayland project.

Basically xwayland is a capitalisation mess. Yes they have not called the fork off project Xwayland but its called xwayland and can be written as Xwayland by proper noun capitalisation rule. Due the the project name being lower and xwayland still compacted form of X on Wayland the freedesktop capitalisation is also valid and is different application of the proper noun capitalisation for compound words.

The horrible reality is both Xwayland and XWayland are not the project name so both are technically wrong but writing xwayland with no capitalisation at all is horrible on the reader as we expect names to have capitalisation.

Pure lower case project names can be quite cursed.

[Mario Junior]

My God, I hate Xwayland so much!

[slagiewka]

It's a matter of one being more complicated than the other. You could work on the HiDPI stuff if you want.

There's no need for me to do so. The first contributions from community happened in !111 (by KWin dev) precisely 3 years ago. Then it evolved into !432 and finally !733 in August 2021. All by community.

It doesn't seem like this is a hard change anymore after all those iterations. There's also a wlroots patch available that shows the implementation on the compositor side.

Don't get me wrong. I have the utmost respect to the people maintaining X code and moving Xwayland forward. The thing is that the HiDPI stuff could get more TLC. Without it there will be pain for people trying out Wayland with apps that are not Wayland compatible. And some of them won't be for a long time still.

[Vistaus]

This and HDR 10-bit support are things that should have been available for a long time.
But it seems that so many layers (e.g. kernel, wayland protocol, desktop compositor, xwayland, drm/gbm libraries etc) require negotiating and settling down on a certain standard or way on how to implement something... which always takes years and years...

That isn't a bad thing per se. I mean: Windows has had HDR-10 support for quite some time now, but it's quite finicky and unpolished. So earlier support doesn't mean better support. If the XWayland team needs more time, but they deliver a better result, then I'm not complaining.

[Vistaus]

My God, I hate Xwayland so much!

I know, right? XWayland and xwayland is where the magic happens. The devs of Xwayland can suck it!!!