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
Rick Yorgason wrote:
When you have multiplayer games, you just want to be able to launch the game
and have everybody automatically in it. You don't want your extra players to
have to think about focusing the app or anything like that.
That's the crux of the problem: how do you have one focus fo
On Tue, May 14, 2013 at 10:18 AM, Daniel Stone wrote:
> Hi,
>
> On 14 May 2013 05:49, Rick Yorgason wrote:
> > Okay, so the most common configuration would be one seat with a mouse,
> > keyboard, and gamepad. If you only ever play single player games, this is
> > all you would see.
> >
> > When
Hi,
On 14 May 2013 05:49, Rick Yorgason wrote:
> Okay, so the most common configuration would be one seat with a mouse,
> keyboard, and gamepad. If you only ever play single player games, this is
> all you would see.
>
> When you have multiplayer games, you just want to be able to launch the game
(Still digesting the rest of the thread.)
On 14 May 2013 08:11, Peter Hutterer wrote:
> the other thing that made me thing about your approach:
> with the gamepad_manager, you've got an extra layer in the tree for gamepads
> that pointers/keyboards don't have. that's not a bad thing and focus
> h
On Mon, May 13, 2013 at 09:14:25AM +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer wrote:
>
> > On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
> > > On Thu, 9 May 2013 16:44:09 +1000
> > > Peter Hutterer wrote:
> > >
> > > > On Mon, May 06, 20
On Tue, 14 May 2013 04:49:39 + (UTC)
Rick Yorgason wrote:
> 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)
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
>
Hi,
On 13 May 2013 14:43, Todd Showalter wrote:
> On Mon, May 13, 2013 at 2:33 AM, David Herrmann wrote:
>> That is why the kernel provides "PHYS" and "UNIQ" fields for every
>> input device (they might be empty if not implemented, but at least
>> they're supposed to be there..). "PHYS" provides
Hi,
On 13 May 2013 07:14, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer wrote:
>> > Those were exactly my thoughts in the beginning, however during the way
>> > long email thread, I got convinced otherwise for now. There are a few
>> > issues that come mind:
>> > -
On Mon, May 13, 2013 at 2:33 AM, David Herrmann wrote:
> That is why the kernel provides "PHYS" and "UNIQ" fields for every
> input device (they might be empty if not implemented, but at least
> they're supposed to be there..). "PHYS" provides the physical location
> for the device. "UNIQ" provid
Hi
On Mon, May 13, 2013 at 8:14 AM, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer wrote:
>
>> On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
>> > On Thu, 9 May 2013 16:44:09 +1000
>> > Peter Hutterer wrote:
>> >
>> > > On Mon, May 06, 2013 at 03:36
On Mon, 13 May 2013 09:12:03 +1000
Peter Hutterer wrote:
> On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
> > On Thu, 9 May 2013 16:44:09 +1000
> > Peter Hutterer wrote:
> >
> > > On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
> > > [...]
> > > > I had a privat
On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
> On Thu, 9 May 2013 16:44:09 +1000
> Peter Hutterer wrote:
>
> > On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
> > [...]
> > > I had a private chat with Daniel, and we came to an understanding,
> > > which I try to
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
Hi,
On 9 May 2013 11:49, Rick Yorgason wrote:
> But now I'm seriously wondering, does the compositor really need *any*
> protocol support to handle this case? I think we've been assuming that each
> seat will get its own free reign over the desktop, but isn't the compositor
> free to *not* do tha
On Thu, 9 May 2013 10:49:03 + (UTC)
Rick Yorgason wrote:
> 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
On Thu, 9 May 2013 16:44:09 +1000
Peter Hutterer wrote:
> On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
> [...]
> > I had a private chat with Daniel, and we came to an understanding,
> > which I try to describe below. The interface names below are more like
> > placeholders for
On Thu, May 9, 2013 at 5:49 AM, Rick Yorgason wrote:
> 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_
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
On Wed, May 08, 2013 at 11:46:43AM +, Rick Yorgason wrote:
> 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 u
On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
[...]
> I had a private chat with Daniel, and we came to an understanding,
> which I try to describe below. The interface names below are more like
> placeholders for now.
>
> Into wl_seat, we should add a capability bit for gamepad.
On Tue, May 07, 2013 at 11:14:08AM -0400, Todd Showalter wrote:
> On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen 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
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 wrote:
Currently it would make perfect sense for wl_gamepad to use wl_keyboard's
focus except... what do you do if there is no keyboard? This would have been
an easier problem to solve if we could just say that wl_keyboard and
wl_gamepad both use wl_seat's focus.
If the gamepad c
I like the second-class seat proposal. got the roughly
same idea
called it a focus inherit seat.
It's kind of a child seat that is, for some reason, not
capable
to change it's own focus, instead it follows the mother
seat focus.
Nice thing is, the seat id = player id, making the player
id redun
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 enter/leave events to the
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-
> > focus. What happens when the two cursors ar
Todd Showalter wrote:
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
On Tue, 7 May 2013 14:04:14 -0400
Todd Showalter wrote:
> On Tue, May 7, 2013 at 1:02 PM, Pekka Paalanen wrote:
>
> >> 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
Hi,
On 7 May 2013 16:14, Todd Showalter wrote:
> On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen 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
On Tue, May 7, 2013 at 1:02 PM, Pekka Paalanen wrote:
>> 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
On Tue, 7 May 2013 11:14:08 -0400
Todd Showalter wrote:
> On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen 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
On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen 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,
Hi Todd,
Daniel nicely replied to the most important comments, here are a few
more.
On Mon, 6 May 2013 09:48:47 -0400
Todd Showalter wrote:
> On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
>
> > Into wl_seat, we should add a capability bit for gamepad. When the bit
> > is set, a client
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
On Mon, May 6, 2013 at 5:10 PM, Rick Yorgason wrote:
> 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
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
On 6 May 2013 14:48, Todd Showalter wrote:
> On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
>> Into wl_seat, we should add a capability bit for gamepad. When the bit
>> is set, a client can send wl_seat::get_gamepad_manager request, which
>> creates a new wl_gamepad_manager object. (Do we
On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
> Into wl_seat, we should add a capability bit for gamepad. When the bit
> is set, a client can send wl_seat::get_gamepad_manager request, which
> creates a new wl_gamepad_manager object. (Do we actually need a
> capability bit?)
There ar
On Mon, 6 May 2013 11:01:28 +0100
Daniel Stone wrote:
> Hi,
>
> On 5 May 2013 17:55, Pekka Paalanen wrote:
> > On Fri, 3 May 2013 17:42:20 +0100
> > Daniel Stone wrote:
> >> tl;dr: wl_seat has a very specific meaning of a set of devices with
> >> one focus, please don't abuse it.
> >
> > I'm n
44 matches
Mail list logo
