For the Venu2s, the on-device value of DeviceSettings.inputButtons is 0xf whereas the simulator value is 0x89.
Of the devices I've tested so far, this is the only one I've seen with the discrepancy.
| Device | Device Val | Simulator Val | Notes |
|:---------------:|:-------------:|:-------------:|:--------------------:|
| fenix5plus | 0x9f | 0x9f | |
| fenix6 | 0x9f | 0x9f | |
| fr645m | 0x9f | 0x9f | |
| venu | 0x89 | 0x89 | |
| venu2s | 0xf | 0x89 | Fw 12.13 |
| vivoactive3m | 0x1 | 0x1 | |
As you can see from below, the 0xf implies that the UP and DOWN button are present on the Venu2s, which seems suspicious. The simulator value seems correct.
$ ./tools/supported-input-buttons 0xf
BUTTON_INPUT_DOWN
BUTTON_INPUT_MENU
BUTTON_INPUT_SELECT
BUTTON_INPUT_UP
$ ./tools/supported-input-buttons 0x89
BUTTON_INPUT_ESC
BUTTON_INPUT_MENU
BUTTON_INPUT_SELECT
Larger Context
One thing Runcasts needs to do is figure out what class of music player it will be dealing with: a Forerunner/Fenix button-based player, or a Venu/Vivoactive touch-based player. Now that dual-input devices are a thing (Fr955, Fenix7, etc), testing for touchscreen isn't sufficient, since those use a button-based player even though they have a touchscreen.
Runcasts was using the presence of the UP button as a way to distinguish these different devices:
UP and Touchscreen: DUAL_INPUT
Touchscreen: TOUCH_INPUT
Otherwise: BUTTON_INPUT
It then maps those input-types to the music player it expects to see: TOUCH_INPUT -> Venu-style, otherwise Button-based.
This bug is causing Runcasts to think it's dealing with a button-based music player, when in fact its really the Venu-style.
All this is to say, it'd be nice if there was a more explicit/blessed way of interrogating the system to figure out what kind of a music-player class an audio app is dealing with. Obviously, no-one wants to maintain a part-number mapping!
