# Lost some ACPI keys after kernel update

## luismw

Hi, I have just updated from gentoo-sources 2.6.31-r10 (I think it was r10, the one that that was stable yesterday in any case) to gentoo-sources 2.6.32-r7. I compiled the new kernel after a simple 'make oldconfig' and accepting all the default answers.

Everything is working fine, except that the keys I used to adjust the sound volume aren't working, they don't generate and ACPI event now. How can I get them to work again? Looking for a kernel patch? Some new config option I missed? Using an alternative to ACPI?

My PC is an Asus Eee PC S101 (which is hardware-wise practically the same as the 901, or was it 1001?).

Thanks.

----------

## mikegpitt

The 2.6.32 kernel has some ACPI regression issues.  I have a thread open here about the LID event not triggering properly:

https://forums.gentoo.org/viewtopic-t-807468-highlight-.html

Of note, look at this bug report:

http://bugzilla.kernel.org/show_bug.cgi?id=14667

It looks like a patch has been developed and will be rolled into 2.6.34.  I'm not exactly sure if this will fix your issues as well, but it seems likely.

----------

## luismw

In my case the lid events still work, but in any case it probably is the same problem. I guess we'll have to wait for 2.6.34.

One question, though: if this is a known bug, and there is a patch available, how come this kernel is marked as stable? Or, if it is marked stable, why not add the patch to gentoo-sources? This is not a complaint, I'm just trying to understand what's the difference between vanilla kernel and the gentoo sources that are released a while later.

----------

## mikegpitt

 *luismw wrote:*   

> One question, though: if this is a known bug, and there is a patch available, how come this kernel is marked as stable? Or, if it is marked stable, why not add the patch to gentoo-sources? This is not a complaint, I'm just trying to understand what's the difference between vanilla kernel and the gentoo sources that are released a while later.

 There are a lot of open bugs in the kernel sources.  Most of the time they will have little effect on you, but in this case it looks like we both got bitten.  Gentoo simply follows the kernel release schedule and marks the kernel sources stable after some QA process.  Bugs like this won't really affect the Gentoo devs from marking sources as stable, since it's an upstream issue and only affects some users.

The reason you won't see this patch in gentoo-sources, is because gentoo-sources simply adds a handful of gentoo specific patches to the vanilla-sources.  This type of bug fix will need to wait for an integration with the vanilla-sources (the release from kernel.org) before it makes its way into gentoo.

----------

## luismw

I've tried vanilla kernel 2.6.34 today and the issue persists   :Crying or Very sad: 

How can I have the system react to keys that don't even register on acpi_listen?

----------

## mikegpitt

 *luismw wrote:*   

> I've tried vanilla kernel 2.6.34 today and the issue persists  
> 
> How can I have the system react to keys that don't even register on acpi_listen?

 Hmm... that patch should have been rolled into the 2.6.34 kernel.  I haven't tried it myself, but according to the kernel bugzilla it should be there.

Since your issue is related to the volume buttons you might be able to create a workaround based on key presses.  You can use xbindkeys to bind your volume keys to a script that raises/lowers your volume.  You can get the proper key codes with xev.  This is actually what I use on my laptop to control volume, since those keys have never worked for me on pretty much any laptop I've owned.

Here is the script I use if you need it.  It controls volume via the Front channel.  You can un-comment the PCM lines and comment the Front lines if you want to control it via PCM instead.  You call the script with the parameter 'up' or 'down' (without quotes) to increase / decrease the volume.  

```
#!/usr/bin/perl

$CURRENT = `amixer get Front`;

#$CURRENT = `amixer get PCM`;

$CURRENT =~ s/\n/ /g;

$CURRENT =~s/^.* Playback ([0-9]+).*$/$+/;

if      ($ARGV[0] eq up)        { $volume = $CURRENT + 1; }

elsif   ($ARGV[0] eq down)      { if ($CURRENT > 0)

                                        { $volume = $CURRENT - 1; }

                                  else

                                        { $volume = 0; }

                                }

`amixer set Front $volume`;

#`amixer set PCM $volume`;

```

----------

## luismw

Thanks a lot for your suggestion. Sadly, xev does not detect the volume keys, maybe that's a problem with the kernel. It does detect all the fn+F key combinations that already work, such as brightness up or down and wireless toggle.

I'm going to try just making up a combination using, for instance, the super_L key instead of the fn key.

----------

