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

[Peter Hutterer]

On Fri, Sep 25, 2015 at 04:14:25PM +0900, �ڼ��� 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.
> 
> 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.
> 
> 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.
> 
> In addition to this example, there can be many examples.
> 
> Thus, I share this patch. Any ideas on this ? : )

At least based on this example, I think this is fixing the wrong problem.
knowing which device sends a key is fairly meaningless unless you have
direct access to the devices anyway (which you probably don't, at least not
in the default setups). And there are plenty of devices that have
meaningless names made from the pid/vid hex codes or even worse - "USB
Keyboard".

the source of your problem is IMO that you're treating the remote control
like a keyboard when it isn't one. This is what we've been trying to solve
with the buttonset interface in libinput (still WIP and needs a wayland
protocol extension). Those devices are merely sets of buttons and require
their own focus control and behaviour, separate to (and more domain-specific
than) keyboards. But it moves the issue into its own separate corner where
it can be handled correctly, rather than papering over the issues.

Cheers,
   Peter

> 
> ==================================================================
> 
> From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001
> 
> From: Sung-Jin Park <sj76.park at samsung.com>
> 
> Date: Fri, 25 Sep 2015 14:01:57 +0900
> 
> Subject: [PATCH] Add name event for wl_pointer and wl_keyboard in wayland
> 
> protocol
> 
>  
> 
> ---
> 
> protocol/wayland.xml | 38 ++++++++++++++++++++++++++++++++++++--
> 
> 1 file changed, 36 insertions(+), 2 deletions(-)
> 
>  
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> 
> index 42c9309..7e98720 100644
> 
> --- a/protocol/wayland.xml
> 
> +++ b/protocol/wayland.xml
> 
> @@ -1402,7 +1402,7 @@
> 
>  
> 
>    </interface>
> 
>  
> 
> -  <interface name="wl_pointer" version="3">
> 
> +  <interface name="wl_pointer" version="4">
> 
>      <description summary="pointer input device">
> 
>        The wl_pointer interface represents one or more input devices,
> 
>        such as mice, which control the pointer location and pointer_focus
> 
> @@ -1569,9 +1569,26 @@
> 
>        </description>
> 
>      </request>
> 
>  
> 
> +    <!-- Version 4 additions -->
> 
> +
> 
> +    <event name="name">
> 
> +      <description summary="unique identifier for each pointer">
> 
> +        This can be used by the client to help identify which pointer
> events
> 
> +        come from which physical pointer device.
> 
> +
> 
> +        In some cases, a specific client application can acts in different
> ways
> 
> +        when it gets pointer events from different pointer devices.
> 
> +        For instance, a series of motion events coming from a mouse
> 
> +        will be used as a cursor mover while the other series of motion
> events coming
> 
> +        from a pointer device which has a special wheel will be used as a
> scroller
> 
> +        of list of items.
> 
> +      </description>
> 
> +      <arg name="name" type="string"/>
> 
> +    </event>
> 
> +
> 
>    </interface>
> 
>  
> 
> -  <interface name="wl_keyboard" version="4">
> 
> +  <interface name="wl_keyboard" version="5">
> 
>      <description summary="keyboard input device">
> 
>        The wl_keyboard interface represents one or more keyboards
> 
>        associated with a seat.
> 
> @@ -1683,6 +1700,23 @@
> 
>        <arg name="delay" type="int"
> 
>             summary="delay in milliseconds since key down until repeating
> starts"/>
> 
>      </event>
> 
> +
> 
> +    <!-- Version 5 additions -->
> 
> +
> 
> +    <event name="name">
> 
> +      <description summary="unique identifier for each keyboard">
> 
> +        This can be used by the client to help identify which key events
> 
> +        come from which physical keyboard device.
> 
> +
> 
> +        In some cases, a specific client application can acts in different
> ways
> 
> +        when it gets an identical key from different keyboard devices.
> 
> +        For instance, in TV like environment, '1' key coming from a
> keyboard
> 
> +        will be used as a character. Meanwhile '1' key coming from a remote
> 
> +        control key device will be used as a channel switching key.
> 
> +      </description>
> 
> +      <arg name="name" type="string"/>
> 
> +    </event>
> 
> +
> 
>    </interface>
> 
>  
> 
>    <interface name="wl_touch" version="3">
> 
> --
> 
> 1.9.1
> 
>  
> 
>  
> 


> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel