Re: [PATCH v3 2/3] leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.

[Roderick Colenbrander <thunderbird2k@gmail.com>]

Hi Pavel,

On Mon, Sep 27, 2021 at 7:12 AM Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
> > > 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@sony.com>
> > > ---
> > >  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.)

Thanks,
Roderick


>
> Best regards,
>                                                                 Pavel
> --
> http://www.livejournal.com/~pavelmachek