On Thu, 2 May 2013 19:28:41 +0100 Daniel Stone <[email protected]> wrote:
> Hi, > > On 2 May 2013 10:44, Pekka Paalanen <[email protected]> wrote: > > On Tue, 30 Apr 2013 09:14:48 -0400 > > Todd Showalter <[email protected]> wrote: > >> 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. > > There's one crucial difference though, and one that's going to come up > when we address graphics tablets / digitisers too. wl_pointer works > as a single interface because no matter how many mice are present, you > can aggregate them together and come up with a sensible result: they > all move the sprite to one location. wl_touch fudges around this by > essentially asserting that not only will you generally only have one > direct touchscreen, but it provides for multiple touches, so you can > pretend one touch each on multiple screens, are multiple touches on a > single screen. Right. Could we just say that each such non-aggregatable device must be put into a wl_seat that does not already have such a device? Or make that an implementors guideline rather than a hard requirement in the protocol spec. > The gamepad interaction doesn't have this luxury, and neither do > tablets. I don't think splitting them out to separate seats is the > right idea though: what if (incoming stupid hypothetical alert) you > had four people on a single system, each with their own keyboards and > gamepads. Kind of like consoles are today, really. Ideally, you'd > want an association between the keyboards and gamepads, which would be > impossible if every gamepad had one separate wl_seat whose sole job > was to nest it. So... what's wrong in putting each keyboard into the wl_seat where it belongs, along with the gamepad? > I think it'd be better to, instead of wl_seat::get_gamepad returning a > single new_id wl_gamepad, as wl_pointer/etc do it today, have > wl_seat::get_gamepads, which would send one wl_seat::gamepad event > with a new_id wl_gamepad, for every gamepad which was there or > subsequently added. That way we keep the seat association, but can > still deal with every gamepad individually. It would be left for the client to decide which gamepad it wants from which wl_seat, right? Do we want to force all clients to choose every non-aggregatable device this way? Essentially, that would mean that wl_seat are just for the traditional keyboard & mouse (and touchscreen so far) association, and then everything else would be left for each client to assign to different wl_seats on their own. This seems strange. Why do we need a wl_seat then, why not do the same with keyboards and mice? Oh right, focus. You want to be able to control keyboard focus with a pointer. Why is a gamepad focus different? Would all gamepads follow the keyboard focus? If there are several wl_seats with kbd & ptr, which keyboard focus do they follow? What if the same gamepad is left active in more than one wl_seat? What if there is no keyboard or pointer, e.g. you had only a touchscreen and two gamepads (say, IVI)? And then replace every "gamepad" with "digitizer", and all other non-aggregatable input devices, and also all raw input devices via evdev fd passing. The fd passing I believe has similar problems: who gets the events, which wl_seat do they follow. This is a new situation, and so many open questions... I just continued on the exitisting pattern. Cheers, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
