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?
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?
Why doesn't inotifywatch /sys/kernel/uevent_seqnum work? I get no changes reported at all – and I've even tried using inotify in C adding a watch for IN_ALL_EVENTS. Maybe I'm being really stupid here, but inotify doesn't seem to work at all for sysfs. Help appreciated.
EDIT: Yes, I was being stupid. sysfs doesn't change the value until the file is read. Of course. poll to the rescue, except now that doesn't even work…
During the 2.17.x development phase, I was experimenting with the g-p-p UI. I changed the preferences to be per-task (e.g. “display”) rather than per state (e.g. “on ac”) so we could add more configuration parameters. Yes I know, bad, bad, bad – read on…
A few people, who's opinions I respect, told me that the new preferences interface was, well, pretty crap.
I reverted to the 2.14.x style UI a few weeks ago. I also removed some configurable features from the UI (where we can choose sane defaults for 99% of the use cases) and also added one item, namely cpu frequency scaling selection.
We are very close to the string freeze, so I would like some quick feedback or suggestions for alternate wording of individual labels if they are difficult to understand or translate. Please leave comments here or email me directly. Many thanks.
OLPC people: wow. My test-B laptop arrived yesterday morning. I assumed I would have to stick with the test-A boards for hibernate and suspend testing – but no. Of course, now I feel guilty for not doing more on the power management side of things – so as soon as exams have finished (1 more week) I'll start doing some proper work – promise.
Okay, one down, a few more to go. Now we have a fully functional inhibit applet.
Inhibit applet (with wrong icons)
The icons are of course wrong, but I've asked on tango-list for better metaphors (and hopefully better icons).
This applet took about 40 minutes to write. The reason for this is my MATLAB simulations take a long time, and now I can just leave the auto-suspend option enabled and just click one button when matlab is running. The same goes for vmware. Don't use this applet if you just use GNOME software, instead file a bug to make the application use the Inhibit() and UnInhibit() methods as this stuff should “just work”.
Now that gnome-power-manager can do trivial applets, I'm open to suggestions to what would be sane to expose to a power user as additional “manually add” features.
Ideas I'm playing with at the moment include:
- Hotspot applet : click the icon and the computer won't auto-suspend or blank the screen until it is clicked again. Useful for proprietary programs that don't support the Inhibit() interface like matlab or vmware.
- CPU frequency scaling applet : i.e. a re-implementation of the existing cpufreq-applet but using g-p-m to do the policy and HAL to do the heavy lifting. Should be tiny in comparison to the old applet (and not be setuid), and would work well with existing g-p-m policy.
- Logout, suspend, hibernate and shutdown icons (power-applet) : i.e. a set of icons that provide one click access to these functions (and that hide individual icons if you have no support or not enough permissions). i.e. a distro would add this applet, and it would show the right stuff on the right computers.
Feel free to suggest other “cool applets”, or just tell me I'm insane. Thanks.
I've just merged Benjamin Canou's new brightness applet into gnome-power-manager CVS. It's still WIP, but it looking good already.
Some sweet applet action…
If you've got a laptop without brightness buttons, you can now change the brightness easily. And yes, before anyone has a coronary, this is an applet and not another notification area icon, so you have to add it manually if you want it.
We have chosen to integrate this with g-p-m and not use HAL method calls directly as g-p-m is the policy agent. This means it's doing some clever things in the background – for instance dimming your screen when the computer session is idle, or changing your brightness when you are on battery power, and we have to be a bt clever when we try to change things manually.
Now, I've got no problem moving this applet into gnome-applets long term if desired, but for the moment the BrightnessLcd interface for g-p-m is not stable, and might change at a moments notice. You'll have to manually add –enable-applets to the gnome-power-manager configure line if you want to build this from CVS now.
Reading back byte EC0:0x31 on a IBM Thinkpad embedded controller returns the laptop panel brightness. Setting this byte changes the panel brightness. This is how the ibm_acpi module has worked for years. Hacky, but it worked.
On a Lenovo N100, doing this didn't work due a slightly different embedded controller. I've managed to work out that you can read the brightness back (0-7) from reading the byte EC0:0xB9 (\_SB.PCI0.LPCB.EC0.BRTS) but changing it does nothing to the panel brightness. I can set the EC0:0xB9 value manually, and read back the 'new' value but I can't get EC0 to change the brightness at all.
I'm guessing Lenovo have upgraded the EC0, and now we either:
- Can't software control the brightness due to physical h/w limitation
- Have to poke some other register to make the brightness value “set”
I've had a look at the Renesas H8S datasheets (used for the EC0 chip) but it just seems like a bog standard micro-controller.
I've also read the 2161BV ec.s disassembly of the ThinkPad EC0 firmware (which looks like it should do the right thing) but I can't seem to get hold of the decompiled sources for the latest Renesas chip used in the N100. I've a sneaky suspicion there is either a software bug in the EC0 firmware, or that there is just no physical electrical connections to be able to change the brightness in software.
There's a pint offered at the next GUADEC for any help getting this to work.
EDIT: Update: setting the brightness to 7 using the Fn keys and then setting C0:0xB9 value to zero, and then pressing Fn brightness up, the display is set to brightness 1. This means we just have to convince the EC0 to update the brightness, which maybe we could do with a fake keypress or something. Still confused.
In my opinion, Lenovo didn't read the ACPI specification when designing the N100 line of notebooks.
I'm unable to get the backlight class support working on my notebook due to the missing _BQC (Brightness Query Current level) method which is meant to be present in the BIOS.
Lenovo do implement the _BCL (Query List of Brightness Control Levels) and _BCM (Set the Brightness Level) methods, so I just cannot understand why they didn't add the additional three line method to have full support for the ACPI “Output Device” class.
Now, after my partial success in getting a new BIOS from Lenovo to fix the battery reporting (fixes the problems in Windows XP also) I've had no more correspondence from Lenovo. I have also been been sent an email “…IBM/Lenovo provides free software support for the first 30 days after the purchase of the machine… Please note that the software support is chargeable after the first 30 days…” which I'm guessing is their way of telling me “stop bothering us, go away, we're not interested in fixing anything“. I'm not sure if I should send the notebook back to LENOVO as defective (as it's quite clearly not working with ACPI as advertised) or just send them a bill for my BIOS hacking.
This notebook is fast and Linux support is pretty good, but the BIOS looks like it was rushed and not properly QA'd. At the moment I would probably not recommend Lenovo to somebody that wants Linux compatible hardware, which is a shame considering how good most of the Thinkpads used to be. Perfect Linux support is only a few man-hours of engineer time Lenovo, and I'm sure that would be cost-effective just with one extra bloke choosing Lenovo hardware “because it works with Linux”.