I've just had a bug reported:
“At Ottawa Linux Symposium, it was common to see people walking around with
their laptops half-open because they didn't want them to sleep. Whether wardriving, Web serving, or music playing, some people do not want their PCs to sleep.“
I cast my mind back to GUADEC, and sure enough I can remember an entrance hall full of people walking about with half-open laptops. This made me smile.
I figured I could use the inhibit applet for people to use for a “don't do what you normally do” type action.
So now we have a new toy. With gnome-power-manager from SVN you can add the standard “inhibit” applet into the panel, click the button, shut the lid and walk over to show someone your new coolness.
But wait! Some laptops melt or get rather hot when you do this. So just in case we have the following warning that is displayed when you manually inhibit and you have either suspend or hibernate configured as the battery lid close action.
So, maybe for GUADEC this year we'll see less half-open laptops…
The powertop utility from INTEL has been very interesting to use. Unfortunately, I'm quite pissed off.
“gnome-power-manager doesn't dim the backlight to save power it actually just changes the colour of the pixels on the screen”
Err no. It never has and never will. It actually dims the backlight on all the hardware I have tested it on.
Dimming to 30% when idle saves me about 1-3W of power on all three laptops I own. That's a X60 (ibm+intel), n100 (lenovo+nvidia) and a A10 (toshiba+old-intel).
For the X60, g-p-m calls HAL, which writes to the thinkpad_acpi controlled backlight class. This then writes a value into the embedded controller address space (or issues a CMOS command) which changes the hardware backlight brightness.
Really impressive graph by the way – but what crack are you smoking?
If you have a Gateway 400VTX or 450ROG please email me your output of lshal.
More batteries to recall!
I would like to add more broken batteries to the hal-info blacklist. Thanks!
For the last few days I've been working on DBus system activation, extending and slightly modifying on the work David Zeuthen did a few months ago. So what is is?
You already see activation working in the session, for instance where notify-send can get dbus to start notification-daemon only when a notification needs to be shown. The bigger problem was to launch stuff on the system bus under different users. Securely.
We think we've worked out how to do this securely, but further review would be lovely. The patch is here, and I've got a SRPM also here.
- We can launch helpers to do things as different users, for instance use a combination of PolicyKit and a system helper to set gconf defaults for all users. We can do some cool things with this.
- We can launch some automatically, only when required. For instance, we only need to start ConsoleKit when HAL is started, and this is done automatically for us on the first method that HAL requests from the ConsoleKit service.
So, for a non-legacy system (think OLPC) we can just do:
And that is it. As sugar (or another interface) requests the network state, then NetworkManager is started. This calls into HAL, so that is started. That calls into ConsoleKit, so that is started. As soon as we are on the network, we search for users, which queries avahi, so that is started. Can you see where this is headed? Parallel start-up with dependencies essentially for free.
Already, I've taken my Fedora 7 boot time from 20 seconds to 14 seconds by dropping a few service files in directory and turning off services in chkconfig. That's pretty substantial in my book. I've yet to build this for OLPC, but I'm guessing it will be a more substantial reduction.
So you are using gnome-power-manager on your laptop. You notice that sometimes when you shut the lid it suspends, and sometimes it doesn't. After a suspend it also acts a little funny, but you can't quite work out why…
The lid “up” event is not sent when you resume from suspend as the lid state changing triggers the resume, but no event is sent to userspace. This took me ages to work out yesterday. See my patch to LKML for a fix. Hopefully this is headed to 2.6.22 as it's a trivial fix, although it might be a little late in the day. Distributions might want to add this patch in the meantime.
When g-p-m doesn't have a complete profile of your battery, it tries to shutdown or hibernate when the known battery remaining is very low. If you've never tried to take your battery to 10%, g-p-m assumes it can't and calculates only the capacity it has seen being used.
This fixes many broken batteries. It also introduces a problem when you first start using the profiling code, in that g-p-m knows nothing about what the battery actually can do.
What about the following tooltip:
Laptop battery 30 minutes remaining (97%)
Battery discharge profile is estimated
Policy actions will not be performed until battery profiled
As usual, my spelling and grammar are sh1te and so suggestions welcome. The last line is far too techy, but I'm not sure what to write. Please add a comment to this blog (or email me) with better suggestions, thanks!
The SMI method on the X40 looks sorta like the PHSS method on the n100. It's protected by the same type of mutex and does a similar sort of SMI call. SMI is undocumented and thus difficult to understand. The SMI interface on the n100 is 40% similar to the X40 interface, although there's a lot missing on my lenovo. None of the cmos commands work, although that's not a big surprise. Lenovo, I would really appreciate a hand with this, even if it's just one of the BIOS engineers saying “it just won't work”.