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

wayland: don't bind to touch events if they are not used #1555

Open
David96 opened this issue May 2, 2020 · 6 comments
Open

wayland: don't bind to touch events if they are not used #1555

David96 opened this issue May 2, 2020 · 6 comments
Labels
C - needs investigation Issue must be confirmed and researched DS - wayland

Comments

@David96
Copy link

David96 commented May 2, 2020

As I understand, this library currently doesn't support touch on wayland but it seems to setup listeners for it anyway. This causes compositors to not be able to determine whether they should emulate mouse events for applications using this library (tested with alacritty).

@kchibisov
Copy link
Member

kchibisov commented May 2, 2020

It implements touch only if it was advertise by your compositor.

if capabilities.contains(wl_seat::Capability::Touch) && self.touch.is_none() {

And, it supports touch as you can see.

@David96
Copy link
Author

David96 commented May 2, 2020

Yes it implements touch, but it doesn't necessarily use it. I'm currently working on swaywm/sway#5229 and if an application sets up touch listeners without actually using them there's no way to fall back to pointer emulation.

The wayland metaissue states it wouldn't support touch that's why I thought it wouldn't at all use those listeners, I was wrong there then. Still, this issue remains.

@emersion
Copy link

emersion commented May 2, 2020

Some winit users (e.g. Alacritty) don't support touch, they ignore touch events. In this case the compositor can't fallback to pointer event simulation, because winit binds to wl_touch (meaning it accepts touch events).

So it would be nice to have a way for winit users to say "I don't support touch". In this case winit could either not bind to wl_touch or either implement pointer event simulation itself.

@kchibisov
Copy link
Member

kchibisov commented May 2, 2020

Hm, I see, I'm not sure what stops alacritty from using touch events here though. It sounds like a reasonable flag to add into winit on the other side.

@David96
Copy link
Author

David96 commented May 2, 2020

I don't think anything stops alacritty from using them. But as long as it doesn't, it would be nice to know on the compositor side, so the compositor can emulate pointer events ;)

@emersion
Copy link

emersion commented May 2, 2020

Yeah. While it shouldn't be too hard for Alacritty to implement touch support, I think other winit users will still be missing touch handlers, so it'd be nice to fix them too. Additionally the same idea could be re-used for tablet input devices when winit adds support for those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs investigation Issue must be confirmed and researched DS - wayland
Development

No branches or pull requests

4 participants