![]() |
|
|
#1 |
|
Guest
Posts: n/a
|
ACPI and governors on AMD laptop under Slackware 12
Would someone be kind enough to point to resources describing how to set up ACPI on Slackware 12 on a laptop, such as which modules to load, which governor to use, how to set it all up? I've a Dell Inspiron 1501 with Mobile AMD Sempron(tm) Processor running Slackware 12. KLaptop is configured. /etc/rc.d/rc.modules is edited to load the following modules on boot-up: ac, asus_acpi, battery, button, container, dock, fan, processor, thermal, video. acpi_cpufreq fails to load. I've cpufrequtils installed. However, `cpufreq-info` complains that there is 'no or unknown cpufreq driver active for the CPU', and I can't find documentation on how to use `cpufreq-set` (the man page is a tab bit too brief). I tried `cpufreq-set -g ondemand` to load the ondemand governor, but that didn't get anywhere. Also, there seems to be no `cpufreq` directory under `/sys/devices/system/ cpu/cpu0/`. A web page that described setting up slackware-10.2 on the author's ThinkPad mentioned also loading cpufreq_conservative, cpufreq_stats modules. If I modprobe them, they get inserted into memory just fine, but I am not sure what difference they make. Thanks. -- Ayaz Ahmed Khan |
|
|
|
#2 |
|
Guest
Posts: n/a
|
Re: ACPI and governors on AMD laptop under Slackware 12
Ayaz Ahmed Khan wrote:
> Also, there seems to be no `cpufreq` directory under > `/sys/devices/system/ cpu/cpu0/`. I did some research and found out that `acpi_cpufreq` is for Intel motherboards only. Loading powernow-k8 enabled CPUFreq Scaling for the AMD Mobile Sempron 3500+ running on the laptop. I have configured the governor to be used to `ondemand`, and apparently it seems to be working. Is there a need to add anything to /etc/acpi/acpi_handler.sh to capture and react to various events? For example, when the system switches between plugged-in and battery states, the following show up in /var/log/ messages: logger: ACPI group ac_adapter / action ACAD is not defined logger: ACPI group battery / action BAT1 is not defined I am assuming /etc/acpi/acpi_handler.sh need be set properly. Are there any references respecting setting that up? -- Ayaz Ahmed Khan |
|
|
|
#3 |
|
Guest
Posts: n/a
|
Re: ACPI and governors on AMD laptop under Slackware 12
On 2007-11-18, Ayaz Ahmed Khan <ayaz@dev.null> wrote:
> Ayaz Ahmed Khan wrote: > >> Also, there seems to be no `cpufreq` directory under >> `/sys/devices/system/ cpu/cpu0/`. > > I did some research and found out that `acpi_cpufreq` is for Intel > motherboards only. Loading powernow-k8 enabled CPUFreq Scaling for the > AMD Mobile Sempron 3500+ running on the laptop. I have configured the > governor to be used to `ondemand`, and apparently it seems to be > working. > > Is there a need to add anything to /etc/acpi/acpi_handler.sh to capture > and react to various events? For example, when the system switches > between plugged-in and battery states, the following show up in /var/log/ > messages: > > logger: ACPI group ac_adapter / action ACAD is not defined > logger: ACPI group battery / action BAT1 is not defined > > I am assuming /etc/acpi/acpi_handler.sh need be set properly. Are there > any references respecting setting that up? Well, there are a few around. This doesn't deal with the power button, but the general idea is the same. Here's an example that I have for suspend2ram when my lid is closed: liberty $ cat /etc/acpi/events/lid # Optionally you can specify the placeholder %e. It will pass # through the whole kernel event message to the program you've # specified. event=button/lid.* action=/etc/acpi/actions/lid.sh %e liberty $ cat /etc/acpi/actions/lid.sh #!/bin/sh # Suspend to ram when the lid is closed # First, let's make sure we're not shutting down or rebooting if [ ! -e /etc/powerdown ]; then sync ; sync # Just in case... echo -n mem > /sys/power/state fi Yes, in case you're wondering, there is a bit of customization in that last script. I hate when I shut down the system and then immediately close the lid of the laptop, because it will suspend to ram, and then when I open the lid sometime later, the shutdown finishes... :-) So... I made a slight modification to /etc/rc.d/rc.6 to create the /etc/powerdown file when rc.6 is run, and rc.M removes the file on startup. There's probably more elegant ways to do it, but this works for me :-) -RW |
|
|
|
#4 |
|
Guest
Posts: n/a
|
Re: ACPI and governors on AMD laptop under Slackware 12
Ayaz Ahmed Khan wrote:
> ... I've added bits to alter brightness levels of the LCD whenever the > special Fn key-sequences to toggle brightness are pressed. I bet some would appreciate if you shared details. For example, what receives the key-presses, and how do you tell which key was pressed? I've been wanting to add this functionality to my own laptops (and to some extent, a couple of desktops, too) for some time. -- ---------------------------------------------------------------------- Sylvain Robitaille syl@alcor.concordia.ca Systems and Network analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ---------------------------------------------------------------------- |
|
|
|
#5 |
|
Guest
Posts: n/a
|
Re: ACPI and governors on AMD laptop under Slackware 12
Sylvain Robitaille wrote:
> Ayaz Ahmed Khan wrote: > >> ... I've added bits to alter brightness levels of the LCD whenever the >> special Fn key-sequences to toggle brightness are pressed. > > I bet some would appreciate if you shared details. For example, what > receives the key-presses, and how do you tell which key was pressed? > I've been wanting to add this functionality to my own laptops (and to > some extent, a couple of desktops, too) for some time. I have been meaning to write a detailed mini-HOWTO respecting getting almost everything working with Slackware-12 on a Dell Inspiron 1501, but owing to demanding work deadlines, I have not been able to take out time. I will put the article up on The Slack World and my personal blog when it is ready. As Alan noted, the key strokes are logged by acpid in /var/log/ acpid.log. For example, if I press the Fn+Down combination to lower brightness level, ACPID registers the following in its log file: [Fri Nov 23 11:08:15 2007] received event "video LCD 00000087 00000000" [Fri Nov 23 11:08:15 2007] notifying client 3003[82:82] [Fri Nov 23 11:08:15 2007] notifying client 3162[0:102] [Fri Nov 23 11:08:15 2007] executing action "/etc/acpi/acpi_handler.sh video LCD 00000087 00000000" [Fri Nov 23 11:08:15 2007] BEGIN HANDLER MESSAGES [Fri Nov 23 11:08:15 2007] END HANDLER MESSAGES [Fri Nov 23 11:08:15 2007] action exited with status 0 [Fri Nov 23 11:08:15 2007] completed event "video LCD 00000087 00000000" Similarly, the key combination to increase brightness generates nearly similar output but with 00000087 replaced with 00000086. So, in effect, the actual signal that is caught by acpid, and subsequently passed to / etc/acpi/acpi_handler.sh under Slackware-12, is "video LCD 0000008x 00000000". Once that's identified, it is only a matter of altering BASH code in /etc/acpi/acpi_handler.sh to react to arguments provided to it when it is invoked by acpid (indirectly) to get the brightness keys to do something. For the time being, I'll only post the part of acpi_handler.sh that deals with the brightness control signals. video) case "$2" in LCD) case "$3" in 00000087) echo 12 > /proc/acpi/video/VGA/LCD/brightness ;; 00000086) echo 87 > /proc/acpi/video/VGA/LCD/brightness ;; *) logger "ACPI [$1]->[$2]->[$3]->[$4] not defined." ;; esac ;; *) logger "ACPI [$1]->[$2]->[$3] not defined." ;; esac ;; Also, having talked to a couple of people in ##slackware, I came to the conclusion that the video.ko module behaves weirdly with my hardware (or, vice versa). For example, if you look at the following output: root@dante# cat /proc/acpi/video/VGA/LCD/brightness levels: 100 37 12 25 37 50 62 75 87 100 current: 12 The values in the levels row are arranged in no particular pattern. They should be, at least from what I've learned. Apparently, for my particular situation, level 12 happens to be the lowest brightness level my LCD can be toggled too, and 100 the highest. Knowing that, you might be wondering why in the acpi_handler.sh script I've only provided for setting of only two levels. There is no special reason perhaps save for lack of time for writing a proper BASH script. And, yes, I've also modified, on Dagmar's suggestion on ##slackware, /etc/ rc.d/rc.modules to load the following modules: /sbin/modprobe ac /sbin/modprobe asus_acpi /sbin/modprobe battery /sbin/modprobe button /sbin/modprobe container /sbin/modprobe dock /sbin/modprobe fan /sbin/modprobe processor /sbin/modprobe thermal /sbin/modprobe video -- Ayaz Ahmed Khan |
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|