EdgeTX
feature(backlight): obsolete SF and allow for assigning a knob
Fixes #1844 Fixes #1637 Fixes #418 Fixes #53
Summary of changes:
- Special Function "Backlight" obsoleted
- Added a
Sourceparameter to the backlight settings (inRadio Setup).
Potential Bug/Confusion - because the special function has been ripped out, any prior configs now will substitute the trainer SF (although it is disabled).
General functionality seems to be working fine. Can we have the ON brightness slider update when the source is moved (when defined)? Since without looking at the code isn't this what the source is effectively changing?
This then just needs Companion support. And do we also crash the Volume party as well (in another PR!!) for double the complaints? :grin:
Volume would be nice. Then it would br complete. Maybe better to break it in one pr
And do we also crash the Volume party as well (in another PR!!) for double the complaints? 😁
Why not 😋
No, there were too many changes in between, and had to focus on fixing the bugs in other overhauled code rather than adding this.
While adding the radio settings to have backlight and volume assigned to knobs or sliders is nice I don't like the idea of removing the corresponding special functions.
There are likely to still be use case for the special functions (e.g. having a switch to mute the radio), and I think they should remain.
That discussion has already been had, and will not be happening. There still needs to be both Lua and SF triggers for these, so that logic and other model level configurations can override.
I have the feeling this going to be a hard fight...
There still needs to be both Lua and SF triggers for these, so that logic and other model level configurations can override.
The issue right now is: it is already quite complex and the logic behind all this is rather unclear. We should really simplify this one way or the other. Ideally, both backlight and volume should work in a similar way.
Also, I think we have a design problem with special functions in general:
- Special functions have been introduced to allow for some "programmability" in an easy. Most users love them.
- Special functions are executed in the mixer, which should normally be restricted to "things that influence channels" (directly or indirectly).
- Customising UI via SF is somehow a hack and has many drawbacks, that will come back to haunt us once we try to separate real-time flight related code (mixer, modules, ADC, switches) from UI/UX (display, sound, haptic).
So.... the question is: how do we retain "easy programmability" (I've heard a lot: "I can do SF, but no LUA, I'm no dev") but still split real-time from UI?
One way to do it (not pretending this is the only one) is to remove SF that are not related to real-time stuff, and thus have no business being executed in the mixer (or on anything running on a real-time MCU) and move these things to being "UI only", thus running solely in the UI task. As LUA code is not executed in real-time, but in the UI-task, it makes sense to allow for some customising from LUA code, as it does not break the bank.
What we cannot do is: keep executing UI-related SFs (backlight, volume, sound in general) from the mixer.
What we cannot do is: keep executing UI-related SFs (backlight, volume, sound in general) from the mixer.
Where the SF/GF get's executed is not important to end users - losing functionality is.
There is no reason that UI related SF/GF functions have to executed in the mixer task. They could just as easily be run from the UI task by splitting the execution logic out from the mixer task code.
Here is a rough split of what I mean:
@philmoz you would advocate for splitting the runtime? Like: 2 different evalFunctions(), each running a subset of SFs, based on the domain they belong to?
What we cannot do is: keep executing UI-related SFs (backlight, volume, sound in general) from the mixer.
Where the SF/GF get's executed is not important to end users - losing functionality is.
There is no reason that UI related SF/GF functions have to executed in the mixer task. They could just as easily be run from the UI task by splitting the execution logic out from the mixer task code.
You beat me in writing this.
Maybe we ca split them in the UI to two diferent sections, one for RT-related functions and one for UI-Related ones. Channel/input values need to be available to the UI code anyways for channel display and simmilar things, so it would be possible to still have them as inputs for UI-related SFs Generally speaking, the, much needed, split and interfaceing between UI and realime code needs to be planned well, to accomodate all the needs we have.
you would advocate for splitting the runtime? Like: 2 different
evalFunctions(), each running a subset of SFs, based on the domain they belong to?
Yes, if running things like backlight, volume, play sound/track/beep etc in the mixer is a concern.
Is there any reason why they could not be done in the UI task?
Here is a rough split of what I mean:
Nice picture, just the interface between non-RT and RT is missing
@philmoz you would advocate for splitting the runtime? Like: 2 different
evalFunctions(), each running a subset of SFs, based on the domain they belong to?
Sounds good to me.
you would advocate for splitting the runtime? Like: 2 different
evalFunctions(), each running a subset of SFs, based on the domain they belong to?Yes, if running things like backlight, volume, play sound/track/beep etc in the mixer is a concern.
Is there any reason why they could not be done in the UI task?
He did no write that this can not be in the UI-Thread. When we start looking into these thing, we have to start looking into thread-safety
Is there any reason why they could not be done in the UI task?
Nope, just discussed it with @3djc, he cannot find any reason for not doing it. It might have certain advantages as well, for example to be able to come up with something more deterministic and simple for volume/backlight control. ATM it is a pain as SFs/GFs are executed at their own pace while the UI task tries to figure out what the user actually wants.