[PATCH] protocol: Add gaming input protocol

[Pekka Paalanen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170120/3d3c77f1/attachment.sig>