Technical Blog of Richard Hughes

I've been looking at the gnome-power-manager Inhibit API. So far we basically have this:

Inhibit – to get a cookie to prevent suspending
UnInhibit – clear the cookie and allow suspending

Having an active cookie stops the auto-suspend feature when you are copying files over a slow network link, and also stops you from pressing the off button on your computer half the way through burning a DVD.

The distinction between the two need to be clearer, and I think I need new method names to solve things like bug 402863.

The new method names needs to differentiate between “I'm in the middle of an RPM transaction don't suspend even if the user pressed the suspend button” and “I'm playing music, don't auto-suspend if all the sessions go idle”.

So ideas welcome. I'm erring so far to Inhibit() for inactive sleep and ForceInhibit() for the RPM transaction case, but I'm not sure that's particularly intuitive. Ideas welcome. Thanks.

So, today I got told that Lenovo had released a new BIOS, which (I am rather sad) got me quite excited…. Maybe they've fixed ACPI brightness control, or allow me to resume from suspend, or just added the battery current voltage patch I sent to them a few months ago.

No, Version 3.0 (third major release) just bumped the OEM revision header (in the AML header) from 51 to 52. No other changes.

Wow, thanks Lenovo. Just remember kids, Lenovo doesn't support Linux.

My Nokia subsidized n800 arrived today, cheers guys. It appears much quicker in average use than the 770, and the software appears to have more features, be more stable and generally mature. Plus, it can read SD flash cards which means I can share cards between my camera, OLPC machine, and n800. If you've got big fingers like me, then you'll also find the “poke at it” input mode much improved. Plus the stereo sound is FANTASTIC from such a little device.

A few minor problems, that some of you may know the answer to;

• What other radio stations can be listened to on the n800? AccuRadio is not my thing, and BBC Radio 1 feed did not work. Is there a list somewhere of known working feeds, or has anyone got any specific recommendations?
• There's a lot more software packaged for the 770, but I guess that will improve with time.
• In mediastreamer my album artwork never appears – does the filename have to be something special or the size adjusted perhaps?
• The webcam image is the wrong way round (i.e. not inverted, so left is right and vice-versa) and there appears no UI option to change that.
• I've used –set-rd-flags to set the device into R&D mode, but can't seem to get a root prompt – any ideas?

I've spent the last couple of hours playing with PulseAudio. Wow. How is this not installed instead of ESD on Fedora and GNOME? This is a sound system done the right way. It's quick, I've not found a bug yet, and it JUST WORKS. It works on Windows, Linux and BSD and works with avahi for new network and HAL for hotplug local sound devices.

In my opinion, “rm -rf esound arts alsa-dmix” – GNOME guys, why is this not an external dependency of 2.17.x?

A lot of very talented hackers have been working for the last couple of releases making GNOME work with smaller memory devices and using memory more efficiently.

Maybe we should focus on the other direction: SPEED. My laptop is a dual core 1.6GHz and has 1.5 gig of memory, and although that's quite a high spec now, in a few months that will be standard. Maybe we should be using more memory for on-disk caches and that sort of thing.

For instance, I startup the laptop, click Applications, click Programming and then the menu appears after about 200ms, and then the icons on the menu after another few hundred milliseconds. This isn't so great when other operating systems appear to have the menu appear instantly on start. Maybe we should cache as much as possible in memory at load?

I click the epiphany icon on the panel launcher. I wait over a second for the window to appear. Why? Internet explorer can appear in a tiny fraction of this on the same machine on Windows XP. I guess it's preloaded into memory, which isn't a problem with over 78% of my memory unused.

I click the terminal icon, the window appears quickly, and the prompt takes a few hundred ms to appear. Am I being impatient, or do we really have to wait nearly a second to launch essential applications?

GNOME Power Manager already has quite a comprehensive DBUS API to allow it to interface with stuff like the brightness applet and gnome-logout screens.

I think this is something that should be cross-desktop compatible, so that XFCE, KDE and GNOME applications can all play nicely. Something like a session service name of org.freedesktop.PowerManagement would be lovely. Of course, this requires standardization of a set API, which traditionally has been hard to agree on.
I've put up a list of the new DBUS API that gnome-power-manager presents, but before anyone stresses out about API compatibility the old API is present as well, except not documented there.
Please have a look through and tell me about any method or signal naming funnies, or areas that don't look right – or even descriptions that don't make sense to mere mortals. When I've got some initial feedback, I'll make the important changes to the new API, and suggest just the “required” DBUS methods to xdg-list for comments about using a org.freedesktop namespace.
p.s. Don't comment too much about the Register() and UnRegister() methods yet, they are just stub functions at the moment, and not tested by gnome-power-self-test at all.
Thanks for any help,
Richard.

I've just pledged my $10 to the nouveau project fund to help replace the binary nvidia driver. This is unofficial i.e. the nouveau developers know about it, but the developers don't actually need that much cash for new hardware.
Initially I thought this was crazy, but after reading the blog entry by David Nielsen I think I understand.

We can say two things with this pledge:

• People are willing to pay $10,000 of their own money to get a free driver. People don't want insecure binary crap.
• Thank you to all the nouveau developers; I don't care if my $10 is not spent on hardware, but instead spent on alcohol and cigarettes. This is my way of saying thanks for doing this difficult and time consuming work. It's not easy coding on drm and Xorg without hardware specifications, and there's not that many people on the planet that could do this.

Okay, after my last post where I discussed waf, I've been pointed to cmake. This is what KDE4 will use, and is meant to be better than automake.

I'll cut to my personal conclusions:

• cmake would need lots of GNOME-specific extra modules written (for instance gnome-doc-utils) and POTFILES support.
• cmake is fast to configure and build and has pretty output
• cmake syntax is much more concise and easy to learn than m4
• It's not obvious how you enable make dist or make check, although I'm new to all this
• cmake has an optional gui based (easier to use in my opinion) configuration system.
• Lots of useful modules have already been written, for example pkg_check_modules
• Executing stuff like “libtool –mode=execute dbus-binding-tool” is quite difficult, although this should probably be wrapped up and abstracted in a module.
• There are not that many standards in cmake, for example do you include directories before or after you've checked for dependencies? There would need to be GNOME guidelines on this sort of stuff.
• The supplied examples are really simple, which don't help much.
• It's a single system-wide install leaving single CMakeLists.txt in each directory. Very clean.
• It's an established product with many people supporting it.

I have done some testing with gnome-power-manager and found it to be stable, and fast – although it does require you practically re-writing how the build is done.

So, anybody had any good or bad experiences with cmake? Thanks.

First, apologies about the long blog.

The programs autoconf, automake are not the easiest friends to get to know. Scripted in odd languages, and with seemingly many ways to do the same thing they are confusing. Most developers I know simply copy/paste configure.in code from one project to another with little understanding of how it works. I call it auto-foo.

People working on GNOME have looked at many replacements over the years, and for gnome-power-manager I've even looked at using scons as a build system in the past. Scons is great for building a program, but not suitable for managing a project. Something bigger and better is required.

I've also been following the progress of a project called waf quite closely for the last few months, and even getting involved with providing gnome example code and filing bugs. All the helper modules are python, so it's quite easy to extend and hack. As a build system it's looking quite promising, and I have even got a local copy of gnome-power-manager built using it. It takes about half the time to configure and build compared to ./configure && make and also has pretty output formatting.

I have found a few architectural design choices in waf that in my mind make it less suitable as a general build system:

• It creates project cache files in ~/.wafcache, which is obviously not okay in an automated build machine. In my opinion it should create the configure cache in the project directory under .waf/_cache_.
• There is a full tree of wafadmin (waf python source code) in every project, which for managing many projects is a no-no. That's like having a copy of the m4 interpreter in every module (okay, it's pretty small, but still a bad idea)
• Waf has no stable branch, and the API is not stable yet. I keep having to change my wscripts to keep up with svn head.
• You have to set the WAFADMIN path for each user if you have installed a shared copy in /usr/local/share – no other paths are permitted. waf's ability to work with a shared wafadmin path is poor.
• By default waf outputs details in console colour text mode – and the yellow text is unreadable.
• Checking for headers is not simple, requiring a few lines of python for each include, where autoconf could do this in one line.
• You have to decompress a semi-binary waf-light file to waf before you can start. This also smatters files into ~/.waf-version/wafadmin/. This is confusing on so many levels. If waf installed a single system shared copy then we wouldn't need all this madness.
• You can have lots of different input files, like wscript, wscript_build, wscript_configure etc. I don't think the extra suffix saves anything at all except a layer of indentation, and it certainly confuses people.
• Handling of the .po, .xml and .in files for GNOME is basic at best (mainly my fault).

waf does do a lot of stuff right in my opinion:

• All generated files are put into a _build_ directory rather than clutter up the source tree.
• Configure checking is really quick and cached for the next run
• Building is fast due to parallel building
• Dependency resolution is really quick, REALLY quick.
• Can change the prefix and destpath for rpms and debs.
• Lots of support for lots of languages (qt, c++, c, java, tex and more) and modules ready to go
• Written in 100% python so no messing about with custom scripting languages – it also means you can do some funky python stuff in the wscript.

This is simple stuff should just work. An application developer shouldn't have to be playing with manually setting WAFDIR or debugging m4.
In my ideal world (with my GNOME “just works” hat on), waf would install the common python files in /usr/share/wafadmin and there would be one main file waf in /usr/bin. waf would just run the top level wscript in each project and then follow subdirs looking for other wscripts. The author isn't keen on this, and would prefer one complete copy of waf in each project. In my opinion there's a fair bit that needs to be changed before it can be used with GNOME software.
What can we do about waf? It's BSD licensed, so we could fork the project and make it more suitable for GNOME (and then try to stay in sync or contribute the new stuff back to waf). We could just re-write the frontend (waf-gnome?) so that it works better with stuff like jhbuild and is easier to use. Or we could just start pestering the maintainer to modify the way development is going.
So, the purpose of this blog. What do you think about the way forward? Do we keep limping on with auto-foo? Is it just me who doesn't understand all this m4 stuff? Is waf a viable system to try? Has anybody else got any ideas for a new build system? Am I asking too many questions?

Thanks.

Dear Lenovo,

In your latest BIOS you've added into OperationRegion GNVS a flag called LINX which is only set high if the OSI name is “Linux”. I assume this is to tell the EC0 to do something different just for the Linux case. I'm guessing it is not to move brightness changes from EC level to ACPI layer (as I've tried that and it still doesn't work) so I'm a bit confused. Please tell us what it does.
Also, I've noticed your new public release BIOS does not include the trivial changes that I sent to your BIOS engineers regarding reading and exporting the present battery voltage, design voltage, and design capacity. I'm sure you are aware this breaks completely the remaining time calculation on Windows XP and reduces the accuracy in Linux by about 20% (as we have to guess the values).
Plus, the release notes with the new BIOS were not exactly helpful in explaining the changes. At the moment, I'm stuck with a laptop that won't let me change the screen brightness automatically, and with wildly inaccurate remaining charge notifications. Does that count as defective?

Many thanks,

Richard Hughes