GNOME Bugzilla – Bug 750845
popup windows don't get touch events
Last modified: 2015-11-19 22:47:45 UTC
Lots of touch stuff in the Wayland backend was fixed for 3.14 but one thing that still seems broken are popup windows (or at least comboboxes). This is easy to reproduce by opening a combo box (for example in gtk3-demo) and then trying to choose an item. I can hack around the problem and get things to seemingly work by using an updated version of the patch in bug #731380 but obviously it's not a great approach.
Created attachment 305147 [details] [review] said updated patch
Review of attachment 305147 [details] [review]: ::: gdk/wayland/gdkdevice-wayland.c @@ +1443,3 @@ + _gdk_event_set_pointer_emulated (mevent, TRUE); + _gdk_wayland_display_deliver_event (device->display, mevent); + } Correct me if I'm wrong, but this patch seems to emulate a mouse enter event in order to trick GTK into believing it has focus i.e. so that it can deal with the touch events. This doesn't sound like the right approach to me. It seems more reasonable make GTK properly deal with touch events even when pointer focus is elsewhere instead of occasionally emulating certain pointer events.
(In reply to Jonas Ådahl from comment #2) > Correct me if I'm wrong, but this patch seems to emulate a mouse enter event > in order to trick GTK into believing it has focus i.e. so that it can deal > with the touch events. > > This doesn't sound like the right approach to me. It seems more reasonable > make GTK properly deal with touch events even when pointer focus is > elsewhere instead of occasionally emulating certain pointer events. This is absolutely not the right approach but it got things working for me in the meantime. I hope to have some time to investigate the problem at some point but right now I don't so I opened this bug to keep track, and also in case someone else wanted to have a look.
The patch might not be too off. This problem comes from the difference in behavior between X11 and wayland wrt the "pointer emulating" touch. On X11, the first touch onscreen takes over the master pointer, and that touch has a flag set that gets translated in GDK into gdk_event_set_pointer_emulated(ev,TRUE). In the higher layers GtkGestures do rely on this for "single touch" gestures, so no multiple fingers can trigger single touch gestures in different places. On Wayland, this is emulated somewhat on the first touch the client is aware of. Otherwise, these gestures would stay deaf to any touch (and so would most widgets). But, internally in GDK, some assumptions are done with the pointer position with those "pointer emulating" touches, it ends up trying to look the window the pointer is over, and finds out it's actually not over the window, so the events are ignored. In order to fix this, I'd say we have two paths: - Going further forward in the "pointer emulating" approach, which involves sending fake crossing events, selectively silencing the pointer if there is a pointer emulating touch around, fixing device queries to return coordinates/windows relative to the touch if there's one around, etc... - Admitting "pointer emulating" is not something that can be honored outside of X11, adding an extra "first touch" flag that gestures can listen to, and avoid setting the "pointer emulating" flag on Wayland, so touch-aware paths are used within GDK. I guess #2 is better for the longer term, it won't help much though for widgets that only have pointer events mask/handlers though.
(In reply to Carlos Garnacho from comment #4) > In order to fix this, I'd say we have two paths: > > - Going further forward in the "pointer emulating" approach, which involves > sending fake crossing events, selectively silencing the pointer if there is > a pointer emulating touch around, fixing device queries to return > coordinates/windows relative to the touch if there's one around, etc... > > - Admitting "pointer emulating" is not something that can be honored outside > of X11, adding an extra "first touch" flag that gestures can listen to, and > avoid setting the "pointer emulating" flag on Wayland, so touch-aware paths > are used within GDK. > > I guess #2 is better for the longer term, it won't help much though for > widgets that only have pointer events mask/handlers though. I gave a go to #2, and effectively we can't get too far with it nowadays. Even if GTK+ itself can be made to work reasonably, the vast majority of applications have done nothing wrt the adoption of GDK_TOUCH_MASK or GtkGesture, which causes major regressions on touch all around. I won't dare go that way until the adoption of GtkGesture is wider (or is the canonical way to handle input), so I'm attaching a patch that goes along the lines of the current one. It will enforce crossing events when the user switches between real and emulated pointer events, and only if these lie on different windows. This makes the balance of enter and leave events right on the GDK side. NB, The mutter patches from bug #756296 are also needed so you can trigger the popup through touch, in addition to being able to operate with it afterwards.
Created attachment 312964 [details] [review] wayland: Emulate crossing events when switching between pointer and touch The common GDK code accounts for "pointer emulating" touch sequences to be synchronized with the pointer position by the windowing system. However on Wayland pointer and touch are completely independent, the backend attempts to implement pointer emulation, but doesn't account for the possible crossing events happening when the user switches from pointer to touch or the opposite. This will ensure that window_under_pointer lookups are correct for pointer events emulated out of touch events, and don't end up ignored if the pointer emulating touch sequence and the real pointer lie in different toplevels. Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
Created attachment 315892 [details] [review] wayland: Separate touch pointer emulation into its own master pointer The common GDK code accounts for "pointer emulating" touch sequences to be synchronized with the pointer position by the windowing system. However on Wayland pointer and touch are completely independent, the backend attempts to implement pointer emulation, but doesn't account for the possible crossing events happening when the user switches from pointer to touch or the opposite. In order to fix this, and to ensure we don't have to interact with the master pointer (which backs the wl_pointer), separate the touch interface to have its own master pointer, and ensure crossing events are emitted on it, so the picture of an "emulated pointer" is complete above the backend. Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
This last patch separates the touch interface to have its own master pointer. It feels a lot cleaner, since the interaction with the real pointer is none, deals with it in a way gtk+ is already prepared for, and which feels more consistent with what's really happening here (a separate focus, instead of one borrowed from wl_pointer).
I ended up pushing this last patch, brings things in the right direction at least.