feat(lua): expose Disable Touch state

[bultodepapas]

Summary

• add a read-only getTouchEnabled() Lua API on touch-capable builds
• expose the existing effective FUNCTION_DISABLE_TOUCH state used by the input path
• document the API semantics and cover both model and global special-function activation

Motivation

Lua widgets and applications need access to radio/UI state so they can present that state in custom interfaces. This API is not intended to replace the firmware feedback discussed in #1085 or implemented by #7565; it is a general capability for Lua consumers.

Examples include a top-bar indicator, a custom control surface, or future widgets that combine touch state with other radio-state indicators.

Semantics and scope

getTouchEnabled() is available only on HARDWARE_TOUCH builds. It returns false while a model or global Disable touch special function is active.

The result represents that special-function state only. A true result does not guarantee that touch events are currently accepted because the touch driver can suppress input for other reasons, such as while the backlight is off.

Validation

Built the TX16SMK3 native radio test target in the official EdgeTX development container:

• Lua.TouchEnabled: 1/1 passed
• Lua test suite: 7/7 passed
• full native radio test suite: 102/102 passed

Upstream GitHub Actions also passed completely:

• 23/23 test jobs
• 19/19 firmware-build jobs
• final firmware packaging

The 3.0.0 Lua documentation tag matches the version declared by current main.

Supersedes #7593. GitHub does not allow that closed PR to be reopened because its head was rebased/force-pushed. This revision incorporates the post-close maintainer feedback and resolves both prior review threads.

[bultodepapas]

@pfeerick, this is the clean successor to #7593 following your post-close feedback. It is now framed as a general Lua radio/UI-state API, rebased onto current main, and validated with all 102 native radio tests. Could you review the API direction when convenient? The contributor account cannot formally assign upstream reviewers.

[Copilot]

Pull request overview

This PR adds a small, touch-hardware-gated Lua API to let Lua widgets/apps query whether the firmware’s “Disable touch” special-function state is currently active, matching the state already used in the input/UI path.

Changes:

• Added getTouchEnabled() to the general Lua API on HARDWARE_TOUCH builds, returning true unless FUNCTION_DISABLE_TOUCH is active.
• Documented the API’s semantics (special-function state only; not a guarantee the driver is accepting touches).
• Added a Lua unit test covering both model and global special-function activation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
radio/src/lua/api_general.cpp	Adds the getTouchEnabled() Lua binding (touch-only) and luadoc entry.
radio/src/tests/lua.cpp	Adds a touch-only Lua test verifying behavior for model vs global disable-touch state.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[3djc]

I think it should return nil when no touch is present:

• ensure it doesn't break by syntax error on non touch radio
• Indicates no touch screen is installed on those where this is optional

[pfeerick]

The current implementation is focused on FUNCTION_DISABLE_TOUCH SF/GF, while using a more generic getTouchEnabled naming... so I agree on that premise... given the identification that the backlight being off might also reject touch input... it wouldn't hurt to dig a bit more also to see if the current backlight state can be considered also... or left as a documented limitation if it would require too much rework.