Hi, On 9 May 2013 11:49, Rick Yorgason <r...@firefang.com> wrote: > But now I'm seriously wondering, does the compositor really need *any* > protocol support to handle this case? I think we've been assuming that each > seat will get its own free reign over the desktop, but isn't the compositor > free to *not* do that? And instead to have some seats which only interact > with the focused application?
Yes, the mechanics of how focus is set and transferred are unspecified, thankfully. > We could have one wl_gamepad per wl_seat, just like wl_pointer, wl_keyboard, > or wl_touch, put the player ID in wl_seat instead of wl_gamepad, and give > compositor writers a few suggestions: > > * Not all seats need to have a desktop pointer or the ability to control > their own focus. Seats without wl_pointer already don't have a desktop pointer, and seats don't necessarily control their own focus. What happens when the compositor transfers focus is very well-defined. But nowhere in the protocol does it specify when focus is transferred, because without a view of the full window tree, clients don't have enough context to know what would happen anyway. So this is a moot point. > It can be useful to allow "second class" seats which follow > the focus of another seat, in which case neither the pointer nor any other > event from that seat should be allowed outside of the focused application. That's not the point of a seat right now. But this is totally doable without any compositor changes if you want, and the client doesn't ever need to know about it. > * Each gamepad should automatically be put in a separate seat, either by > putting it in an existing seat without a gamepad, or automatically creating > a new seat. Why put it in a seat, then? If it's not going to go in with a keyboard, mouse or touch device, don't bother with the seats, just keep it as a separate object. The purpose of seats was to aggregate and relate input devices. If all you're doing with wl_seat is using it as a shim to carry one (_exactly_ one) object, why bother? > * If a seat is automatically created for a gamepad, it should ideally be of > the "second class" type by default. Users can always reconfigure their seat > if they want control over the desktop. Again, doesn't require protocol changes. > Wouldn't that allow everything we want? It allows every user to have a full > set of devices, and users don't have to worry about focus issues unless they > want to. It also means the protocol doesn't need the contrivances of > wl_gamepad_manager or seat parenting. I don't see what it brings us, if I'm honest. I guess it all hinges on how the focus model is implemented, and to what extent we want to express that through the protocol. *shrug* Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel