As per DBus spec the `important` hint is meant to override
the global feedback level not any per app level the user
might have configured as otherwise there's no way to override
this.
Closes: https://gitlab.freedesktop.org/agx/feedbackd/-/issues/93
Signed-off-by: Guido Günther <agx@sigxcpu.org>
As noted in include/dt-bindings/leds/common.h in the Linux kernel, the Nokia
N900 has leds that use legacy naming. Until this naming scheme is removed from
the kernel, support it through the use of an additional FEEDBACKD_LED_COLOR
udev property, which must be set to the color corresponding to the LED.
Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com>
When determining the value for the rumble we assigned the result to the
value in the array thus potentially overwriting the value from the theme.
This goes unnoticed as long as we don't lower the global `max_strength`
below the magnitude. But when we e.g. set the `max_strength` to
zero the device will fail to rumble when we increase `max_strength`
later on again.
Steps to reproduce:
- Use an event that used `VibraRumble`, e.g. `button-press`
in the oneplus,fajita device theme
- `fbcli -E button-pressed` -> works
- set haptic feedback to 0%:
`gsettings set org.sigxcpu.feedbackd max-haptic-strength 0.0`
- set it back to 100%:
`gsettings set org.sigxcpu.feedbackd max-haptic-strength 1.0`
- `fbcli -E button-pressed` -> no feedback
Signed-off-by: Guido Günther <agx@sigxcpu.org>
This makes sure we e.g. prefer multicolor leds over single color ones
and those that can be on insuspend (qcom) over those that can't.
We can extend this to allow to set the priority via udev/hwdb in the
future.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
While in theory we could have themes with only freq = 0 values we
currently assume there can be patterns.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
We assume that multicolor LEDs are RGB so reject those that don't
have three components.
E.g. the Framework Laptop exposes a power button LED as multicolor
that only has a white component. This way it gets treated as single color LED.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Lets start at zero when not specified otherwise and also set an
arbitrary fade-in-time as setting it to the duration isn't very helpful.
While at that move the defaults to the feedback rather than the device
so we ensure consistency over different device implementations.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Lets not artificially cap the magnitude in the device specific
implementation.
Since the default magnitude for the common rumble feedback was set to
0.5 in the previous commit the effective magnitude in existing themes
remains unchanged for that event.
The pattern feedbacks didn't make it into a release yet so there's
nothing that could get broken.
The change doubles the effective when using the Vibra DBus API but as it
seems that libmanette didn't land support yet lets just ignore that
here.
Periodic feedback is unaffected as it uses a different internal API.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
We add a magnitude property and set it to 0.5 by default. This ensure
the relative magnitude stays the same when switching from 0xFFFF to
0x7FFF in dev-vibra.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
The carefree developer might try running meson test
before meson compile, leaving them with a failing integration test:
Start of lfb-integration tests
dbus-daemon[326641]: [session uid=1000 pid=326641 pidfd=8] Activating service name='org.sigxcpu.Feedback' requested by ':1.0' (uid=1000 pid=326640 comm="$(pwd)/_build/tests/te")
+ exec $(pwd)/_build/src/feedbackd
$(pwd)/_build/run: 18: exec: $(pwd)/_build/src/feedbackd: not found
Signed-off-by: Evangelos Ribeiro Tzaras <devrtz@fortysixandtwo.eu>
This wasn't much of an issue for the DBus API but when using
it as event feedback it matters as we might start the new
feedback just before the old one ended due to timers being
slighlty late.
If a custom sound is provided for the event, use that instead of the one
from the theme. We always add the sound event, even when the theme
doesn't have sound feedback for that event honoring the users choice.
Closes: https://source.puri.sm/Librem5/feedbackd/-/merge_requests/150
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Just check the elements on the event list. This makes it easier to
extend as we can't forget to toggle the variable.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
To trigger a 200ms rumble at 100%, a 50ms pause and a 300ms rumble at 50%:
busctl call --user org.sigxcpu.Feedback /org/sigxcpu/Feedback org.sigxcpu.Feedback.Haptic Vibrate 'sa(du)' org.foo.app 3 1.0 200 0.0 50 0.5 300
To cancel an ongoing pattern:
busctl call --user org.sigxcpu.Feedback /org/sigxcpu/Feedback org.sigxcpu.Feedback.Haptic Vibrate 'sa(du)' org.foo.app 0
The API has lower priority than the event based API to e.g. not miss
incoming phone calls or cell broadast messages.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Add a new class that takes an array of durations and magnitudes.
A magnitude of 0 indicates a pause.
We can consider dropping the VibraRumble class at some point as that
is a special case of VibraPeriodic now however as the feedbacks are
encoded in the themes let's make sure VibraPattern is good API before
deprecating VibraRumble.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
This allows the derived classes to perform the length duration
calculation. The parent class can thus still keep track of the total
feedback length.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Guido Günther
Sicelo A. Mhlongo
knoppix knoppix
Evangelos Ribeiro Tzaras
Sam Day