OS wide key emulation for NV14/EL18

[JimB40]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

• No OS wide key emulation (LUA only)
• No SYS/MDL/TELE keys emulation

Describe the solution you'd like

Coming back to key emulatiuon on NV14/EL14 that will render those radios fully functional

• OS navigation
• compatibility with LUA scripts without TouchUI ability.

There was long discussion here #985 and discord but without deliverable.

Proposal:

As for the switching my poroposal is to implement GF/SF function that will switch modes hat function between trimming and key emulation.

1. default behaviour is trimming
2. for those who dont need trimming - condition of GF/SF can be set to ON
3. for those who need both functions - condition of GF/SF can be set to switch (plenty of them in NV14/EL14)

Describe alternatives you've considered

No response

Additional context

No response

[JimB40]

To recap reacap discussion with @mha1

Hats will have two configurable modes

1. Work as trims (trim-mode)
2. Work as keys (key-emulation--mode)

Hat emu-keys binding redefine

How it works

• LeftHat-up emulaters SYS key
• LeftHat-right emulaters MDL key
• LeftHat-down emulaters TELE key
• LeftHat-left emulaters RTN key
• LeftHat-press is used to switch between modes.

1. When hats work as trims key-combo to switch to key-mode will be LeftHat-press and RightHat-press
   Presses are not used for trims so no trim position will be changed using this combo.

2. When hats work as key-emulation-mode, key-combo to switch to key-mode will be first LeftHat-press (OPT) then RightHat-press (ENTER)
   When LeftHat will be pressed, pressing RightHat (ENTER) will not generate event so UI navigation won't be affected

TODO:

• Key bindings according to picture.
• Configuration option for NV14/EL14 only "Hats function" - Trims only, Keys only, Switchable
• Change bootlader binding of RTN to unify key emulation scheme and update information at the bottom.
  Optionaly
• UI indicator to show what mode is selected
• Sounds "Trim mode", "Key mode"

[JimB40]

Final implementation

[richardclli]

A few points may need to be considered:

1. Configuration should have a model level (aka, radio default, model level can override), because planes need trims and not helis.
2. It will be good for mode switching can be controlled by SF/GF

[JimB40]

1. Configuration should have a model level (aka, radio default, model level can override), because planes need trims and not helis.

This can be done by another PR.
So far

• if you fly quads,helis only setiing will be mostly 'Keys Only'
• if fly planes (and Quads or Helis) setiing will be mostly 'Switchable' and default mode after power up is always 'Trims'
• if you are die-hard "It was good don't change anything" - "Trims only"

2. It will be good for mode switching can be controlled by SF/GF

IMHO this also for another PR. Step by step :)

[pfeerick]

1. Negative... it should be in this PR - it is in relation to its core configurability.

2. Agreed, another PR can implement that as an extension.

[mha1]

Please work out a specification to discuss before implementing the followup PR. How should it work (e..g. precedence of selections), how should it look in terms of UI elements (list, combo, switches, SF, entries contents).

[JimB40]

Then we don't need configuration setting on radio level only on model level.
Two leveles of same feature is is always more complicated to setup for user.

Hats Mode - configuration option should go there:

And be visible only for NV14/EL18

[pfeerick]

For the part remaining for this PR, it's relatively straightforward - have a look at the "Enabled Features" section ... you've already got the radio level "global" setting down... now it just needs something for model level, with the same options as available at the radio setup level, with an extra "Global" option.

companion_f3BtIvKkQJ.mp4

For the SF, I'm not even sure yet that there is a need for it, so leaving any thought of that for another time.

[JimB40]

And if we really decide to keep hats configuration feature on radio level. it should go to hardware screen here as "Trim Switches".

RADIO SETUP screen over time became mix of harware and UI related stuff that are not grouped properly in terms of UX and definetely needs to be redesigned (in 3.0 probably) but we should not add more hardware related stuff ot it.

[mha1]

@pfeerick I'm slightly confused:

• radio and model level "enabled features" UI allows Tabs(!) to be switched on or off
• the model level enabled features UI lists the same Tabs(!) as in radio setup -> there is now Hats mode Tab anywhere
• on radio level Tabs can just be selected on/off -> Hats mode has more selections option on radio level and all are different than on/off

I don't believe the enabled features section is the right place for radio and model level Hats mode selections.

[mha1]

I'd leave the Hats mode selection on radio level in radio settings (hw settings is just as good) and extend the Trims portion of model setup

Just add a line Hats Mode with options "Trims only", "Keys only", "Switchable", "Global" here for NV14/EL18 only (USE_TRIMS_AS_BUTTONS defined)

[pfeerick]

radio and model level "enabled features" UI allows Tabs(!)

you missed for now 😛 ... it may also be turning on and off features in the future such as ... shock horror... trims... rendering your option inaccessible as the Trims button will be completely missing 🤣 . Same as the trainer button will need to be turned off when the trainer tab is hidden.

I was suggesting:

• you've already got the radio level "global" setting done - (doesn't matter if the number of options are different)
• the model level setting would be the same as the radio level setting with the addition of "global" (trims only, keys only, switchable, global). Just needs a new heading "Hats mode"? (reuse the translation string?)

[JimB40]

Agreed. The GF/SF stuff in another PR

[mha1]

"the model level setting would be the same as the radio level setting with the addition of "global" (trims only, keys only, switchable, global). Just needs a new heading "Hats mode"? (reuse the translation string?)"

where exactly should that be? In Model Setup / Trims?

[pfeerick]

If in the future the "Enabled Features" screen does turn off the "Model Setup / Trims" button (as part of turning trims off UI wide), how will you access it if it's in "Model Setup / Trims"?

[mha1]

I'd play mega millions if I could predict the future:-)

Where under Model Setup would you put it?

[mha1]

A separate "Hats mode" button?

[JimB40]

Peter 'Enabled features' were intended to show/hide whole feature-sets than single feature.
Going this way we can start to think what will happen if we want to switch on/off Serial Ports or Calibration. Do we?
This path leads to wonderland called 'PR never done'.

[pfeerick]

Why is there a need for a button to have a screen for a single option in the first place (after all, it would be pretty lonely in there all on its lonesome🤭)? Stick it next to the ADC filter option. Which is a single feature, also with model and global level option.

[mha1]

Just asking what your preferences are. I'm ok with after ADC filter. It's easier to implement than a separate button. @JimB40 ok with this?

[mha1]

Is it ok to extend model data just for NV14 or is it better to have hatsMode permanently in?

PACK(struct ModelData {
  CUST_ATTR(semver,nullptr,w_semver);
 ...
  uint8_t   ignoreSensorIds:1;
#if defined(USE_TRIMS_AS_BUTTONS)
  uint8_t   hatsMode:2;
#endif
  int8_t    trimInc:3;            // Trim Increments
...
  uint8_t   showInstanceIds:1;
#if defined(USE_TRIMS_AS_BUTTONS)
  uint8_t   spare3:3 SKIP;
#else
  uint8_t   spare3:5 SKIP;
#endif
  int8_t    customThrottleWarningPosition;
...

[JimB40]

Not separate button.
MODEL SETUP>Trims screen (above)

'Hata mode is kind of 'set-and-forget' feature. No need to force user to scroll more MODEL SETUP screnn through unrelevant data

[raphaelcoeffic]

@mha1 I'm actually trying to get rid of these differences. The smarter move is to use CUST_ATTR(hatsMode, read, write), which will directly read/write to a variable stored separately in a file that is only linked into the target if necessary.

Please note that these attributes are not used for the emergency backup (similar to NOBACKUP(...))

[mha1]

@JimB40
This was Peter's words against using Trims: "If in the future the "Enabled Features" screen does turn off the "Model Setup / Trims" button (as part of turning trims off UI wide), how will you access it if it's in "Model Setup / Trims"?"

@raphaelcoeffic so just add CUST_ADDR(hatsMode, r_hatsMode, w_hatsMode) and do the USE_TRIMS_AS_BUTTONS conditional in r_hatsMode and w_hatsMode?

[raphaelcoeffic]

@mha1 that would be the most straight forward way, yes. You could also have some layer "in-between" where basically the storage code (r_hatsMode, w_hatsMode) is not aware of whether or not the feature is enabled. That allows you to delegate this decision to the board itself, and thus for instance be able to decide on run-time (ex: simulator).

[JimB40]

This was Peter's words against using Trims: "If in the future the "Enabled Features" screen does turn off the "Model Setup / Trims" button (as part of turning trims off UI wide), how will you access it if it's in "Model Setup / Trims"?"

if MODEL SETUP>Trims would be switched off in hypotetical-maybe-done-sometime-in-future option in "Enabled Features" I would change C++ code so hats are behaving like Keys, since user decided he/she have no interest about Trims.

I will reverse question.
What will you do in sucha a case with "Trims only" option in RADIO SETUP 'Hats mode" feature?
Need to be re-coded when introducing "Model Setup / Trims" on/off feature. Right?

For me bit academic "what-if" discussion when there is even no concept of hiding hardware-related features.

[pfeerick]

In the known **planned** future option, yes, that is one way it could work. And the reverse question is bunk.. radio level settings are not going to be turned off at model level, only features such as GVs and trainer which are split across both. The radio level setting remains unchanged regardless of what the model level setting is, as it is the default global setting, which can be overridden on a per model basis. Just like the ADC filter, just like with enabled features.

…

On Thu, 3 Aug 2023, 10:30 pm Robert, ***@***.***> wrote: This was Peter's words against using Trims: "If in the future the "Enabled Features" screen does turn off the "Model Setup / Trims" button (as part of turning trims off UI wide), how will you access it if it's in "Model Setup / Trims"?" if MODEL SETUP>Trims was switched off in hypotetical-maybe-done-sometime-in-future option in "Enabled Features" I would change C++ code so hats are behaving like Keys, since user decided he/she have no interest about Trims. I will reverse question. What will you do in sucha a case with "Trims only" option in RADIO SETUP 'Hats mode" feature? Need to be re-coded when introducing "Model Setup / Trims" on/off feature. Right? For me bit academic "what-if" discussion when there is even no consept of hiding hardware-related features. — Reply to this email directly, view it on GitHub <#3202 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KMWIRTXQCGTQSLM2XLXTOKXVANCNFSM6AAAAAAU7H2LPU> . You are receiving this because you were mentioned.Message ID: ***@***.***>