Shallow Thoughts : tags : acpi

Vaio tips for Debian Squeeze

I switched to the current Debian release, "Squeeze", quite a few months ago on my Sony Vaio laptop. I've found that Squeeze, with its older kernel and good attention to power management (compared to the power management regressions in more recent kernels), gets much better battery life than either Arch Linux or Ubuntu on this machine. I'm using Squeeze as the primary OS at least until the other distros get their kernel power management sorted out.

I did have to solve a couple of minor problems when switching over, though.

Suspend/Resume quirks

The first problem was that my Vaio TX650 would freeze on resuming from suspend -- something that every other Linux distro has handled out of the box on this machine.

The solution turned out to be simple though non-obvious, apparently a problem with controlling power to the display:

sudo pm-suspend --quirk-dpms-on

That wasn't easy to find, but ever since then the machine has been suspending without a single glitch. And it's a true suspend, unlike Ubuntu Natty, which on this machine will use up a full battery if I leave it suspended all day -- Natty uses nearly as much power when suspended as it does running.

Adjusting screen brightness: debugging ACPI

Of course, once I got that sorted out, there were the usual collection of little changes I needed to make. Number one was that it didn't automatically handle brightness adjustment with the Fn-F5 and Fn-F6 keys.

It turned out my previous technique for handling the brightness keys didn't work, because the names of the ACPI events in /etc/acpi/events had changed. Previously, /etc/acpi/events/sony-brightness-down had contained references to the Sony I/O Control, or SPIC:

event=sony/hotkey SPIC 00000001 00000010
action=/etc/acpi/sonybright.sh down

That device didn't exist on Squeeze. To find out what I needed now, I ran acpi-listen and typed the function-key combos in question. That gave me the codes I needed. I changed the sony-brightness-down file to read:

event=video/brightnessdown BRTDN 00000087 00000000
action=/etc/acpi/sonybright.sh down

It's probably a good thing, changing to be less Sony-specific ... but as a user it's one of those niggling annoyances that I have to go chase down every time I upgrade to a new Linux version.

Tags: linux, suspend, acpi, debian, sony, vaio
[ 12:07 Aug 27, 2011    More linux/laptop | permalink to this entry | ]

Making those Fn- laptop keys do something useful

A friend was trying to get some of her laptop's function keys working under Ubuntu, and that reminded me that I'd been meaning to do the same on my Vaio TX 650P.

My brightness keys worked automagically -- I suspected via the scripts in /etc/acpi -- and that was helpful in tracking down the rest of the information I needed. But it still took a bit of fiddling since (surprise!) how this stuff works isn't documented.

Update: That "isn't documented" remark applies to the ACPI system. Matt Zimmerman points out that there is some good documentation on the rest of the key-handling system, and pointed me to two really excellent pages: Hotkeys architecture and Hotkeys Troubleshooting. Recommended reading!

Here's the procedure I found.

First, use acpi_listen to find out what events are generated by the key you care about. Not all keys generate ACPI events. I haven't get figured out what controls this -- possibly the kernel. When you type the key, you're looking for something like this:

sony/hotkey SPIC 00000001 00000012

You may get separate events for key down and key up. It's your choice as to which one matters.

Once you know the code for your key, it's time to make it do something. Create a new file in /etc/acpi/events -- I called mine sony-lcd-btn. It doesn't matter what you call it -- acpid will read all of them. (Yes, that means every time you start up it's reading all those toshiba and asus files even if you have a Lenovo or Sony. Looks like a nice place to shave off a little boot time.)

The file is very simple and should look something like this:

# /etc/acpi/events/sony-lcd-btn

event=sony/hotkey SPIC 00000001 00000012
action=/etc/acpi/sonylcd.sh

Now create a script for the action you specified in the event file. I created a script /etc/acpi/sonylcd.sh that looks like this:

#! /bin/bash
# temporary, for testing:
echo "LCD button!" >/dev/console

Now restart acpid: service acpid restart if you're on karmic, or /etc/init.d/acpid restart on earlier releases. Press the button. If you're running from the console (or using a tool like xconsole), and you got all the codes right, you should be able to see the echo from your script.

Now you can do anything you want. For instance, when I press the LCD button I generally want to run this:

xrandr --output VGA --mode 1024x768

Or to make it toggle, I could write a slightly smarter script using xrandr --query to find out the current mode and behave accordingly. I'll probably do that at some point when I have a projector handy.

Tags: linux, acpi,
[ 17:15 Mar 09, 2010    More linux/kernel | permalink to this entry | ]

Reading the temperature using /sys rather than /proc

I was curious whether Linux could read the CPU temperature on Dave's new Mac Mini. I normally read the temperature with something like this:

cat /proc/acpi/thermal_zone/ATF0/temperature

(the ATF0 part varies from machine to machine).

Though this doesn't work on all machines -- on my AMD desktop it always returns the same number, which, I'm told, means that the BIOS probably has some code that looks something like this:

if (OS == "Win95" || OS == "Win98") {
  return get_win9x_temp();
}
else if (OS == "WinNT" || OS == "WinXP" || OS == "Vista") {
  return get_nt_temp();
}
else {
  return 40;
}

Anyway, I wondered whether the Mac would have that problem (with different OS names, of course).

There wasn't anything in /proc/acpi/thermal_zone on the Mac, but /proc is deprecated and we're all supposed to be moving to /sys, right? But nobody writes about the new way to get the temperature from /sys; most people are still using the old /proc way.

Took some digging, but I found it:

cat /sys/class/thermal/thermal_zone0/temp

It's in thousandths of a degree C now, rather than straight degrees C.

And on the Mini? Nope, it's not there either. If Dave needs the temperature he needs to stick to OS X, or else figure out lm_sensors.

Update: Matthew Garrett has an excellent blog article on the OS entries reported to ACPI. Apparently Linux since 2.6.29 has claimed to be "Microsoft Windows NT" to avoid just the sort of problem I mentioned. Though that leaves me confused about why my desktop machine always reports 40C. Thanks to JanC for pointing me to that article!

Tags: linux, acpi, kernel, tips
[ 21:54 Apr 08, 2009    More linux/kernel | permalink to this entry | ]