Daniel Stone daniel@... 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
On Tue, 14 May 2013 04:49:39 + (UTC)
Rick Yorgason r...@firefang.com wrote:
Daniel Stone daniel@... 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
(Still digesting the rest of the thread.)
On 14 May 2013 08:11, Peter Hutterer peter.hutte...@who-t.net 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
Hi,
On 14 May 2013 05:49, Rick Yorgason r...@firefang.com 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
On Tue, May 14, 2013 at 10:18 AM, Daniel Stone dan...@fooishbar.org wrote:
Hi,
On 14 May 2013 05:49, Rick Yorgason r...@firefang.com 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
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
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:
On Mon, 13 May 2013 09:12:03 +1000
Peter Hutterer peter.hutte...@who-t.net 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 peter.hutte...@who-t.net wrote:
On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen
On Mon, May 13, 2013 at 2:33 AM, David Herrmann dh.herrm...@gmail.com 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.
Hi,
On 13 May 2013 07:14, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 13 May 2013 09:12:03 +1000
Peter Hutterer peter.hutte...@who-t.net 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
On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
On Thu, 9 May 2013 16:44:09 +1000
Peter Hutterer peter.hutte...@who-t.net 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,
On Thu, 9 May 2013 16:44:09 +1000
Peter Hutterer peter.hutte...@who-t.net 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
On Thu, 9 May 2013 10:49:03 + (UTC)
Rick Yorgason r...@firefang.com wrote:
Pekka Paalanen ppaalanen@... 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
Hi,
On 9 May 2013 11:49, Rick Yorgason r...@firefang.com 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
Pekka Paalanen ppaalanen@... 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
Daniel Stone daniel@... 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
On Tue, May 07, 2013 at 11:14:08AM -0400, Todd Showalter wrote:
On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen ppaala...@gmail.com 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
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. When
On Wed, May 08, 2013 at 11:46:43AM +, Rick Yorgason wrote:
Rick Yorgason rick@... 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
Pekka Paalanen ppaalanen@... 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,
On Thu, May 9, 2013 at 5:49 AM, Rick Yorgason r...@firefang.com wrote:
Pekka Paalanen ppaalanen@... 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
Rick Yorgason rick@... 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
Rick Yorgason rick@... 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
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
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
Bill Spitzak 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
Martin Minarik minarik11@... 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
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 t...@electronjump.com wrote:
On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen ppaala...@gmail.com wrote:
Into wl_seat, we should add a capability bit for
On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen ppaala...@gmail.com 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
On Tue, 7 May 2013 11:14:08 -0400
Todd Showalter t...@electronjump.com wrote:
On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen ppaala...@gmail.com 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,
On Tue, May 7, 2013 at 1:02 PM, Pekka Paalanen ppaala...@gmail.com 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
-
Hi,
On 7 May 2013 16:14, Todd Showalter t...@electronjump.com wrote:
On Tue, May 7, 2013 at 3:23 AM, Pekka Paalanen ppaala...@gmail.com 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
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,
On Mon, 6 May 2013 11:01:28 +0100
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On 5 May 2013 17:55, Pekka Paalanen ppaala...@gmail.com wrote:
On Fri, 3 May 2013 17:42:20 +0100
Daniel Stone dan...@fooishbar.org wrote:
tl;dr: wl_seat has a very specific meaning of a set of devices with
On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen ppaala...@gmail.com 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
On 6 May 2013 14:48, Todd Showalter t...@electronjump.com wrote:
On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen ppaala...@gmail.com 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
Pekka Paalanen ppaalanen@... 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
On Mon, May 6, 2013 at 5:10 PM, Rick Yorgason r...@firefang.com wrote:
Pekka Paalanen ppaalanen@... 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
Jason Ekstrand jason@... 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
39 matches
Mail list logo
