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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
