On Fri, 3 May 2013 09:12:20 -0400 Todd Showalter <[email protected]> wrote:
> On Fri, May 3, 2013 at 6:42 AM, Pekka Paalanen <[email protected]> wrote: > > > Sure, the heuristics can cover a lot, but there is still the mad case, > > and also the initial setup (system started with 3 new gamepads hooked > > up), where one may want to configure manually. The GUI is just my > > reminder, that sometimes it is necessary to configure manually, and > > there must be some way to do it when wanted. > > > > Even if it's just "press the home button in one gamepad at a time, to > > assing players 1 to N." > > If there's going to be a gamepad setup gui, my preference would be > for it to be a system thing rather than a game thing. Partly because > I'm lazy/cheap and don't want to have to do themed versions of it for > every game I do, but also partly because otherwise it's something else > that someone can half-ass or get wrong. > > > Well, yes. But the question was not whether we should have heuristics > > or a GUI. The question is, do we want the heuristics *and* the GUI in > > the server or the games? The GUI is a fallback, indeed, for those who > > want it, and so is also the wl_seat-player mapping setup in a game. > > > > If we do the heuristics in the server, there is very little we have to > > do in the protocol for it. Maybe just allow to have human-readable > > names for wl_seats. The "press home button to assign players" would be > > easy to implement. The drawback is that the server's player 1 might not > > be the game's player 1, so we need some thought to make them match. > > > > If we do the heuristics in the games, we have to think about what > > meta data of the gamepads we need to transmit. You said something about > > a hash of some things before. If we have just a single hash, we cannot > > implement the heuristics you described above, so it will need some > > thought. Also, if we want to drive things like player id lights in > > gamepads, that needs to be considered in the protocol. > > > > Maybe there could be some scheme, where we would not need to have the > > wl_seat<->player mapping configurable in games after all, if one goes > > with server side heuristics. There are also the things Daniel wrote > > about, which link directly to what we can do. > > I vote do it on the server, however it winds up being done. It > means the client is isolated from a whole bunch of things it would > otherwise need to explicitly support, and it means that things happen > consistently between games. It also means that any bugs in the > process will be addressable without shipping a new build of the game. Cool, I agree with that. :-) Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
