On 02/27/2014 02:45 PM, Matthew Garrett wrote:
Hm. I'm not a huge fan of this approach - do any other drivers do it the same way? It seems like this forces userspace code to special-case this system.
Well i'm not aware of any other kernel drivers that control multi color LED zones like this. This is the first alienware kernel driver. The older MCU driven systems don't (yet) have a kernel module and instead there is a libusb driven project out there for them. The expectation is that the user-space color switcher that's written will have a color palette like this: http://www.nexthardware.com/repository/recensioni/611/immagini/img_AlienwareM17x-R3ControlCenter2_324312453106921989.jpg The tool will need to know how much of each color to mix to make the different colors in the palette anyway so how it's packed shouldn't matter. Also it shouldn't be a special case for this single system. I'm pushing for the same BIOS interface to be used for any future Alienware systems without an MCU (some are in development). If you would still prefer that I revert to having individual color nodes I can switch it back, I'm just trying to avoid that situation where the user will need to have the system jump between multiple colors if they pick from two different ends of the spectrum in that palette. Also, any other feedback on the driver implementation? -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
