[PATCH] protocol: Add gaming input protocol

[Peter Hutterer]

On Sat, Jan 21, 2017 at 12:01:18PM -0800, Roderick Colenbrander wrote:
> Hi Pekka,
> 
> Thanks for your input as well. You raised some valid points as well
> e.g. performance, just in case of my company's devices they run up to
> close to 1kHz even for regular input aside from motion sensors. The
> amount of processing can be high.
> 
> I'm not so sure about moving towards a evdev file descriptor passing
> solution. To me it ties wayland it too much to evdev. For some of my
> use cases we need 'virtual gamepads', which we would like to inject
> into the compositor, right now we can already do the same for keyboard
> / mouse (in our own compositor) without having to fake devices through
> uinput. My bet is that Jingkui was after something similar based on my
> understanding of how they are integrating Android into ChromeOS by
> means of Wayland.

If the fd is passed by the compositor (or any other daemon) then part of the
message can be the type of fd that is being passed. We already do this for
the wl_keyboard.keymap event where we pass an fd together with a "format"
enum that specifies the keymap as e.g. "xkb format".

If you assume that the other side of this fd is going to be a library
anyway, passing an fd for some made-up protocol for virtual devices would be
relatively trivial.

Cheers,
   Peter

> On Fri, Jan 20, 2017 at 2:22 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Hi all,
> >
> > sorry for the fly-by commenting, but I would like to mention an idea
> > that has popped up in the past for game controller support, IIRC on
> > wayland-devel at .
> >
> > That idea was that the compositor would not translate everything into
> > Wayland protocol. Instead, the compositor would hand out open evdev
> > device file descriptors to applications when game controller focus is
> > given, and revoke those file descriptors (make them dead) when game
> > controller focus is taken away.
> >
> > (Hmm, do we have a mechanism to revoke fds or was that never merged in
> > the kernel?)
> >
> > If you have something wild like a motion sensor at 1kHz, the compositor
> > might actually become a bottle-neck on performance or at least consume
> > quite some CPU if it was forwarding events. Passing device file
> > descriptors to the app would avoid that.
> >
> > This means that applications would need to understand the kernel ABI
> > and do all the semantic mappings themselves, plus handle different
> > capability sets etc. A possible solution to that could be a
> > "libgamecontroller", somewhat akin to libinput except used by apps.
> > That would also support game apps that did not use a display server at
> > all. I'm not sure I remember right, but someone might have started on
> > one already.
> >
> > The justification why this could work with game controllers while it
> > does not work with mice, keyboards, etc. is the difference in focus and
> > state handling. When a user activates a game, the compositor could just
> > give the game all the game controllers and not care what happens with
> > them. There is no global state to be managed, like pointer position or
> > keys held down, and switching focus would be very rare.
> >
> > However, of course it is possible that in some cases the compositor
> > would need to catch and react to game controller events, e.g. if there
> > are no other input devices. I suppose the compositor would need to keep
> > its own instance of the device open and filter the event stream? Or
> > maybe the kernel provided a separate evdev device for "system
> > attention" buttons? I'm not sure.
> >
> > Even bigger open questions are how to handle features like touchpads. I
> > also do not know how player id assignments should be handled, by the
> > compositor or by the app? Who would e.g. set up the player id leds in a
> > controller?
> >
> > This email is meant as food for thought, an example of how things might
> > be designed completely differently. I would also encourage to search
> > for the earlier game controller / gamepad threads in the wayland-devel@
> > mailing list archives for ideas and interested people to CC. IIRC there
> > were quite many people and long discussions.
> >
> > Dennis, Jingkui, did you ever consider this approach, and if you did,
> > what downsides did you see?
> >
> >
> > Thanks,
> > pq
> 
> 
> 
> -- 
> Roderick Colenbrander
> Senior Manager of Software Engineering
> Gaikai, a Sony Interactive Entertainment Company
> roderick at gaikai.com
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>