On Tue, 7 May 2013 11:14:08 -0400 Todd Showalter <[email protected]> wrote:
> On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen <[email protected]> wrote: > > > Yeah, like Daniel said, there is no concept of a "return value". > > > > When a client creates a new object, the server can only either agree, > > or disconnect the client with a protocol error. Any other behaviour > > requires specialized handling, and causes a roundtrip, where the client > > must either wait for a reply before continuing, or risk having further > > requests ignored without any obvious way to know what got ignored in > > the end. Both cases are unacceptable. > > Ok. I was assuming that cases where you had fundamental > capability change in the server (ie: input devices appearing or > disappearing) were rare and special enough to warrant a round trip. > > > When a client sends a request, that creates a new protocol object, then > > from the client's point of view, the object is created on that instant, > > before the request has even been submitted to the wire. This allows the > > client to immediately send more requests on that new object, without > > waiting for a roundtrip in between. The same works also in the reverse > > direction, when the server creates protocol objects by sending events. > > > > A major design principle in Wayland is to minimize roundtrips, as it > > leads to better performance and lower overhead. > > Fair enough. We're talking about rare events here, so I wouldn't > have called it essential, but if that's an organizing principle of the > project then so be it. They can be rare, but they can also happen any time. > > It's not about the gamepad capabilities at all. It's just an > > assignment, configured in the server: this input device belongs to > > player N. > > The place where that becomes a problem is with controller > batteries. As an example, I've got a PS3, and my wife uses it to > watch netflix (it's a streaming tv/movie service, for those who > haven't heard of it). It uses the PS3 controller as a remote, to do > things like play/pause. > > It's not uncommon for the battery in the controller to run flat > while she's watching. I've got a second controller, and we typically > charge one while the other is in use, but fairly often the controller > she's using runs flat. When that happens, we have a second charged > controller, but to use it we have to reboot the PS3, because without > rebooting it connects as Player 2, and netflix only listens to Player > 1. As far as I know there's no simple way to tell the gamepad to > reconnect as Player 1, short of rebooting the machine and rerunning > all the controller handshaking. > > When a gamepad goes away and then it reappears or another appears, > it's *probably* the same player. So what I'm thinking is that it > makes more sense to have the wl_gamepad go into a "disconnected" > state, and then reactivate when the next gamepad appears, rather than > creating a new wl_gamepad. > > > If the gamepad later comes back "online", it is like it was hotplugged > > again: a new wl_gamepad object is sent, with the same player id as > > before. > > This would work too. The main thing is dealing well with the > single player case where the player is replacing a gamepad. This > could be because: > > - they wandered out of RF range when they were getting a drink > - they want to play the game with a different gamepad > - the gamepad they were using ran out of power and is now plugged in via usb > - the gamepad they were using ran out of power and is being replaced > with a charged gamepad > - someone tripped over the usb cord and yanked it out and then plugged > it back in Yeah, sure, and that's all just heuristics inside the server. The server needs to make sure the player id becomes what the user wants, even if one wl_gamepad object is deleted and another created. The server will have the same problem even if it was supposed to revive a dead wl_gamepad object, anyway. The problem you described with PS3 should be solvable with the mysterious gamepad configuration GUI I talked about before, somehow. > > Yeah, the main point of the leave event is to say "you don't get any > > more input events from this device, until it comes back", and it also > > implies that the client should forget all temporary state of the > > gamepad, like which buttons were down. > > Yes. > > > Immediately following an enter event, or in the enter event, a new set > > of current state is sent. Notice, that this should not be done by > > sending e.g. fake button-down events. We have a protocol design policy, > > that input events from user actions are never manufactured. > > My temptation would actually be to say that when focus goes to a > new application, we treat buttons that are down as if they were up; > don't send a release when they are lifted. So, if I'm holding down > SELECT when focus enters the client window and then release it, press > it and release it, the client sees the press and the second release, > but not the initial release. It depends. If a gamepad enters with button A down, and then the user presses button B down, is the application supposed to respond to B or A+B? I'm not sure what wl_keyboard does, but it needs at least some keys handled in current state, like shift. wl_pointer OTOH never had this problem, since pressing down a button activates an implicit grab, which means the wl_pointer device can never change focus with buttons down. Well, almost never. > That doesn't work with axis values, but if the client cares about > deltas it's going to have to clear them on focus change anyways, since > it has already been said that the protocol will not be sending deltas. > If we were sending deltas we could make things a little cleaner in > some ways, but it does expand the protocol and I'm not sure it does so > usefully. Right, better send the values as closest to their physical interpretation. Mouse motion is always relative, and a stick axis or a button is always absolute. Absolute valued inputs may all need initial state sent. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
