From: Richard Hughes <hughsient gmail com>
To: Brian Hutsell <bhut_ooto yahoo com>
Cc: GPM Mailing List <gnome-power-manager-list gnome org>
Sent: Wed, May 12, 2010 11:56:18 PM
Subject: Re: [Bug 617529] gnome power manager doesn't recognize battery at startup
On 12 May 2010 16:28, Brian Hutsell <
bhut_ooto yahoo com> wrote:
> The brightness settings are busted on master. There appear to be several
> levels of issues.
ccing the mailing list, I hope this is okay.
> 1) The most obvious problem was caused by commit
> d3594664f59ef31278f7d95f9f73e2d52fe3a3f6
> Author: Richard Hughes <
richard hughsie com>
> Date: Thu May 6 20:40:07 2010 +0100
>
> Provide a pkexec helper for systems that do not have xbacklight
> capability
>
> a) It explicitly references /usr/sbin/ instead of pulling the file from
> the path. It's fairly standard practice (and
default) to install programs
> you compile yourself into
/usr/local, and to setup precidence between the
> versions in /usr/local/{bin,sbin} and /usr/{bin,sbin} by setting up the
> path. Please remove the hardcoded reference. After installing into
> --prefix=/usr/local, this causes a long stream of errors to .xsession-errors
> of the variety:
> Error accessing /usr/sbin/gnome-power-backlight-helper: No such file
> or directory
This is the way pkexec works. pkexec is not supported on any other
root as the binary name is hardcoded in the policy file. You'll need
to install the package systemwide for this to work correctly.
> b) When providing either a symbolic link or copying
> /usr/sbin/gnome-power-backlight-helper to its desired place, even with suid
> set, it requires root permissions in order to run. A pop-up window appears
> to allow entering the root
password. After this password is entered, as you
> move the slider, you are continuously barraged with these pop-up windows.
> From a user point-of-view, this is intolerable.
Well, if you installed the package systemwide then the polkit policy
file would have been installed in /usr/share/polkit-1/actions/ and the
UI would have not been shown.
> c) The commit message appears to suggest that this is to fix systems
> that couldn't do it for themselves in user mode. Before this commit, system
> could adjust the brightness on my LCD just fine. This suggests that the
> code that detects when this mechanism should be used isn't working properly.
Sure, that could be the case. It should only fallback to the helper
code if xrandr failed to find a device and change the brightness. I
assume if you kill g-p-m you can still change the brightness using
the
hotkeys?
> 2) The following commits appear to be intertwined, s.t. reverting just one
> isn't enough:
> a) commit d3594664f59ef31278f7d95f9f73e2d52fe3a3f6: Provide a
> pkexec helper for systems that do not have xbacklight capability
> b) commit 176df6b38f26936d05705a548f3ea2356c2b42b1: As we no longer
> have more than one backlight mechanism, remove a ton of abstract code.
> c) commit d23f4afbb99ad914ca0e33feff365d15a1e60532: Remove
> GetPreferencesOptions() and untie the preferences fro the daemon. Fixes
> #617529
>
> Since 2c) is the change I was supposed to test, continuing to revert changes
> is sort of pointless.
You need to install system wide for the PolicyKit stuff to work
correctly, or, you have to build a PolicyKit in the same prefix
that
you're installing to, and start it by hand.
Richard.
