[Feature Request]: Choose what the User button does on single/double/triple click

[TheQWERTYCodr]

Platform

NRF52

Description

This feature has now been requested multiple times before:
#7829 #5004 #7949

Can we get some support for choosing any one of:

• what a single click does; currently it does nothing
• what a double click does; currently it sends a NodeInfo broadcast, but only if one hasn't been sent in the last 5 minutes, which is at best mildly useful
• what a triple click does; currently it toggles GPS on/off, which is somewhat useful but there's indication that some users would prefer a user-programmable action for the user button
• what multipress 4x and above do; currently they do nothing

This feature would greatly improve the experience on card-style devices with a single button, which I use because they're fairly cheap and generally pretty durable, and should also mildly improve user experience on devices with screens, as it should allow for quicker sending of set messages.

Alternatively, if repurposing existing single, double, and triple press isn't acceptable, having multipress 4x and above map to canned messages should work just as well.

In any case, can we get at least some support for such use cases? If necessary I can try to jump on and solve this shortly, but I haven't yet setup a development environment and if either option is clearly easy to implement then this can probably get done way faster by someone who's had some experience in the codebase (well, that and I'd rather not shoot myself in the foot with a band-aid fix that might make further enhancements near-impossible, thus I'm probably going to look over the existing code for a while before I try writing any of my own).

[TheQWERTYCodr]

One of the thoughts I had while brainstorming this is to rework input handling on single button devices to select out of a list of programmable actions (e.g. the current list of actions would be do nothing, broadcast nodeinfo, toggle gps). In my head this feels like the best route for customization and further enhancements, and is probably the route I'll start down when I get to attempting an implementation of this.

[DarkRanger935]

To say that a single-click on devices with one button does nothing is not accurate. it is presently multi-function by default, used to wake up the display if it is asleep, then each additional fast-click will advance to the next screen or menu option. A long-press of the same button will open a context-sensitive menu depending on which screen is open, and/or select the present menu option shown. I (and presumably many others) use this all the time, even without having to configure anything on my RAK4631 or Wio Tracker L1 pro units. I trust whatever gets changed isn’t going to break it for existing users, but other than that I’m all for adding configurable options. On Apr 29, 2026, at 03:27, TheQWERTYCodr ***@***.***> wrote:  [https://avatars.githubusercontent.com/u/93845040?s=20&v=4]TheQWERTYCodr created an issue (meshtastic/firmware#10338)<#10338> Platform NRF52 Description This feature has now been requested multiple times before: #7829<#7829> #5004<#5004> #7949<#7949> Can we get some support for choosing any one of: * what a single click does; currently it does nothing * what a double click does; currently it sends a NodeInfo broadcast, but only if one hasn't been sent in the last 5 minutes, which is at best mildly useful * what a triple click does; currently it toggles GPS on/off, which is somewhat useful but there's indication that some users would prefer a user-programmable action for the user button * what multipress 4x and above do; currently they do nothing This feature would greatly improve the experience on card-style devices with a single button, which I use because they're fairly cheap and generally pretty durable, and should also mildly improve user experience on devices with screens, as it should allow for quicker sending of set messages. Alternatively, if repurposing existing single, double, and triple press isn't acceptable, having multipress 4x and above map to canned messages should work just as well. In any case, can we get at least some support for such use cases? If necessary I can try to jump on and solve this shortly, but I haven't yet setup a development environment and if either option is clearly easy to implement then this can probably get done way faster by someone who's had some experience in the codebase (well, that and I'd rather not shoot myself in the foot with a band-aid fix that might make further enhancements near-impossible, thus I'm probably going to look over the existing code for a while before I try writing any of my own). — Reply to this email directly, view it on GitHub<#10338>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BW3AWNVNPFT6MNYZH6ZQUXL4YHKK3AVCNFSM6AAAAACYKSGNA6VHI2DSMVQWIX3LMV43ASLTON2WKOZUGM2DSNZTGI3DSNQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>