[weston1.5]Question about HardKey input monitor with wayland/weston

[Pekka Paalanen]

On Wed, 24 Dec 2014 09:32:42 +0000
Yang Andy <williamyang13 at hotmail.com> wrote:

> Hi everyone
> 
> I have a question about HardKey input monitor with wayland/weston.

"HardKey input monitor" does not seem to be a program or a piece of
hardware that Google knows about. Any pointers to what it is?

> [Use Case]
> When user press specific HardKey on panel,IVI system launch referred application.

Ok.

> So application have to monitor HardKey press.
> 
> [Question]
> Draft software archiecture design as below:
> 
> Application(client)-->Weston(v1.5)-->Kernel Input Subsystem-->HardKey
> 
> 
> Question1:Is Draft software archiecture right?

Yes, at least if HardKey is hardware. Either Weston (the compositor)
itself handles the input event, or you need protocol to relay it to a
client if you want a client to handle it and launch your new app.

> Question2:Is is necessary to modify weston in order to monitor HardKey press?

Yes, or you can write a Weston plugin to do that.

> Question3:How to design application(protocol) to communicate with weston(input)?

That's the hard question. We have had some discussions how a desktop
global hotkey protocol should look like to both work nicely and be
secure (prevent spying input). If you're interested in that, you can
dig the wayland-devel mailing list archives, or if you can't find it,
someone else probably can. This discussion was about any normal app
that just wants to register for a global hotkey.

If you don't need this capability for normal apps, but it would be
enough for your shell helper program to handle it, you can simply
invent whatever protocol you need - just make sure no normal client can
bind the interface. An example in Weston for desktop is the
protocol/desktop-shell.xml extension, which is implemented in
desktop-shell/shell.c and used from clients/desktop-shell.c. If your
goal with the input event is to launch a new app, this is probably the
best option.

However, your context is IVI which is totally not a desktop. I suppose
the controller could define specific ivi-ids somehow with which a
client could bind to the extension interface. This would be similar to
the shell helper program design, except the mechanism to authorize a
client is different.

In all cases, the main idea is to prevent random clients from
eavesdropping input, while still letting the right client(s) get them.
This is always some new protocol extension that is unrelated to
wl_keyboard, wl_pointer, etc.


Thanks,
pq