Not all Thinkpads generate events for volume hotkeys, so hook into the
CMOS update and generate events from there without polling. This should
let Pulseaudio do something sensible with the mute state.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/thinkpad_acpi.c | 32
On Thu, May 06, 2010 at 12:02:39AM -0300, Henrique de Moraes Holschuh wrote:
> Reading that stuff ain't cheap. Either a locked trip through the LPC bus
> for the CMOS nvram, or ACPI EC I/O (which is even worse, I fear. That EC is
> also hooked to LPC, and there's a lot more code involved).
>
>
On Wed, 05 May 2010, Matthew Garrett wrote:
> On Wed, May 05, 2010 at 08:30:05AM -0300, Henrique de Moraes Holschuh wrote:
> > The idea is sound, but it would be probably cleaner to do it only on those
> > thinkpads which need it. I don't like the idea of handling duplicate
> > notifications, and
On Wed, May 05, 2010 at 08:30:05AM -0300, Henrique de Moraes Holschuh wrote:
> The idea is sound, but it would be probably cleaner to do it only on those
> thinkpads which need it. I don't like the idea of handling duplicate
> notifications, and the logic depends entirely on nothing messing with
On Mon, 03 May 2010, Matthew Garrett wrote:
> Not all Thinkpads generate events for volume hotkeys, so hook into the
> CMOS update and generate events from there without polling. This should
> let Pulseaudio do something sensible with the mute state.
The idea is sound, but it would be probably cle
