I see this in my syslog: Sep 27 18:46:56 planemask dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.254" (uid=42 pid=25618 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="GetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1020 comm="hald)) This is the gpm thats running in the login session, as far as I can see. Side effect of our switch of hal to be entirely 'at-console' ?
Well, on a tangent, you must be hitting the fallback code -- I'm surprised you're not using BACKLIGHT. Does xbacklight return any data for your display? What machine and graphics is this? As for the failure of GetBrightness, I can't reproduce, but do you also get the warning if you try to change the brightness using the keys with SetBrightness in gdm, or is it just GetBrightness?
xbacklight reports 100.00. this is a T61 with 965 graphics
Same error shows up here in gdm, also when I try to SetBrightness with keys: Oct 6 08:08:09 victoria dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.152" (uid=42 pid=3382 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="GetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1221 comm="hald)) Oct 6 08:08:09 victoria dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.152" (uid=42 pid=3382 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="SetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1221 comm="hald)) This is a Dell XPS M1330 with Nvidia 8400M GS video.
Still getting this with the 2.9.0 intel driver, too.
[root@rikkilap log]# cat /etc/fedora-release Fedora release 12 (Constantine) [root@rikkilap log]# uname -a Linux rikkilap 2.6.31.5-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 i386 GNU/Linux and.... Nov 21 23:05:32 localhost dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.24" (uid=42 pid=1599 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="SetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1194 comm="hald)) Nov 21 23:11:21 localhost dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.79" (uid=42 pid=2756 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="GetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1194 comm="hald)) SetBrightness and GetBrightness I have my laptop docked and the primary display is very dark but the second display is OK. NVidia card. HP nw9440 laptop. http://www.smolts.org/client/show/pub_923ec415-c78c-442a-8fec-664179a75906 [ra@rikkilap Documents]$ xbacklight -get No outputs have backlight property [ra@rikkilap Documents]$ xgamma -> Red 1.000, Green 1.000, Blue 1.000
I see this is against Rawhide. Can we change that to Fedora 12 ?
In dmesg I get: [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
Richard Allen, your problem is possibly something else - this message (and bug) is just about within the login screen. Richard Hughes, I have an Nvidia card (using the binary drivers). xdpyinfo doesn't show the BACKLIGHT extension (and |xbacklight -get| tells me "No outputs have backlight property". The brightness soft-keys on my laptop work fine when I'm logged in, but at the login screen I get the errors for GetBrightness and SetBrightness - one of each at the login screen, and then another set (both Get and SetBrightness) whenever I try to use the softkeys to change the brightness up or down)
Created attachment 377442 [details] /var/log/messages Seeing the same problem when attempting to start gdm on my macbook pro running Fedora 12 (updated to latest updates repo). SMOLT: http://www.smolts.org/client/show/pub_a45bca46-400c-4444-a607-e0e9283eaff4 Dec 10 07:22:31 localhost dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.27" (uid=42 pid=1796 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="SetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1346 comm="hald)) Dec 10 07:22:41 localhost dbus: Rejected send message, 1 matched rules; type="method_call", sender=":1.27" (uid=42 pid=1796 comm="gnome-power-manager) interface="org.freedesktop.Hal.Device.LaptopPanel" member="SetBrightness" error name="(unset)" requested_reply=0 destination=":1.1" (uid=0 pid=1346 comm="hald))
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.