Often the user doesn't realize that there are more menu items then displayed and the only way to tell was to try and move the selection to the bottom to see if another page appears.
This PR adds page up/down indicators if there are more menu items than those visible on the current display.
Uses the OSD arrow symbols when possible (for OSD supporting devices), otherwise the `^` (carat) and `V` are used for text-only represenatations.
To determine if the device was capable of displaying symbols the `displayPort` structure has a new `deviceType` set when it is initialized. There have been other times when knowing the type of device would have been useful so that's now supported. Then this is abstracted by a new `displaySupportsOsdSymbols()` function. Devices that support OSD are assumed to support the OSD symbols as the OSD element drawing code always uses them. For devices that don't support OSD function we have to presume the sybols aren't available.
Improves menu readability by changing the background from a transparent display of the camera image to a static opaque gray background.
The behavior is controlled with the `osd_menu_background` parameter which defaults to `TRANSPARENT` to preserve the previous behavior. Other opaque options are available:
```
osd_menu_background = TRANSPARENT
Allowed values: TRANSPARENT, BLACK, GRAY, LIGHT_GRAY
```
The background setting is available in the CMS OSD menu and the user can cycle through the various options with the display updating in real-time.
Currently only the onboard MAX7456-based OSD is supported, but the implementation adds `displayPort` support so it can easily be extended to other OSD devices if those manufacturers want to add support. Also can be extended to other background types (like colors, varying transparency, etc.) for future device support.
Makes use of the built-in MAX7456 feature to display all transparent pixels as "gray". The MAX7456 display area seems to be a few scan lines smaller than the actual camera video image so it's normal for some of the camera image to "leak" at the top/bottom of the display. The OSD display area can be adjusted up/down using the `vcd_v_offset` setting if desired.
Previous logic was always registering CRSL and SRXL as CMS displayPort devices regardless of whether the user was actually using that type of radio and telemetry.
The problem this caused is that if the user accidentally (or intentionally) used the CMS invoke stick command while already in the CMS on the MAX7456 the logic interprets this to mean "switch to the next registered displayPort device". So in this case the CMS would appear to exit based on what the user could see. But in reality it's still active and simply switched to the next (nonexistent) device. The user is then stuck and can't arm because the `CMS` arming disabled will be active and they have no way to interact with the CMS. They can technically blindly do the CMS stick command 2 more times to get back to the MAX7456, but how would they know that?
So this change only registers the CRSF and SRXL displayPorts when the user has selected those receiver types and enabled telemetry.
This is actually only a partial solution since it prevents registering the devices when they're impossible to work, but doesn't do anything for the actual CRSF or SRXL user that may be using equipment not capable of displaying the CMS. So it's still possible for them to get stuck in this situation. But I don't see any reasonable way to prevent this.
Perhaps it's time to rethink this "Switch to next CMS device" logic? It's something that nobody really knows about and seems to be more trouble than value. Maybe there are some edge cases where it's useful like using the OLED dashboard along with a MAX7456, but that's a rare use-case. Or possibly we need some explicit control where the user has to enable the particular displayPort device to be eligible for CMS?
Optimizes the display to use available space by calculating the label length vs. the screen size instead of a fixed 12 character limit.
For lookup table strings that are still too long the value is displayed as a scrolling ticker so the user can see the entire name.
Adds a `STICK COMMAND DISABLE SW` mode used to prevent inadvertant triggering of controls, calibrations, or settings changes. Useful for USB HID mode when using the flight controller as a joystick (and auto-detect doesn't work), in "team" or "relay" racing where multiple quads might be bound to the same transmitter, or just in general if the user wants prevent stick commands.
Will also prevent stick arming when the mode is active (but not stick disarming).
Moved to shared code and cms.c refactoring
Added missing line endings and comments
Passing tests - defines added
Added missing definition
Added check for USE_USB_CDC_HID in cmsUpdate
Code refactoring and condition change
Remove unnecessary include
Disable stick commands when HID is active and USB is connected
cdcDeviceIsMayBeActive refactored
Disable stick commands when HID is active and USB is connected
The CMS task was configured to run at 60hz but there was limiting logic in place to restrict it to every 50ms (20hz). Remove the extra logic and simply run the task at 20hz.
There was incorrect logic that checked if `(cmsDeviceCount < 0)` to not run the task. Firstly `cmsDeviceCount` can never be < 0, and secondly the task should not run when it is 0 as that means there are no registered `displayPort` devices. Generally fix the logic to used `unsigned` for `cmsDeviceCount`. It can only ever be increaded (new device registered) and there is no mechanism to "unregister" a device.
Lots of coding style cleanup.
Adds a dynamically constructed menu that will appear before the main menu when the user enters CMS if there are any outstanding setup items to complete. Currently only includes entry to calibrate the ACC if required, but provides a framework for other setup reminders as needed. The user can choose to exit this menu without remedying the problems, but the menu will reappear when they next enter CMS. If there are no required setup items then the menu will be skipped and the user will go straight to the main menu.
Makes the invert, black brightness, and white brightness update the display as the settings are changed rather than only taking effect once the menu is exited.
Significantly reduces the time the OSD task spends drawing elements that are completely or mostly static. The larger the element the more time savings are realized. Currently implemented support for:
- Crosshairs
- Artificial Horizon Sidebars
- Craft name
- Display name
- Stick overlay
Since the static portions are only rendered once, the static elements add no processing time to the OSD task. As an example, enabling the above elements prior to these changes results in a total rendering time of 47us. After the enhancements they take only 6us (basically the rendering phase minimum overhead). So effectively 41us are removed from the OSD task.
Opens the possibility to add large mostly static elements with no additional overhead. An example would be a camera framing element that might draw a "box" around most of the screen. Previously this would add significant processing overhead to the OSD task, but now it will have no impact.
Instead of having individual menus for RTC6705, SmartAudio, and Tramp, Now there is a single VTX menu that detects the type of active device and redirects to the appropriate protocol menu.
Reduces confusion and chances of erroneously using the wrong VTX menu.
Fixes a problem where the Tramp menu could be used to change band/channel/power even though the VTX was a SmartAudio device.
If the VTX is not configured or not communicating, a more informative message will be presented rather than a partially populated protocol menu. For example:
```
VTX NOT RESPONDING
OR NOT CONFIGURED
> BACK
```
Extends the CMS menu capabilities by adding an optional `redirectCheck` function that can conditionally return a menu that should be redirected to instead of the current menu. This redirect happens before any processing happens for the original menu. Adds flexibility to make the CMS menus have a more dynamic aspect.
CMS menu items can now be defined with a `REBOOT_REQUIRED` flag. If the user changes flagged elements the the exit/save options will change to `EXIT&REBOOT` and `SAVE&REBOOT` - ensuring that the changed items will be handled properly. This should be used for options where runtime changes either won't take effect (because they are read at boot), or for items that could have unexpected behavior if changed.
Several appropriate menus have been updated to include the flag.
To accomodate the dynamic nature of the save/exit options, the individual options have been removed from the main menu and replaced with a `SAVE/EXIT` submenu. This is the same menu that is presented as the quick-access popup save menu (yaw-right). This menu will adapt to requiring a reboot if any flagged setting is changed. Additionally the `REBOOT_REQD` arming disabled reason will be set (cleared by the reboot).
After commit d2e7abd the for loop following my change use pageMaxRow to determine which flags to clear.
But this pageMaxRow value is updated after the loop, which caused a crash in a very specific circumstance:
1 open the CMS OSD menu and go to profile
2 close the profile by yaw right, select exit
3 open CMS OSD menu and go to profile again
This caused a crash as runtimeEntryFlags wasn't cleared properly and the Copy Profile entry's flags still indicated OPTSTRING somehow.
which caused it's CMSEntryFuncPtr function to be cast to OPTSTRING and called without arguments.
Remove the giant `select` block that contained all the code to generate the elements and transition them to individual functions called only when the element is active. Simplifies the code and results in a performance improvement as it's not necessary to fall through the large `select` statement for every element that will be drawn. The individual functions and the element to function mapping are moved to a new `osd_elements.c` file.
Moved the OSD related code files to a new `osd/` directory.
Also pre-analyze the active elements and only process those that are active. This also saves processing as it's not necessary to loop through all 50 or so elements when only a couple are active.
Various other cleanup and removal of stale or unnecessary code.
In the default configuration the element drawing phase of the OSD task is reduced from ~51us to ~35us - resulting in about a 30% decrease in processing time.
Previously the runtime page state was mixed with the page configuration.
This resolves this by:
a) making the configuration entries constant so they do not need to be
in RAM.
b) Maintaining page state independently.
