On 2013-05-20 23:56, Peter Hutterer wrote:
what I am wondering is whether that difference matters to the outside
observer (i.e. the compositor). a gamepad and a joystick are both gaming
devices and with the exception of the odd need to control the pointer it
doesn't matter much which type they ar
Hi Bill,
In reply to everything below, I don't think there's anything in any of
the proposals that prevents compositors from implementing pointer
emulation for gamepads, or from suspending that emulation when a game
has the gamepad's focus.
-Rick-
On 2013-05-14 15:08, Bill Spitzak wrote:
I
On 2013-05-14 11:18, Daniel Stone wrote:
1) Some compositors may put every gamepad in one seat, and some compositors
may assign one gamepad per seat. The game programmer has to support both
code paths. And unfortunately, when game programmers inevitably neglect to
do that, the gamers are going to
Daniel Stone writes:
> I know I've had some trouble expressing my problems with the
> every-gamepad-in-a-seat proposal, but this pretty much hits the nail
> on the head. How does the gamepad's focus get assigned (and change)
> if it's in its own seat? Does it always follow the focus of another
>
Daniel Stone 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
>
Pekka Paalanen writes:
> Also, allowing multiple gamepads in one seat does not exclude the seat
> approach. A server could still assign every gamepad to a different
> seat, provided it had some way to solve the focus assignment.
Unfortunately, that comes at the expense of requiring clients to sup
Peter Hutterer writes:
> > >assuming we have two clients C1, C2, and C1 has the gamepad open, what is
> > >the behaviour of the gamepad and the shared pointer:
> >
> > >- when the gp-controlled pointer enters/leaves C1's surface
> > >- when the gp-controlled pointer enters and clicks inside the s
Pekka Paalanen writes:
> From the game's point of view, it will need to iterate over all
> wl_seats. For each seat with the gamepad capability bit set, create a
> wl_gamepad_manager, receive all wl_gamepad objects, and for each
> wl_gamepad receive the player id. Create your surfaces, wait for foc
Martin Minarik writes:
> Most common scenario would be:
> A: joypad 1 on mother seat with keyboard and pointer
> B: joypad 2 on child seat
>
> Let's say:
> - user plugs another keyboard and pointer, udev assigns it
> to B:
> - weston promotes B: to mother seat
> The situation is as follows:
>
Bill Spitzak writes:
> If the gamepad can move the pointer then I think the buttons should go
> to the pointer focus.
I think if the gamepad is emulating a pointer, it should go all the way and
send wl_pointer events.
I believe this is perfectly workable with the proposed design. The
compositor
Rick Yorgason writes:
> In thinking more about this some more, I don't even think these seats need
> to be aggregated. A second-class wl_seat would just mean "This seat is
> intended to be used at the application level rather than the compositor
> level, and it will send ent
Rick Yorgason writes:
> > Having the two controllers paired doesn't solve 3. There are a lot of UI
> > problems with having two pointers running around the screen that share a
> > focus. Let's say they're one of those crazy users that like sloppy-
> > fo
Jason Ekstrand writes:
>> Scenario 2) Two users are using a multi-user display server. Each user
>> has a keyboard, mouse, and gamepad. User 2 has to set up their wl_seat
>> using some
>> configuration window built into the display server, but once that's done
>> each user can jump in and out of a
Pekka Paalanen writes:
> This design allows several gamepads associated with one wl_seat, and
> thus one focus. It also allows gamepads to be assigned to different
> seats, but then we will have more problems on managing the foci, not
> unlike with keyboards. Hopefully there are no protocol design
Pekka Paalanen writes:
> Uh oh, yuk...
>
> I wonder if one would have serious trouble achieving the same on
> Wayland. X is so much more liberal on what one can do wrt. protocol and
> the C API. For instance, in X I believe one can query a lot of stuff
> from the server, in Wayland nothing. In X
Daniel Stone and Pekka Paalanen wrote:
> ...a bunch of stuff about per-player keyboards and wl_seats...
Okay, let's go over some typical situations:
* It's common for controllers to have keyboard and/or headset attachments,
and built-in touch screens are becoming more common. These are clearly
in
Pekka Paalanen writes:
> > > 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 d
Pekka Paalanen writes:
> Yes, I agree.
>
> Even if BP was not a nesting compositor, making the home button
> minimize the active window would usually get you to the BP right under
> it. The task switcher would be more reliable, though, and also allow to
> get back to the game. It is all mostly a
Todd Showalter writes:
> I think all gamepad input should be routed to whatever has focus
> or whatever has grabbed input.
...and then...
> > I don't think we need a separate event for this, just the normal button
> > event is enough. If the display server wants to eat the event, it can
> >
Todd Showalter writes:
> The core of my argument here is that there should be a standard
> gamepad coming through the event system, much like the standard mouse
> does. The standard gamepad would be:
For reference, in the Windows XP days joystick input was done with
DirectInput, which was
20 matches
Mail list logo
