On Fri, Jan 20, 2017 at 2:22 AM, Pekka Paalanen <[email protected]> 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@.
Thanks, Pekka. I would like first to describe what I am working on and why our approach pops up naturally. I am working on arc++ to support gamepads (some background here: https://lwn.net/Articles/701964/). Gamepad events are read in Chrome and routed to Android through Wayland. Android expose gamepad input to game developers through Android api: (https://developer.android.com/training/game-controllers/controller-input.html) Naturally, it worked well for us to read/process/remap events in compositor, and send button/axis events. > 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?) > It sounds like this will also solve Roderick's concern? (Correct me if I am wrong, the client will utilize "non-standard gamepad" functions like rumble/led? I strong agree with the idea of exposing/revoking fd to support additional features, while I think we can translate the standard features to wayland-protocol. The client might choose to consume only standard set of gamepad events or take the fd and get a full set of capabilities. Exposing the "standard set" will save the client from understanding the kernel and using toolkit/library. If some feature becomes so common, maybe we can move on to add it into the "standard set". Thanks, Jingkui _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
