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

[Pekka Paalanen]

On Mon, 06 May 2013 18:01:11 +0200
Markus Germann <germannenmarkus at gmail.com> 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 they are also often used input devices for 
> games/simulations, and this debate seems to be about gamepads only (in 
> my eyes, but I'm not an expert).

Well, this particular email was about pointer devices only, not
joysticks. Joysticks are not pointers, so they don't have a "current
pointer position".

Given that, I'm not sure what you are asking about. It's true, that
this whole thread and the interface proposals have been only about
"standard gamepads". Joysticks will probably need their own thing,
provided there is a thing that could be called the "standard joystick".
If not, it'll probably be just evdev pass-through.

However, the gamepad discussion can be relevant to joysticks, too, on
the device management and focus handling parts, and also for all
file descriptor (evdev) passthrough devices.

I guess the answer to your question would be "No, scroll wheel is a
relative input and a part of a pointer device. All pointer device
inputs are relative, and multiple physical devices can be sensibly
aggregated into a single logical device interface. Joysticks are not
relative, and cannot be aggregated."


Thanks,
pq

> Am 06.05.2013 08:40, schrieb Pekka Paalanen:
> > On Sun, 5 May 2013 15:27:54 -0400
> > Todd Showalter <todd at electronjump.com> wrote:
> >
> >> On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen <ppaalanen at gmail.com> 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, they have no relation.
> >>      As a total aside, OSX has this and it drives me nuts.  Scrollwheel
> >> focus follows the pointer, keyboard focus doesn't.  In practise what
> >> that means is that whenever I'm on OSX I wind up closing the wrong
> >> thing.
> > Actual focus assignment is just server behaviour, an implementation
> > detail. We could as well have Wayland servers where keyboard focus
> > follows mouse, but...
> >
> > 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.
> >
> >>   Example:
> >>
> >> - running an irc client and firefox
> >> - colleague sends an url, I click on it
> >> - firefox brings up the url, I mouse over to it and scroll through
> >> with the scroll wheel
> >> - I'm done with the link, clover-w to close the tab, and it closes my
> >> IRC session instead, because keyboard focus never left the irc window
> >>
> >>      I've had to use OSX for a couple of years now because of some iOS
> >> projects we've been working on, and this still bites me at least once
> >> a day.  It's *completely* counterintuitive GUI behaviour.
> >
> > Thanks,
> > pq