-
Notifications
You must be signed in to change notification settings - Fork 161
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
fix buffer offset handling #1341
Conversation
bf14019
to
23c9ac9
Compare
@YaLTeR would be nice to get some feedback from you |
@ids1024 @Drakulix @PolyMeilex would love to get some feedback on this topic, maybe we can find some better solution together. |
Test cases:
|
23c9ac9
to
5d529d9
Compare
Number 2 is actually a good example on why and what it is currently broken in smithay. The current implementation offsets all surfaces by the buffer offset, but weston actually modifies the position of the toplevel. Without SSD (which weston does not have) it just looks the same, but it actually does something completely different. The offset should (and this is how it is done in weston) be handled in a role specify way. For pointer it defines that it should decrement the hotspot, dnd defines it as adding it to the current offset, toplevel will be moved, ... I hope this helps to clarify the motivations behind these changes and why it looked like it was working, while it was actually broken. |
5d529d9
to
4ad5199
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## fix/pointer_image_stuck #1341 +/- ##
========================================================
Coverage 20.55% 20.55%
========================================================
Files 158 158
Lines 25868 25934 +66
========================================================
+ Hits 5317 5332 +15
- Misses 20551 20602 +51
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
4ad5199
to
1c95260
Compare
the buffer offset should be handled in a role specific way. adding the offset to the surface view to offset the surface is wrong.
1c95260
to
3ffd9cc
Compare
3ffd9cc
to
2a12100
Compare
Okay, I moved the whole buffer offset handling into anvil. I do not like to have more |
@@ -152,6 +152,22 @@ impl<BackendData: Backend> CompositorHandler for AnvilState<BackendData> { | |||
} | |||
if let Some(window) = self.window_for_surface(&root) { | |||
window.0.on_commit(); | |||
|
|||
if &root == surface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For subsurfaces it is supposed to do nothing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not so easy to answer, it might have been intended to also apply to subsurfaces. But as mutter and wlroots always ignored the offset for subsurface weston has been changed to also ignore it. So imo we should follow that and just accept this as the common behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this seems like a very sane approach, given how role-specific this is.
fixes the regression introduced in #1123 (comment)
(not that is was working correctly before, but pointer was broken at bit less)
what I do not like is all the manual plumbing in the Dnd handling, handling this in smithay will require re-structuring a few things. From the spec of DnD start:
According to this we need the cursor hotspot at the start of the grab to initialize the DnD icon offset. But as the hotspot is stored in the current pointer surface we can no access it in smithay. On commit of the DnD icon we need to be able to change the current DnD offset by the surface offset if any. But again we can not do this internally as we have no access to the icon.
We can probably do better by either:
SeatState
)based on #1340