| View previous topic :: View next topic |
| Author |
Message |
luismw
Tux's lil' helper
Joined: 04 Jan 2010
Posts: 91
|
 Posted: Fri Apr 09, 2010 12:11 pm Post subject: Lost some ACPI keys after kernel update |
 |
|
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. |
|
| Back to top |
|
 |
mikegpitt
Advocate
Joined: 22 May 2004
Posts: 3224
|
|
| Back to top |
|
|
luismw
Tux's lil' helper
Joined: 04 Jan 2010
Posts: 91
|
| Posted: Sat Apr 10, 2010 6:13 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
mikegpitt
Advocate
Joined: 22 May 2004
Posts: 3224
|
| Posted: Sat Apr 10, 2010 1:59 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
luismw
Tux's lil' helper
Joined: 04 Jan 2010
Posts: 91
|
| Posted: Mon May 17, 2010 8:45 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
mikegpitt
Advocate
Joined: 22 May 2004
Posts: 3224
|
| Posted: Tue May 18, 2010 1:31 pm Post subject: |
|
|
| 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.
| Code: | #!/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`;
|
|
|
| Back to top |
|
|
luismw
Tux's lil' helper
Joined: 04 Jan 2010
Posts: 91
|
| Posted: Wed May 19, 2010 7:05 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
|
Kernel & Hardware
