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

Implement wayland side of tearing control #1325

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

PolyMeilex
Copy link
Member

@PolyMeilex PolyMeilex commented Feb 10, 2024

Probably needs some work on DRM side, but this does plumbing for the wayland side.

@Drakulix
Copy link
Member

Wayland side LGTM.

I think all this need for drm is:

The latter should only happen, when a surface with that hint set is fullscreen though. Possibly the DrmCompositor could extract that state from the surface render-elements (might need a new method for RenderElement and apply that automatically, when directly scanning out such a surface on the primary plane. (cc @cmeissl)

@cmeissl
Copy link
Collaborator

cmeissl commented Feb 13, 2024

The latter should only happen, when a surface with that hint set is fullscreen though. Possibly the DrmCompositor could extract that state from the surface render-elements (might need a new method for RenderElement and apply that automatically, when directly scanning out such a surface on the primary plane. (cc @cmeissl)

I see a few different ways to implement that:

  1. Semi-automatically in the DrmCompositor, which like you said requires extending the trait by a function informing us about the preference. I believe we might be able to make the detection a bit more intelligent then basing it off primary plane scan-out. For example it might be ok to tear if only a single surface (that has tearing enabled) on an overlay plane is updated and everything else stays the same. Or a bit simpler and probably good enough, if all elements are directly scanned out and allow tearing.
  2. As a parameter/option of DrmCompositor and allow downstream decide based on whatever
  3. Combination of 1. and 2., maybe some option on DrmCompositor which allows to select Auto, Disabled, Force or something like this.

Option 2. and 3. would allow to expose some global preference, like disabling tearing even if it would be possible.

@YaLTeR
Copy link
Contributor

YaLTeR commented Feb 17, 2024

I agree with @cmeissl; I'd like more manual tearing control in my compositor. So that I can implement the fullscreen with hint => tear policy, but also other policies, like maybe I want to enable it for windowed too under some conditions.

@PolyMeilex
Copy link
Member Author

I agree with @cmeissl; I'd like more manual tearing control in my compositor. So that I can implement the fullscreen with hint => tear policy, but also other policies, like maybe I want to enable it for windowed too under some conditions.

For now I'm working on a simplest possible setup, you either queue a frame as VSync or ASync, you can see it or even test it here
My kernel does not support Atomic async page flips yet, so I have not yet tested that code path, but legacy one with SMITHAY_USE_LEGACY env variable works already on my system.

@PolyMeilex PolyMeilex force-pushed the wp-tearing-control-v1 branch 2 times, most recently from 4be1312 to 8d5dc76 Compare April 19, 2024 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants