Axis events to keyboard focus (Re: Input and games.)

[Peter Hutterer]

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 the gp-controlled pointer enters and clicks inside the surface
> >- when the compositor changes the keyboard and/or gamepad focus to C1's
> >  surface while the gp-controlled pointer is inside or outside the surface,
> >  respectively
> 
> 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 the surface, you cannot escape unless you change the
physical device to move the pointer. less than ideal, imo

> >- when the mouse-controlled pointer enters and/or clicks C1's surface
> 
> C1 gets enter and button events just like normal.
> 
> >- when the mouse-controlled pointer leaves the surface while a gamepad
> >  button is held down
> 
> I think it may be desirable to have any buttons on any devices (ie
> keyboard keys as well) perform a temporary-grab much like mouse
> buttons so the pointer focus does not change until all the buttons
> are released. In this case C1 will get the mouse-move events and any
> buttons until it gets the release of all of them.
> 
> If there is no such multi-device button grab, then C1 sees a
> mouse-leave event. It will also get the up event for the gamepad
> button since it still has the gamepad focus.

this is a weird disconnect then. I can control the pointer until I move into
a client that uses the gamepad. then the gamepad won't control the pointer,
but it will still effectively _block_ the pointer from leaving the window if
a button is pressed. very inconsistent.
 
> >  - when the gamepad presses a button after the mouse-controlled pointer has
> >    left the surface
> 
> The gamepad entries still go to the gamepad focus which is C1

with this, if I move the pointer outside of the window while a GP button is
down, I can't click anywhere. if I release the button, I can click anywhere
but the GP button still goes to the old client. or not - depending on
whether the GP has control over the pointer again.

Cheers,
   Peter

> >- if a keyboard event triggers a compositor shortcut immediately followed by
> >  a gamepad button event (e.g. alt-tab followed by gamepad button 1 press,
> >  does this select the window currently underneath the pointer?)
> 
> If this moves the gamepad focus to another client that has not
> opened the gamepad, I think it does restore the control of the
> pointer. So the click does go to the window under the pointer.
> 
> >- what is the position of the cursor between the gamepad detached and
> >  reattached to pointer mode
> 
> If follows the mouse only.