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.VideoAdapterP
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 -*- -->
system.product: Satellite Pro A10
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.Devic
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.