Input and games.

[David Herrmann]

Hi Pekka

On Mon, May 6, 2013 at 8:54 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Sun, 5 May 2013 15:27:54 -0400
> Todd Showalter <todd at electronjump.com> wrote:
>>     Having given it some thought, I'd be inclined to be cautious about
>> how much you consider the gamepad-with-builtin-keyboard case.  They
>> really made those things to make MMOs viable on game consoles.  As far
>> as I know, not a lot of people have them, and the main argument for
>> them is on consoles which don't have native keyboards.  On a PC, the
>> kinds of games that need keyboards are the kinds of games you tend to
>> want access to the mouse.  That's not to say that nobody will ever use
>> a gamepad keyboard in a game on Linux, but I'd argue it's on thin
>> enough ground that I wouldn't let it drive the design considerations.
>
> 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?

I wrote the Wii-Remote kernel driver and I can assure you that there
is _no_ way you can handle this as a generic device. It is a good
example for a device that needs client support to make sense.
Of course, you can write a compositor input driver that emulates a
mouse via the raw Wii-Remote input, but then you should also advertise
it as a mouse to the clients. Depending on the method you use, it can
report absolute or relative events (accel: relative, IR: absolute)

I think we shouldn't try to support such special devices. It doesn't
make sense. Instead, provide generic devices via generic interfaces
(mouse, keyboard, touch, gamepad) but also provide a raw interface so
clients can have device-specific support. And if it turns out that a
new device-class emerges, we can always add support for them.

Regards
David