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

Rebased onto current main and 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

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

[Copilot]

Pull request overview

This PR adds a small Lua-facing API to let widgets/scripts detect whether touch input has been disabled via the existing “Disable touch” special function, addressing the need raised in #1085 without prescribing a UI/UX in firmware.

Changes:

• Added a touch-only, read-only Lua API getTouchEnabled() that reports !isFunctionActive(FUNCTION_DISABLE_TOUCH).
• Registered the function in the general Lua library only when HARDWARE_TOUCH is defined.
• Added a unit test covering both model and global special-function activation paths.

Reviewed changes

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

File	Description
radio/src/lua/api_general.cpp	Adds and documents getTouchEnabled() and registers it in the Lua general API on touch builds.
radio/src/tests/lua.cpp	Adds a touch-only Lua test validating behavior for model/global FUNCTION_DISABLE_TOUCH activation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[philmoz]

PR #7565 already solves #1085 with a popup

[bultodepapas]

Thanks for pointing this out. I missed that #7565 now also adds enabled/disabled touch popups and feedback when the user touches the screen while touch is disabled. That directly addresses #1085, so this additional Lua API is no longer justified by the issue. I am closing this PR to avoid adding duplicate API surface.

[pfeerick]

I think there is value in adding something along these lines anyway? While the still open #7565 may actually solve #1085 (which indicates the PR is altering more than it should be if it is just adding a SF), this PR is not really related to #1085 (more inspired from), but adding to the Lua API about the radio/UI state. There are more indicators like this needed in the Lua API, one of which I am working on now for the RGB leds.

[bultodepapas]

Follow-up: GitHub rejected reopening this PR because its head branch was rebased/force-pushed (state cannot be changed). The corrected, rebased successor is #7647.

The successor incorporates @pfeerick's post-close feedback, clarifies the special-function-only semantics, resolves both prior review concerns, and passes all 102 native radio tests.