You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OverlappingOutputGroup calculates in logical coördinates, but at the hardware level outputs need to be using physical coördinates. It doesn't group outputs with dissimilar scales together, but if both outputs have the same scale and are partially overlapping the scanout position of the one that's not top-left will be incorrect.
You can see this behaviour with the following configuration taken from my laptop; the active ingredient is “position: [1919, 0]”. You can see that changing back between 1919 (so the outputs are grouped into a single overlapping group which should share only a single line of pixels) and 1920 (so that the outputs are distinct) results in drastic output changes.
…SOutput.
This is a different behaviour to `gbm-kms`. On `gbm-kms`, when outputs
have an overlapping view of the logical space they are grouped
together so that they share a single *physical* framebuffer.
When the overlap is great (such as a complete clone), this
should result in lower GPU memory usage (as we need only a single
set of framebuffers for all clones) at the cost of tying
the refresh rates of each clone together. (And some bugs, like
#3641).
When the overlap is *not* great, this potential memory saving
goes away (and may indeed result in *higher* GPU memory usage -
if outputs have different sizes, we may now need to have a
bunch of unused pixels, as the FB can only be rectangular).
For Atomic KMS, instead, we give each output its own physical
framebuffer, regardless of whether it overlaps.
Affects (at least)
gbm-kms
andatomic-kms
.OverlappingOutputGroup
calculates in logical coördinates, but at the hardware level outputs need to be using physical coördinates. It doesn't group outputs with dissimilar scales together, but if both outputs have the same scale and are partially overlapping the scanout position of the one that's not top-left will be incorrect.You can see this behaviour with the following configuration taken from my laptop; the active ingredient is “position: [1919, 0]”. You can see that changing back between 1919 (so the outputs are grouped into a single overlapping group which should share only a single line of pixels) and 1920 (so that the outputs are distinct) results in drastic output changes.
The text was updated successfully, but these errors were encountered: