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

Work around touch up events delivered too late with certain Weston versions #444

Conversation

tronical
Copy link
Contributor

Weston <= 10 at least has a bug where the frame event isn't always sent when the last touch point was released.

This is tracked in
https://gitlab.freedesktop.org/wayland/weston/-/issues/44 and it would seem that
https://gitlab.freedesktop.org/wayland/weston/-/commit/5448580111b5ff992ce2603cb6e99b9f54db7ad8 may fix it.

Meanwhile, work around the issue by processing all buffered events when there are no more active touch points.

…rsions

Weston <= 10 at least has a bug where the frame event isn't always sent
when the last touch point was released.

This is tracked in
https://gitlab.freedesktop.org/wayland/weston/-/issues/44 and it would
seem that
https://gitlab.freedesktop.org/wayland/weston/-/commit/5448580111b5ff992ce2603cb6e99b9f54db7ad8
may fix it.

Meanwhile, work around the issue by processing all buffered events when
there are no more active touch points.
@tronical
Copy link
Contributor Author

Related downstream issue on our side that triggered this: slint-ui/slint#4551

@kchibisov
Copy link
Member

kchibisov commented Feb 28, 2024

No, adding workarounds for protocol violation is not how it should be done, I'd suggest to fix weston instead, if someone relies on it. The protocol mandates the processing on the frame event, no frame event means that the event was likely canceled (though cancel could be send as well), which could introduce bugs along the way.

@tronical
Copy link
Contributor Author

tronical commented Feb 28, 2024

The problem is that upgrading Weston is not always an option on embedded systems :( - especially when they're based on older Yocto or Debian versions.

I also wouldn't mind applying this workaround on a different level, but I don't know if that's possible.

Also worth nothing that Qt worked around this the same way (and still ships that code).

@kchibisov
Copy link
Member

I also wouldn't mind applying this workaround on a different level, but I don't know if that's possible.

I'm not sure it's because it breaks core protocol. Though, the only thing that could be broken is the cancel event, but cancel event implies that all the touch points are lifted, thus probably it won't really break anything when this workaround will be applied.

So maybe it's fine, but I'll leave it up to @wash2 .

@wash2
Copy link
Member

wash2 commented Feb 28, 2024

I think this is unlikely to break anything, so it's an ok workaround.

@kchibisov
Copy link
Member

Well, yeah, the only area where it can break, is wl_touch::cancel, but it's likely won't break because it's the last point and you need to lift everything anyway.

@wash2 wash2 merged commit 8708dd5 into Smithay:master Mar 1, 2024
4 of 5 checks passed
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.

3 participants