Provide our own supports_color method to specify which colors are
actually implemented by the driver. RGB LEDs could provide different
colors as well such as orange, purple, etc. but those are not supported
yet.
Drop has_color API since supported colors are set during probing
and can be handled completely separately from the classes for
each type of hardware.
Rename set_color to set_supported_color because the usage
of this API is to check if the color is supported, but not
setting it. Setting the color is also separated from
start_periodic API to re-use multicolor across multiple LED types
with a set_color API. Multicolor LEDs are actually the same as
regular LEDs but they require a few additional sysfs entries to
actually set the color. Single color LEDs only have a single color
so the set_color method just returns TRUE for these LEDs.
Supported colors are advertised through the supports_color API now.
This way, each LED driver define which colors are supported
through supports_color API. RGB multicolor LEDs will report only fixed colors
like red, blue, green and white until the kernel can expose if a diffusor
is present to mix these colors.
Loading the required kernel modules such as ledtrig-pattern via
/etc/modules-load.d may introduce a race condition on some systems such
as non-systemd based distros. Load the kernel modules using the builtin
'kmod load' udev command instead.
Reads the compatible list of the device and tries to find a device-specific theme file in all directories. If no configuration is found, we fall back to a default theme file. The device-specific theme file can always be overriden by specifying the FEEDBACK_THEME environment variable
Dylan Van Assche