Input and games.

[Todd Showalter]

On 2013-05-06, at 2:54 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

>>    I don't think there's any problem in principle with the gamepad
>> events being delivered to the same client that has keyboard focus.
>> The only annoying thing is if (in a multiplayer game) someone can
>> screw you by sending you a well-timed IM that pops up a window and
>> steals focus, but honestly I think that's more an argument against
>> focus stealing than it is for not attaching gamepad focus to keyboard
>> focus.
> 
> Focus stealing indeed, there has been some discussion about that.
> 
> The problem is, that a wl_seat may not have a keyboard, hence it does
> not have a keyboard focus. And if there are multiple wl_seats, one for
> each player, as a user I don't want to individually assign each player's
> focus to the game.

    That seems like an argument for ganging gamepads into a single seat, preferably one with a keyboard. I presume we want the normal case to be the easy case, and I think the normal case is one game running that has the focus of the keyboard, mouse and gamepads.

    It's important to support other scenarios, but I think that is the one that has to Just Work with as little user effort as possible.

> I could imagine the Wii pointer exposed as a wl_pointer with the
> gamepad... hrm, that's another curious input device that does not fit
> well in our categories: it needs a cursor image, but provides absolute
> positions unlike a mouse, right?

    Sort of. It's actually more complex in some ways, because the position actually comes from a camera in the end of the wiimote looking at a couple of infra red LEDs.  It also has accelerometers and hot-docking peripherals, and a built-in speaker.

    It can lose sight of the "screen", at which point the pointer is in an undefined location. The accelerometers mean the pointer can have an orientation; you can in principle rotate the pointer.  It can change capability somewhat drastically depending on what is jacked in.

    It's kind of neat, but if you're writing something that uses it, you're going to be writing a lot of device-specific code. I'm not sure how much of a useful abstraction can be built around it.

    The other thing is, the pointer is driven by a camera looking at LEDs, but IIRC decoding that happens on the host machine; it just gets a stream of intensity pixmaps from the device and uses that to calculate position. Which means there are potentially a lot of interesting things you could do with it if you know a little signal processing and how to wire up LEDs.

                                    Todd. 

--
  Todd Showalter, President
  Electron Jump Games, Inc.