EdgeTX
Add virtual inputs and virtual switches
This PR adds virtual inputs (Vin1 ... Vin16) and virtual switches (V01 ... V64) and neccessary LUA support functions
setVirtualInput()setVirtualSwitch()getVirtualSwitch()
A LUA widget lvglControls (see: https://github.com/wimalopaan/LUA/tree/main/WIDGETS/lvglControls ) is provided for demonstration a simple use case: extending the number of physical inputs and physical switches of the radio via a widget that provides some virtual touch controls for these virtual inputs and virtual switches.
Another purpose is to extend the amount of physical knobs, etc. of the radio by connecting some external device via serial (AUX1, AUX2) to the radio, and installing a custom widget, that reads from the serial and uses the above functions to set the virtual inputs and virtual switches.
A proposal for such a serial protocol can be found: https://github.com/wimalopaan/Electronics?tab=readme-ov-file#hwext
Rationale:
In the good old days there were radios like the FrSky X9E that provide a large amount of potentiometers and switches. This type of radio was/is very popular for controlling crawler/ships- or other functional-models. The number of these physical items is still limited and due to their physical nature, the labels for all these elements are also handwritten on paper.
With the advent of the lvgl LUA support it is possible to create virtual controls that perfectly fit into the UI look-and-feel of EdgeTx and also are not very compute-intensive. This opens the way to use widgets to provide arbitrary virtual controls and switches with customisable labes and colors. It also opens the way to use widgets to read from serials like AUX1/AUX2 and get controls data from some external devices (e.g. a µC with some physical potiometers, switches, incrementals, ... connected).
Alternative:
There is a cumbersome alternative way to achieve a similar but very limited result: a widget could use the function shmSet() to transport up to 16 values, to a mixer script which could pick them up via shmGet() and simple return them (only up to 6). These output values of the mixer script could then be used as mixer-inputs. There is no such a way for switches.
Example Widget:
Please do not add something like this on bw, it will make scrolling a nightmare! (And likely Colors too)
Please do not add something like this on bw, it will make scrolling a nightmare! (And likely Colors too)
On BW it should be not available (need to check COLORLCD)
On COLORLCD: why do you think scrolling would be an issue?
I added the possibility to explicitly activate a virtual control (input, switch). If no LUA script activates some virtual controls, they do not show up at all. A LUA script can activate some of them by using
activateVirtualInput()activateVirtualSwitch()
The complete API for the virtual controls (virtual inputs, virtual switches) now comprises the following LUA functions:
setVirtualInput()getVirtualInput()activateVirtualInput()setVirtualSwitch()getVirtualSwitch()activateVirtualSwitch()
Literally that - some form of Companion support needed. i.e. I guess Companion needs to know virtual sources/inputs exist so when you read/write it doesn't delete them all! ;)
On Mon, 31 Mar 2025, 10:59 pm Wilhelm, @.***> wrote:
@elecpower https://github.com/elecpower What does the label "needs: companion" mean?
— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/pull/5885#issuecomment-2766150129, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KITPLMIV3EA3BY6IWT2XE34LAVCNFSM6AAAAABWYAJFTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRWGE2TAMJSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***> [image: wimalopaan]wimalopaan left a comment (EdgeTX/edgetx#5885) https://github.com/EdgeTX/edgetx/pull/5885#issuecomment-2766150129
@elecpower https://github.com/elecpower What does the label "needs: companion" mean?
— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/pull/5885#issuecomment-2766150129, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KITPLMIV3EA3BY6IWT2XE34LAVCNFSM6AAAAABWYAJFTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRWGE2TAMJSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Ok, think I need some advice here ;-)
In firmware/simulator a widget activates virtual sources / switches. This is to prevent littering the sources lists / switches lists with unused virtual controls. The question is now how to emulate this activation process, since widget installation in simulation started from companion is not persistent. So, this activation hast to be done by other means. Maybe an extra dialog for the model config? But that wouldn't exist in firmware/simulator.
As a guide Companion:
- must be able read and write the yml files without data loss or corruption (not negotiable);
- update radio and model settings editing to support maintenance of the feature as radio firmware (unless performed using lua as it is not currently implemented in Companion or reliant on radio firmware runtime environment eg receiver capabilities or custom hardware mods)
- update two-way interfacing between simulator and libsimulators including "faking" the runtime environment for the libsimulator
I'd rather see virtual inputs symbols with VIxx syntax. Using 2 capital letters.
I'd rather see virtual inputs symbols with VIxx syntax. Using 2 capital letters.
... and rename virtual switches to VSxx.
After thinking about this, I have to say it feels very risky to me.
Anything that requires a user to look away from their model puts not only the model; but more importantly other people, at risk of injury or worse.
Implementing something that can only be used reliably by looking at the screen should be considered very very carefully.
I know there are use cases with lower risk (slow crawlers, etc); but once this is out there we have no control over how it will be used.
I believe we have a level of responsibility to consider the potential safety impact.
Whist I do agree with @philmoz on the risk of looking down at a screen whilst operating a model there are currently plenty of use cases where this behaviour occurs. The current code does not turn off all the screen widgets when the throttle is active. The is no restriction on which radio is used for operating which model types.
Consider the family vehicle, other than the local road rules, nothing stops you driving the vehicle at high speed and operating the in-built dash touch screen and that is way more risky. The manufacturer just sticks a start up warning on the screen.
The current code does not limit the uses to which the object containing the receiver(s) is put be that in error or deliberately. Ever seen the TV show Battle Bots, that is some serious destructive power in a controlled environment. But who says you cannot build a similar vehicle and run amok in your neighbourhood.
There are plenty of instances already where people look away from the model while it is in operation, i.e. even changing settings in flight... We have zero control over that ... all we can do is recommend that you don't do that. The same goes with having critical controls not directly controlled by physical controls (I won't mention my LS arming switch chain... although I do have a mix line override tied to "trim" switches). At the end of the day, as long as we make sure this works how it should work, the onus is on the operator, not us (we're not their parents). And for models with lots of effects (like boats, construction equip, cars with bling and other non-essential controls) I think this will be greatly appreciated. Mainly just needs Cpn support and testing.
I can do Companion side but only after there is agreement on it progressing on the radio side as there is not insignificant effort on my part. I have a long todo list as it is.
Well, I do not want to feed the discussion about things that attract the pilots/captains away from their models: there are so many and the range goes from talking to each other up to steering more than one model at the time. If you want to go that route you have to ban all radios with displays at all ...
@elecpower I would be more than happy if you could look at the cpn part. I left that out because it have too less experience doing Qt stuff.
This PR is in use on plenty of radios of rc-ships/function models, mostly in combination with the corresponding widget: https://github.com/wimalopaan/LUA/tree/main/WIDGETS/lvglControls
After thinking about this, I have to say it feels very risky to me.
Anything that requires a user to look away from their model puts not only the model; but more importantly other people, at risk of injury or worse.
Implementing something that can only be used reliably by looking at the screen should be considered very very carefully.
I know there are use cases with lower risk (slow crawlers, etc); but once this is out there we have no control over how it will be used.
I believe we have a level of responsibility to consider the potential safety impact.
I agree on the responsibility thing, that is one of the main reasons we do not implement a way to switch to a different model via Lua or a switch. Here, to me, the situation is a bit different. Most of what this PR does was already possible, but just a bit more difficult and with some restrictions regarding the number of inputs. So we do not actually add something dangerous that has not been possible before.
I'm in agreement with Phil and the ownership of responsibility mentioned by Malte, but I'm also against it for yet another reason: those would be controls not protected by watchdog reset.
Create a common input layout for all radios #9
This is now also possible? Are these new inputs and switches to be named like inputs and switches?
If so, just decide on a minimum that will always be there and your model files become interchangable on this aspect. No?
Possible, perhaps, but there has not been of any work towards that of late. And that is not pertinent to this PR... which is adding two new types of inputs.
Ok. It is what it is. I just hoped someone would have seen how a different way to achieve what is done in this change, could have improved model portability between radio's at the same time. But i do understand your reply.