# asus eeepc 1015pem volume keys not working [SOLVED]

## mpharter

I have tried everything that i could think of to get the volume keys working.  Im pretty sure that they are not even being recognized.  I have tried to use the eeepc_laptop module but is just returns "No such device".  Those keys just worked in fedora so I know its possible.  I am running a 2.6.35 kernel.  

Anyone have any ideas?  Let me know what information you need.Last edited by mpharter on Mon Oct 18, 2010 5:40 pm; edited 1 time in total

----------

## psycho

 *mpharter wrote:*   

> Im pretty sure that they are not even being recognized

 

let's be sure about that first. run xev (emerge xev if it isn't already installed), and put your mouse cursor in the little white square. press some keys and see the kind of output you get if the x server recognises the key (it should output a keycode, keysym, etc.). does this work for your volume keys?

if so, all's well and you just need to bind something to those keys (aumix or whatever). if you get a keyCODE but no keySYM, this also is very easy to sort out: just use xmodmap to map them (e.g. something like keycode 123 = XF86AudioRaiseVolume).

if nothing's happening, you have a more serious problem. tap the problem key(s) a few times and check dmesg for output. if you're lucky, it will complain about an unknown key and you can simply fix it with setkeycodes. however...if you get NOTHING from anywhere, including dmesg, when you press those keys, then the kernel can't even see them: as far as your software knows that hardware just doesn't exist. this is the worst case scenario, and means you will need some kind of special module or kernel patch to get them working. the eeepc_laptop module sounds promising. at least you'll know that such a module has definitely been written, since it was working in Fedora. that's basically how you know this story will have a happy ending: if it worked in Fedora, it will work in Gentoo as well!

----------

## mpharter

no results with xev, other keys have results

nothing in dmesg about unknown keys.  

Well thats a start. Its a kernel issue or something.  Thanks. 

Any other ideas?

----------

## psycho

a couple of my laptops have required WMI extensions to get extra keys and so on working. in the kernel config menus it's under device drivers / x86 platform specific drivers / wmi, and then there are some options for asus laptops. this is only a guess though: your best bet is probably to google for someone else who's had trouble with their eeepc volume keys, and see what module(s) they enabled. as you say, "it's a start" that you now know your kernel isn't properly configured: chucking "kernel" into your google search terms should narrow things down a bit. i'd be very surprised if nobody else has had this problem (there must be lots of people running eeepc's with custom kernels).

----------

## Randy Andy

Hi Folks.

As an alternative you can use your working fedora kernel to copy its running configuration with zcat /proc/config.gz > /path/to/your/target/config

Also you could check with the help of lsmod which modules are loaded, compared to yours,so store its output too.

Later you can compare this config with yours, using kdiff for example.

Much success,

Andy.

----------

## mpharter

I have found a solution after goggling with better search terms.  I'm not sure why it works but adding 'acpi_osi=Linux' as a boot option allows the module to load.  

Thanks for your help guys.  Anyone know what that option does and why the module will not load without it?

----------

## psycho

i remember fiddling with the acpi_osi kernel parameter while trying to change a laptop's response to its lid switch. basically acpi handles low-level hardware stuff...generally power management, but this also includes responding to hardware events from the obvious power-button presses to things like changes in processor activity and even special buttons and other machine-specific stuff that can be defined by the manufacturer. i think through acpi the bios can actually query what os is running on it: by passing "acpi_osi=Linux" to the kernel, you're asking it to identify itself to acpi as Linux rather than some version of Windows. don't ask me why it doesn't do this by default anyway: my guess would be that some manufacturers assume Windows and so we lose some acpi functionality if we tell it we're running something else, but i don't know.

----------

