Initial wl_touch support
#217
Conversation
ids1024
force-pushed
the
wl-touch_jammy
branch
from
5a13aa0 to
3fcadb0
Compare
There was a problem hiding this comment.
The Smithay APIs for touch events could probably be improved a bit.
Really? 🤣 /s
While this is a good starting point, there is no good way to implement touch grabs right now. So this is really not usable for tablet-like devices, just kinda usable for laptops with touchscreens, I guess.
So I am not sure, if we want to merge this in the meantime or first rework the smithay api to be more like the Pointer and Keyboard apis.
src/input/mod.rs
Outdated
| if let Some((target, pos)) = under { | ||
| if let Some(wl_surface) = target.wl_surface() { | ||
| let serial = SERIAL_COUNTER.next_serial(); | ||
| let mut touch = seat.get_touch().unwrap(); |
There was a problem hiding this comment.
We should check here, if the client has actually bound wl_touch and do pointer emulation otherwise.
There was a problem hiding this comment.
Do any other compositors emulate wl_pointer for touch events like that? Or is it generally assumed clients are responsible for that? That should be safe to do though, for any clients that don't.
There was a problem hiding this comment.
Honestly I am not sure. I never looked into this a lot, but at least Xwayland will never bind wl_touch, so we need to do emulation for some clients anyway or there is no way to interact with them.
There was a problem hiding this comment.
I haven't tested it, but https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-input.c does call wl_seat_get_touch and have other wl_touch related code.
So I'm not sure how touch works in X11, but checking if the client binds wl_touch shouldn't change anything.
There was a problem hiding this comment.
Oh interesting! That is new to me, but pretty cool.
There was a problem hiding this comment.
Presumably it needs wl_touch to generate the multi-touch events specified in Xinput 2.2: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/specs/XI2proto.txt.
That protocol also has a section titled "Pointer emulation from multitouch events". Presumably that's handled in XWayland and doesn't require anything from us.
Yeah, as is this works well enough on a laptop with a touch screen (maybe with some issues in edge cases) but wouldn't actually be usable on a tablet unless SSDs and other in-compositor UI handles touch events, an on screen keyboard is added, etc. It may be reasonable to merge this once the major hacks here (using |
ids1024
force-pushed
the
wl-touch_jammy
branch
from
3fcadb0 to
26f6d7e
Compare
`builtin_output` is similar to `get_builtin_output_name` in Sway. For full support, we need support for touch targets/grabs, touch support for SSDs, and a way to configure what output is mapped to what input. But this is usable for apps that support touch on a laptop with a touchscreen.
ids1024
force-pushed
the
wl-touch_jammy
branch
from
26f6d7e to
a52a602
Compare
|
I've added a check for the "builtin monitor" similar to the default used in Sway. This seems to be working fine with external monitors and fractional scaling. So I think it's good enough for initial touch support. |
|
I wonder if we could make the mapped display a property of our input-config at least? So that users could override it and we just take the builtin display as a default? |
|
added a |
A very rough implementation, that is sufficient to get a touchscreen device working.
I'm not sure how we should detect which output is associated with a touchscreen device.
The Smithay APIs for touch events could probably be improved a bit.