On Mon, Sep 15, 2014 at 5:54 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > ... That predates LED subsystem. When we saw that it is not flexible enough LED > subsystem was created. Input, for better or worse, has "sound" support as well, > but I do not think anyone would want to to enhance it to support 7.1 surround > output ;) When I said standard I meant HID, not the input subsystem. I totally understand wanting to create a better separation of responsibilities internally. > What does it mean "their led"? The led that happens to share the same physical > package? Sure, but in this case we really care that they're part of the same physical package. We're lighting up the LED for the first player's input device, so we *need* this ability to correlate. LEDs also don't appear to have any uapi headers. Is the sysfs entry considered stable API? Are we supposed to classify what they're for (e.g. PLAYER_1 vs. PLAYER_2) by their name? -- Michael Wright Android Frameworks -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
