[PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)
박성진
sj76.park at samsung.com
Sun Oct 18 21:17:57 PDT 2015
>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".
Sorry for replying late. :)
Actually, as you mentioned, there are many keyboards which has {bus} Keyboard something like that.
I'm not telling that we need distinguish between a keyboard device (which doesn't have any unique name) and the others.
We need to distinguish between a specific key device and the others,
of course, the key device will have the its exact name which can be used as an identifier.
Then, there are some applications in which separate behavior needs to be done for each of key device.
Even though these kinds of requirements seem to be relatively rare, it'll be wonderful if it exists in protocol.
I'm mentioning from this point of view.
>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.
Right, by adding 'buttonset' into wayland protocol and by assigning a device as a buttonset device, we will be ready to have separate interface between keyboard and buttonset. Will there be any identifier in the buttonset interface?
When it comes to identification between buttonsets, it'll be also needed to identify each of them, if required.
Thanks and regards,
Sung-Jin park
-----Original Message-----
From: wayland-devel [mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of Peter Hutterer
Sent: Tuesday, October 13, 2015 2:01 PM
To: �ڼ���
Cc: wayland-devel at lists.freedesktop.org
Subject: Re: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)
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
More information about the wayland-devel
mailing list