[PATCH] protocol: Add gaming input protocol

[Peter Hutterer]

On Fri, Jan 20, 2017 at 12:22:01PM +0200, Pekka Paalanen 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?)

yes, EVIOCGMUTE and it's used by logind to take access to devices away from
us too.

Cheers,
   Peter

> 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



> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel