All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Jiri Kosina" <jikos@kernel.org>,
	"Roderick Colenbrander" <roderick@gaikai.com>,
	"Benjamin Tissoires" <benjamin.tissoires@redhat.com>,
	linux-input <linux-input@vger.kernel.org>,
	linux-leds@vger.kernel.org,
	"Barnabás Pőcze" <pobrn@protonmail.com>,
	"Daniel J . Ogorchock" <djogorchock@gmail.com>,
	"Roderick Colenbrander" <roderick.colenbrander@sony.com>
Subject: Re: [PATCH 2/3] leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.
Date: Tue, 3 Aug 2021 16:29:51 -0700	[thread overview]
Message-ID: <CAEc3jaAoDfJD92q9q_HoFq3nsjkDqfZHu-VO+Ei8xSP8QrE8rg@mail.gmail.com> (raw)
In-Reply-To: <20210803221055.GA32527@amd>

Hi Pavel,

See some quick comments inline.

On Tue, Aug 3, 2021 at 3:39 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
> > > From: Roderick Colenbrander <roderick.colenbrander@sony.com>
> > >
> > > 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 a new LED_FUNCTION_PLAYER 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_PLAYER.
> > >
> > > 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>
> > > ---
> > >  include/dt-bindings/leds/common.h | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
> > > index 52b619d44ba2..94999c250e4d 100644
> > > --- a/include/dt-bindings/leds/common.h
> > > +++ b/include/dt-bindings/leds/common.h
> > > @@ -60,6 +60,9 @@
> > >  #define LED_FUNCTION_MICMUTE "micmute"
> > >  #define LED_FUNCTION_MUTE "mute"
> > >
> > > +/* Used for player LEDs as found on game controllers from e.g. Nintendo, Sony. */
> > > +#define LED_FUNCTION_PLAYER "player"
> > > +
> > >  /* Miscelleaus functions. Use functions above if you can. */
> > >  #define LED_FUNCTION_ACTIVITY "activity"
> > >  #define LED_FUNCTION_ALARM "alarm"
> >
> > Pavel, can I please get your Ack on this one, so that I can take it with
> > the rest of the series?
>
> I'm sorry for delays.
>
> But no, player is not suitable function. Function would be "player1"
> AFAICT, right?

A given gaming device such as Sony or Nintendo controllers have a
multiple of these LEDs, which are meant to be configured with a player
number. A typical device has like 4 of these LEDs, so a single
controller would have: "player-1", "player-2", "player-3" and
"player-4". It is up to userspace to configure the player number (a
driver may set a default number across a number of LEDs).

If player is not the right term (many people know it), what would it be?

>
> I'm not sure "function" is suitable here, and we may want to create
> documentation like this... where it would be explained which functions
> apply to which devices and what they actually mean.
>
> Best regards,
>                                                                 Pavel
>
> -*- org -*-
>
> It is somehow important to provide consistent interface to the
> userland. LED devices have one problem there, and that is naming of
> directories in /sys/class/leds. It would be nice if userland would
> just know right "name" for given LED function, but situation got more
> complex.
>
> Anyway, if backwards compatibility is not an issue, new code should
> use one of the "good" names from this list, and you should extend the
> list where applicable.
>
> Bad names are listed, too; in case you are writing application that
> wants to use particular feature, you should probe for good name, first,
> but then try the bad ones, too.
>
> * Keyboards
>
> Good: "input*:*:capslock"
> Good: "input*:*:scrolllock"
> Good: "input*:*:numlock"
> Bad: "shift-key-light" (Motorola Droid 4, capslock)
>
> Set of common keyboard LEDs, going back to PC AT or so.
>
> Good: "platform::kbd_backlight"
> Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
> Bad: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900)
>
> Frontlight/backlight of main keyboard.
>
> Bad: "button-backlight" (Motorola Droid 4)
>
> Some phones have touch buttons below screen; it is different from main
> keyboard. And this is their backlight.
>
> * Sound subsystem
>
> Good: "platform:*:mute"
> Good: "platform:*:micmute"
>
> LEDs on notebook body, indicating that sound input / output is muted.
>
> * System notification
>
> Good: "status-led:{red,green,blue}" (Motorola Droid 4)
> Bad: "lp5523:{r,g,b}" (Nokia N900)
>
> Phones usually have multi-color status LED.
>
> * Power management
>
> Good: "platform:*:charging" (allwinner sun50i)
>
> * Screen
>
> Good: ":backlight" (Motorola Droid 4)
>
>
> --
> http://www.livejournal.com/~pavelmachek

  reply	other threads:[~2021-08-03 23:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02  6:12 [PATCH 0/3] HID: playstation: add LED support Roderick Colenbrander
2021-06-02  6:12 ` [PATCH 1/3] HID: playstation: expose DualSense lightbar through a multi-color LED Roderick Colenbrander
2021-06-02  6:12 ` [PATCH 2/3] leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers Roderick Colenbrander
2021-06-24 13:25   ` Jiri Kosina
2021-07-06  4:51     ` Roderick Colenbrander
2021-07-22 16:22       ` Roderick Colenbrander
2021-08-03 22:10     ` Pavel Machek
2021-08-03 23:29       ` Roderick Colenbrander [this message]
2021-08-13  6:00         ` Daniel Ogorchock
2021-08-31 19:09           ` Jiri Kosina
2021-09-01  5:19             ` Pavel Machek
2021-09-01 20:24               ` Roderick Colenbrander
2021-06-02  6:12 ` [PATCH 3/3] HID: playstation: expose DualSense player LEDs through LED class Roderick Colenbrander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEc3jaAoDfJD92q9q_HoFq3nsjkDqfZHu-VO+Ei8xSP8QrE8rg@mail.gmail.com \
    --to=thunderbird2k@gmail.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=djogorchock@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=pobrn@protonmail.com \
    --cc=roderick.colenbrander@sony.com \
    --cc=roderick@gaikai.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.