KPowersave config tutorial

As wrote in my last post about the current KPowersave release 0.7.1 there are some settings which the user can't change at the moment via the configure dialog. Here now a small tutorial how to control this settings via the KPowersave config file.

You can control the settings for these options:

• battery warning levels
• actions for battery warning levels and lidclose
• default AC and battery scheme
• CPU frequency policy for each scheme

To change the config keys for these options you need to open in your home with a editor of your choise this file (if the file is not present, create the file): ~/.kde/share/config/kpowersaverc

KPowersave provide three different battery warning levels: warning, low and critical. To define the percentage (between 0 and 100) of battery fill for these levels you need to edit config keys in the section [General]. If the section is not there, simply add a line with [General] at top of the file and add/edit these keys there :

batteryWarning=12
batteryLow=7
batteryCritical=2

You can also define a action (currently only one per level) which is called if one of the battery warning levels reached. The available actions are:

• shutdown the machine (SHUTDOWN)
• suspend to disk (SUSPEND2DISK)
• suspend to ram (SUSPEND2RAM)
• change the CPU freqency policy to 'performance' (CPUFREQ_POWERSAVE) or 'dynamic' (CPUFREQ_DYNAMIC)
• change the brightness if supported by your hardware (BRIGHTNESS)

To define the actions for the battery warning levels you have to change this keys (also in the section [General]):

batteryWarningAction=
batteryLowAction=BRIGHTNESS
batteryCriticalAction=SHUTDOWN

The values in this example are the already defined defaults, so you don't need to add/change the keys if this is what you want. For the action BRIGHTNESS you need an additional key for each level to define the level (in percentage) of brightness to set:

batteryWarningActionValue=
batteryLowActionValue=
batteryCriticalActionValue=

You can use the same actions and values as for battery warning levels also for the event if the lid of your laptop get closed. To control the behavior you need to change these keys:

ActionOnLidClose=
ActionOnLidCloseValue=

To control which scheme KPowersave should use on battery or on AC you need to know the names of the available schemes. You can find them in this file: /opt/kde3/share/config/kpowersaverc . Currently there are (excluding the [default-scheme]) these schemes per default: Performance, Powersave, Presentation and Acoustic. To set the schemes you have to change these keys:

ac_scheme=Performance
battery_scheme=Powersave

At least you can change the CPU frequency for each scheme. For this you need, if not already there, for each a own section in the config file (a section starts with the name of the scheme withing '[ ]'). The available CPU frequency policies are: PERFORMANCE, POWERSAVE and DYNAMIC. Here a example for the performance scheme:

[Performance]
cpuFreqPolicy=DYNAMIC

If you canged all you want, you need to restart KPowersave to apply the changes.

Tags: KPowersave Tutorial

KPowersave 0.7.1 released

Monday I released the first offical (v0.7.0 was only for openSUSE 10.2) release from the new development tree of KPowersave. With this release KPowersave depends no longer on the powersave daemon (sadly!) and use HAL (>= 0.5.8.1) instead to get hardware information and to trigger suspend or set brightness and the CPU frequency policies.

Also if KPowersave depend no longer on powersave, I would recommend to use the new powersave daemon furthermore. The daemon can, if there is no program that claim org.freedesktop.Policy.Power on the D-Bus system bus, handle system powermanagement without do crazy things like start a applet in KDM or GDM. If KPowersave start up the daemon stop automatically to handle powermanagement policy and KPowersave applet can force (if allowed) the user specific settings.

With this release KPowersave handle the different schemes and battery/lid actions independently. This include this parts:

• definable battery warning levels (warning, low, critical)
  
• definable actions for each battery warning level (e.g. suspend, change brightness, set a special CPU frequency policy or shutdown the machine)
• definable actions if the lid get closed (same as for batteries)
  
• set CPU frequency policy for each scheme
• define AC and battery schemes

Currently the user can't change these settings via the config dialog in KPowersave, I concentrated for this release on reproduce the former functionality of KPowersave together with the old powersave daemon. A tutorial to change the settings in the config file follow as soon as possible. Extend the config dialog is one of the todos for the next releases.

I also fixed the KDE screensaver and DPMS handling to reduce/avoid interfer with the KDE user settings (e.g. if KPowersave exit). There is a KDE patch, from Dirk Müller (Thanks!), available to check if KPowersave already handle DPMS settings and call the KPowersave config dialog instead of the KControl dialog.

You can download KPowersave from kde-apps.org or directly from the sourceforge project page. This version is included in openSUSE 10.2. Feel free to test the package. Bugreports (for openSUSE to the Novell bugzilla, for other distros to the powersave-devel mailinglist) are really appreciated!

Tags: KPowersave

Why waste GNOME/GConf /etc ?

I was always wonder why /etc need on a fresh installed system so much space, if there are only config files. On a fresh installed openSUSE 10.2Beta2 with KDE and some development pattern /etc need ~39 MByte on my harddisk. The question is: Which config files need all this space?

After some investigate: /etc/opt need 28 MByte and /etc/opt/gnome need 96 % of this. So why the hell need GNOME 27 MByte for config files in /etc ? I was wondering how many config keys they could have there and what they could configure within 27 MByte, but after taking a look at the files in e.g. /etc/gnome/gconf/schemas/ it become more clear. GConf store in this directory on my machine 1630 config keys, but need ~12MByte for them because they also have translations (and hints for the translators) for the key descriptions within the files.

Why store GConf translations/localisation information of key descriptions within the config files and not in seperate files e.g. under /opt/gnome ? The current behavior waste /etc with (for configuration) bootless information, make it painful to change the keys e.g. with vim and is IMO potentially incompatible with FHS 2.3 because this files are more translation than config files.

So my proposal: separate the translations from the config data and hold only a generic english description in the files under /etc (as already e.g. in firefox.schemas). This would: reduce the needed space under /etc/gnome/gconf/schemas/ significantly (e.g. for gfloppy.schemas from 64KByte to 1.5 KByte which means -97.5 %), make it easier to find the keys and values and should make it easier to update the translation part without touch the config files.

Let see what the discussion in this bug bring ...

Tags: GNOME GConf

HAL patch collection (2)

Today again some new patches I send to the HAL mailing list which aren't included in the git repository because they are not approved so far :

• fix detection of wireless network capability for devices which use drivers with dscape stack as e.g. rt2500pci: here
• fix to add hardware specific/dependent sound devices to HAL (as e.g. /dev/snd/hwC0D0): here
• fix of libhal related to changed behavior of dbus_error_is_set(error) if error == NULL in the new D-Bus. Now the check would crash the realated application which use libhal. Download: here
  

These patches are against current HAL git. As always: you can find all my current HAL patches here.

Tags: HAL Patches

Novell bring some light in the dark ...

It was about time. So many questions from the community about the Novell/Microsoft deal and the details. All this (justified) spec and rumours about Novell violoate the GPL section 7 with this arrangement and the other issues like Novell and the Open Invention Network (OIN) or Mono. Now we have some answers to the questions. Take a look at: Novell Answers Questions from the Community.

Here some parts (for more read the FAQ):

How is this agreement compatible with Novell's obligations under Section 7 of the GPL?

Our agreement with Microsoft is focused on our customers, and does not include a patent license or covenant not to sue from Microsoft to Novell (or, for that matter, from Novell to Microsoft). Novell's customers receive a covenant not to sue directly from Microsoft. We have not agreed with Microsoft to any condition that would contradict the conditions of the GPL and we are in full compliance.

Novell's end user customers receive a covenant not to sue directly from Microsoft for their use of Novell products and services, but these activities are outside the scope of the GPL.

Will Novell's involvement with the Open Invention Network (OIN) change due to this agreement with Microsoft?

[...] Novell is a founding member of the OIN and remains strongly committed to its mission. We have contributed valuable resources to OIN and will continue to participate in OIN in the future. Novell remains firmly in support of the goal of creating an environment of open innovation in the Linux world, without worry about the threat of patent lawsuits.

The value of OIN's patents as a deterrent remains critical to the entire Linux industry, including Novell, and is not affected by our agreement with Microsoft.

There is now also an new Novell announcement with more details of the deal. This also include a statement about GPL Section 7 and (very interesting) about the financial parts:

As part of the business cooperation agreement, Microsoft will make an upfront payment to Novell of $240 million for SUSE Linux Enterprise Server subscription certificates. [...] Microsoft will dedicate $60 million total over the five year period for marketing Linux and Windows virtualized scenarios and will also spend $34 million over the five year term of the agreement for a Microsoft sales force devoted primarily to marketing the combined offering.

[...] Under the patent cooperation agreement, Microsoft will make an up-front net payment to Novell of $108 million, and Novell will make ongoing payments of at least $40 million over five years to Microsoft, based on percentages of Novell's Open Platform Solutions and Open Enterprise Server revenues.

I think this should bring finally some light in the dark ...

Tags: Novell Microsoft GPL

Novell, Microsoft ... and what think RedHat?

Today I read a article about a interview with Mark Webbink from RedHat. There is no denying that they feel inadequate:

... In the end, Red Hat's high customer satisfaction ratings will allow his company to ride the tide. In one year's time [...] Red Hat will be the only Linux commercial vendor left standing ...

I've rarely laughed so hard! We will see if this come true, next November and if SUSE, Ubuntu and e.g. Mandriva still standing ... or Oracle bought you. ;-)

Tags: Novell Microsoft RedHat Linux

KPowersave on the way to 0.7.0

Only some hours until deadline for openSUSE Beta2 and a new version of KPowersave, which no longer depends on the powersave daemon and use HAL instead.

In the last days I removed the complete powersave related code and replaced it with new classes and hardware abstraction. Today I finished the basic part and we have now a powersave independend version in SVN which runs. But this does not mean the new version work as planed ... there is enough work left.

Yesterday I added an pre-annoucement for the new 0.7.x development version at kde-apps.org planed for this week. And as you can see in the comments there are people which are not so happy about switch from powersave to HAL (as you can see in this post I'm not that happy too):

... going HAL is a real downer and ( at least to me ) it turns Kpowersave into just "another" solution, stripping it from what made it different ..

powersave was EXACTLY the way to go .. and to tell you the truth, knowing why Kpowersave is going HAL is what makes everything even worse. It makes me feel like mediocrity and disdain won once again.

And there is also this question in the comments here:

What are the benefits of changing from powersaved to HAL?

So, what are the reasons for change from powersave to HAL? As first: Since the powersave developer decided to kill the powersave daemon and integrate (the most of) the functions of the daemon into HAL and pm-utils, we have no choise. We have to use the new infrastructure or KPowersave die with the daemon. This was the main reason to rewrite KPowersave.

So what are the benefits?

• No dependency to the powersave daemon (the package is not in every distribution default).
• We can move the most of the scheme management from the daemon to KPowersave. This make KPowersave anymore flexible than before.
• We have now the chance to get KPowersave into the KDE SVN and maybe KPowersave could replace KLaptop as default KDE powermanagement solution.

And the disadvantages?

• We lose the great powersave daemon, but for more read this post.
  

Tags: KPowersave KDE Linux

How to cheat distrowatch ranking

You always wanted to know how to promote the ranking of your Linux distribution at distrowatch? Simply do the same as in the english version of the Fedora wiki start page and link against the page of your distribution at distrowatch.com instead of provide your own package list (as e.g. Debian or openSUSE do). And don't forget to name the link 'Packages' ;-) :

And whoso want to know which packages are available push the level of popularity for your Linux distribution in the 'Page Hit Ranking' with each click (checked google's cache and this link in the fedora wiki is new):

Tags: linux distrowatch

Novell and Microsoft ?

I'm not quite sure what to make of this news/rumors:

• (REUTERS) Microsoft, Novell reach agreement on Linux
• (WSJ) Microsoft Is Set to Give Linux a Boost Through Partnership With Novell

The best would be to wait for the offical annoucements from Novell and Microsoft (webcast), but sounds a littlebit like sup with the devil ;-) . We will see.

Update: Annoucement "Joint letter to the Open Source Community"

Tags: Novell SUSE Linux Microsoft