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

[Bill Spitzak]

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 clients
> can handle axis events without a pointer position.

No don't do this. Windows used to do this and it is completely nuts. 
They fixed it in recent versions (at least per-widget, it is possible 
that the scrollwheel still only goes to the application with keyboard 
focus and is ignored now). OS/X is at least trying to make the mouse 
work as expected. Someday everybody will learn that point-to-type is the 
correct solution :-)

I am certainly no expert on games, but I would expect the gamepad arrows 
to move the mouse cursor around when you are not using it for a game. So 
it should work like a mouse by default, and belong to a "seat". And all 
button events on the gamepad should go to the pointer focus. A gamepad 
with an attached obvious keyboard (ie with a full alphabet) should just 
be both a gamepad and a keyboard, not one device.

A game can do the pointer-lock and then distinguish the motion events 
from them if it wants the mouse and gamepad to act different in the game.

To match all multi-user user interfaces I have ever seen there may be a 
need to make all seats share a single pointer and pointer focus (I'm not 
sure about keyboard focus). This would allow all the gamepads to move 
the focus so the user trying to choose the game to play does not have to 
find the "working" one. Also most schemes I have seen for two users 
sharing the same screen, such as remote control of a desktop, has both 
users moving the same pointer.