Category: Uncategorized

I'm looking to add an fdi file to HAL so we can check if a battery is defective and is likely to go boom.

I want to see if I can match battery serial numbers against fdi rules and if present, merge a key battery.is_likely_faulty so applications like gnome-power-manager can give a nice warning message so the user can go check on the recall website.
Note, I think we need to keep the word “likely” to avoid lawsuits. :-)

So, I need some data. If you have a Dell laptop:

 – Latitude: D410, D500, D505, D510, D520, D600, D610, D620, D800, D810
 – Inspiron: 500M, 510M, 600M, 700M, 710M, 6000, 6400, 8500, 8600, 9100,
9200, 9300, 9400, E1505, E1705
 – Precision: M20, M60, M70, M90
 – XPS: XPS, XPS Gen2, XPS M170, XPS M1710

Or an HP/Compaq laptop:

HP Pavilion : dv1xxx ze2xxx
Compaq Presario: V2xxx M2xxx
HP Compaq : nx48xx

I would really appreciate if you could send me (richard at hughsie dot com) the complete output of lshal. Include [fire] in the subject so I can filter them easily :-). And also, if you know your laptop might be affected (or another one that might have been affected) and isn't a DELL or HP then please send me the data also.

IMPORTANT NOTE: Don't panic. Your battery is probably fine, but I want to see if these models express the battery serial number in HAL (via ACPI) or just fill in junk data.

Thanks.

UPDATE!

Please also state:

• If your battery is affected by the recall
• The value of your barcode
• cat /proc/acpi/battery/BAT*/info | grep number

Also, I would appreciate it if someone could test this hal patch as it looks like it's needed to properly detect the DELLs.

Okay, two posts in one day. A new record for me. :-)
Whilst playing with bug #347913 I've been thinking about killing the “Information” window (as this is also in-process with gnome-power-manager).

The planned solution is like NetworkManager, where you have all the possible battery devices on the drop down, where you click them for more information. I can then launch gnome-power-info (or whatever the executable will be called) with the HAL UDI, and the user can get all the detailed hardware information (like present capacity and stuff like that).
Now, two questions all you p.g.o readers: What is the standard for the right-click menu, and what belongs in left-click? The r-c-m has About and Help currently, but I've a feeling Preferences belongs there too. Second question. Is this sane? There's nothing in CVS yet.

Lots of people has recently been striving to get down the memory requirement of thier GNOME application or deamon.

I've recently created an out of process (the old one was in-process for each instance) graphing program, gnome-power-statistics. The displayable name is yet to be decided, but it's basically a graph viewer that talks to gnome-power-manager over DBUS to the shiny new org.gnome.PowerManager.Statistics interface.

Notice the surge in power usage as I start “make distcheck” on HAL in the 23rd minute.

Now, I know the application really needs some HIG love, but this removes a whole chunk of memory from the session daemon, namely 500kb of writable memory.

Comments welcome.

Maybe because it's been a long week, or maybe because I'm being a moron, I can't see to get a specific dbus annotation to work. The problem I'm having is with the signature “a(ii)” i.e. an array of a structures made up of two integers.

There's no example in the tutorial or the test/glib/test-service-glib.xml file, so I'm somewhat lost. I'm guessing the prototype would contain 'GList **list', but when I try appending a GValueArray of two G_TYPE_INT's then I don't get any data returned.

So anybody really using the glib bindings for dbus to unwrap an array of structures? Pointers to code or documentation welcome. Thanks.

Today I've released 2.15.92 which is the last test release before 2.16.0 is released. I'm amazed at the work people have done in the last few weeks to make gnome-power-manager ready for the 2.16.0 release.
Now I've been banned (thanks to the string freeze) making large changes and adding functionality, I've been thinking about functionality to add post 2-16.
I get an email or bugzilla every few weeks asking about CPU frequency scaling, and how to add support into g-p-m. Traditionally the CPU frequency has been changed by system daemons such as cpufreqd (there are a lot more to choose from) which require editing odd files in /etc and are not new-user friendly. Holger Macht has written a addon to control this using HAL, so system and session software can control CPU frequency scaling in an easy, and architecture neutral way.

Maybe this is too much detail for the average user, but the feedback I've been getting is that users are screaming for cpufreq support in g-p-m.
The question is how to expose the options, given that there is are a large number of permutations of governers and working options for any given laptop.
My initial reaction was to hide the “use low power mode” checkbox to do scaling, but some computers scale better than others, and some just dont work in some modes, but do others. So it's got to be exposed in the UI.

So far, all the possible options (assuming you have all the governers installed) are:

#define CPUFREQ_ONDEMAND_TEXT           _(“Based on processor load”)
#define CPUFREQ_CONSERVATIVE_TEXT       _(“Automatic power saving”)
#define CPUFREQ_POWERSAVE_TEXT          _(“Maximum power saving”)
#define CPUFREQ_USERSPACE_TEXT          _(“Custom”)
#define CPUFREQ_PERFORMANCE_TEXT        _(“Maximum performance”)
#define CPUFREQ_NOTHING_TEXT            _(“Do nothing”)

With “Computer processor policy:” as the prefix. New names and descriptions
welcome.

Tell me what you think.

Just a few days ago, gnome-power-manager was accepted as part of the GNOME desktop 2.16 release.

This makes me happy. I've been getting some overwhelmingly good feedback about this, and I'm hoping being part of the release proper means we get more HIG compliance, more translations, and more polish generaly.
I would like to thanks all the contributors to gnome-power-manager over the last couple of years, and all the people that have helped me and pointed the project in the right direction. And for all you translators, you rock.

Okay, a few weeks ago I blogged about a script that could autogenerate a fdi file for HAL that could create the required video_adapter_pm methods and properties needed to suspend and resume your videocard on suspend and hibernate.

So, if you are one of a few people that are running a very recent (CVS less than a few months old) HAL and the new pm-utils (the one from freedesktop.org rather than redhat), and have to set odd kernel command lines or hacky commands to get your machine to work please can you give my script a whirl.

The idea is for technical people to send me autogenerated fdi files that are matched to their hardware, which are then be merged into upstream hal. This means on the next HAL release more systems just work out of the box without new users having to google and add oddball options gleaned from some random post of a bloke that has a similar laptop.

So, if you know you have to set S3_MODE or you have to add dpms suspend calls at the end of your custom suspend script, can you please try pm-utils and my script. The script probably won't be much use if you don't know what the cause your suspend problem is, although you could use it for that.

Feedback, as always, welcome.

Utopia FC5 repository now has never new version of glibc (and the updated deps for glibc…) needed for the new CVS HAL dependency on libvolume_id. This is a good thing as removes a whole chunk of code out of HAL and into a shared library that can be used by other stuff.

Not sure how many people this will affect, but don't run this repo update on an important machine. It all seems to work for me, but test at your peril.

On a related note, the latest g-p-m checks with PolicyKit to prevent the “suspend error: unknown error” if you try to suspend with no (or with a broken) PolicyKit. You'll need to add –disable-policykit to the configure line for now, if you don't use a new HAL or have no desire to test PolicyKit. :-)

Okay, long time no blog, which I'll apologize for: As some of you may know, I've just started a stressful new job for the summer, and am sharing with a friend in Gravesend near London. The house is a new-build, and has no phone-line or Internet yet, and the Internet at work is closely monitored – hence why I havn't blogged since before GUADEC. And people complain my entries are too long, so I'll try to keep this one brief.

There are also a few people in my family who are currently unwell, so all-in-all this month has had little time or concentration on OSS stuff, so apologies if there have been long delays in email replies.

GUADEC: Wow wow wow. I've never been to a GUADEC before, and sure will be going again next year. It was really great to meet all you guys in the flesh, so to speak. It was really odd to talk to people face-to-face for the first time even tho I've known them for years. Apart from not finding my flatmates on the first day till nightfall, and Jon McCann successfully getting me very drunk on the Fluendo beach party, the whole thing was really great. Thanks go to all the people that made me feel very welcome (especially Puaff for the lift from Reus airport).

GNOME Power Manager: Lots of nice fixes and translations being committed (THANKS), and also lots of sane feature requests in bugzilla. Initial feedback on d-d-l is good for inclusion in 2.16, which would be great as other modules can then start relying on the Inhibit stuff for g-p-m and g-s also. Feedback on sleep nomenclature has been good, even tho a recent Fedora kernel has broken resume for a few people. I'm just glad I'm not a kernel maintainer. :-)

Caveat: All this refers to CVS versions of HAL and pm-utils, and thus won't work for older versions.

When you suspend or hibernate, sometimes you have to do crazy things to the video adapter.
I'm lucky with my Toshiba, I don't need any extra options, but some people will need kernel options, vbe options or dpms commands.
In the past this used to be done via per-distro or manual hacks learned from obscure websites.
For instance, FC5 hard-codes different card vendors to do different things, and this over-simplified approach actually breaks resume for my Intel card.
What is needed is fine grained white-listing of certain laptop models and video-cards based on the vendor id and product id.
Now this is great in theory, but certain laptop vendors (as opposed to video card vendors) do funny things to the hardware on the cards.
Luckily we can use the sub vendor id and the sub product id, which should be set as the laptop vendor.
This is found to be just as accurate as the dmi data, as it's practically working at that level anyway.

Recently I added the video_adapter_pm namespace into Hal which lets us specify using FDI files what a computer actually needs to do the suspend and resume.
This means that once the laptop with the oddity has been added, then other laptops of the same type will start to “just work” without the user needing to poke around in config files.
This works in a similar way to how the USB quirk system works in the kernel — someone identifies the problem, and fixes it for everyone.

Now, the observant among you may notice the methods on org.freedesktop.Hal.Device.VideoAdapterPM: SuspendVideo and ResumeVideo.
When these are called, the the hal-system-video-* scripts are called, that actually do the hacks mentioned in the spec (like using the dpms and vbetool commands).
This means that any application that wishes to resume any connected video adapter just has to find a UDI with the capability video_adapter_pm and then execute SuspendVideo and ResumeVideo on it without worrying about any details.

It just so happens, that pm-utils does exactly this!
This means that HAL is used as an abstract layer, with pm-utils driving the video suspend and resume.
It's all a happy coincidence that pm-utils itself is called by HAL during the global Suspend() and Hibernate() methods, but there's no reason these methods can't be used by other software such as powersaved.

That was the good. Now for the bad.

In order to do the right thing for the right machine we have to know the videocard vid, pid, subvid and subpid, which I'm guessing most of you don't know off by heart.
HAL to the rescue. Using this prototype script we can search for video card devices and then generate the correct XML entry for you automatically.
You answer a few easy questions:

Section 1/3 : Kernel parameters
Use S3_BIOS (y|n): n
Use S3_MODE (y|n): n

Section 2/3 : Suspend actions
Use DPMS to force the screen off (y|n): y
Use vbestate restore (y|n): n
Use vbemode restore (y|n): n

Section 2/3 : Resume actions
Set VGA text mode to mode 3 (y|n): n
Use DPMS to force the screen on (y|n): y
Use VGA vbe post (y|n): n

Okay, maybe not so easy, but if you already know you need S3_MODE and S3_BIOS manually entered on the grub command line for resume to work then you just need to say yes to these and no to the others.

So the script does its thing, and you get a nice lump of XML in your home directory:

[hughsie@hughsie-laptop docs]$ cat /home/hughsie/autogenerated_video.fdi
<?xml version=”1.0″ encoding=”ISO-8859-1″?> <!– -*- SGML -*- –>
<deviceinfo version=”0.2″>
  <!–
    system.manufacturer: TOSHIBA
    system.product:      Satellite Pro A10
    bios.release_date:   09/02/2003
    bios.version:        Version 1.30
  –>
  <device>
    <match key=”pci.vendor_id” int=”0x8086″> <!– Intel Corporation –>
      <match key=”pci.product_id” int=”0x3582″> <!– 82852/855GM Integrated Graphics Device –>
        <match key=”pci.subsys_vendor_id” int=”0x1179″> <!– Toshiba America Info Systems –>
          <match key=”pci.subsys_product_id” int=”0x2″> <!– Unknown (0x0002) –>
            <merge key=”video_adapter_pm.dpms_suspend” type=”bool”>true</merge>
            <merge key=”video_adapter_pm.dpms_on” type=”bool”>true</merge>
            <append key=”info.capabilities” type=”strlist”>video_adapter_pm</append>
            <append key=”info.interfaces” type=”strlist”>org.freedesktop.Hal.Device.VideoAdapterPM</append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_names” type=”strlist”>SuspendVideo</append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_signatures” type=”strlist”></append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_execpaths” type=”strlist”>hal-system-video-suspend</append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_names” type=”strlist”>ResumeVideo</append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_signatures” type=”strlist”></append>
            <append key=”org.freedesktop.Hal.Device.VideoAdapterPM.method_execpaths” type=”strlist”>hal-system-video-resume</append>
          </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

Now, copy this file into /usr/share/hal/fdi/policy/10osvendor/ or just take the <device>…</device> information and add to 10-video-power-policy.fdi
Restart HAL, and it all should “just work”. :-)
The idea is that as people get hardware working, we can get these lumps of XML into HAL cvs so that other people don't have the same problems.
The actual utopian possibility is that hardware manufacturers actually send this info from internal testing, but I'm not holding my breath on this one.

Now, please don't send me hundreds of emails saying “this works : here's my lump of XML” as the script is not finished yet.
I'll announce it on this blog as soon as it's been tested really well, but I would appreciate if you could leave a comment if it works for you, or if you think the script needs any bugfixing or other improvements.