forked from len0rd/rockbox
28b9c8bfeb
In short, the display fading back in after a pause resuming interferes with the audio codec, causing BadThings(tm) that cannot be recovered from This really is just avoiding a known trigger; there's no guarantee this condition won't occur under random circumstances during normal use, and there's no good way to work around this from within rockbox. I suspect the underlying problem is that both the display control and codec control share an i2c bus, but the kernel drivers implementing them isn't using proper linux bus access/locking. Change-Id: Id4f56f9cb269ed74aac2f041146b3630cef09030
13 lines
322 B
C
13 lines
322 B
C
#ifndef __ROCKER_CODEC__
|
|
#define __ROCKER_CODEC__
|
|
|
|
#define AUDIOHW_CAPS 0
|
|
AUDIOHW_SETTING(VOLUME, "dB", 1, 5, -115*10, 0, -30*10)
|
|
#endif
|
|
|
|
//#define AUDIOHW_MUTE_ON_PAUSE
|
|
//#define AUDIOHW_NEEDS_INITIAL_UNMUTE
|
|
|
|
/* Note: Due to Kernel bug, we can't use MUTE_ON_PAUSE with backlight fading */
|
|
|
|
void audiohw_mute(int mute);
|