On Mon, Jan 23, 2017 at 10:38 PM, Peter Hutterer <[email protected]> wrote: > On Mon, Jan 23, 2017 at 07:24:24PM -0800, Roderick Colenbrander wrote: >> On Mon, Jan 23, 2017 at 2:05 PM, Jingkui Wang <[email protected]> wrote: >> > 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? >> >> Yes, in general clients utilize these kind of features. There are edge >> cases like playerid assignments in which maybe something outside the >> direct client sets e.g. led states to player 1, 2,.. >> >> > 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. >> >> Some of the features don't easily work over fds. The best example are >> leds, for which applications have to deal with sysfs nodes. >> Hypothetically if clients were to deal with these, they would need to >> be passed hardware bus ids and other fields to be able to locate the >> device. I don't think is desirable at all and would have to be done >> over a protocol. > > there's a different problem: we don't have access to write to LEDs in the > compositor. we have logind for getting evdev access but we have nothing that > gives us write-access to LEDs in sysfs. this only works for keyboard LEDs > because we we can use EV_LED on the evdev node.
It would be nice if we could evolve EV_LED, the sysfs nodes are often painful, but I doubt the input guys will like to change much. A similar situation actually appears with battery through the powersupply class on Linux. This kind of information may need to be provided as well. How is this currently doing for like a wireless keyboard, mouse, tablet? Maybe it is not considered so much, because often batteries last a very long time. Gamepads are more likely to last maybe 12 hours, probably even half of that. > This is an issue we ran into during the tablet pad support. in that case we > added LED support and handling to the kernel (because we had straightforward > behaviour) so that we now only read it but don't have to write to it. > > so we need to figure out a few more bits and pieces, neither the fd passing > nor a compositor protocol is sufficient for LED updates right now. > >> Many of the features I previously described are very common (on most >> gamepads since first Xbox / Wii) and I don't think we should dismiss >> right away. Some of the cheap clone controllers often lack them, but >> if you look at market share all the major ones have them (touchpad is >> more exotic, I admit). > > exotic? isn't it a default feature of (one of) the most popular gaming > consoles out there? :) I'd say that whatever ps/xbox provide, should be > considered the standard feature set. > > Cheers, > Peter > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
