Latest working kernel version: 2.6.27 Earliest failing kernel version: probably 2.6.28-rc1, but could be later in the release candidates. Distribution: Ubuntu 8.10 Hardware Environment: Asus, N20A, all intel. Problem Description: If the laptop loads the video module at boot time, /sys/devices/virtual/backlight/acpi_video0/brightness is created. However, it's all backwards, confusing applications like gnome-power-manager and the likes (well, that basically means hal). Echoing 0 to 'brightness' raises the backlight of this laptop to maximum. Echoing 13 to it, takes the backlight to a minimum. actual_brightness' seems to stay at 0 at all times. If I disalllow the video module to be loaded at boot time, there's no backlight interface in /sys/class/backlight/*. But, nevertheless, the xbacklight utility and hal seem to be able to control the backlight just fine. In this latter case, withouth the video module loaded, xbacklight & hal handle the backlight correctly, i.e. less means lower backlight, and more means brighter backlight. I just confirmed this problem exists with the latest git from Linus' tree, as well as the rc8 patch. If I remember correctly, the 2.6.27-series created an interface under /sys/devices/platform/asus-laptop/ for controlling backlight which worked just fine. Please let me know what additional information to post. I'd love to have this fixed before the 2.6.28 release. ----- http://dl.getdropbox.com/u/175461/lspci-nnvv.output http://dl.getdropbox.com/u/175461/dmidecode.output
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 16 Dec 2008 03:36:11 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12235 > > Summary: /sys/devices/virtual/backlight/acpi_video0/brightness > has it backwards > Product: ACPI > Version: 2.5 > KernelVersion: 2.6.28-rc8 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Power-Video > AssignedTo: acpi_power-video@kernel-bugs.osdl.org > ReportedBy: khashayar.lists@gmail.com > > > Latest working kernel version: > 2.6.27 > > Earliest failing kernel version: > probably 2.6.28-rc1, but could be later in the release candidates. > > Distribution: > Ubuntu 8.10 > > Hardware Environment: > Asus, N20A, all intel. > > Problem Description: > If the laptop loads the video module at boot time, > /sys/devices/virtual/backlight/acpi_video0/brightness is created. However, > it's > all backwards, confusing applications like gnome-power-manager and the likes > (well, that basically means hal). Echoing 0 to 'brightness' raises the > backlight of this laptop to maximum. Echoing 13 to it, takes the backlight to > a > minimum. > actual_brightness' seems to stay at 0 at all times. > > If I disalllow the video module to be loaded at boot time, there's no > backlight > interface in /sys/class/backlight/*. But, nevertheless, the xbacklight > utility > and hal seem to be able to control the backlight just fine. In this latter > case, withouth the video module loaded, xbacklight & hal handle the backlight > correctly, i.e. less means lower backlight, and more means brighter > backlight. > > I just confirmed this problem exists with the latest git from Linus' tree, as > well as the rc8 patch. > > If I remember correctly, the 2.6.27-series created an interface under > /sys/devices/platform/asus-laptop/ for controlling backlight which worked > just > fine. > > Please let me know what additional information to post. I'd love to have this > fixed before the 2.6.28 release. OK, that's weird. I have a suspicion that we're about to find out that this is intentional, but I don't know what the fix is..
Reply-To: mjg59@srcf.ucam.org On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote: > OK, that's weird. I have a suspicion that we're about to find out that > this is intentional, but I don't know what the fix is.. My recollection is that some BIOSes provide the list of brightness values in reverse order - someone posted a patch to sort them in-kernel, but I can't remember what happened to it. xbacklight will work because it triggers a direct write to the hardware if the acpi driver isn't loaded.
On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote: > On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote: > > > OK, that's weird. I have a suspicion that we're about to find out that > > this is intentional, but I don't know what the fix is.. > > My recollection is that some BIOSes provide the list of brightness > values in reverse order - someone posted a patch to sort them in-kernel, > but I can't remember what happened to it. xbacklight will work because > it triggers a direct write to the hardware if the acpi driver isn't > loaded. > right, this seems to be a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=12037 khashayar, please attach the result of "grep . /proc/acpi/video/*/*/*". please try the patch in http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5 and see if it helps. thanks, rui
On Wed, Dec 17, 2008 at 1:57 AM, Zhang Rui <rui.zhang@intel.com> wrote: > On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote: >> On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote: >> >> > OK, that's weird. I have a suspicion that we're about to find out that >> > this is intentional, but I don't know what the fix is.. >> >> My recollection is that some BIOSes provide the list of brightness >> values in reverse order - someone posted a patch to sort them in-kernel, >> but I can't remember what happened to it. xbacklight will work because >> it triggers a direct write to the hardware if the acpi driver isn't >> loaded. >> > right, this seems to be a duplicate of > http://bugzilla.kernel.org/show_bug.cgi?id=12037 > > khashayar, > please attach the result of "grep . /proc/acpi/video/*/*/*". > please try the patch in > http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5 > and see if it helps. > Here's the output of "grep . /proc/acpi/video/*/*/*". The video module wasn't loaded at boot time, but just before greping. I don't know if that has any relevance. Also, there's an external display attached at this point. /proc/acpi/video/VGA/CRTD/brightness:<not supported> /proc/acpi/video/VGA/CRTD/EDID:<not supported> /proc/acpi/video/VGA/CRTD/info:device_id: 0x0100 /proc/acpi/video/VGA/CRTD/info:type: CRT /proc/acpi/video/VGA/CRTD/info:known by bios: yes /proc/acpi/video/VGA/CRTD/state:state: 0x1d /proc/acpi/video/VGA/CRTD/state:query: 0x00 /proc/acpi/video/VGA/DVID/brightness:<not supported> /proc/acpi/video/VGA/DVID/EDID:<not supported> /proc/acpi/video/VGA/DVID/info:device_id: 0x0321 /proc/acpi/video/VGA/DVID/info:type: DVI /proc/acpi/video/VGA/DVID/info:known by bios: yes /proc/acpi/video/VGA/DVID/state:state: 0x1d /proc/acpi/video/VGA/DVID/state:query: 0x00 /proc/acpi/video/VGA/HDMI/brightness:<not supported> /proc/acpi/video/VGA/HDMI/EDID:<not supported> /proc/acpi/video/VGA/HDMI/info:device_id: 0x7320 /proc/acpi/video/VGA/HDMI/info:type: DVI /proc/acpi/video/VGA/HDMI/info:known by bios: yes /proc/acpi/video/VGA/HDMI/state:state: 0x1d /proc/acpi/video/VGA/HDMI/state:query: 0x00 /proc/acpi/video/VGA/LCDD/brightness:levels: 100 91 86 81 76 70 65 60 55 50 45 40 35 30 25 20 /proc/acpi/video/VGA/LCDD/brightness:current: 86 /proc/acpi/video/VGA/LCDD/EDID:<not supported> /proc/acpi/video/VGA/LCDD/info:device_id: 0x0410 /proc/acpi/video/VGA/LCDD/info:type: LCD /proc/acpi/video/VGA/LCDD/info:known by bios: yes /proc/acpi/video/VGA/LCDD/state:state: 0x1d /proc/acpi/video/VGA/LCDD/state:query: 0x00 I will try the patch as soon as I can, and get back to you. > thanks, > rui > Thank you, Khash.
On Wed, Dec 17, 2008 at 10:44 AM, Khashayar Naderehvandi <khashayar.lists@gmail.com> wrote: > On Wed, Dec 17, 2008 at 1:57 AM, Zhang Rui <rui.zhang@intel.com> wrote: >> On Wed, 2008-12-17 at 04:55 +0800, Matthew Garrett wrote: >>> On Tue, Dec 16, 2008 at 10:00:23AM -0800, Andrew Morton wrote: >>> >>> > OK, that's weird. I have a suspicion that we're about to find out that >>> > this is intentional, but I don't know what the fix is.. >>> >>> My recollection is that some BIOSes provide the list of brightness >>> values in reverse order - someone posted a patch to sort them in-kernel, >>> but I can't remember what happened to it. xbacklight will work because >>> it triggers a direct write to the hardware if the acpi driver isn't >>> loaded. >>> >> right, this seems to be a duplicate of >> http://bugzilla.kernel.org/show_bug.cgi?id=12037 >> >> khashayar, >> please attach the result of "grep . /proc/acpi/video/*/*/*". >> please try the patch in >> http://bugzilla.kernel.org/show_bug.cgi?id=12037#c5 >> and see if it helps. >> > Here's the output of "grep . /proc/acpi/video/*/*/*". The video module > wasn't loaded at boot time, but just before greping. I don't know if > that has any relevance. Also, there's an external display attached at > this point. > > /proc/acpi/video/VGA/CRTD/brightness:<not supported> > /proc/acpi/video/VGA/CRTD/EDID:<not supported> > /proc/acpi/video/VGA/CRTD/info:device_id: 0x0100 > /proc/acpi/video/VGA/CRTD/info:type: CRT > /proc/acpi/video/VGA/CRTD/info:known by bios: yes > /proc/acpi/video/VGA/CRTD/state:state: 0x1d > /proc/acpi/video/VGA/CRTD/state:query: 0x00 > /proc/acpi/video/VGA/DVID/brightness:<not supported> > /proc/acpi/video/VGA/DVID/EDID:<not supported> > /proc/acpi/video/VGA/DVID/info:device_id: 0x0321 > /proc/acpi/video/VGA/DVID/info:type: DVI > /proc/acpi/video/VGA/DVID/info:known by bios: yes > /proc/acpi/video/VGA/DVID/state:state: 0x1d > /proc/acpi/video/VGA/DVID/state:query: 0x00 > /proc/acpi/video/VGA/HDMI/brightness:<not supported> > /proc/acpi/video/VGA/HDMI/EDID:<not supported> > /proc/acpi/video/VGA/HDMI/info:device_id: 0x7320 > /proc/acpi/video/VGA/HDMI/info:type: DVI > /proc/acpi/video/VGA/HDMI/info:known by bios: yes > /proc/acpi/video/VGA/HDMI/state:state: 0x1d > /proc/acpi/video/VGA/HDMI/state:query: 0x00 > /proc/acpi/video/VGA/LCDD/brightness:levels: 100 91 86 81 76 70 65 60 > 55 50 45 40 35 30 25 20 > /proc/acpi/video/VGA/LCDD/brightness:current: 86 > /proc/acpi/video/VGA/LCDD/EDID:<not supported> > /proc/acpi/video/VGA/LCDD/info:device_id: 0x0410 > /proc/acpi/video/VGA/LCDD/info:type: LCD > /proc/acpi/video/VGA/LCDD/info:known by bios: yes > /proc/acpi/video/VGA/LCDD/state:state: 0x1d > /proc/acpi/video/VGA/LCDD/state:query: 0x00 > > > I will try the patch as soon as I can, and get back to you. > I've now tried the patch and can confirm that it fixes the problem. Well, almost; I'm now having the same issue reported in comment 8, http://bugzilla.kernel.org/show_bug.cgi?id=12037#c8. But that, I guess, is a whole other thing. Thanks for this one, though! Will the patch be part of the 2.6.28 final release? Regards, Khash.
For the dark screen issue, please open a new bug report. :) I think the patch will be queued for 2.6.29. *** This bug has been marked as a duplicate of bug 12037 ***
Khashayar, please follow the suggestion in http://bugzilla.kernel.org/show_bug.cgi?id=12249#c34 and see if it helps.
*** This bug has been marked as a duplicate of bug 12249 ***
hi, please follow the instructions in http://bugzilla.kernel.org/show_bug.cgi?id=12249#c60 to see if the patch helps.
hi, the previous patch you tested is not for upstream kernel. please try this patch in http://bugzilla.kernel.org/show_bug.cgi?id=12249#c69