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

[박성진]

>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-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 
> 
> 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 

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

[Peter Hutterer]

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
> 
> > 
> > 

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

[Peter Hutterer]

On Fri, Oct 16, 2015 at 06:58:32PM -0700, Bill Spitzak wrote:
> On Mon, Oct 12, 2015 at 10:01 PM, Peter Hutterer 
> 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).
> 
> 
> Nonsense. A client may very well want to do something different for the X
> key on device 1 than the X key on device 2. It does not need any low-level
> device access to do that, in fact it is not going to send or query anything
> from any device, just receive wayland events.
> 
> This is used to differentiate the tablet pen and eraser and puck and the
> normal mouse. The program does absolutely nothing special, it gets position
> events, but ignores the device, then they all move the cursor and have the
> same effect. But a painting program that figures out which device is the
> eraser will certainly act differently for that one.

what does this example have to do with the original example that you
conveniently dropped?
tablets are different, which is why we have a separate interface for it and
per-device handling. it's not the same as the keyboard.

> > And there are plenty of devices that have
> > meaningless names made from the pid/vid hex codes or even worse - "USB
> > Keyboard".
> >
> 
> Yea that is a problem, but not as big as you think, as long as all clients
> see the same name assignments, and all the devices have a different name.

and the last requirement is not guaranteed. yes, maybe in some ideal setup
you can assume this, but not in the real world where e.g. every gaming mouse
gives you multiple event nodes with the same pid/vid and the same name.
 
> > 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.
> >
> 
> Buttonset interface is not going to solve anything. What if the user has
> two button devices, both with the same button?

I'm glad that you're convinced the buttonset interface isn't going to solve
anything, clearly without having looked at it or being part of the
design/discussion around it. Otherwise you'd know that unlike the
pointer/keyboard/touch interface it's designed as a per-device interface.

*plonk*

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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 
> 
> 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 @@
> 
>  
> 
>
> 
>  
> 
> -  
> 
> +  
> 
>  
> 
>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 @@
> 
>
> 
>  
> 
>  
> 
> +
> 
> +
> 
> +
> 
> +  
> 
> +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.
> 
> +  
> 
> +  
> 
> +
> 
> +
> 
>
> 
>  
> 
> -  
> 
> +  
> 
>  
> 
>The wl_keyboard interface represents one or more keyboards
> 
>associated with a seat.
> 
> @@ -1683,6 +1700,23 @@
> 
> 
> summary="delay in milliseconds since key down until repeating
> starts"/>
> 
>  
> 
> +
> 
> +
> 
> +
> 
> +
> 
> +  
> 
> +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.
> 
> +  
> 
> +  
> 
> +
> 
> +
> 
>
> 
>  
> 
>
> 
> --
> 
> 1.9.1
> 
>  
> 
>  
> 


> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> 

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

[Daniel Stone]

Hi,

On 29 September 2015 at 19:07, Bill Spitzak  wrote:
> On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman 
> wrote:
>> I'm not sure I follow - are you saying we need a "special buttons" focus
>> for multimedia keys?  (backlight keys?  do we need a backlight focus
>> too, or?)
>
> I thought the assumption was that if a key does a global action, it is the
> compositor's job to know that key is special and either do the action
> itself, or deliver an event to a particular client. That does sound like a
> possible different focus for every assignable key. So yes, that is what I am
> saying.
>
> I see no reason why this same mechanism cannot be used to deliver buttons
> from the remote to correct clients. There is no need for a different "seat".
> I was also proposing that the seat already has two focus and it seems like
> reusing the pointer focus as the remote focus would solve the proposed
> problem.

There's only one focus; grabs temporarily change this focus, or routes
event delivery other than what the focus would imply.

> Abusing the seat mechanism this way is not a good idea. The client wants to
> know what input devices are grouped together. Imagine if shift on the
> keyboard could modify one or the remove buttons. If the remote is it's own
> seat then the client has no way to know which seat's modifiers should
> actually have an effect on the remote, as the seats are how they are grouped
> together.
>
> It sounded to me like the original problem, as stated, requires exactly two
> foci. One for the keyboard and one for the remote. I suggested reusing the
> pointer focus for the remote focus, rather than adding another type of
> focus, or some hack with an extra seat, to Wayland.

So they would be separate wl_keyboard objects, or ... ? This wouldn't
help anything, because then _someone_ still has to merge the modifier
state from two disparate wl_keyboard interfaces.

>> If you run, say:
>> WAYLAND_DEBUG=1 weston-terminal
>>
>> you can quite readily confirm that the window with pointer focus is
>> given modifier state from the keyboard in the same seat.
>
> It looks like wl_keyboard::modifiers events are sent to both the keyboard
> and mouse focus. That is not clear from the protocol documentation. It is a
> little annoying that a client has to create a wl_keyboard object to get
> these, though.

wl_keyboard::modifiers is meaningless without the keymap, so it makes
sense that you need to get the wl_keyboard.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Bill Spitzak]

On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman 
wrote:


> I'm not sure I follow - are you saying we need a "special buttons" focus
> for multimedia keys?  (backlight keys?  do we need a backlight focus
> too, or?)
>

I thought the assumption was that if a key does a global action, it is the
compositor's job to know that key is special and either do the action
itself, or deliver an event to a particular client. That does sound like a
possible different focus for every assignable key. So yes, that is what I
am saying.

I see no reason why this same mechanism cannot be used to deliver buttons
from the remote to correct clients. There is no need for a different
"seat". I was also proposing that the seat already has two focus and it
seems like reusing the pointer focus as the remote focus would solve the
proposed problem.

Abusing the seat mechanism this way is not a good idea. The client wants to
know what input devices are grouped together. Imagine if shift on the
keyboard could modify one or the remove buttons. If the remote is it's own
seat then the client has no way to know which seat's modifiers should
actually have an effect on the remote, as the seats are how they are
grouped together.

It sounded to me like the original problem, as stated, requires exactly two
foci. One for the keyboard and one for the remote. I suggested reusing the
pointer focus for the remote focus, rather than adding another type of
focus, or some hack with an extra seat, to Wayland.

If you run, say:
> WAYLAND_DEBUG=1 weston-terminal
>
> you can quite readily confirm that the window with pointer focus is
> given modifier state from the keyboard in the same seat.
>

It looks like wl_keyboard::modifiers events are sent to both the keyboard
and mouse focus. That is not clear from the protocol documentation. It is a
little annoying that a client has to create a wl_keyboard object to get
these, though.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Derek Foreman]

On 28/09/15 11:58 AM, Bill Spitzak wrote:
> 
> 
> On Mon, Sep 28, 2015 at 12:37 AM, Pekka Paalanen  > wrote:
> 
> wl_seat are not meant to model possible targets, they are collection of
> foci related to aggregates of input devices. If the compositor needs to
> re-route a certain key to something else than the current wl_keyboard
> focus, it is fairly easy to temporarily switch the focus.
> 
> 
> Exactly! Therefore if a new type of foci is needed, it needs to be added
> to the seat! Not saying you need a new seat. If that was true, why not
> just make the pointer and keyboard focus two different seats???

I'm not sure I follow - are you saying we need a "special buttons" focus
for multimedia keys?  (backlight keys?  do we need a backlight focus
too, or?)

> > I am not clear on how the client with the pointer focus can figure out 
> what
> > modifiers are down however. But if the remote has modifiers I think 
> users
> > expect them to act global, ie holding the Shift on the remote is the 
> same
> > as holding Shift on the keyboard.
> 
> This scenario breaks your proposal of abusing the wl_pointer device
> type.
> 
> 
> No, it breaks the CURRENT scheme. If the pointer focus is a different
> client from the keyboard focus, the pointer focus client cannot tell
> what shift keys (or other keys) are held down when the user clicks the
> mouse. Lots of UI designs require this information.
> 
> I am rather alarmed to hear that this is broken right now, I thought for
> sure I was just not finding the method that modifier change events were
> sent to clients other than the keyboard focus...

If you run, say:
WAYLAND_DEBUG=1 weston-terminal

you can quite readily confirm that the window with pointer focus is
given modifier state from the keyboard in the same seat.

This seems pretty reasonable to me, and no cause for alarm...
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Bill Spitzak]

On Mon, Sep 28, 2015 at 12:37 AM, Pekka Paalanen 
wrote:

wl_seat are not meant to model possible targets, they are collection of
> foci related to aggregates of input devices. If the compositor needs to
> re-route a certain key to something else than the current wl_keyboard
> focus, it is fairly easy to temporarily switch the focus.
>

Exactly! Therefore if a new type of foci is needed, it needs to be added to
the seat! Not saying you need a new seat. If that was true, why not just
make the pointer and keyboard focus two different seats???


> > I am not clear on how the client with the pointer focus can figure out
> what
> > modifiers are down however. But if the remote has modifiers I think users
> > expect them to act global, ie holding the Shift on the remote is the same
> > as holding Shift on the keyboard.
>
> This scenario breaks your proposal of abusing the wl_pointer device type.
>

No, it breaks the CURRENT scheme. If the pointer focus is a different
client from the keyboard focus, the pointer focus client cannot tell what
shift keys (or other keys) are held down when the user clicks the mouse.
Lots of UI designs require this information.

I am rather alarmed to hear that this is broken right now, I thought for
sure I was just not finding the method that modifier change events were
sent to clients other than the keyboard focus...
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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 10:06:20 -0700
Bill Spitzak  wrote:

> On Fri, Sep 25, 2015 at 2:14 AM, Pekka Paalanen  wrote:
> 
> You don't need multiple seats.
> 
> The remote control would simply not be a "keyboard". It can send
> wl_pointer::button events for the buttons. Note that they have exactly the
> same format as wl_keyboard::key. There is a reason for this. The clients
> can distinguish between wl_pointer::button and wl_keyboard::key events, and
> the compositor is already set up to deliver these to different clients. So
> it satisfies the stated need.

Your approach is more hacky than multiple seats, and does not scale.
Remote controls are not pointing devices, unless you're talking about
something like a wiimote. Traditional remotes are more close to
keyboards than pointers, if one is forced to choose between these two.

To change pointer focus, you will need to fake pointer motion and match
it to window regions. That's a lot of faking and bending over backwards.
Also, adding a wl_pointer implies you get a pointer cursor on screen.

What happens if you actually want to add a pointer device?

> If your api requires more than these 2 foci then either you add extensions
> to the compositor to support more foci or you use multiple seats. But the
> stated problem needs no more than 2 seats, since you only listed two
> destinations for the events.

Adding extensions for this sounds crazy. As the alternative, you revert
back to the proposal you set out to replace. Nice. Why bother with the
trickery at all then?

wl_seat are not meant to model possible targets, they are collection of
foci related to aggregates of input devices. If the compositor needs to
re-route a certain key to something else than the current wl_keyboard
focus, it is fairly easy to temporarily switch the focus.

> I am not clear on how the client with the pointer focus can figure out what
> modifiers are down however. But if the remote has modifiers I think users
> expect them to act global, ie holding the Shift on the remote is the same
> as holding Shift on the keyboard.

This scenario breaks your proposal of abusing the wl_pointer device type.


Thanks,
pq


pgpG411ZgqUCN.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[박성진]

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 ? : )

 

Thanks and regards,

Sung-Jin Park

 

==

>From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001

From: Sung-Jin Park 

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 @@

 

   

 

-  

+  

 

   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 @@

   

 

 

+

+

+

+  

+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.

+  

+  

+

+

   

 

-  

+  

 

   The wl_keyboard interface represents one or more keyboards

   associated with a seat.

@@ -1683,6 +1700,23 @@

   

 

+

+

+

+

+  

+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.

+  

+  

+

+

   

 

   

--

1.9.1

 

 



0001-Add-name-event-for-wl_pointer-and-wl_keyboard-in-way.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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
__  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


pgpxAAJyndhXj.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel