Post author, excellent work on this; for future long press investigation:
> So the center button is now click-only: every debounced rise emits a fixed 60ms click pulse, and there are no hold semantics at all, because the chip can’t reliably report press duration.
This reliability point seems incorrect. The chip reports a valid press duration when less than 5 seconds have passed since the last plug-in or button press events; and, the chip reports an invalid press duration for presses of less than ~1.8 seconds when 5 seconds or more have elapsed since prior events. That is perfectly reliable behavior, and I expect the 5 second threshold is hard-coded into the OEM Mikey drivers to account for it. It’s perhaps unpalatable to consider coding support for that, and certainly I don’t fault the choice made here; but that’s not cause to label the design “unreliable”.
Looking at the long-press controls for wired earpods, this seems to have been accounted for by the software design: during playback, either you double- or triple-tap the button followed by a long press; or, during call scenarios, you long press in response to an incoming call event, or you long press while in a call. These are all compatible with the 5s sleep compromise; ‘pick up call’ and ‘hang up call’ can be reasonably allowed to take 1.9 seconds to be registered as a true long press, if they haven’t already forced the chip awake for responsiveness. Perhaps of more interest to Rockbox, however: during-playback long presses are always preceded by multi-taps, which I assume results in some interesting signal patterns that I don’t see explored by this writeup.
> So the center button is now click-only: every debounced rise emits a fixed 60ms click pulse, and there are no hold semantics at all, because the chip can’t reliably report press duration.
This reliability point seems incorrect. The chip reports a valid press duration when less than 5 seconds have passed since the last plug-in or button press events; and, the chip reports an invalid press duration for presses of less than ~1.8 seconds when 5 seconds or more have elapsed since prior events. That is perfectly reliable behavior, and I expect the 5 second threshold is hard-coded into the OEM Mikey drivers to account for it. It’s perhaps unpalatable to consider coding support for that, and certainly I don’t fault the choice made here; but that’s not cause to label the design “unreliable”.
Looking at the long-press controls for wired earpods, this seems to have been accounted for by the software design: during playback, either you double- or triple-tap the button followed by a long press; or, during call scenarios, you long press in response to an incoming call event, or you long press while in a call. These are all compatible with the 5s sleep compromise; ‘pick up call’ and ‘hang up call’ can be reasonably allowed to take 1.9 seconds to be registered as a true long press, if they haven’t already forced the chip awake for responsiveness. Perhaps of more interest to Rockbox, however: during-playback long presses are always preceded by multi-taps, which I assume results in some interesting signal patterns that I don’t see explored by this writeup.