InkHUD: Allow non-system applets to subscribe to input events

[Vortetty]

Adds a way for applets to subscribe to input events, with the default being that no inputs being consumed to preserve compatibility and expected behaviours. Adds example for use/testing as well. Discussed here prior to pr.

Useful for user applets that need to do more than display information, without creating a system applet popup when you want to use controls. Users of this will need to remember to provide a way to stop capturing inputs and/or a way to go to the next user applet. They will also need to account for control scheme differences with vs without joystick.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other: Seeed Wio Tracker L1 E-ink

Will need tested on another inkhud device, likely one without a joystick.

[github-actions]

@Vortetty, Welcome to Meshtastic!

Thanks for opening your first pull request. We really appreciate it.

We discuss work as a team in discord, please join us in the #firmware channel.
There's a big backlog of patches at the moment. If you have time,
please help us with some code review and testing of other PRs!

Welcome to the team 😄

[fifieldt]

I like the idea of having hooks enough that users can add their own apps!

[Copilot]

Pull request overview

This pull request adds an opt-in input event subscription system for InkHUD user applets, enabling them to handle input events directly without triggering system applet popups. This is useful for interactive user applets that need more than just displaying information.

Changes:

• Added input subscription mechanism with per-input-type granularity using bitmask flags (InputMask enum)
• Modified all input event handlers in Events.cpp to check if the active user applet wants to consume the input before falling back to default behavior
• Added example applet (UserAppletInputExample) demonstrating how to subscribe to and handle various input events

Reviewed changes

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

Show a summary per file

File	Description
src/graphics/niche/InkHUD/Applet.h	Adds InputMask enum, subscribedInputs field, and methods isInputEnabled() and setInput() to support input subscription
src/graphics/niche/InkHUD/Applet.cpp	Implements setInput() and isInputEnabled() methods for managing input subscriptions using bitwise operations
src/graphics/niche/InkHUD/WindowManager.h	Adds getActiveApplet() method declaration to expose the currently focused user applet
src/graphics/niche/InkHUD/WindowManager.cpp	Implements getActiveApplet() to return the applet assigned to the currently focused tile
src/graphics/niche/InkHUD/InkHUD.h	Exposes getActiveApplet() at the InkHUD API level
src/graphics/niche/InkHUD/InkHUD.cpp	Implements InkHUD::getActiveApplet() wrapper that delegates to WindowManager
src/graphics/niche/InkHUD/Events.cpp	Modifies all input event handlers to query the active user applet and route events to it if subscribed, otherwise using default behavior
src/graphics/niche/InkHUD/Applets/Examples/UserAppletInputExample/UserAppletInputExample.h	Header for example applet demonstrating input subscription feature
src/graphics/niche/InkHUD/Applets/Examples/UserAppletInputExample/UserAppletInputExample.cpp	Implementation of example applet that toggles input grabbing and displays last received input

[Vortetty]

I like the idea of having hooks enough that users can add their own apps!

That's the idea with it. The Applet system already has user Applets which are scrolled through normally, but right now they can only do info display.
Mentioned on discord were potential uses like zooming in/out on the node map as well as for scrolling in lists.
I am also looking into using it for very lightweight games that could potentially be added similar to the Chippy pet or a minesweeper clone.

I'd be curious if anyone else has any potential usecases or suggestions for this? The API's naming scheme was recently made more consistent, though it may need more work. And i am not 100% sure if adding getActiveApplet() is necessarily the best option for what it accomplishes.

[Vortetty]

To expand on the above, using a SystemApplet would generally be silly for most people's usecase. You'd then have to add custom controls to access it or more buttons in the menu, both of which generally overkill. The other option is to make a normal user Applet which brings a SystemApplet to the foreground, which is unnecessarily convoluted.

One downside to this system is that it currently has no way to force release of control, so a poorly programmed Applet could lock the user there until they restart the node. However this should not meaningfully affect any finished products due to how easy it is to catch.
Adding such a method to force release would also have the potential to interfere with the applet's function, since an applet could conceivably take any pattern of inputs in normal use.