On Mon, 27 Sep 2021, Roderick Colenbrander wrote: > > > > Player LEDs are commonly found on game controllers from Nintendo and Sony > > > > to indicate a player ID across a number of LEDs. For example, "Player 2" > > > > might be indicated as "-x--" on a device with 4 LEDs where "x" means on. > > > > > > > > This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate > > > > player LEDs from the kernel. Until now there was no good standard, which > > > > resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and > > > > other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx. > > > > > > > > Note: management of Player IDs is left to user space, though a kernel > > > > driver may pick a default value. > > > > > > > > Signed-off-by: Roderick Colenbrander <roderick.colenbrander@xxxxxxxx> > > > > --- > > > > Documentation/leds/well-known-leds.txt | 14 ++++++++++++++ > > > > include/dt-bindings/leds/common.h | 7 +++++++ > > > > 2 files changed, 21 insertions(+) > > > > > > Pavel, could you please eventually Ack this, so that I can take it > > > together with the rest? > > > > I'm willing to take Documentation/leds/well-known-leds.txt part > > through LED tree. > > > > I don't like the common.h change; either avoid the define or put it > > into your local header. > > If the LED_FUNCTION_PLAYER* defines don't belong in common with the > other LED_FUNCTION* ones, where should it go? The hid-nintendo driver > intends to use the same defines, so defining it local to each driver > isn't right. Not sure if there is a great place in the input system > either (you would then have to move scrolllock and all those other LED > definitions too.) Pavel, ping please? This has been lingering really for a bit too long. Thanks, -- Jiri Kosina SUSE Labs
