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

[Peter Hutterer]

On Wed, May 08, 2013 at 09:38:53AM +0300, Pekka Paalanen wrote:
> On Tue, 07 May 2013 12:14:56 -0700
> Bill Spitzak <spitzak at gmail.com> wrote:
> 
> > Pekka Paalanen wrote:
> > 
> > > 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.
> > 
> > I was under the impression that a "seat" can have more than one mouse 
> > and they both move the single pointer, but that does not stop a client 
> > from distinguishing between the mice if it wants.
> 
> No, clients cannot distinguish the mice in that case, with the existing
> protocol.
> 
> > All I am suggesting is 
> > that the same mechanism be used for gamepads so the controls can move 
> > the cursor as well for a client that does not care about gamepads.
> 
> That is completely different to the mice thing: you are emulating a
> pointer device with a gamepad, and then at least switching between
> pointer emulation and real gamepad events, or worse, sending several
> input events (pointer and gamepad) from one physical event. To quote
> your words: No don't do this.

plus, it's not clear which axes/buttons on the gamepad represent axis
movement for pointers. and I have too much experience with sending multiple
protocol events from a single physical event so I can't stress the
"don't go there" enough.

Cheers,
   Peter

> > I think my other concern that multiple seats control a single pointer is 
> > already been brought up by others in this list, as the idea of there 
> > being a hierarchy of seats, or some kind of linking of seats. This seems 
> > to solve the problem imho.
> 
> That's also madness, if it is present in the protocol or in any way
> visible to clients apart from current behaviour.
> 
> 
> Thanks,
> pq