is there any interface to set key mask (or filter?) of surface ?

[Mark Lee]

Thanks for your advice with insight in the Wayland domain.

I have got your idea,
and something of them already were implemented and released in our
products, for example hotkey filters on the compositor-side.

Thanks,

2019년 9월 12일 (목) 오후 9:13, Pekka Paalanen <ppaalanen at gmail.com>님이 작성:

> On Thu, 15 Aug 2019 00:32:47 +0900
> Mark Lee <ivorycloud1013 at gmail.com> wrote:
>
> > OK. I'll make it simple.
>
> Hi,
>
> thanks. :-)
>
> > system (TV) composes of a graphic compositor based QtWayland and clients
> > used Qt, web, and native framework.
> > a couple of applications can be foreground, and also they can get input
> > events through compositor input handling logic.
> > unlike most system, our product provides RCU (remote control: only
> > keyboard) and MRCU (Magic RCU: keyboard + pointer).
> >
> > generally, there is no trouble about input event propagation considering
> > input region of client and surface z-order at compositor-side.
> > but, why it needs to use key mask is that and what it is use case of it
> is
> > following,
> > *1) key masking between parent and child surface using wl_subsurface*
> >     - (init state) parent has wl_keyboard focus.
> >     - keyboard event happens. (ex. channel number key)
> >     - compositor asks parent accept the key (HOW?), (maybe unaccept it)
> > child surface should get and consume it.
>
> With sub-surfaces, it is all internal to the client. There is no need
> to involve Wayland at all. The compositor delivers the input events to
> the client regardless of which of the client's wl_surfaces has keyboard
> focus. You do per-surface input routing inside the client.
>
> > *2) key masking ? between exporter and importer surface using wl_foreign*
> >     - (init state) parent has wl_keyboard focus.
> >     - keyboard event happens. (ex. arrow key, it can be navigated
> > throughout visible items including exporter and importer surfaces)
> >     - compositor asks parent accept the key (HOW?), (maybe unacceptably
> it)
> > child surface should get wl_keyboard focus and consume the key.
> >     - since next keys, compositor asks client first.
>
> This is an inferior design. Wayland has very specifically avoided a
> design where a compositor would need to do roundtrips to clients. Input
> delivery is sensitive to latency, hence roundtripping to clients to ask
> who wants to handle a key press is a bad idea. Also, you cannot
> realistically route keyboard events like that. Keyboard focus needs to
> be assigned as a whole because the combination and order of pressed
> keys matters, not just the individual key events.
>
> You could probably define a Wayland extension to attach an input event
> mask to a wl_surface so that the compositor knows to route correctly
> without asking on the spot, but I have no idea what that might look
> like for keyboards. You are using RCUs which are just a bunch of
> buttons, not actual keyboards, and for a bunch of buttons it could be
> doable. If you cannot define the input event routing policy in the
> compositor already, you might look into defining such a protocol
> extension for "simple keyboards".
>
> For full-blown keyboards I suspect it would become intractable.
>
> Another direction would be to go with global hotkey bindings, but I
> don't think we have a generally implemented or even accepted protocol
> extension for those. It would suffice if all you need is to have a
> certain button delivered always to the certain client regardless of
> focus.
>
> In general, I would recommend to use one of two options:
>
> - Avoid siblings. This means that you only have a single Wayland
>   client, that does all input routing internally. If it has to have
>   sub-processes, they could be clients to the first client (the first
>   client would act as a nested domain-specific Wayland server).
>
> - Teach the compositor your domain specific input routing rules. This
>   means modifying a compositor to do the routing you need. You probably
>   will need some identification of the windows from the clients, for
>   which you might use xdg_toplevel features or develop your own
>   extension.
>
>
> Thanks,
> pq
>
> >
> > How do you think about it ?
> > In my knowledge,
> > compositor should provides dynamic key masking interface in reference to
> > keymap like keyboard
> > but... it is complicated to use by client dynamically according to
> > situation of application ?
> >
>


-- 
Sincerely, Jinho Lee
Tel) +82 010 7923 8620
ivorycloud1013 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190929/8a47ac03/attachment.html>