Input and games.

[Pekka Paalanen]

On Wed, 24 Apr 2013 10:03:35 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Wed, Apr 24, 2013 at 9:41 AM, Todd Showalter
> <todd at electronjump.com>wrote:
> 
> > On Wed, Apr 24, 2013 at 2:26 AM, David Herrmann
> > <dh.herrmann at gmail.com> wrote:
> >
> > > I'm currently looking into an interface that provides
> > > file-descriptors for wl_keyboard/wl_mouse for clients. The FDs
> > > are muted (EVIOCMUTE proposed on linux-input by krh) while
> > > clients are inactive and unmuted when they get input focus. This
> > > is basically a performance boost because input events no longer
> > > pass through the compositor. However, this mechanism could be
> > > easily used to forward any other input fd to clients. A
> > > wl_gamepad interface could be just empty except for this
> > > FD-passing logic.
> >
> >     Being able to talk to the gamepads through evdev without
> > elevated permissions would definitely be a step forward.
> >
> 
> Hi all,
> I hope you'll allow me to chip in just a bit here.  As a disclaimer, I
> haven't read the entire thread but I think I have a decent idea of
> what's gone on.
> 
> Personally, I would like to see some sort of a wl_joypad interface
> that isn't just an FD passthrough.  Sure, it will probably be
> optional and clients shouldn't assume it, but I think it would still
> be good to have it there.  Part of the reason is that, as of now, the
> wayland protocol isn't terribly restricted to standard Linux and I
> would like to avoid things that require Linux underneath such a an FD
> that's expected to be a Linux evdev. There are a couple of reasons
> for this.
> 
> One reason is if we want to do network forwarding.  Now, instead of
> simply providing a forwarded version of the wl_joypad we have to
> forward the evdev and possibly do some translation of the stream in
> order to make everthing happy (I'm not sure what all this would
> involve).  If the client expects to be able to do any ioctls on said
> stream things would get particularly interesting.

If it is evdev we deal with, you have also uinput. I've done evdev over
netcat myself, though getting it right when one device was a Linux
laptop, the other an Android phone, and in between not only netcat but
also some network relay tool from the Android SDK, it was quite a
stretch. Might have worked with less hickups, if I used TCP sockets
directly. But it worked enough, and Weston was happy on the receiving
end.

> Second is that events may not come directly from the kernel.  Once my
> Android compositor app gets beyond just displaying the simple-shm
> client, I'm going to want to forward input events including mouse,
> touch, virtual keyboard, USB keyboard, and gamepad events.  The
> problem is that NONE of those events come from evdev.  They all come
> from the Android event system and need to be translated into
> something useful.

Uinput solves that if we really want evdev fds. Maybe bluetooth device
representation as an evdev device works via uinput in BlueZ, too?

> I realize that my little Android project shouldn't be the sole driver
> of protocol decisions, but I don't think that is the only case where
> game controller events would come from something that's not evdev.
> As another example, people have talked about Wayland on FreeBSD; how
> does FreeBSD handle game controllers?  Can we assume that some sort
> of evdev fd passing will work there and on Linux in any sort of
> reasonable way?

I think this is an important point, and I'm starting to see Todd's
point of a standard protocol interface, too, assuming the kernel drivers
really are unfixable.

The ps3 controller evdev output sounds like no-one ever did any mapping
to it, just threw raw hardware indices out. Maybe I should try and
check that some day... or could it be that the driver was written for
an older controller model, and a newer model is simply missing the
quirks from the kernel driver?

Now, I believe I understand the value of a standard interface. Evdev
file descriptor passing however has a significant benefit, which is
probably the whole reason it is being looked into. I leaves the
compositor out of the input path. This also means, that the application
is not limited by the compositor's input forwarding rate. This makes
the input latency issues practically disappear, in addition to power
savings.

Looks like we need both: a standard interface with perhaps limited
capabilities, and the direct evdev fd passing interface for full
performance and features for those who want it.

Todd has already listed what features a standard gamepad or controller
has. Now someone should start designing the protocol. :-)


Thanks,
pq