[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 <spitzak at gmail.com> wrote:

> On Fri, Sep 25, 2015 at 2:14 AM, Pekka Paalanen <ppaalanen at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150928/3e204b1b/attachment.sig>