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
Peter Hutterer wrote:
Because C1 has the gamepad open, the pointer is no longer shared,
and it thus acts exactly like the pointer is only controlled by the
mouse. There is no gp-controlled pointer.
this makes C1 a pointer-trap, similar to qemu's behaviour under X. if you
accidentally move onto
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
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
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 09, 2013 at 05:41:23PM -0700, Bill Spitzak wrote:
> Peter Hutterer wrote:
>
> >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 t
Peter Hutterer wrote:
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 surface
- when the com
On Thu, May 09, 2013 at 11:19:58AM -0700, Bill Spitzak wrote:
> Peter Hutterer wrote:
>
> >plus, it's not clear which axes/buttons on the gamepad represent axis
> >movement for pointers.
>
> I think that is going to have to be figured out anyway. There
> certainly was a lot of talk about having t
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_
On Thu, May 9, 2013 at 2:21 PM, Bill Spitzak wrote:
>> it does/may to the user if the scroll wheel is located on the physical
>> keyboard.
>
> Are there any examples of such hardware that don't also have a way to move
> the mouse cursor?
Yes, actually. I've seen a fair number of "multimedia
Peter Hutterer wrote:
I don't think it makes sense to send a scroll wheel event to a window
that's not beneath the cursor [...]
it does/may to the user if the scroll wheel is located on the physical
keyboard.
Are there any examples of such hardware that don't also have a way to
move the mou
Peter Hutterer wrote:
plus, it's not clear which axes/buttons on the gamepad represent axis
movement for pointers.
I think that is going to have to be figured out anyway. There certainly
was a lot of talk about having the "same" buttons on different gamepads
produce events that the client ca
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
On Mon, May 06, 2013 at 08:06:35PM -0500, Vincent Povirk wrote:
> > Windows used to do this and it is completely nuts. They fixed it in recent
> > versions
>
> I don't know what version of Windows you're using, but I can still
> observe this behavior in the Windows 8 file dialogs. I wrote a progr
On Wed, May 08, 2013 at 09:38:53AM +0300, Pekka Paalanen wrote:
> On Tue, 07 May 2013 12:14:56 -0700
> Bill Spitzak wrote:
>
> > Pekka Paalanen wrote:
> >
> > > If you want to move a pointer with a gamepad in a game, then implement
> > > that whole pointer thing in the game. Don't screw up the p
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
On Tue, 07 May 2013 12:14:56 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > If you want to move a pointer with a gamepad in a game, then implement
> > that whole pointer thing in the game. Don't screw up the protocol for
> > it.
>
> I was under the impression that a "seat" can have mor
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
Pekka Paalanen wrote:
If you want to move a pointer with a gamepad in a game, then implement
that whole pointer thing in the game. Don't screw up the protocol for
it.
I was under the impression that a "seat" can have more than one mouse
and they both move the single pointer, but that does not
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
On Mon, 06 May 2013 11:07:03 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > sending pointer axis events (i.e. scroll wheel) to the window with
> > the keyboard focus is... unexplored. If it is ok to send axis events
> > outside of a wl_pointer.enter/leave pair, then it's perfectly doabl
On Mon, 06 May 2013 18:01:11 +0200
Markus Germann wrote:
> Just of curiosity, are the axis events of a joystick handled the same
> way as a scroll wheel? Because they (joysticks as input devices) might
> then be affected as well. I just mention that in order for you to keep
> in mind, that the
Todd Showalter wrote:
On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk wrote:
A compositor could just drop events that aren't over a focused window,
and it would solve Todd's problem, unless he's also expecting to be
able to scroll things without hovering over them.
My problem is that I
Vincent Povirk wrote:
Windows used to do this and it is completely nuts. They fixed it in recent
versions
Some toolkits on Windows, like gtk, direct scroll wheel input based on
cursor position, but they're not really using the native windowing
system for their widgets. The upshot of this is
On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk wrote:
> A compositor could just drop events that aren't over a focused window,
> and it would solve Todd's problem, unless he's also expecting to be
> able to scroll things without hovering over them.
My problem is that I expect one of two case
> Windows used to do this and it is completely nuts. They fixed it in recent
> versions
I don't know what version of Windows you're using, but I can still
observe this behavior in the Windows 8 file dialogs. I wrote a program
to work around it: https://github.com/madewokherd/xscrollwheel
Some to
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
Pekka Paalanen wrote:
sending pointer axis events (i.e. scroll wheel) to the window with
the keyboard focus is... unexplored. If it is ok to send axis events
outside of a wl_pointer.enter/leave pair, then it's perfectly doable.
Is it, I don't know. I don't see a reason it wouldn't work, if clien
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
On 2013-05-06, at 2:54 AM, Pekka Paalanen wrote:
>>I don't think there's any problem in principle with the gamepad
>> events being delivered to the same client that has keyboard focus.
>> The only annoying thing is if (in a multiplayer game) someone can
>> screw you by sending you a well-time
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 not too clear on what it is.
>
> In a wl_seat, we have one kbd focus, and o
On Mon, 6 May 2013 09:07:01 +0200
David Herrmann wrote:
> Hi Pekka
>
> On Mon, May 6, 2013 at 8:54 AM, Pekka Paalanen wrote:
> > On Sun, 5 May 2013 15:27:54 -0400
> > Todd Showalter wrote:
> >> Having given it some thought, I'd be inclined to be cautious about
> >> how much you consider th
Hi Pekka
On Mon, May 6, 2013 at 8:54 AM, Pekka Paalanen wrote:
> On Sun, 5 May 2013 15:27:54 -0400
> Todd Showalter wrote:
>> Having given it some thought, I'd be inclined to be cautious about
>> how much you consider the gamepad-with-builtin-keyboard case. They
>> really made those things
On Sun, 5 May 2013 15:27:54 -0400
Todd Showalter wrote:
> On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen wrote:
>
> > I was thinking of adding a third one: the gamepad focus. It could
> > be independent from kbd and pointer foci, or maybe it is assigned
> > with the kbd focus. Or maybe the gam
On Sun, 5 May 2013 15:27:54 -0400
Todd Showalter wrote:
> On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen wrote:
>
> > In a wl_seat, we have one kbd focus, and one pointer focus. These
> > two are unrelated, except sometimes some pointer action may change
> > the kbd focus. Most of the time, th
On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen wrote:
> In a wl_seat, we have one kbd focus, and one pointer focus. These
> two are unrelated, except sometimes some pointer action may change
> the kbd focus. Most of the time, they have no relation.
As a total aside, OSX has this and it driv
On Fri, 3 May 2013 17:42:20 +0100
Daniel Stone wrote:
> Hi,
>
> On 3 May 2013 08:17, Pekka Paalanen wrote:
> > On Thu, 2 May 2013 19:28:41 +0100
> > Daniel Stone wrote:
> >> There's one crucial difference though, and one that's going to come up
> >> when we address graphics tablets / digitiser
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
Todd Showalter wrote:
Decelerate/accelerate would cover all the cases I can think of.
I thought you said the speed of mouse movement controlled whether it
slowed down or not. Ie if the user quickly dragged the slider to the
bottom then the scrollbar was at the bottom, but if they moved s
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
On Fri, May 3, 2013 at 12:12 PM, Daniel Stone wrote:
>> I think edge resistance/edge snapping really wants pointer warping as
>> well.
>
> It's really difficult to achieve a nicely responsive and fluid UI
> (i.e. doing this without jumps) when you're just warping the pointer.
> To be honest,
On Fri, May 3, 2013 at 12:06 PM, Daniel Stone wrote:
> I think with 6DoF-type devices, we really shouldn't try to do anything
> clever with them, and pretty much just pass evdev input through. The
> only reason we created wl_pointer and wl_keyboard as they are is that
> the compositor needs to i
Hi,
On 3 May 2013 08:17, Pekka Paalanen wrote:
> On Thu, 2 May 2013 19:28:41 +0100
> Daniel Stone wrote:
>> 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 ho
Hi,
On 29 April 2013 18:44, Bill Spitzak wrote:
> Has anybody thought about pens (ie wacom tablets)? These have 5 degrees of
> freedom (most cannot distinguish rotation about the long axis of the pen).
> There are also spaceballs with full 6 degrees of freedom.
As Todd said, these really need to
Hi,
On 21 April 2013 06:28, Todd Showalter wrote:
> On Fri, Apr 19, 2013 at 7:08 PM, Bill Spitzak wrote:
>> I think this is going to require pointer warping. At first I thought it
>> could be done by hiding the pointer and faking it's position, but that would
>> not stop the invisible pointer fr
Hi,
On 19 April 2013 10:18, Pekka Paalanen wrote:
> Keyboards already have extensive mapping capabilities. A Wayland server
> sends keycodes (I forget in which space exactly) and a keymap, and
> clients feed the keymap and keycodes into libxkbcommon, which
> translates them into something actuall
Hi,
On 20 April 2013 22:13, Nick Kisialiou wrote:
> Generic device input may be too complicated to put it into Wayland protocol.
> For example, take Razer Hydra controller:
> http://www.engadget.com/2011/06/08/razer-totes-hydra-sticks-and-6400dpi-dual-sensor-mice-to-e3-2011/
>
> There are 2 USB c
On Fri, 3 May 2013 09:12:20 -0400
Todd Showalter wrote:
> On Fri, May 3, 2013 at 6:42 AM, Pekka Paalanen wrote:
>
> > Sure, the heuristics can cover a lot, but there is still the mad case,
> > and also the initial setup (system started with 3 new gamepads hooked
> > up), where one may want to c
On Fri, May 3, 2013 at 6:42 AM, Pekka Paalanen wrote:
> Sure, the heuristics can cover a lot, but there is still the mad case,
> and also the initial setup (system started with 3 new gamepads hooked
> up), where one may want to configure manually. The GUI is just my
> reminder, that sometimes it
On Fri, 3 May 2013 03:51:33 -0400
Todd Showalter wrote:
> On Fri, May 3, 2013 at 3:34 AM, Pekka Paalanen
> wrote:
>
> > Yup. Whatever we do, we get it wrong for someone, so there needs to
> > be a GUI to fix it. But should that GUI be all games' burden, or
> > servers' burden...
> >
> > Along w
On Fri, May 3, 2013 at 3:34 AM, Pekka Paalanen wrote:
> Yup. Whatever we do, we get it wrong for someone, so there needs to be
> a GUI to fix it. But should that GUI be all games' burden, or servers'
> burden...
>
> Along with the GUI is the burden of implementing the default
> heuristics, which
On Thu, 2 May 2013 10:46:56 -0400
Todd Showalter wrote:
> On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen
> wrote:
> > On Tue, 30 Apr 2013 09:14:48 -0400
> > Todd Showalter wrote:
> >
...
> >> The question is, is a gamepad an object, or is a *set* of
> >> gamepads an object?
> >
> > Both, ju
On Thu, 2 May 2013 19:28:41 +0100
Daniel Stone wrote:
> Hi,
>
> On 2 May 2013 10:44, Pekka Paalanen wrote:
> > On Tue, 30 Apr 2013 09:14:48 -0400
> > Todd Showalter wrote:
> >> The question is, is a gamepad an object, or is a *set* of
> >> gamepads an object?
> >
> > Both, just like a wl_p
On Thu, 2 May 2013 18:18:27 + (UTC)
Rick Yorgason wrote:
> 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 reli
Hi,
On 2 May 2013 10:44, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter 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
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
On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter wrote:
>
>> I'm getting set up to write code. Someone kindly gave me a bash
>> script to pull down all the components, so once I get things set up
>> properly I'll see if I can get a p
On Tue, 30 Apr 2013 10:30:33 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 10:25 AM, Todd Showalter
> wrote:
>
> > On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen
> > wrote:
> >
> > > unfortunately that is not how Wayland works at all. All clients
> > > are isolated from the start, rega
On Tue, 30 Apr 2013 09:14:48 -0400
Todd Showalter wrote:
> On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen
> wrote:
>
> > you've provided lots of valuable information already. Unfortunately
> > my input is left as hand-waving, since I cannot dedicate to
> > designing this protocol myself (as in
Pekka Paalanen wrote:
Normally Wayland does
not allow clients to e.g. randomly raise themselves to top
I hope it allows this.
Otherwise clients are going to resort to destroying/recreating their
surfaces, which is how we work around bugs in Gnome window managers when
click-to-raise is turn
On Tue, Apr 30, 2013 at 10:25 AM, Todd Showalter wrote:
> On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen
> wrote:
>
> > unfortunately that is not how Wayland works at all. All clients are
> > isolated from the start, regardless how they are spawned. The idea
> > might be ok, but concepts and pro
On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen wrote:
> unfortunately that is not how Wayland works at all. All clients are
> isolated from the start, regardless how they are spawned. The idea
> might be ok, but concepts and protocol design will be very different.
I had a feeling that might
On Tue, 30 Apr 2013 08:30:52 -0400
Todd Showalter wrote:
> On 2013-04-30, at 3:29 AM, Pekka Paalanen wrote:
>
> > What an application could actually do when it receives a home button
> > press via the special path is an important question. Since Wayland
> > does not allow random clients to just
On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen wrote:
> you've provided lots of valuable information already. Unfortunately my
> input is left as hand-waving, since I cannot dedicate to designing this
> protocol myself (as in writing the XML spec).
I'm getting set up to write code. Someone
On 2013-04-30, at 3:29 AM, Pekka Paalanen wrote:
> What an application could actually do when it receives a home button
> press via the special path is an important question. Since Wayland does
> not allow random clients to just jump in, you need to specifically
> think how to enable a desired re
1 - 100 of 153 matches
Mail list logo
