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

[Pekka Paalanen]

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 ?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190912/9849f981/attachment.sig>