Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

Daniel Stone <daniel at ...> writes:
> 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?

For the same reason you would put a keyboard in a seat by itself: just
because it's the only device in that seat right now, doesn't mean it will
always be the only device in its seat. Hopefully my last email with the
scenario makes this more clear.

Keep in mind that both the OUYA and PS4 controllers are coming with touch
pads built in. Seats would be a perfect way of grouping the two devices
together.

Also, while we're talking about aggregation, earlier in the thread we were
assuming that it never makes sense to aggregate controllers, but now I think
it's safer to say that it *rarely* makes sense to aggregate controllers.

Consider a scenario where a user has a really nice wireless controller, but
they also have a crappy controller that's plugged directly into their
computer which they only use when they run out of batteries. This is
advanced user territory, but it's conceivable to think that the user would
want to permanently assign both gamepads to the same seat.

The only tricky part about aggregating gamepads is dealing with the axes,
but all you really have to do is add each axis component together and ensure
that the component doesn't go beyond the max size.

-Rick-