I get one step per press instead of a ramp on a Hisense U6G (Android 11 TV), and only while Key Mapper's accessibility service is on. Disable the service and holding the volume button ramps normally again.
Some context that seems to matter: on this TV the volume is applied to a receiver over HDMI-ARC (AudioService logs "device cec"), and the remote does not generate key repeats at all. getevent during a 3 second hold shows exactly one DOWN and one UP, no repeat events. The repeats that end up driving the ramp are generated by the framework.
Measured with the same physical button and the same ~3s hold, only changing which accessibility services are enabled:
- none: 29 volume commands, 12 steps
- Projectivy Launcher only: 28 commands, 13 steps
- Key Mapper only: 2 commands, 0 steps
- Key Mapper + Projectivy (my normal setup): 2 commands, 1 step
So on this device it is Key Mapper's service specifically, not accessibility services in general.
With Key Mapper's service enabled the window manager never sees a repeatCount > 0 event. It gets the initial down, then a second down with repeatCount=0 about 145ms later that has no counterpart in getevent, then the up 2.6s after that. With the service disabled, repeatCount goes 0, 1, 2 ... up to 43 at roughly 50ms intervals and the volume ramps.
I could not find what in Key Mapper would cause this. Looking at 4.4.0, the consume paths I found are all gated on having a mapping (triggerKeysThatSendRepeatedKeyEvents is documented as only containing trigger keys flagged to consume, and DpadMotionEventTracker only matches dpad keycodes), and I have no volume buttons mapped. So maybe the repeats are dropped in the accessibility key filtering path rather than by Key Mapper itself, but it is definitely tied to enabling that one service.
Happy to run anything you want on the device to narrow it down. It is fine to close this as a duplicate of #2101 if you prefer, the measurements just do not match what is described there.
Setup: Key Mapper 4.3.1-foss, Android TV 11 (MediaTek m7322), audio out over HDMI-ARC with CEC volume.
I get one step per press instead of a ramp on a Hisense U6G (Android 11 TV), and only while Key Mapper's accessibility service is on. Disable the service and holding the volume button ramps normally again.
Some context that seems to matter: on this TV the volume is applied to a receiver over HDMI-ARC (AudioService logs "device cec"), and the remote does not generate key repeats at all. getevent during a 3 second hold shows exactly one DOWN and one UP, no repeat events. The repeats that end up driving the ramp are generated by the framework.
Measured with the same physical button and the same ~3s hold, only changing which accessibility services are enabled:
So on this device it is Key Mapper's service specifically, not accessibility services in general.
With Key Mapper's service enabled the window manager never sees a repeatCount > 0 event. It gets the initial down, then a second down with repeatCount=0 about 145ms later that has no counterpart in getevent, then the up 2.6s after that. With the service disabled, repeatCount goes 0, 1, 2 ... up to 43 at roughly 50ms intervals and the volume ramps.
I could not find what in Key Mapper would cause this. Looking at 4.4.0, the consume paths I found are all gated on having a mapping (triggerKeysThatSendRepeatedKeyEvents is documented as only containing trigger keys flagged to consume, and DpadMotionEventTracker only matches dpad keycodes), and I have no volume buttons mapped. So maybe the repeats are dropped in the accessibility key filtering path rather than by Key Mapper itself, but it is definitely tied to enabling that one service.
Happy to run anything you want on the device to narrow it down. It is fine to close this as a duplicate of #2101 if you prefer, the measurements just do not match what is described there.
Setup: Key Mapper 4.3.1-foss, Android TV 11 (MediaTek m7322), audio out over HDMI-ARC with CEC volume.