Try first the QCOM hardware LED types which require the most features of
LED drivers. Try until we have a single color GPIO LED which is the
minimal LED driver support we require. If the LED does not meet that
expectation either, we ignore the LED.
QCOM LPG LEDs can also operate in a multicolor fashion.
Re-use the probing sequence of multicolor LEDs and the hw_pattern
configuration of single color QCOM LPG LEDs.
QCOM LPG LEDs expose a hw_pattern sysfs entry which accepts a limited
set of patterns but allows to use dedicated hardware for blinking the
LED. This way, battery life can be improved and the LED still blinks,
even if the device is suspended.
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.
When all feedbacks are done the event signals "feedbacks-ended" which
lets the manager dispose the feedback. When all feedbacks end instantly
and synchronously (as is the case with the dummy feedback) this triggers
the disposal of the event within the loop leading to a crash.
Make sure the object doesn't go away be referencing it during the loop
iteration.
We didn't see this before as glib's slice allocator for lists papered
over this for us.
Closes: https://source.puri.sm/Librem5/feedbackd/-/issues/69
Everything related to multicolor moves into the new class and we add the
necessary getters and setters so derived classes can access the parent
classes attributes where needed.
Adjust to the one API change. We do it all in one commit to keep
bisectability. We use a slightly newer commit than 0.0.1 to include
build fixes for older glib (as required on PureOS Byzantium).
Loading the theme can trigger calls to
fbd_feedback_manager_get_default() which then results in an endless look
as the object isn't fully initialized in constructed. Instead do
the setup in main() which has the advantage that the manager's life
cycle becomes more obvious too.
Guido Günther
Dylan Van Assche