Holger's Blog

Saving Power with a new Killswitch Applet

2010-06-14T10:15:00+02:00

Saving Power with a new Killswitch Applet

So there has been Hackweek at SUSE/Novell the last week and I'm finally finding the time to release a new version of killswitch-applet. This time, it's version 0.2.3, and really a lot has changed from the previous 0.1 release:

The applet remembers your settings across reboots
That is actually the feature which makes you want killswitch-applet at all. Without the applet, whenever you disable a device, let's say bluetooth, after a reboot, the device is active again. I'm assuming two prerequisites here:
1. You're not using a Thinkpad laptop, because those are the only ones I know of (please enlighten me if you know of others) which are able to store the state of their devices in NVRAM. Speficically, the thinkpad-acpi driver is able to do so.
2. Your laptop doesn't have a physical hardware switch for enabling/disabling bluetooth/wifi. This hardware switch might also be hidden after a usual button which doesn't look like it is handled in hardware.
All other laptop owners might find killswitch-applet very useful. If you're the owner of let's say, a sony, HP, Acer, or whatever laptop, you would have to disable the bluetooth device over and over again after each reboot. Maybe even after a sleep, depending on the hardware configuration, distribution, kernel version, etc.. These unnecessary mouse clicks are just avoided. Disabling the bluetooth device once will take care that it is disabled the next time killswitch-applet starts, which is mostly when you're doing a reboot and/or logging in to your desktop.
Vector graphic (svg) is used for the tray icon, which makes it scale nicely for whatever panel (kicker, gnome-applet, etc.) you're using.
Add tool tip to get a fast overview about which killswitches are active.

Source Code/Tarball Release

I found a home for the code and chose gitorious for it. Contributions welcome!

Here are the required tarballs:

Packages for openSUSE users

The package can be found in my home project or can be installed via 1-Click-Install:

z-shell (zsh) completion for osc and zypper

2010-03-29T00:13:00+02:00

z-shell (zsh) completion for osc and zypper

When working with the openSUSE distribution, there are a couple of tools you have to deal with over and over again. Two of them are osc and zypper. The first one to build or fix packages, the latter to install, remove or update them. Using one of those tools on a regular basis? Read on…

…but to make this post actually useful for you, there needs to be another prerequisite: You need to use zsh as your primary shell. And I hope you do. If not, you should definitely put this on your TODO list.

All of the following is ready to use, because it's already in openSUSE Factory for quite some time and has already been in openSUSE 11.2. I just have the feeling that people are not aware of this feature, so I am writing this post…

osc

So let's start with osc. There are a couple of sub commands like checkout, getbinaries or branch I need all the time. And every time I do, I have to look up the syntax. For instance, have a look at the osc getbinaries command:

$ osc help getbinaries
osc getbinaries PROJECT PACKAGE REPOSITORY ARCHITECTURE

Hm? Four parameters? Things like that were actually the reason I sat down implementing a solution which works quite well for me: Zsh completion for osc. Now you can do stuff like the following:

$ osc getbinaries <tab>
home:hmacht              openSUSE:11.0            openSUSE:11.3            SUSE:SLE-11:Update:Test
home:hmacht:kernel-sony  openSUSE:11.1            openSUSE:Factory
openSUSE:10.3            openSUSE:11.2            SUSE:SLE-11-SP1:GA

$ osc getbinaries openSUSE:Factory aaa_base <tab>
openSUSE_10.2     openSUSE_11.0     openSUSE_11.2     openSUSE_Factory  SUSE_SLE-11_GA
openSUSE_10.3     openSUSE_11.1     openSUSE_11.3     standard

$ osc getbinaries openSUSE:Factory aaa_base openSUSE_Factory
i586    x86_64

Quite handy, isn't it?

You might also wonder why the first completion output in the above example contains my personal home project home:hmacht. By default, the completion contains a couple of default build targets, repositories and architectures like openSUSE_Factory, openSUSE:Factory or x86_64. You can extend those lists with the shell variables ZSH_OSC_PROJECTS_EXTRA and ZSH_OSC_BUILD_TARGETS_EXTRA. My corresponding part of my ~/.zshrc looks so:

export ZSH_OSC_PROJECTS_EXTRA="home:hmacht home:hmacht:kernel-sony SUSE:SLE-11:Update:Test SUSE:SLE-11-SP1:GA"
export ZSH_OSC_BUILD_TARGETS_EXTRA="standard SUSE_SLE-11_GA"

After that, the extra repos/targets show up in the completion output.

By default, the completion is in verbose mode:

$ osc <tab>
--debugger             -- jump into the debugger before executing anything
--no-keyring           -- disable usage of desktop keyring system
--post-mortem          -- jump into the debugger in case of errors
--version              -- show program's version number and exit
-A                     -- URL/alias, --apiurl=URL/alias
-H                     -- --http-debug debug HTTP traffic
-c                     -- FILE, --config=FILE
-d                     -- --debug print info useful for debugging
-h                     -- --help show this help message and exit
-q                     -- --quiet be quiet, not verbose
-t                     -- --traceback print call trace in case of errors
-v                     -- --verbose increase verbosity
abortbuild             -- Aborts the build of a certain project/package
add                    -- Mark files to be added upon the next commit
addremove              -- (ar) Adds new files, removes disappeared files
aggregatepac           -- "Aggregate" a package to another package
api                    -- Issue an arbitrary request to the API
branch                 -- (bco, branchco, getpac)
bugowner               -- Show bugowners of a project/package
build                  -- Build a package on your local machine
[...]

To change that you can set

$ zstyle ':completion:*:osc:*' verbose no
$ zstyle ':completion:*:osc-subcommand:*' verbose no

Now it looks like:

$ osc <tab>
--debugger             api                    diff                   meta                   resolved
--no-keyring           branch                 disable                mkpac                  results
--post-mortem          bugowner               getbinaries            mv                     rremove
--version              build                  global                 my                     search
[...]

All the completion output is auto generated by the osc help output (btw., even osc help <tab> can be completed), so new commands should show up automatically. However, this contains the risk of possible bugs where the help output is unexpected, so if you find any issues, send me a mail or add a comment.

zypper

Basically all the above applies for zypper. An example output looks like:

$ zypper re<tab>
refresh                 -- ref Refresh all repositories.
refresh-services        -- refs Refresh all services.
remove                  -- rm Remove packages.
removelock              -- rl Remove a package lock.
removerepo              -- rr Remove specified repository.
removeservice           -- rs Remove specified service.
renamerepo              -- nr Rename specified repository.
repos                   -- lr List all defined repositories.

Change verbose/short output with:

$ zstyle ':completion:*:osc:*' verbose no
$ zstyle ':completion:*:osc-subcommand:*' verbose no

Personally I use the zypper completion quite seldom, nevertheless, some people might find it useful.

Power Management in openSUSE and SLE11

2009-05-11T20:50:00+02:00

Power Management in openSUSE and SLE11

Wanna know what we're doing to make your laptop run longer? Have a look at the new wiki page I have just finished. It talks about three major topics:

What is done
What can be done better
What is not done

It might give you some hints to tease even more out of your battery runtime.

Discussion welcome!

killswitch-applet-0.1 ... or my personal Hello World in Python

2009-04-17T21:29:00+02:00

killswitch-applet-0.1 … or my personal Hello World in Python

One thing that was on my TODO for already quite some time was to have a look at that half-new language called Python. Because an old-fashioned "Hello World" is far too simple here, I was looking for some kind of project to get familiar with the basic principles.

One thing I found quite annoying in the past was the fact that I always had to disable some kind of radios in some far too complicated ways to save some battery power. Modern laptops often have multiple killswitches for their wireless communication devices like bluetooth, WLAN or WWAN. So that was the chance for me to seize, and the output looks like this:

From the README:

killswitch-applet is a small application sitting in the system tray providing the possibility to manage all the killswitches found in the system. In this context, "managing" means enabling or disabling certain killswitches. This is especially useful if you have multiple killswitches like bluetooth, WWAN or WLAN seen in many modern laptops.

Tray Icon on the Left

The source tarball for version 0.1 can be downloaded here: killswitch-applet-0.1

The summary here definitely is: Wow, that was damn simple! Especially when it comes down to GTK programming and D-Bus interaction, Python definitely provides a very good way to hack those things together quite easily. The whole source file contains a whole of 189 lines of code including comments.

Another question: Is it worth creating a sourceforge project for this? I'll wait until and if I'm getting some feedback.

Note for openSUSE users:

Of course this is also available in the openSUSE Buildservice. Go to http://software.opensuse.org/search and search for "killswitch-applet".

Tomboy^WGnote

2009-04-16T22:49:00+02:00

Tomboy^WGnote

Inspired by a recent blog post, Gnote is now available in the openSUSE build service. If you have been using Tomboy and wouldn't miss any of its plugins (which are WIP), give it a try. The Mono to C++ conversion can be that easy:

For Factory: $ zypper ar \

http://download.opensuse.org/repositories/home:/hmacht/openSUSE_Factory/ \ home:hmacht

For 11.1: $ zypper ar \

http://download.opensuse.org/repositories/home:/hmacht/openSUSE_11.1/ \ home:hmacht

$ zypper in gnote
$ mkdir ~/.gnote && cp ~/.tomboy/*.note ~/.gnote/
$ gnote

AFAICT, it's running quite well. Tomboy has been the only Mono application I was running, so 'zypper remove mono' removed a bunch of 42 packages.

Have fun, Holger

Maemo Music Player Client (MMPC) for Diablo

2009-02-24T08:56:00+01:00

Maemo Music Player Client (MMPC) for Diablo

Finally I took the time to respond to multiple requests about providing mmpc 0.2.1 packages for Diablo. That also gave me the possibility to try the maemo autobuilder to upload my packages to the extras repository. And well, it worked out. It's especially useful for those people not running debian based systems, because with autobuilder you don't have to care about signing and uploading the packages with debian tools like debsign and dput.

So, this is not a new release, these are just new packages build for the Diable 4.1 distribution. I still did not manage to find the time to enhance mmpc further. There are just too many other things like work and university I have to care about. Either download the packages from Maemo Garage, or just get it through the extras repository as usual.

GreenIT: Power Consumption and -Optimization of PCs

2009-01-14T10:27:00+01:00

"GreenIT: Power Consumption and -Optimization of PCs"

In the middle of last year, I participated in a seminar called "GreenIT" at university. The result was a 17 paged whitepaper called "GreenIT: Power Consumption and -Optimization of PCs". It took quite some time to finish this up, so it would be a waste of time if I would not publish it. A shortened table of contents looks like this:

Introduction
ACPI
System as a Whole
System Components
Software Policies
Conclusion

Please note: If you are only interested in how things are implemented in Linux, this might not be that interesting for you. It does not include any specific operating system details. It's rather general, although of a technical nature, and thus can be applied to any operating system out there.

If you are lazy of reading through the whole document, you might consider having a look at the corresponding presentation slides. However, you need to be able to speak, or at least to read, the German language for the slides to be useful for you.

GNOME Docker 0.1 Released

2008-07-14T21:13:00+02:00

GNOME Docker 0.1 Released

Finally I managed to release gnome-docker 0.1, a small application to support users using a docking station. It is already included in openSUSE 11.0, but other pending things prevented me to do a public release earlier. One of these things is the self designed tray icon :-). I definitely have to look for a better alternative. The README should have all the necessary information:

GNOME docker 0.1

GNOME application for notifying laptop users about the state of their dock station and the possibility to undock the system via software, either from the tray icon, or via a hotkey. In future, it will also care about hotpluggable devices placed on the dock station, such as hard drives and DVD/CD drives.

It is meant to be well designed and to fit into the GNOME desktop. So an important aim for gnome-docker is to be shipped with GNOME upstream. It is still in early development.

Currently, it has the following features:

tray icon showing the current status and with functionality to undock a laptop
handling of hotkeys to undock a laptop (e.g. FN-F9 on ThinkPads)
xrandr support to enable/disable external outputs attached to the dock station (experimental, evaluating how it fits there)
user notifications about the state of the dock station. E.g.: "Now it's safe to remove the laptop"

As gnome-docker forges ahead, the linux kernel has to improve and has to provide sensible date for userspace to make use of, like exporting which devices are inside a dock station.

Requirements

liblazy >= 0.2 from http://www.freedesktop.org/wiki/Software/liblazy

Download

gnome-docker 0.1

Back from LinuxTag 2008

2008-06-03T19:32:00+02:00

Back from LinuxTag 2008

Came back from Linux Tag 2008 on saturday evening. It was a short, only two days lasting trip to Berlin, but nevertheless, just great! Had a lot of fun with my colleagues Timo Hoenig and Helmut Schaa giving a talk about laptop support in the upcoming openSUSE 11.0. It was a huge success. Great thanks goes to Martin Lasarsch for managing/moderating our talk. The quiz at the end giving away some USB sticks for correct answers has been just fun. It seems people are really listening to our laptops stories, or should we better not have told them at the beginning that there will be give-aways? ;-)

If you like to have a look at our achivement regarding fingerprint readers, suspend, power management and wireless, go have a look at the slides.

I think the improvements have never been so astonishing before! Actually, they even suprised myself when seeing the test results. Just some key facts:

Suspend to Disk

LinuxTag 2007: 37.5 seconds
LinuxTag 2008: 14.9 seconds

Pretty fast, I guess.

Idle power consumption on a battery powered Thinkpad T61

openSUSE 10.3: 11.11 Watt
openSUSE 11.0 RC1: 8.51 Watt

Pretty economical, I guess.

For more details, look here.

Providing a D-Bus interface for CPUFreq knobs

2008-05-09T23:30:00+02:00

Providing a D-Bus interface for CPUFreq knobs

There has been a discussion on the HAL development list regarding DeviceKit, a corresponding power management subsystem daemon, and a possible CPU frequency scaling interface.

During the discussion, it turned out, and I realised this quite late, that KPowersave still exports the possibility to set either the powersave or performance governor. That is basically a bad idea, and still there because of former times. See this journal for a good rationale. However, the author quite unfriendly rants towards the developers. Unfortunately, I've not seen a bugreport in sourceforge's bugtracker for that, nor anywhere else. Maybe he could have pointed this out in a more elegant way, instead of immediately telling people they are dangerous. How emotional. And funny after all. I filed it here, just to be sure it is not missed for upcoming openSUSE 11.0.

So that is the one issue of the discussion, a completely other one is about if we need a D-Bus interface for tuning CPU frequency scaling (related to the ondemand governor) knobs. As an example, the ondemand governor provides an up_threshold setting you can tune through sysfs. Basically it defines how long a CPU burst has to be so that the frequency is increased. Quoting the kernel documentation:

up_threshold: defines what the average CPU usaged between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.

When having only short CPU bursts, it is better to stay at a low frequency for a short period of time when it comes down to power consumption. And the typical desktop use consists of those short CPU bursts. Browsing a web page, opening a mail folder, etc.

The kernel sets a sane default for this setting. It is nearly self-evident for a default to be sane, someone should have thought carefully about it. However, that does not mean it is ideal. It just cannot be for all different kind of use cases. Servers, desktops, what applications are running, "on battery", "on AC", namely, depending on the current power source.

So I am an advocator of having a D-Bus interface somewhere at the system level (we already have in HAL, but this will most likely vanish sooner or later due to its successor called DeviceKit) for tuning such knobs by someone who cares about policy. And policy is more and more put to Desktop applications these days.

Maemo Music Player Client 0.2.1

2008-04-14T15:21:00+02:00

Maemo Music Player Client 0.2.1

I finally managed to get to work on MMPC after quite some time. MMPC 0.1 was 2007-11-14 08:45 (wow, that was pretty early in morning :-))

Well, mmpc-0.2.1 is available for immediate consumption. Changes, which were major concerns until now, are:

New buttons and images, finally. And a new logo you can see above.
Add tap-and-hold functionality to more places. For example, it's now possible to update the database from within the client.
Add scroll windows to all preference tabs to display the full content.
Bold the currently played track.
Increase connection timeout to 3 seconds. This will hopefully solve the strange disconnect issues I wasn't able to reproduce.
Fixed tree browsing in playlist browser.

Fresh screenshots can be found here. Packages are available from the extras repository. So most people will get the update automatically (if anything goes wrong, try to enable red pill mode). Otherwise, grab them from garage.

Next things will include the support for some plugins. Please report any problems. Happy listening!

Energy Star: Jump on the Bandwagon!

2008-03-09T21:50:00+01:00

"Energy Star: Jump on the Bandwagon!"

Do it yourself

Ever wondered what the Energy Star label is good for? Ever wondered why it mostly pops up on things like printers and monitors? But how about your personal computer or your laptop?

If you want to find out, consider reading Measuring Power Consumption in the Light of EnergyStar. It contains a detailed guide about how to test your laptop for Energy Star compliance. At SUSE's Mobile Devices Team, we're currently building up a database of all different kind of laptop computers regarding their Energy Star compliance and power consumption. Wanna help? Follow the above mentioned guide and send your results to me (hmacht a t suse d o t de). All results will help us to drive development efforts in this area and will help to identify possible power consumption regressions in upcoming releases. However, to make this possible, the first thing we need is a base collection of laptop results to compare against.

To prevent questions about publishing the results, no, I won't do that. I do not want to compromise any kind of manufacturer in public. They will notice for themselves as soon as there pop up more laptops running Linux having a shiny blue Energy Star label printed on the case or packing ;-)

FOSDEM 2008

Like the homonymous title of this post, I gave a talk at this year's FOSDEM at Brussels on Energy Star. It focuses on the requirements for laptop computers, and about how anyone can test his laptop for Energy Star compliance.

If you're too lazy to read through the slides, which should be quite self-explanatory, wait for the video showing me in action. The videos of all FOSDEM talks given by openSUSE community people should be up at the openSUSE FOSDEM page soon. Stay tuned.

http://en.opensuse.org/PowerMeasurements

Interested in power consumption measurements in general? Consider having a look at the PowerMeasurements openSUSE wiki page. This is, and will be pushed to become the central point for collecting information, hints or tips and tricks about this topic.

Package Updates (Powersave, QNotify, Update KTray)

2008-02-04T23:16:00+01:00

Package Updates (Powersave, QNotify, Update KTray)

Powersave Daemon

I finally managed to release a new version of the powersave daemon, 0.15.20. This is a plain bugfix release. We're some kind of feature complete, so I doubt that there will be anything else than bugfix releases in the future ;-) Sourceforge has the files.

QNotify

After almost 2 years of QNotify hacking abstinence, I finally managed to do what was on my TODO for so long. I removed the qnotifyd daemon which blew my machine with 100% CPU usage from time to time. Now the qnotify command line client manages multiple notification widget on the desktop on its own, by using a simple file locking mechanism. The outcome is qnotify-0.6. Again, Sourceforge is your friend. For a really cool video about what QNotify actually can be used for, have a look at this video.

On a related note, does KDE4 actually have a companion piece to GNOME's notification daemon? Does it look cool? May be I've to check again myself… If not, may be I finally manage to get a grip on myself and try to integrate libQNotify's features into KDE4.

Update: KTray

And while we're at it, just hacked in a user request feature into KTray. I was suprised that someone is actually still using it. Yes, there are users out there who don't use KDE or GNOME, so they need ktray to use tray applications correctly. Sourceforge has version 0.2 which features:

add cmd line option -r to use horizontal alignment
add cmd line option -w to draw widget without borders
add cmd line option -p to specify the window position

Fixing a broken N810, or... A new way to freeze a device

2008-01-12T14:05:00+01:00

Fixing a broken N810, or… A new way to freeze a device

Finally I ordered a Nokia N810 with my discount code provided by the Maemo project on Tuesday. It arrived Thursday. With all my tenseness and pleasant anticipation, it looked and felt great while having a quick glance. But the disenchantment followed right away:

Huh? What's that? It doesn't power on after shutting it down the first time. Putting in the charger doesn't help. Removing the battery and putting it back doesn't help. "Charging" it several hours (without any sign that it does so) doesn't help. Removing the battery for several minutes doesn't help. Checking with a original Nokia battery and charger from a colleague doesn't help. What to do? (Already really frightened of having received a broken device…)

In the evening, I decided to remove the battery and put it on the balcony. On the balcony? Why that? It only was a very vague suspicion…it's currently winter in Europe, you know ;-). Waiting…(and maybe praying) about another 30 minutes. Device was cold now. Inserting the battery, pushing the power button, and voila! The N810 turns on and powers up properly. Happy about thinking that this was only a temporary failure, I tried again some minutes later and the device kept silent again. What a mess! Next day, another colleague came to me telling me that he has exactly the same problem. And I already had a temporary solution for him…(Skip the next paragraph if you want to read it immediately)

Yahoo'ing around, I found out that this is a well known problem, at least for the customers, I don't know how it behaves to the Nokia company/manufacturers. There are plenty of reports for this issue. On Internettablettalk and even in the Maemo bugzilla known as "N800 Power up Drama". Interestingly, the problem seems to also be present on N800 devices. But only the new and recent ones. So it seems that some electronic parts like capacitors installed in recent devices (N800 and N810) are causing this issue. I tried everything people are suggesting, waiting a specific period of time before switching it on again, making sure that everything fits properly, enabling r&d mode, and so on. Please don't tell me "Just don't power off the device", because that's what I'm generally doing, but that's no choice when you're on the road running out of battery. And you sometimes need to power down the device for development, too.

The only thing that seems to help:

Switch the device off
Remove the battery
Put the device to a fridge (without the battery) for about 30 minutes. If you are impatient like I am, put it into a deep-freezer for about 10 minutes to get it cold. Hint: Use a plastic bag to protect it from moisture, and more importantly, don't forget about it while doing something else ;-)
Take it out and insert the battery
Turn it back on, you'll see that it works

This procedure was already verified on two devices.

Strange, I currently know of five people having a N810, with two of them showing this issue. This is really bad percentage. I already fear that this is like the issue I encountered with my N800 and the display issue where the right side of the touchscreen became more and more unresponsive. Also widely known. To that time, I returned the N800 back to Nokia, and it lasted solid 6 weeks until I got a repaired device. I do not want to repeat that! I do not want to develop inside a scratchbox without the possibility to see the outcome on a live device. But the most frustrating thing I encounter these days is that there is no official statement from Nokia about this issue. There's still not even one for the display issue with the N800. Please correct me if I'm wrong.

The only thing which keeps me alive ( ;-) ) and which prevents me from returning the device immediately is the hope that it can be fixed via software. I just hope that there will be a statement by the Nokia or Maemo people telling me: "Be patient, we're working on the issue with high pressure and we think it can be fixed with a firmware update". If it really is a hardware issue, I at least hope that the issue is handled as "we've sold broken devices, process returned ones with high priority!".

Getting away from the bad news, if there wouldn't be those, I would really be amazed by this gadget! As long as it's on, I just have fun with it. I'm just very frustrated.

MMPC for Chinook

2007-11-14T12:04:00+01:00

MMPC for Chinook

Even before the N810 is shipped, I'm able to to announce MMPC packages for the new Chinook 4.0 (OS2008) release. Untested in real production environments, of course, but I see no reason why it shouldn't work outside my ARM development environment.

Packages are here (including libmpd). Please report any issues you might encounter.

Now I'm eagerly awaiting the availability of the N810 in Germany to finally get rid of my discount code. Thanks Nokia!

On a related note: I'm still looking for designers creating some nice, "Play", "Stop", "Pause", "Backward" and "Forward" buttons. These are just too ugly in the current state. Nobody willing to help out?