From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.9 (like Gecko) Description of problem: Using kpowersave, selecting 'suspend to RAM' suspends, but resume fails. It appears that the HAL_PROP_POWER_MANAGEMENT_QUIRK_* environment variables are not set for hal-system-power-suspend-linux. Setting the appropriate variables for the quirks for my system in the environment for kpowersave fixes the issue, but also generates a pair of SELinux denial message (I've had to set SELinux to permissive). SELinux is preventing vbetool (vbetool_t) "write" to /var/run/vbemode (var_run_t). SELinux is preventing vbetool (vbetool_t) "getattr" to /var/run/vbemode (var_run_t) I have not found where those environment variables are supposed to be set. Version-Release number of selected component (if applicable): kpowersave-0.7.3-1.fc8 How reproducible: Always Steps to Reproduce: 1. Select 'suspend to RAM' from kpowersave on a system requiring hal quirks. 2. 3. Actual Results: resume from suspend failed due to the quirks not being used Expected Results: resume should have succeeded by using the quirks. Additional info: In case it matters, this is on a Dell Latitude D620 (and, I think, D630).
Fwiw, my D620 resumes fine with 0 quirks. I don't think you can expect kpowersave (or hal for that matter) to examine your personal environment (for HAL_PROP_POWER_MANAGEMENT_QUIRK_* values). The better/proper place is to set these in hal-info, and in your case, /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi
(In reply to comment #1) > Fwiw, my D620 resumes fine with 0 quirks. Great; mine doesn't. And neither does my D630. > I don't think you can expect kpowersave (or hal for that matter) to examine your > personal environment (for HAL_PROP_POWER_MANAGEMENT_QUIRK_* values). Sure; that was a work-around to force the use of the quirks, based on the code as shipped. > The better/proper place is to set these in hal-info, and in your case, > /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi Note the entry for the D620 in that file, as shipped by Fedora, specifies the quirks I need. The bug I am reporting is that kpowersave is not using the hal-info data, and because of that, resume does not work for me.
OK, can you be specific then, which quirks (from hal-info) are you alleging that kpowersave is ignoring?
To be clear, I'm only asking these extra questions, because my experience is counter to your claims, kpowersave has always used hal-info quirks (and is how I've debugged/tested suspend/resume quirks in the past).
(In reply to comment #3) > OK, can you be specific then, which quirks (from hal-info) are you alleging that > kpowersave is ignoring? vbemode restore and vbe post.
(In reply to comment #1) > Fwiw, my D620 resumes fine with 0 quirks. > > I don't think you can expect kpowersave (or hal for that matter) to examine your > personal environment (for HAL_PROP_POWER_MANAGEMENT_QUIRK_* values). To clarify on this: /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux from hal-0.5.10-1.fc8 does examine these environment variables. I haven't found any other reference to those variables so far. Setting them in kpowersave's environment, or in my .bashrc before logging in does change the behavior of kpowersave on my system.
I tested again by removing the env vars from my .bashrc, logging out, logging back in, suspending to RAM, and resume failed. I rebooted my system to pull in the new kernel. The kde packages were updated on Wednesday. And now it appears to work. Looks like something in the new packages fixed the issue.