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