Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partially overlapping outputs misrendered when scale ≠ 1 #3641

Open
RAOF opened this issue Oct 18, 2024 · 1 comment
Open

Partially overlapping outputs misrendered when scale ≠ 1 #3641

RAOF opened this issue Oct 18, 2024 · 1 comment
Labels

Comments

@RAOF
Copy link
Contributor

RAOF commented Oct 18, 2024

Affects (at least) gbm-kms and atomic-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.

layouts:
  default:                         # the current layout
    cards:
    # a list of cards (currently matched by card-id)

    - card-id: 0
      eDP-1:
        # This output supports the following modes: [email protected]
        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled # {enabled, disabled}, defaults to enabled
        mode: [email protected]    # Defaults to preferred mode
        position: [0, 0]        # Defaults to [0, 0]
        orientation: normal     # {normal, left, right, inverted}, defaults to normal
        scale: 2
        group: 0        # Outputs with the same non-zero value are treated as a single display

      DisplayPort-1:
        # (disconnected)

      DisplayPort-2:
        # (disconnected)

      DisplayPort-3:
        # This output supports the following modes: [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected]
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected], [email protected], [email protected], [email protected],
        # [email protected], [email protected]
        #
        # Uncomment the following to enforce the selected configuration.
        # Or amend as desired.
        #
        state: enabled  # {enabled, disabled}, defaults to enabled
        mode: [email protected]    # Defaults to preferred mode
        position: [1919, 0]        # Defaults to [0, 0]
        orientation: normal     # {normal, left, right, inverted}, defaults to normal
        scale: 2
        group: 0        # Outputs with the same non-zero value are treated as a single display
RAOF added a commit that referenced this issue Oct 18, 2024
…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.
@RAOF
Copy link
Contributor Author

RAOF commented Oct 18, 2024

(This no longer affects the atomic-kms platform)

@Saviq Saviq added the bug label Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants