On Mon, Oct 19, 2015 at 01:17:57PM +0900, 박성진 wrote:
> >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.
yep, the plan is to have identifiers. How exactly they'll look like I don't
know yet, we'll take some hints from the wl_tablet interface though and go
from there.
Cheers,
Peter
> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
> Behalf Of Peter Hutterer
> Sent: Tuesday, October 13, 2015 2:01 PM
> To: �ڼ���
> Cc: wayland-devel@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.p...@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@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
