Touch input behavior on overlapping ivi surfaces

[Pekka Paalanen]

On Wed, 25 May 2016 11:13:09 +0530
Vikas Patil <vikasmpatil at gmail.com> wrote:

> On Tue, May 24, 2016 at 6:44 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Tue, 24 May 2016 18:29:52 +0530
> > Vikas Patil <vikasmpatil at gmail.com> wrote:
> >  
> >> Dear All,
> >>
> >> Here (attached here the image ) the touch input is not going to surface 1
> >> even after touching any of the two buttons on surface 1.  Instead touch
> >> event goes to surface 2. Also if I touch anywhere in the area marked green
> >> also goes to surface 2 even it being the part of surface 1. Touching on the
> >> rest of the light blue area delivers touch correctly to surface 1.
> >>
> >> Both the surfaces are on one layer only (e.g. layer id 1000)
> >>
> >> Any one here faced such issue? What could be going wrong here? Any
> >> suggestions/ideas?
> >>
> >> Also try the limiting the input acceptance area using wayland region. But
> >> it didn't work.
> >>
> >>             input_region = wl_compositor_create_region(wlCompositor);
> >>
> >>             wl_region_add(input_region, 728, 5, 72, 144);
> >>
> >>             wl_surface_set_input_region(surface, input_region);  
> >
> > Mind, you need a wl_surface_commit() before that applies. And then,
> > maybe something else overwrites it immediately after your hack, sending
> > another set_input_region request.
> >  
> 
> Do you mean I need to call the wl_surface_commit() immediately after
> wl_surface_set_input_region() even if it is EGL surface and
> somewhere eglSwapBuffers() gets called? If yes then I will test with it.
> 
> What is the usage of wl_surface_commit() with EGL and non EGL surfaces (shm)?

No, I just mean you need to ensure that something calls it. I cannot
know if you guarantee there is a call to eglSwapBuffers() or anything,
since you didn't say. I simply assumed the worst case of nothing
calling wl_surface_commit() afterwards and you wondering why the new
input region is not effective.

But you really have to check the protocol dump to see if anything else
changes the region back to the wrong one.

> >> I am on weston 1.8, wayland-ivi-extension 1.4.0 and qt/qtwayland 5.5.1.  
> >
> > I really have no idea, but I am quite sure it is a surface configuration
> > issue outside of weston core.
> >
> > You could look at the Wayland protocol dump of the client to see how it
> > sets the surfaces up. Input region should be clipped to the surface
> > area in weston core, but maybe the surface has transparent areas and a
> > misplaced input region?
> >
> > Does that setup even let Weston core handle input focus, or is all that
> > hijacked to LayerManager or something?
> >  
> 
> Thanks. I will have a look at wayland dump. There are ILM API (i.e
> ilm_setInputFocus) to set the input focus for specific input device
> for specific surface. However AFAIK it is not required for touch input
> and it is available for all the surfaces while in case of pointer and
> keyboard it need to set using this API for particular surface to
> receive input from it.

Ok, that is enough to say "someone is messing with the focus handling
all over, and upstream Weston developers cannot help you".

> I really need to know what is the default input behavior with weston
> core and ILM (ivi-shell and ilm control) for touch, pointer and
> keyboard.

ILM is not part of Weston upstream, we do not know what it does, so we
cannot tell you.

Ivi-shell with hmi-controller from Weston upstream does not override
Weston core's focus handling, but if you use any other controller
module, it's out of our hands and we can't know. Ivi-layout currently
has no API related to anything input.

Weston core uses the input region, which is clipped to the surface
area, as the key for picking a surface at certain coordinates on
screen. Pointer focus without buttons down is the top-most input region
at the cursor hotspot, the same for the touch focus on first
touch-down. When buttons or touches are down, the focus will remain on
the surface regardless of positions. Keyboard focus seems to update on
button-clicks to the pointer focus, and I believe touch might do the
same for keyboard focus.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160525/ee7c722c/attachment.sig>