[PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

[Pekka Paalanen]

On Fri, 25 Sep 2015 16:14:25 +0900
______ <sj76.park at samsung.com> wrote:

> Dear all,
> 
> Let me share a patch for extending wayland protocol for helping a wayland
> client to identify which events are coming from which physical
> keyboard/pointer device.
> 
> I__d like to discuss with you guys about this patch. : )
> 
> In this patch, I added __name__ event both for wl_pointer and for
> wl_keyboard.

Hi,

this just does not work, because a wl_pointer and wl_keyboard are
abstract devices, and can be backed by several physical or virtual
(nested compositors) input devices.

Naming wl_seats would give you the equivalent. There is already
a wl_seat.name event. Adding name events to wl_pointer and wl_keyboard
does not provide any new information.

> Under wayland protocol applied this patch, a wayland compositor will send
> the name event when a wayland client add a listener for wl_pointer or
> wl_keyboard.
> 
> Then, the client can store the name of the keyboard or pointer and will use
> it when it is required.
> 
>  
> 
> Usually in desktop environment, we don__t need to care the source device
> name of events.

Yes, clients must not care about what physical devices are backing a
wl_pointer or a wl_keyboard. Each can be backed by several devices, and
there is no way to tell which device caused which event.

> In vehicle, mobile and TV environment, there will be many input devices and
> will be many special requirements for them.
> 
>  
> 
> For instance, in TV, __1__ key in an usual keyboard will be used as a
> character __1__ and will be sent to the focus surface/window.
> 
> By the way __1__ key in remote control for TV will be used as a action key
> and will be sent to channel managing process which doesn__t have any focus
> surface/window.

I think you can solve all this without extending the protocol.

First, put the keyboard device and the remote control device behind
different wl_seat globals. (This means that the compositor will
advertise two wl_seat globals with wl_registry.global events.)

Then, for the wl_seat matching the keyboard device, you can use a
normal keymap. For the other wl_seat, the wl_keyboard would use a
different keymap that describes the remote control. This way, clients
will get a different keysym whether the user presses '1' on the keyboard
or the remote control.

As for controlling the input focus for key events, using separate
wl_seats offers more flexibility: your compositor can choose to keep
the remote control's wl_seat always focused to your channel manager
client. This would cause all events from the remote control to always
go the channel manager and never to anything else.

These combined with the wl_seat name, you have several ways to
differentiate between the physical input devices:
- by wl_seat name
- by keysym
- by wl_keyboard focus

Which one(s) you should pick depends on your use case.

All the methods rely on putting the different physical devices on
different wl_seat globals.

Would this be sufficient for you?


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: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150925/e79ff7f5/attachment-0001.sig>