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@. > > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
