X.Org Server Adds "AsyncFlipSecondaries" To Deal With Crappy Multi-Monitor Experience

[pal666]

last I tried I still couldn't seemingly get any unredirect to actually work on any wayland compositors; Sway or Plasma

next time try mainstream compositor

[pal666]

Reading comprehension?

lol.

It is written, but it is a description of the previous, SYNC behaviour that this ASYNC implementation was made to fix.

so what is that tradeof it is talking about? tradeof between slow+tearing vs fast+nontearing? in reality description of previous behavior mentions lack of tearing

[pal666]

the "bypass compositor" feature that lets a game get OpenGL/Vulkan direct-to-monitor for performance

nobody needs it for performance, every game has "fullscreen window" display variant which is just as fast but doesn't break popups etc.

[pal666]

Hans Reiser (the creator of reiserfs)

hey, he wasn't linux graphics dev

[ssokolow]

nobody needs it for performance, every game has "fullscreen window" display variant which is just as fast but doesn't break popups etc.

I fail to see how it can be just as fast if it inherently has to go through an extra stage in the compositing pipeline. You can't magically get more cycles from nowhere so, if that's true, it just means that they didn't implement the direct/unredirected rendering mode properly in the first place.

Now, whether it's noticeable is a different story. I don't use Steam, but I can assume the Steam overlay is proof that it can be done efficiently or else why would anyone tolerate it for anything more demanding than a GPU-scaled 2D game?

[theriddick]

Wayland doesn't even have display gamma control. Always makes me laugh....

[sinepgib]

Wayland doesn't even have display gamma control. Always makes me laugh....

Maybe it is a stupid question, but what does that have to do with window management and compositing? Isn't that more a task for display management?

EDIT: also, who is supposed to take care of display management anyway?

[MrCooper]

Nobody cares if Wayland is technically able to do that or not.
The fact is that the end-user cannot set it up with the GNOME or KDE screen manager because there is no such option...

It means it's possible for them to implement support for this at some point. If you care about this, I suggest filing a an issue at https://gitlab.gnome.org/GNOME/mutter/-/issues.

[billyswong]

Maybe it is a stupid question, but what does that have to do with window management and compositing? Isn't that more a task for display management?

EDIT: also, who is supposed to take care of display management anyway?

If "display gamma control" is only for correcting a less-than-ideal monitor to output colors closer to sRGB, then yes, it shouldn't matter to compositing. But when there are all those fancy wide-color-gamut / high-dynamic-range source materials (image / video) and also such monitors in market, all having their own color space, color curve, dynamic range, and "intention" incompatible with each other, it may be unpractical for compositor to dictate a universal master color space for windows / surfaces to upscale to it, then convert them all back to monitor profile. (I heard such wishful thinking has already costed bad performance for video playing in hiDPI monitor in Linux in the past.)

Another example is compositor need to know the refresh rate of each monitor for best experience when high frame rate / VRR monitors are mixed with standard monitors together. In theory, one can push the framebuffer to the speed of common multiple of all monitors, but in practice such high speed is either impossible or too power-hungry in comparison to the other approach.

Who knows if someone want to run the desktop UI in sRGB, then apply a different gamut A to image surface A, different gamut B to video surface B, with them overlapping 2 wide gamut displays, each with a different dynamic range (max brightness)? While Wayland can refuse to implement "display gamma control", just like how they outsource previous responsibilities of X to libinput / pipewire, the void of "display gamma control" is still there, waiting someone step up and fill it in.

[ssokolow]

just like how they outsource previous responsibilities of X to libinput / pipewire

Bad examples.

libinput is a replacement for older, more hardware-specific input drivers that's also used by X.org. Describing it that way would be like saying that ffdshow "replaced" DirectShow with FFMPEG, when it just replaced the older mess of codecs that plugged into DirectShow.

As for pipewire, it's "replacing" having applications talk directly to devices like /dev/video0 so in the purest sense, it's not replacing anything at all... just adding a new routing layer so applications don't need the video input equivalent of "every DOS game comes with its own pack of sound card drivers" to support every possible type of video source on Linux. (eg. You could use the PipeWire equivalent of pavucontrol to feed an application a screen recording or video streaming in over the network when it was only written with the expectation to read from a webcam.)