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

Bill Spitzak spitzak at gmail.com
Tue Sep 29 11:07:27 PDT 2015


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150929/495d93b8/attachment-0001.html>


More information about the wayland-devel mailing list