[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 <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 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150928/372afee3/attachment.html>