On Sat, 2008-09-27 at 01:00 +0000, Bill Filler wrote:
> Good find Torsten and James. Re: the gconf key, what effect will "/apps/gnome-power-
> > manager/general/lid_battery nothing" have? Will the system still suspend like we want it to on lid-close?
No, I believe it will disable that too.
> - Might be better to actually fix/patch the g-p-m code that is
> incorrectly tracking the lid state. Or is it acpi that is not reporting
> it correctly? The real question is how does
> /proc/acpi/button/lid/LID0/state get set, and why is it not correctly
> set to open in the scenario Torsten describes above.
I doubt it is g-p-m. It is hal, or probably lower, acpi would be my
guess as you suggest. I believe the fact it is not set correctly will
actually be a kernel issue, though it may be something to do with the
hardware or bios that means the kernel isn't setting the value
correctly.
On Sat, 2008-09-27 at 01:00 +0000, Bill Filler wrote: general/ lid_battery nothing" have? Will the system still suspend like we want it to on lid-close?
> Good find Torsten and James. Re: the gconf key, what effect will "/apps/gnome-power-
> > manager/
No, I believe it will disable that too.
> - Might be better to actually fix/patch the g-p-m code that is button/ lid/LID0/ state get set, and why is it not correctly
> incorrectly tracking the lid state. Or is it acpi that is not reporting
> it correctly? The real question is how does
> /proc/acpi/
> set to open in the scenario Torsten describes above.
I doubt it is g-p-m. It is hal, or probably lower, acpi would be my
guess as you suggest. I believe the fact it is not set correctly will
actually be a kernel issue, though it may be something to do with the
hardware or bios that means the kernel isn't setting the value
correctly.
Thanks,
James