[Bugme-janitors] [Bug 23472] 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=23472





--- Comment #7 from Patrick Schaaf <kernelorg at bof.de>  2010-11-24 09:17:05 ---
Thanks Dan for the directions.

On my system I have dbus-send, which works with the command line you gave.

The sysfs stuff is under
/sys/devices/platform/dell-laptop/brightness/dell-laptop
where I have "max_backlight" (7), "actual_backlight", and writable "backlight"
pseudofiles.

writing to the backlight file, has immediately visible, expected outcome.

The dbus-send commands, both reading and writing, are completely consistent
with fondling the sysfs knobs by hand.

When I experience the reported backlight dimming, both the sysfs
actual_brightness file, and the dbus-send reading, STILL SAY 7!

I ran the sysfs / dbus-send stuff from a text console, first without being
logged in (gdm login screen on vt7). Whenever I switch to the gdm screen, the
backlight dims. Switching back to the text console keeps it dim. The
"actual_brightness" file stays at 7. Writing 7 to "brightness" then, has no
effect, probably because the kernel thinks nothing changes. Writing 6 to
"brighness" makes the display brighter, then writing 7 makes it maximally
bright. Switching back to the gdm login screen again DIMS. This is absolutely
repeatable over several tries.

On the other hand, once I log in to X, and switch back and forth between the
running X session and the text console, the visible brighness stays high (after
fondling "brighness" on the text console once, or using the laptop keys).

So, the dimming-that-is-not-visible-in-sysfs-and-dbus, seems to happen when
switching to the gdm login screen.

Hope this helps understanding the problem further.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.