| Message ID | 20210908165539.3102929-3-roderick.colenbrander@sony.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 61177c088a57bed259122f3c7bc6d61984936a12 |
| Headers | show |
| Series | HID: playstation: add LED support | expand |
On Wed, 8 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@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? Thanks,
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. Best regards, Pavel
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
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@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.) Pavel, ping please? This has been lingering really for a bit too long. Thanks,
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.) Ok, so let's put it in the common place. I'll take this patch through LED tree if you resubmit it. You still may want to use local defines so you can apply the other patches without waiting. Best regards, Pavel
On Wed, Oct 13, 2021 at 12:48 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.) > > Ok, so let's put it in the common place. I'll take this patch through > LED tree if you resubmit it. You still may want to use local defines > so you can apply the other patches without waiting. > Thanks for your reply. If we want to decouple the series between LEDs and HID, I don't mind. Not sure what is preferred by Benjamin/Jiri either a temporary local define (#ifndef LED_FUNCTION_PLAYER1 #define LED_FUNCTION_PLAYER1 "player-1"..) or just temporary hard coding the string. Neither is that nice. It is only a few lines of code, so since defines are the long-term way maybe a local define is okay. > Best regards, > Pavel > -- > http://www.livejournal.com/~pavelmachek
On Wed, 13 Oct 2021, Pavel Machek wrote: > Ok, so let's put it in the common place. I'll take this patch through > LED tree if you resubmit it. You still may want to use local defines > so you can apply the other patches without waiting. Pavel, why complicate it so much? Given how trivial the patch is, the easiest way is what's usually done in such cases (where substantial patch depends on a tiny trivial change elsewhere) -- take it through HID tree with your Reviewed-by / Acked-by:. Do you see any issue with that? Thanks,
On Mon, 18 Oct 2021, Jiri Kosina wrote: > > Ok, so let's put it in the common place. I'll take this patch through > > LED tree if you resubmit it. You still may want to use local defines > > so you can apply the other patches without waiting. > > Pavel, why complicate it so much? Given how trivial the patch is, the > easiest way is what's usually done in such cases (where substantial patch > depends on a tiny trivial change elsewhere) -- take it through HID tree > with your Reviewed-by / Acked-by:. > > Do you see any issue with that? Pavel, another week has passed. I am considering just including the trivial LED #define additions and take them through hid.git unless I hear from you today. Thanks,
On Fri 2021-10-22 08:42:06, Jiri Kosina wrote: > On Mon, 18 Oct 2021, Jiri Kosina wrote: > > > > Ok, so let's put it in the common place. I'll take this patch through > > > LED tree if you resubmit it. You still may want to use local defines > > > so you can apply the other patches without waiting. > > > > Pavel, why complicate it so much? Given how trivial the patch is, the > > easiest way is what's usually done in such cases (where substantial patch > > depends on a tiny trivial change elsewhere) -- take it through HID tree > > with your Reviewed-by / Acked-by:. > > > > Do you see any issue with that? > > Pavel, another week has passed. I am considering just including the > trivial LED #define additions and take them through hid.git unless I hear > from you today. I'd prefer not to deal with rejects / common immutable branches / etc. You don't _need_ the defines at all, and you don't need them in the common place. Just merge the patch without the defines. I'll merge the defines. That seems like least complex solution to me. Pavel
On Fri, 22 Oct 2021, Pavel Machek wrote: > > > > Ok, so let's put it in the common place. I'll take this patch through > > > > LED tree if you resubmit it. You still may want to use local defines > > > > so you can apply the other patches without waiting. > > > > > > Pavel, why complicate it so much? Given how trivial the patch is, the > > > easiest way is what's usually done in such cases (where substantial patch > > > depends on a tiny trivial change elsewhere) -- take it through HID tree > > > with your Reviewed-by / Acked-by:. > > > > > > Do you see any issue with that? > > > > Pavel, another week has passed. I am considering just including the > > trivial LED #define additions and take them through hid.git unless I hear > > from you today. > > I'd prefer not to deal with rejects / common immutable branches / etc. I am not proposing common immutable branch; and if there are going to be trivial cotext conflicts because of that, those will be sorted out by Linus without you even noticing. > You don't _need_ the defines at all As I've already pointed to you in several threads, we have quite a lot of code queued that does depend on the defines. > and you don't need them in the common place. I compltely fail to see the point of having them teporarily local before you manage to finally do something about the trivial addition to proper shared header. > Just merge the patch without the defines. I'll merge the defines. That > seems like least complex solution to me. That would cause my tree not to build.
On Fri, 22 Oct 2021, Jiri Kosina wrote: > > > > > Ok, so let's put it in the common place. I'll take this patch through > > > > > LED tree if you resubmit it. You still may want to use local defines > > > > > so you can apply the other patches without waiting. > > > > > > > > Pavel, why complicate it so much? Given how trivial the patch is, the > > > > easiest way is what's usually done in such cases (where substantial patch > > > > depends on a tiny trivial change elsewhere) -- take it through HID tree > > > > with your Reviewed-by / Acked-by:. > > > > > > > > Do you see any issue with that? > > > > > > Pavel, another week has passed. I am considering just including the > > > trivial LED #define additions and take them through hid.git unless I hear > > > from you today. > > > > I'd prefer not to deal with rejects / common immutable branches / etc. > > I am not proposing common immutable branch; and if there are going to be > trivial cotext conflicts because of that, those will be sorted out by > Linus without you even noticing. > > > You don't _need_ the defines at all > > As I've already pointed to you in several threads, we have quite a lot of > code queued that does depend on the defines. > > > and you don't need them in the common place. > > I compltely fail to see the point of having them teporarily local before > you manage to finally do something about the trivial addition to proper > shared header. > > > Just merge the patch without the defines. I'll merge the defines. That > > seems like least complex solution to me. > > That would cause my tree not to build. In other words: could you please elaborate what exact issue are you trying to avoid by not providing your Acked-by: and letting it go through hid.git with all the rest of the code depending on it?
Hi! > > > > Pavel, another week has passed. I am considering just including the > > > > trivial LED #define additions and take them through hid.git unless I hear > > > > from you today. > > > > > > I'd prefer not to deal with rejects / common immutable branches / etc. > > > > I am not proposing common immutable branch; and if there are going to be > > trivial cotext conflicts because of that, those will be sorted out by > > Linus without you even noticing. > > > > > You don't _need_ the defines at all > > > > As I've already pointed to you in several threads, we have quite a lot of > > code queued that does depend on the defines. > > > > > and you don't need them in the common place. > > > > I compltely fail to see the point of having them teporarily local before > > you manage to finally do something about the trivial addition to proper > > shared header. > > > > > Just merge the patch without the defines. I'll merge the defines. That > > > seems like least complex solution to me. > > > > That would cause my tree not to build. > > In other words: could you please elaborate what exact issue are you trying > to avoid by not providing your Acked-by: and letting it go through hid.git > with all the rest of the code depending on it? I'm trying to avoid merge conflict. I believe open-coding string for a while is acceptable price to pay for that, and I'd prefer that solution. If you can promise that no conflicts or other problems will happen for either me or Linus... go ahead and merge the patch. Best regards, Pavel
On Mon, 25 Oct 2021, Pavel Machek wrote: > > In other words: could you please elaborate what exact issue are you trying > > to avoid by not providing your Acked-by: and letting it go through hid.git > > with all the rest of the code depending on it? > > I'm trying to avoid merge conflict. What's wrong with this kind of conflict? That's what linux-next is for; if there is a conflict, we'll be notified and if needed and we could indicate this to Linus during merge window. The trivial ones he resolves without any issues. And we'll know exactly what kind of conflict (if any at all) is there beforehand from linux-next. > I believe open-coding string for a while is acceptable price to pay for > that, and I'd prefer that solution. I don't. It's a mess. If you'd then for some reason change your mind on the last minute and did the numbering differently in your tree, it will go by unnoticed, while when the real conflict happens, it'll be a clear sign that there is a thing to resolve. Conflict is not a bad thing per se that needs to be avoided at all costs. Conflict clearly shows the dependency between the trees and is trivially resolved. > If you can promise that no conflicts or other problems will happen for > either me or Linus... Linus doesn't care about this kind of hypothetical conflict if there is a reason for it, and he resolves them on a daily basis, just check the git history. > go ahead and merge the patch. Can I take this as your Acked-by: then, so that I can finally apply it and get the needed linux-next coverage before merge window opens?
Hi! > > go ahead and merge the patch. > > Can I take this as your Acked-by: then, so that I can finally apply it and > get the needed linux-next coverage before merge window opens? Yes. Best regards, Pavel
On Tue, 26 Oct 2021, Pavel Machek wrote: > > Can I take this as your Acked-by: then, so that I can finally apply it and > > get the needed linux-next coverage before merge window opens? > > Yes. Thanks. The whole series is now in hid.git#for-5.16/playstation
diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt index 4a8b9dc4bf52..2160382c86be 100644 --- a/Documentation/leds/well-known-leds.txt +++ b/Documentation/leds/well-known-leds.txt @@ -16,6 +16,20 @@ but then try the legacy ones, too. Notice there's a list of functions in include/dt-bindings/leds/common.h . +* Gamepads and joysticks + +Game controllers may feature LEDs to indicate a player number. This is commonly +used on game consoles in which multiple controllers can be connected to a system. +The "player LEDs" are then programmed with a pattern to indicate a particular +player. For example, a game controller with 4 LEDs, may be programmed with "x---" +to indicate player 1, "-x--" to indicate player 2 etcetera where "x" means on. +Input drivers can utilize the LED class to expose the individual player LEDs +of a game controller using the function "player". +Note: tracking and management of Player IDs is the responsibility of user space, +though drivers may pick a default value. + +Good: "input*:*:player-{1,2,3,4,5} + * Keyboards Good: "input*:*:capslock" diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h index 52b619d44ba2..3be89a7c20a9 100644 --- a/include/dt-bindings/leds/common.h +++ b/include/dt-bindings/leds/common.h @@ -60,6 +60,13 @@ #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_PLAYER1 "player-1" +#define LED_FUNCTION_PLAYER2 "player-2" +#define LED_FUNCTION_PLAYER3 "player-3" +#define LED_FUNCTION_PLAYER4 "player-4" +#define LED_FUNCTION_PLAYER5 "player-5" + /* Miscelleaus functions. Use functions above if you can. */ #define LED_FUNCTION_ACTIVITY "activity" #define LED_FUNCTION_ALARM "alarm"
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(+)