On Tue, 30 Apr 2013 09:14:48 -0400 Todd Showalter <[email protected]> wrote:
> On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen <[email protected]> > wrote: > > > you've provided lots of valuable information already. Unfortunately > > my input is left as hand-waving, since I cannot dedicate to > > designing this protocol myself (as in writing the XML spec). > > I'm getting set up to write code. Someone kindly gave me a bash > script to pull down all the components, so once I get things set up > properly I'll see if I can get a patch together. Excellent! > >> That's not necessarily how games are designed, though; I know > >> that with our engine, input is represented internally as an array > >> of gamepads. It lets us do things like feed a pad with a stack of > >> pad values to do things like demos and "replays". > > > > Alright. The remaining reasons are still significant, IMHO: this is > > the design pattern for Wayland input devices and even in general, > > and the protocol needs to move less bytes when the pad_index is > > effectively baked into the object id on the wire. > > The question is, is a gamepad an object, or is a *set* of gamepads > an object? Both, just like a wl_pointer can be one or more physical mice. Whether a wl_pointer is backed by several mice, the clients have no way to know, or separate events by the physical device. The interfaces are abstract in that sense. > >> This is I think where there's a potential problem. Gamepads > >> live in a somewhat more chaotic world than mice and keyboards; > >> wireless ones have much shorter battery lives, and players are > >> used to being able to unplug and plug them while playing. It's > >> not uncommon for someone to (say) play for a bit with a gamepad > >> they don't like (maybe it was on sale), unplug it, and plug in one > >> they like better. Or drop the gamepad that ran out of batteries > >> in the charger and pull out another. > >> > >> Players also expect to be able to add a gamepad part way > >> through a game, at least for some games. > >> > >> So, gamepads can appear and disappear during the game's > >> runtime, and the game needs to know that is happening. There also > >> need to be some heuristics about which gamepad is what player (or > >> seat). > > > > So you would rather handle all that in your game, than rely on the > > display server to sort it out for you? The user would have to set up > > each game, instead of just the display server. The display server > > could also drive the player id indicators on some game controllers. > > I'd rather the display server sorted it out, honestly, I just > wasn't sure how much policy people were comfortable with pushing into > the display server. I think we can put lots of policy in the server. A Wayland server is not just a generic display server like X, but is actually tied to the GUI paradigms, shell, and the desktop environment. In principle, every DE will have its own server, and code re-use is punted as an implementation detail. We prefer to communicate intent (set_fullscreen) rather than primitive actions (set window size && position it to 0,0 && raise). For example, a window manager with all its policies is just a component inside a Wayland server. It's also intended to be user configurable, like a modern DE. > > I can easily imagine a game controller configuration GUI for a > > display server, where you can register game controllers and assign > > them to different seats, just like you would do for keyboards and > > mice. > > I'd prefer something like that. On the console side of things, > this is a problem that actually usually gets thrown to the game to > solve, and it's always a hassle. Alright, cool. > >> I think all gamepad input should be routed to whatever has > >> focus or whatever has grabbed input. I don't see a scenario where > >> it makes sense to route different gamepads separately unless > >> you're doing multiuser multihead (which I assume is the point of > >> the wl_seat abstraction). > > > > A wl_seat does not relate to any specific output. Each wl_seat on a > > server simply shares all outputs with all other wl_seats. > > > > If you want to do separate sessions, that is each user has his own > > desktop, own input devices, and own outputs, then you pretty much > > run one display server for each user. > > > > wl_seats OTOH allow one to have several people collaborating on the > > same session and desktop, or just one person who needs more than one > > keyboard focus, for instance. This is one display server with > > several wl_seats. > > > > wl_seat is not really a seat in the physical sense. It may be better > > thought via input devices and input foci. One wl_seat has zero or > > one wl_keyboard, wl_pointer, etc. If you have several physical > > keyboards, they all act as one. To have two keyboards independent, > > they are assinged to different wl_seats. Then each keyboard can be > > typing into a different window at the same time. > > > > Focus is per wl_seat, and mostly per input device type. Keyboard and > > pointer have their own foci, wl_touch does not have a focus at all > > in the protocol. > > > > So for games with multiple local players on the same screen, wl_seat > > would be just a player id. > > > > Does this clarify what I was talking about? > > Ok, that makes sense. So, from the game point of view, if each > gamepad lives in its own wl_seat, how does the game detect that new > gamepads have arrived or gone away? I assume there are wl_seat > create/destroy events? wl_seats are global objects in the protocol, and yes, we have events for globals to come and go dynamically. The events are in the wl_registry interface. If just a gamepad goes away and later comes back, the wl_seat could even stay around in between. There can also be seats without a gamepad, so it is still the game's responsibility to decide which wl_seats it takes as players. Which reminds me: maybe we should add a name string event to wl_seat interface? This way a game, if need be, can list the seats by name given by the user, and the user can then pick which ones are actual players. (It is a standard procedure to send initial state of an object right after binding/creating it.) I imagine it might be useful for other apps, too. Unless it's enough to just pick the wl_seats that have a gamepad? Hmm, is this actually any better than just handing all gamepads individually without any wl_seats, and let the game sort sort them out? How far can we assume that a wl_seat == a player, for *every* existing wl_seat? And which player is which wl_seat? Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
