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

[Pekka Paalanen]

On Mon, 06 May 2013 11:07:03 -0700
Bill Spitzak <spitzak at gmail.com> 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 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.

It's not for "us" to do, it is a decision every individual compositor
can make, and it can be user-configurable in desktop preferences, for
example.

As far as I can see, the protocol already allows this, and many other
focus models. Compositor developers decide which ones they offer to
users, and users decide which one of the offered ones they actually use.

> 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.

This is just one more of your schemes in trying to make the life of
developers as hard as possible, while doing what a user expects becomes
very hard and complicated.

Any device emulation must not be visible to clients at all, and
therefore it will not need any specific protocol design. There is also
the rule of never duplicating any input events in any form. Anything
to the contrary is madness, or so I've come to understand by listening
to X developers.

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.


Thanks,
pq