Log in

No account? Create an account
Caveat: All this refers to CVS versions of HAL and pm-utils, and… - Technical Blog of Richard Hughes

Richard Hughes
Date: 2006-06-19 17:24
Subject: (no subject)
Security: Public
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
    <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>

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.
Post A Comment | 9 Comments | Share | Link

User: (Anonymous)
Date: 2006-06-19 18:00 (UTC)
Subject: (no subject)
s2ram from http://suspend.sourceforge.net/ basically follows the same goal. It also has a whitelist already which you might use.
s2ram also has the advantage that if you don't know which parameters/workarounds are necessary, you can try them with s2ram:
So you'd start with
./s2ram (if your laptop is already listed you are lucky)
./s2ram -f (force, if it works, great)
./s2ram --acpi_sleep=1
./s2ram --acpi_sleep=2
./s2ram --acpi_sleep=3 1=s3_bios, 2=s3_mode, 3=both
./s2ram --vbe_save
./s2ram --vbe_post

So, the first invocation that works for your laptop should be submitted. There is also a great documentation.

Why not join forces with suspend.sf.net?
Reply | Thread | Link

Richard Hughes
User: hughsient
Date: 2006-06-19 18:12 (UTC)
Subject: good idea
Yes, this is very similar and I've seen it before. s2ram does the whitelisting on the dmi data, and is unsuitable to use in HAL in it's current form (as we need to match the adapter not the computer) although we could use some of the entries with bodges to kickstart the HAL database.

We also need more information than what can be gleaned from the suspend.sf.net list, as I would be keen to see patterns (like all Intel adapters on Toshiba's need the s3_mode option) so we can do xml matching on whole classes of computers without listing them all indervidually.

I think the suspend guys would agree that a whitelist shouldn't be in a .c file, and a FDI file is probably best as it's architecture neutral and easy to edit.

I'll talk to some of the guys on #hal and see what they say.
Reply | Parent | Thread | Link

User: (Anonymous)
Date: 2006-06-19 18:22 (UTC)
Subject: Re: good idea
Yeah, hardcoding the whitelist in the c-file is a bit ugly. FDI files might be better suited.

Still your script does not tackle the issue, that people have to find out first, which options they might need. This is where s2ram is great because it allows you to test all possible combinations by simply passing different parameters to s2ram. How do you intend to solve that problem?
Reply | Parent | Thread | Link

Richard Hughes
User: hughsient
Date: 2006-06-19 18:27 (UTC)
Subject: Re: good idea
I don't know, I guess write a script (or get together with the s2ram guys) to do the same thing. We can easily edit a temp fdi file, and automatically restart HAL, so changing stuff on the fly shouldn't be a problem.
Reply | Parent | Thread | Link

User: (Anonymous)
Date: 2006-06-19 18:34 (UTC)
Subject: Re: good idea
Btw, this all sounds very good. I dream of the day, when I don't have to edit my /boot/grub/menu.lst anymore to get STR working. (I need acpi_sleep=s3_bios for my nx7000)

Another advice:
Ubuntu has a laptop testing group. You might inform them when your script is finished. I'm sure they are willing to test and run your script.
Reply | Parent | Thread | Link

User: (Anonymous)
Date: 2006-06-19 20:33 (UTC)
Subject: What if the answer is 'd) None of the above'?
Seriously, on my Thinkpad z60t (i915) I need acpi_sleep=s3_mode, and vbetool save/restore mode. But in addition I need the following:

cat /proc/bus/pci/00/02.0 > /tmp/video_state

cat /tmp/video_state > /proc/bus/pci/00/02.0

I know, crazy, but 'vbestate save/restore' does not work here, at least not reliably.

Ken H.
Reply | Thread | Link

Richard Hughes
User: hughsient
Date: 2006-06-19 20:47 (UTC)
Subject: Re: What if the answer is 'd) None of the above'?
I think we need to fix vbetool save/restore. Does video_adapter_pm.vbemode_restore work?
Reply | Parent | Thread | Link

User: (Anonymous)
Date: 2006-06-20 04:11 (UTC)
Subject: Re: What if the answer is 'd) None of the above'?
Hmmm, while checking this out, I decided to grab the vbetool source to see what it was doing. I discovered that my vbetool binary was having an error saving the state. I built it manually (Gentoo) intending to debug it, but it works fine now. Strange.
Reply | Parent | Thread | Link

User: (Anonymous)
Date: 2006-06-20 04:43 (UTC)
Subject: Re: What if the answer is 'd) None of the above'?
So, "it works for me".
Reply | Parent | Thread | Link

my journal
April 2008