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.
For applications this is figured out automatically but notification
daemons and portal implementations might want to override it to have the
per-app feedback profile picked up automatically.
We can return the const *. This makes it consistent with other getters.
This is an API change we didn't find any users and the API is declared
unstable.
Themes (other than the default theme) can specify a `parent-name` in the
json file. This theme will be used as a base for the theme. Events and
profiles of the children override those in the parents.
For this we move the lookup code into it's separate class and also add
tests.
Closes: #38
When no feedbacks are available (either because the requested event does
not exist in the theme or because the system does not have required
capabilities, e.g. no vibration motor or LED) feedbackd will emit a
"feedback-ended" signal (with reason LFB_EVENT_STATE_REASON_NOT_FOUND)
on DBus _before_ completing the event triggering DBus call.
Since the DBus call was not completed yet, LfbEvent will not have
learned it's ID yet and therefore not emit it's own "feedback-ended"
GObject signal.
In this case the test will timeout since the main loop is never quit.
Dylan Van Assche
Guido Günther
Chris Vogel
Evangelos Ribeiro Tzaras
Rasmus Thomsen