[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 <ppaalanen at gmail.com
> <mailto:ppaalanen at gmail.com>> 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...