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
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, 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 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
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
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
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
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
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 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
20 matches
Mail list logo
