Add virtual inputs and virtual switches

[wimalopaan]

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:

[3djc]

Please do not add something like this on bw, it will make scrolling a nightmare! (And likely Colors too)

[wimalopaan]

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?

[wimalopaan]

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()

[wimalopaan]

The complete API for the virtual controls (virtual inputs, virtual switches) now comprises the following LUA functions:

• setVirtualInput()
• getVirtualInput()
• activateVirtualInput()
• setVirtualSwitch()
• getVirtualSwitch()
• activateVirtualSwitch()

[wimalopaan]

@elecpower What does the label "needs: companion" mean?

[pfeerick]

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 <#5885 (comment)>, 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) <#5885 (comment)> @elecpower <https://github.com/elecpower> What does the label "needs: companion" mean? — Reply to this email directly, view it on GitHub <#5885 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KITPLMIV3EA3BY6IWT2XE34LAVCNFSM6AAAAABWYAJFTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRWGE2TAMJSHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wimalopaan]

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.

[elecpower]

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

[elecpower]

Also populate lookup lists eg sources and switches