I have an ASUS 3500 laptop which has some extended buttons. The linux kernel 2.6 has some features to access brightness and monitor state in the proc filesystem.
I have certain keys (FN and a function key; FN-F1 eg) that control screen brightness, screen state (on/off). These work fine on Windows. On Linux they work too, but they take an extreme long time to do the action, for example, when I press the increase brightness button, it takes the system around 30 seconds to do so, same with switching off and on the screen. I suppose I should tell the kernel to somehow stay away from these interrupts. Unfortunately I do not know how. Any ideas?
Fn keys are making a lot of p
all i know about them i that they send interrupts to ACPI and acpi is a mystery ! ! !
the best things in life are free --- so as myself
Acpi is not a mystery ( at le
Acpi is not a mystery ( at least to me ).
Two places to start looking:
Make sure you have loaded the acpi module:
modprobe asus_acpi
and then run the acpi daemon to catch the events. The acpi daemon needs to be configured as to what actions to take on events.
Try to boot with the following boot parameter:
acpi=off
This should allow the laptop to revert to apm. If things look better then your acpi is broken.
In the unfortunate case of broken acpi:
It's never over till it's over.
so if Fn keys like TVOUT or s
so if Fn keys like TVOUT or suspend or BRIGHTNESS send interrupts to ACPI, what happens if i disable ACPI where would thos interrupts go?
the best things in life are free --- so as myself
no where they are ignored. or
no where they are ignored. or maybe not generated.
It's never over till it's over.
Module loaded
The module is loaded, now one thing I've noticed, is when I press the suspend button in gnome (which obviously usues apm -s) and error pops up saying the command has failed, does this mean I don't have apm in my kernel ?
you can't have both running a
you can't have both running at the same time, so all you need to do is pass to the kernel acpi=off apm=on and make sure the apmd server is runing
the best things in life are free --- so as myself
If both are compiled into the
If both are compiled into the kernel ACPI takes the upper hand, unless acpi=off is passed. In this case acpi is not activated and apm works.
However if acpi is built into the kernel and apm is a module you have to turn off acpi by booting with acpi=off and then doing modprobe apm
If both are modules, you have to figure out how to stop your distro from probing the acpi modules and make it probe the apm modules instead.
It's never over till it's over.
I have no clue what I am doing !
Ok, now I've followed the steps in that wikipage and found out I do have a buggy ACPI (whatever this means). I do not quite understand what I've been doing actually does, what is a DSTD ? and what's that info I've cat'ed from /proc/acpi/dsdt ?
What is the acpica or iasl compiler by intel ? What is ASL ? What is AML ? and what I am disassembling here and what amd I reassembling again ?
Disassembling obviously succeeded, then on reassembling I got this error: root@mind:/home/mohammed/acpi/acpica-unix-20050513/compiler# ./iasl -tc file.dsl Intel ACPI Component Architecture Copyright (C) 2000 - 2005 Intel Corporation Supports ACPI Specification Revision 3.0 file.dsl 7834: If (SS1) Error 1037 - ^ parse error, unexpected PARSEOP_IF ASL Input: file.dsl - 7844 lines, 271359 bytes, 3608 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
Now as the file is around 8000 lines long, I'd rather mail it if someone is interested to debug, because I haven't found anything wrong with the code honestly. Thanks
Email it to me, I'll see what
Email it to me, I'll see what I can do about it.
It's never over till it's over.
Uhhm sorry
Don't want to appear stupid, but I couldn't dig up your e-mail
Look in your private. It
Look in your private.
It's never over till it's over.