XWayland 22.1 RC1 Released With DRM Leasing, Other Improvements

[bple2137]

HiDPI scaling still not merged?

Not even agreed on a single implementation.
https://gitlab.freedesktop.org/xorg/...e_requests/733 - that's the most active discussion, although the MR author is not responding to maintainer's concerns.

It's painful to watch honestly, but I don't have the skills required to maybe try and push that a little instead of just complaining. I would literally need to learn about how both protocols and Xwayland work in order to add anything useful to the endless discussion. Even well skilled people couldn't sort that out for years so it's unlikely that I could as a dumbass. Where do I even start learning? Maybe I'll start building stuff with those patches and just experiment and see what does what?

AFAIK the whole idea is to allow to change global scaling factor of X11 (which I believe is root window property, but I might be wrong) on the fly by a compositor (or by Xwayland) whenever it decides to make the change, e.g. an event triggered when a window on a screen with different scaling factor is focused. That's not enough because windows would resize unnecessarily, so the compositor would also be responsible for rescaling too big windows down. That would be almost good, but I'm not sure about fractional scales.

GNOME now does more-or-less that, but only when changing the "primary display" - which is fine for simple use-cases, but still problematic otherwise.

Interesting idea I read about is sandboxing X11 apps each in separate Xwayland instance. It works more or less like that in Qubes OS where apps are running in separate VMs. That would bring some security pros, but also make it difficult to support stuff like dnd/clipboard i suppose. If that's possible to implement such solution in a reliable manner anyway.

[Myownfriend]

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..

Oh yea, I was aware of the PRs over the last few years lol Sorry, I came off a little harsh. It just feels pretty common in this community, and I guess in the larger Linux community, for people to shame people for not getting stuff done sooner. I don't think I would have thought that if you said something more like "I was really hoping they'd get HiDPI done by this release."

But yea, I agree with what you're saying. There's a lot of people who try out Wayland, see apps that are blurry, and complain because don't know that they're actually running an X11 app through Xwayland. Probably the only benefit to that is that it becomes really easy to tell if you're running something with it's native Wayland backend or not but that's probably better than people immediately getting disgusted and going back to an X session.

[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!!!

[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.

[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.

[Mario Junior]

My God, I hate Xwayland so much!

[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.

[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.

[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

[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