[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 <spitzak at gmail.com> wrote:
> On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman <derekf at osg.samsung.com>
> 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