brightness no more working on karmic (KMS)

Bug #397617 reported by alain57 on 2009-07-09
202
This bug affects 36 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
linux (Ubuntu)
Medium
Unassigned
Nominated for Karmic by Marcel Stimberg
Nominated for Lucid by trendzetter
xserver-xorg-video-intel (Ubuntu)
Low
Unassigned
Nominated for Karmic by Marcel Stimberg
Nominated for Lucid by trendzetter

Bug Description

Binary package hint: xorg

hello,
i have two computer, both on karmic (and both with Intel graphic card)
unfortunately there is no way for me to configure the brightness level, nothing is working : brightness keys, xrandr, xbacklight.

i don't know if it is really an xorg bug, xorg an Intel driver bug

of course i also tried to echo some /proc/acpi/video/OVGA/DD0*/brightness devices
but when i do so i receive a permission denied, even as root
a cat on the same element, give me
<not supported>

i read some tutorials speaking about a file in /sys/class/backlight
but on both computer this directory is empty

running xbacklight gave me this output

No outputs have backlight property

please attach the acpidump output,
you can use the latest pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php

Created an attachment (id=24394)
acpidump

On the driver side, we just need to hook up support for sysfs backlight in the KMS code. We don't want to do any direct register access though... If platforms are missing backlight support we should add new sysfs backlight support for them in the kernel. The i915 driver probably needs to get new code here to support i2c based backlight control on pre-opregion platforms. The VBT has info about where the backlight controller is and what commands to issue.

(In reply to comment #3)
> On the driver side, we just need to hook up support for sysfs backlight in the
> KMS code.
> The i915 driver probably needs to get new code here to support i2c based
> backlight control on pre-opregion platforms.

do you mean that register a sysfs backlight class device in KMS code, and control the backlight via i2c when poking this I/F?

If yes, this may be a regression.
Because we are trying to provide a unique backlight sysfs I/F for users. i.e. hiding platform specific functions if the generic ACPI video interface is available.

(In reply to comment #2)
> Created an attachment (id=24394) [details]
> acpidump

From the acpidump attached, it seems that there is not ACPI video extension support on this platform.
can you tell me the model name of your computer please?

it is a samsung nc 10.

booting the same kernel with 'nomodeset' gets brightness to work again.

This doesn't sound like an ACPI problem to me.

(In reply to comment #4)
> (In reply to comment #3)
> > On the driver side, we just need to hook up support for sysfs backlight in the
> > KMS code.
> > The i915 driver probably needs to get new code here to support i2c based
> > backlight control on pre-opregion platforms.
>
> do you mean that register a sysfs backlight class device in KMS code, and
> control the backlight via i2c when poking this I/F?

Yes, in addition to adding backlight resource code to drmmode_display.c in the 2D driver.

> If yes, this may be a regression.
> Because we are trying to provide a unique backlight sysfs I/F for users. i.e.
> hiding platform specific functions if the generic ACPI video interface is
> available.

In many cases it isn't, and we need to use platform specific i2c commands.

(In reply to comment #7)
Hi, Jesse
    In the UMS 2D driver methods are provided to change the backlight.(Kernel, native, legacy, combox). And the default mode is the kernel, which is the ACPI I/F. Of course the backlight mode can be switched in xrandr tool.
    When the kernel backlight mode is used, it is consistent regardless of the backlight is changed by ACPI I/F or xrandr.
    But if the legacy/native backlight mode is used, it is inconsistent between xrandr tool and ACPI I/F. This is very obvious on the opregion platform. For example: When the brightness is changed by using ACPI I/F, the xrandr can report the correct brightness. But if the brightness is changed by using xrandr, the ACPI I/F will report the wrong brightness. This is not what we expected.

    In the KMS driver the native backlight I/F is used. And now it is not exported to the userland. It means that the backlight can't be controlled by the xrandr tool. Of course it is easy to expose the native backlight property to userland(in KMS mode). But after the backlight property is exposed to userland, the inconsistency appears again.
    How about exposing the ACPI backlight I/F to userland in the drmmode_dislay.c when the KMS mode is used? It means that the ACPI backlight I/F is hook up in 2D driver when it exists. Only when there is no ACPI I/F, other backlight control mode is exposed to xrandr. (For example: legacy/combo/native).
> Yes, in addition to adding backlight resource code to drmmode_display.c in the
> 2D driver.

> In many cases it isn't, and we need to use platform specific i2c commands.
   Yes. The platform specific i2c command is useful in most cases. But how about always using the ACPI I/F if there exists the ACPI I/F? What I say is that we don't use the other backlight control mode if there exists the ACPI backlight I/F. Only when there is no ACPI backlight I/F, the other backlight control mode will be exposed to userland.

   Thanks.
  >

(In reply to comment #7)
> > Because we are trying to provide a unique backlight sysfs I/F for users. i.e.
> > hiding platform specific functions if the generic ACPI video interface is
> > available.
>
> In many cases it isn't, and we need to use platform specific i2c commands.
>
exposing all these I/F to userspace at the same time is dangerous.
that's why IGD OpRegion stuff is introduced because we want to control the backlight in ONE way to avoid the conflicts/asynchronization.
For example, if ACPI I/F is available, we should make sure that all the brightness switch are done via the ACPI backlight control methods.

(In reply to comment #8)
> How about exposing the ACPI backlight I/F to userland in the
> drmmode_dislay.c when the KMS mode is used? It means that the ACPI backlight
> I/F is hook up in 2D driver when it exists. Only when there is no ACPI I/F,
> other backlight control mode is exposed to xrandr. (For example:
> legacy/combo/native).
>
poking ACPI in drmmode_display.c doesn't look good.
I'd prefer something like a backlight control manager in the backlight sysfs class device driver.
I.e. all the drivers can register a set of backlight control callbacks to the backlight sysfs class device driver if they know how to change backlight.
and it's the sysfs driver that decides which callbacks to be called.
For example, only these files are exported under /sys/class/backlight:
1. brightness
2. actual_brightness
3. max_brightness
4. mode
...

we support multiple modes in sysfs backlight driver, like
1. generic (the ACPI backlight control offered by ACPI video driver)
2. platform (the platform specific ways offered by the platform driver)
3. legacy (I2C method)
...

users can switch between the control modes, but the generic mode is set by default.

Note that all these comments are against Jesse's "new backlight sysfs class device" idea. For the bug at hand, I think we should make clear why KMS makes the difference...

(In reply to comment #9)
> (In reply to comment #7)
> > > Because we are trying to provide a unique backlight sysfs I/F for users. i.e.
> > > hiding platform specific functions if the generic ACPI video interface is
> > > available.
> >
> > In many cases it isn't, and we need to use platform specific i2c commands.
> >
> exposing all these I/F to userspace at the same time is dangerous.
> that's why IGD OpRegion stuff is introduced because we want to control the
> backlight in ONE way to avoid the conflicts/asynchronization.
> For example, if ACPI I/F is available, we should make sure that all the
> brightness switch are done via the ACPI backlight control methods.

Agreed, we don't want to expose multiple methods (especially native register banging methods) in the KMS case.

> (In reply to comment #8)
> > How about exposing the ACPI backlight I/F to userland in the
> > drmmode_dislay.c when the KMS mode is used? It means that the ACPI backlight
> > I/F is hook up in 2D driver when it exists. Only when there is no ACPI I/F,
> > other backlight control mode is exposed to xrandr. (For example:
> > legacy/combo/native).
> >
> poking ACPI in drmmode_display.c doesn't look good.
> I'd prefer something like a backlight control manager in the backlight sysfs
> class device driver.
> I.e. all the drivers can register a set of backlight control callbacks to the
> backlight sysfs class device driver if they know how to change backlight.
> and it's the sysfs driver that decides which callbacks to be called.
> For example, only these files are exported under /sys/class/backlight:
> 1. brightness
> 2. actual_brightness
> 3. max_brightness
> 4. mode
> ...

I don't think anyone wants to do direct ACPI access from drmmode_display.c; going through /sys/class/backlight is the best approach.

>
> we support multiple modes in sysfs backlight driver, like
> 1. generic (the ACPI backlight control offered by ACPI video driver)
> 2. platform (the platform specific ways offered by the platform driver)
> 3. legacy (I2C method)
> ...
>
> users can switch between the control modes, but the generic mode is set by
> default.
>
> Note that all these comments are against Jesse's "new backlight sysfs class
> device" idea. For the bug at hand, I think we should make clear why KMS makes
> the difference...

No this sounds very similar to what I'm proposing. In we should have either
  /sys/class/backlight/acpi_video0
or
  /sys/class/backlight/platform_foo (e.g. toshiba or sony specific driver)
or
  /sys/class/backlight/i915 (for legacy i2c case)

As Matthew pointed out we'll need to make sure to prefer the ACPI or platform driver (probably in platform, ACPI, i915 order) to interact properly with the firmware.

(In reply to comment #10)

> Agreed, we don't want to expose multiple methods (especially native register
> banging methods) in the KMS case.
Yes. It is reasonable that only one backlight method is exported in KMS mode. The ACPI backlight I/F can be the primiary control method. But which control method can be exposed when there is no ACPI backlight I/F?
If no control method is exposed to xrandr tool, the user will complain that backlight brightness can't be controlled.
> > (In reply to comment #8)
> > > How about exposing the ACPI backlight I/F to userland in the
> > > drmmode_dislay.c when the KMS mode is used? It means that the ACPI backlight
> > > I/F is hook up in 2D driver when it exists. Only when there is no ACPI I/F,
> > > other backlight control mode is exposed to xrandr. (For example:
> > > legacy/combo/native).
> > >
> > ...
> I don't think anyone wants to do direct ACPI access from drmmode_display.c;
> going through /sys/class/backlight is the best approach.
What I said is that the ACPI backlight I/F is hook up in drmmode_display.c. In such case when backlight brightness is changed through xrandr tool, the /sys/class/backlight is used.
In fact in UMS mode when the brightness is changed through xrandr tool, the /sys/class/backlight is hook up in the 2D driver.

> No this sounds very similar to what I'm proposing. In we should have either
> /sys/class/backlight/acpi_video0
> or
> /sys/class/backlight/platform_foo (e.g. toshiba or sony specific driver)
> or
> /sys/class/backlight/i915 (for legacy i2c case)
> As Matthew pointed out we'll need to make sure to prefer the ACPI or platform
> driver (probably in platform, ACPI, i915 order) to interact properly with the
> firmware.
Very good idea.
It seems that a new backlight interface should be registered in i915 driver. Should this also be registered in UMS mode?
Another issue is whether the /sys/class/backlight/ should be hook up by xrandr tool. If it should be hook up, which should be selected when there exists multiple interfaces? For example: acpi_video0, i915

   Thanks.

(In reply to comment #11)
> > I don't think anyone wants to do direct ACPI access from drmmode_display.c;
> > going through /sys/class/backlight is the best approach.
> What I said is that the ACPI backlight I/F is hook up in drmmode_display.c. In
> such case when backlight brightness is changed through xrandr tool, the
> /sys/class/backlight is used.
> In fact in UMS mode when the brightness is changed through xrandr tool, the
> /sys/class/backlight is hook up in the 2D driver.
>
> > No this sounds very similar to what I'm proposing. In we should have either
> > /sys/class/backlight/acpi_video0
> > or
> > /sys/class/backlight/platform_foo (e.g. toshiba or sony specific driver)
> > or
> > /sys/class/backlight/i915 (for legacy i2c case)
> > As Matthew pointed out we'll need to make sure to prefer the ACPI or platform
> > driver (probably in platform, ACPI, i915 order) to interact properly with the
> > firmware.
> Very good idea.
> It seems that a new backlight interface should be registered in i915 driver.
> Should this also be registered in UMS mode?
> Another issue is whether the /sys/class/backlight/ should be hook up by xrandr
> tool. If it should be hook up, which should be selected when there exists
> multiple interfaces? For example: acpi_video0, i915

We may as well register it in the UMS case, as long as there are no conflicts between the way the UMS and kernel drivers are using the i2c interfaces. I think we want to avoid a situation where multiple backlight driver register, so we may need a notifier chain or some kind of mutual exclusion in the backlight code.

*** Bug 21904 has been marked as a duplicate of this bug. ***

Created an attachment (id=26160)
backlight.py

A script to be run via sudo meanwhile.
Thanks for your idea of setpci, didn't think about directly setting the register.
It saves my day for now!

Created an attachment (id=26206)
backlight.py

Just noticed while playing with my script which now sudoes itself and fix the last bug (now fully tested).
If I turn the backlight below 12 (0x0C) then the backlight is off until I use xset dpms force off then on, should this be reported as a problem?

*** Bug 22573 has been marked as a duplicate of this bug. ***

Binary package hint: xorg

hello,
i have two computer, both on karmic (and both with Intel graphic card)
unfortunately there is no way for me to configure the brightness level, nothing is working : brightness keys, xrandr, xbacklight.

i don't know if it is really an xorg bug, xorg an Intel driver bug

of course i also tried to echo some /proc/acpi/video/OVGA/DD0*/brightness devices
but when i do so i receive a permission denied, even as root
a cat on the same element, give me
<not supported>

i read some tutorials speaking about a file in /sys/class/backlight
but on both computer this directory is empty

running xbacklight gave me this output

No outputs have backlight property

alain57 (alain57) wrote :

if you guys need some informations, of course i will give them to you...

if this is not the right place, please tell me (i hesitate between xorg intel bug and kernel intel bug, because there is no way to increase brightness even without Xorg running :( )

alain57 (alain57) wrote :

i just googled a bit and find out that the only solution to increase or decrease the brightness (in fact i need to decrease it, because it is at 100% all the time) was with these commands:

first : find the device address (here 00:02.0)
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)

second :
setpci -s 00:02.0 F4.B=66 (a value between 00 and FF, where FF is 100%)

alain57 (alain57) wrote :

i really think that this is no xorg bug... my apologies

how can i be so sure ?

well the trick with setpci was cool
but when i modified the grub configuration to disable KMS with "nomodeset" guess what ....
all the brightness worked again
fn+ brightness
xbacklight
....

so i'm pretty sure its not an xorg bug :( sorry

i'll search for a know KMS bug, or open one if it does not exist

Bryce Harrington (bryce) wrote :

Let us know what you find

affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
pittipatti (pittipatti) wrote :

I added the upstream bugreport.

This problem only occurs when using KMS.

Bryce Harrington (bryce) on 2009-07-16
summary: - brightness no more working on karmic
+ brightness no more working on karmic (KMS)
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Low
status: Incomplete → Triaged

I have this problem too. I can not change brightness level with Fn keys untill I add acpi_backlight=vendor as a kernel parametar. Then everything works fine.

version info:

kernel: 2.6.31-rc3
mesa: 7.5rc4
xf86-video-intel 2.7.99.902
xorg-server: 1.6.2
Dell Vostro 1310

In reply to comment #17:

I can confirm that "acpi_backlight=vendor" on the kernel command line fixes brightness controt on a Sony Vaio TT

(II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset

Kernel: 2.6.31-rc3
intel driver: 2.7.99.901-2
xorg: 7.4+1

re comment #16 and #17
please attach the acpidump output.
this is an ACPI problem because the ACPI backlight control methods don't work.

Created an attachment (id=27840)
acpidump

please remove acpi_backlight=vender boot option and then:
1. attach the output of "grep . /sys/class/backlight/*/*"
2. attach the output of "cat /sys/class/backlight/acpi_video*/device/path".

does poking these I/F changes the backlight?

[combuster@vostro ~]$ grep . /sys/class/backlight/*/*
/sys/class/backlight/acpi_video0/actual_brightness:7
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:7
/sys/class/backlight/acpi_video0/max_brightness:7
[combuster@vostro ~]$ cat /sys/class/backlight/acpi_video*/device/path
\_SB_.PCI0.GFX0.DD03

Yes, changing /sys/class/backlight/acpi_video0/brightness values change the brightness level

please attach the result of "grep . /proc/acpi/video/GFX0/DD03/*".
please attach the result of "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the hotkey.

Created an attachment (id=27867)
acpi grep output

This is output I get before and after several hotkeypresses (level up/down) without the acpi_brightness=vendor kernel parametar..

Created an attachment (id=27869)
customized DSDT

please apply this customized DSDT and see if it helps.
please also attach the output of "cat /proc/acpi/video/GFX0/*/state".

this seems to be a BIOS problem to me.
several flags in ACPI namespace (DID1, DID2, DID3, DID4, DID5) are all cleared in this DSDT, but AML code sends the ACPI notifications to DD03 device only if DID3 is set. that's why the ACPI video driver doesn't change the backlight when hotkey is pressed.
I don't know how to fix this problem because Linux/ACPI are not aware of these flags.
Maybe changing some BIOS options may change the DID3 flag?

cat /proc/acpi/video/GFX0/*/state
state: 0x1f
query: 0x01
state: 0x1f
query: 0x01
state: 0x0b
query: 0x01
state: 0x1d
query: 0x00
state: 0x1d
query: 0x00

I've applied custom dsdt through regenerating image with mkinitcpio and passing dsdt hook (placed your dsdt.hex as custom.dsdt in /lib/initcpio) but it doesn't help.

dmesg|grep DSDT
[ 0.000000] ACPI: DSDT 000000007f6d7db1 06EB1 (v02 TOSCPL CRESTLNE 06040000 INTL 20060608)
[ 0.104069] ACPI: EC: Look up EC in DSDT

cat everything.log | grep atkbd.c
Jul 21 08:49:17 vostro kernel: [ 3.645375] atkbd.c: Unknown key pressed (translated set 2, code 0x8e on isa0060/serio0).
Jul 21 08:49:17 vostro kernel: [ 3.645379] atkbd.c: Use 'setkeycodes e00e <keycode>' to make it known.

I've noticed this strange message also, but it appears only after a cold boot, upon subsequent restarts it doesn't, could it be related to this bug?

(In reply to comment #27)
> cat /proc/acpi/video/GFX0/*/state

what about cat /proc/acpi/video/GFX0/*/state?

> dmesg|grep DSDT
> [ 0.000000] ACPI: DSDT 000000007f6d7db1 06EB1 (v02 TOSCPL CRESTLNE 06040000
> INTL 20060608)
> [ 0.104069] ACPI: EC: Look up EC in DSDT
>
could you please try to build the custom DSDT into kernel?
you just need to follow the step 5, 6 and 7 in this page
http://www.lesswatts.org/projects/acpi/overridingDSDT.php

[combuster@vostro ~]$ dmesg|grep DSDT
[ 0.000000] ACPI: Override [DSDT-CRESTLNE], this is unsafe: tainting kernel
[ 0.000000] ACPI: DSDT @ 0x000000007f6d7db1 Table override, replaced with:
[ 0.000000] ACPI: DSDT ffffffff8147c8b0 06EA0 (v02 TOSCPL CRESTLNE 06040000 INTL 20081204)
[ 0.095845] ACPI: EC: Look up EC in DSDT
[combuster@vostro ~]$ cat /proc/acpi/video/GFX0/*/state
state: 0x1f
query: 0x01
state: 0x1f
query: 0x01
state: 0x0b
query: 0x01
state: 0x1d
query: 0x00
state: 0x1d
query: 0x00

Replacing DSDT was succesfull but changing brightness with fn keys still doesn't work

Created an attachment (id=27918)
Acpidump of Sony Vaio TT11LN

(In reply to comment #30)
> [combuster@vostro ~]$ dmesg|grep DSDT
> [ 0.000000] ACPI: Override [DSDT-CRESTLNE], this is unsafe: tainting kernel
> [ 0.000000] ACPI: DSDT @ 0x000000007f6d7db1 Table override, replaced with:
> [ 0.000000] ACPI: DSDT ffffffff8147c8b0 06EA0 (v02 TOSCPL CRESTLNE 06040000
> INTL 20081204)
> [ 0.095845] ACPI: EC: Look up EC in DSDT
> [combuster@vostro ~]$ cat /proc/acpi/video/GFX0/*/state

here I mean "cat /proc/acpi/video/GFX0/*/info"

please do the following test,
1. kill acpid
2. cat /proc/acpi/event
3. press the hotkey for several times
attach the output of /proc/acpi/event file.

cat /proc/acpi/video/GFX0/*/info
device_id: 0x0001
type: UNKNOWN
known by bios: no
device_id: 0x0002
type: UNKNOWN
known by bios: no
device_id: 0x0003
type: UNKNOWN
known by bios: no
device_id: 0x0004
type: UNKNOWN
known by bios: no
device_id: 0x0005
type: UNKNOWN
known by bios: no

cat /proc/acpi/event doesn't show any output when I'm pressing the hotkeys

I've just tried with 2.6.30.1 also (wich doesn't have a custom dsdt) and the situation is the same, same output from cat /proc/acpi/video/GFX0/*/info
and no output from cat /proc/acpi/event, just to see if it will show any output I've pulled the power cord from the laptop and put it back in and it shows
ac_adapter ACAD 00000080 00000000
battery BAT1 00000080 00000001
ac_adapter ACAD 00000080 00000001
battery BAT1 00000080 00000001

but it doesn't react when I press Fn+Up/Down...

Created an attachment (id=27937)
customized DSDT

please
1. use 2.6.30 kernel
2. applied this customized DSDT
3. set CONFIG_ACPI_DEBUG
4. set CONFIG_DRM_I915_KMS
5. rebuild and boot with acpi.debug_level=0x07 acpi.debug_layer=0xffffffff
does the problem still exist?
please attach the dmesg output after pressing the hotkey for several times.

Created an attachment (id=27941)
dmesg log

Yes, the problem persists, but I've noticed this lines in dmesg after I press the hotkey for brightness:

[ 258.751742] exregion-0290 [72] ex_system_io_space_han: System-IO (width 32) R/W 1 Address=0000000000000080
[ 258.751803] exregion-0187 [71] ex_system_memory_space: System-Memory (width 8) R/W 0 Address=000000007F6E1E78
[ 258.751877] exregion-0187 [71] ex_system_memory_space: System-Memory (width 8) R/W 0 Address=000000007F6E1E83
...

Here is complete dmesg output...

FWIW on my samsung NC10 acpi_backlight=vendor does not help. I still need to work with the setpci line. This is on kernel 2.6.31-rc4 and xorg-intel 2.8.0. Well and things work as soon as I put nomodeset=1 on the kernel cmdline.

Created an attachment (id=28019)
customized DSDT with more debug info

[ 1.818118] video-1872 [07] video_device_enumerate: dod element[0] = 65536
[ 1.818545] video-1872 [07] video_device_enumerate: dod element[1] = 65536
[ 1.818961] video-1872 [07] video_device_enumerate: dod element[2] = 65536
this is weird.

please try this new custom dsdt and do the same test.
I think we could root cause the problem this time. :)

Created an attachment (id=28027)
dmesg log

I sure hope so :)

Created an attachment (id=28028)
costom DSDT

new custom DSDT that should workaround this bug.
Ivan,
please try this DSDT and see if the hotkey works for you. :)
don't forget to attach the dmesg output if it doesn't work.

Created an attachment (id=28029)
dmesg log

Well it still doesn't help, brightness levels won't change but this time I see somewhat more output from dmesg like:

[ 82.536612] exregion-0187 [4294967280] ex_system_memory_space: System-Memory (width 8) R/W 0 Address=000000007F6E1E8A
[ 82.536671] evmisc-0125 [4294967272] ev_queue_notify_reques: Dispatching Notify on [DD02] Node ffff88007f011ae0 Value 0x86 (**Device Specific**)
[ 82.536695] ACPI: Failed to switch the brightness

The last two weren't appearing untill now, I think you are getting very close...

Created an attachment (id=28030)
dmesg for attachment id=28019 on samsung nc10

on my samsung nc 10 trying with this customized DSDT (http://bugs.freedesktop.org/attachment.cgi?id=28019)

# cat /proc/acpi/video/GFX0/*/info
device_id: 0x0001
type: UNKNOWN
known by bios: no
device_id: 0x0002
type: UNKNOWN
known by bios: no
device_id: 0x0003
type: UNKNOWN
known by bios: no
device_id: 0x0004
type: UNKNOWN
known by bios: no
device_id: 0x0005
type: UNKNOWN
known by bios: no

Note that w/o this DSDT all but the last were known.

Created an attachment (id=28032)
custom DSDT.

Ivan,
IMO, there are two BIOS bugs that causes this problem.

1.
Method (SDDL, 1, NotSerialized)
{
                    ...
                    Store (And (Arg0, 0x0F0F), Local0)
                    Or (0x80000000, Local0, Local1)
                    If (LEqual (DIDL, Local1))
                    {
                        Return (Local1)
                    }
                    ...
                    Return (Zero)
}
bit 31 of the values in IGD DIDL field is set by i915 driver, which follows the ACPI and IGD OpRegion spec. But BIOS only returns a meaningful value when it's cleared.

2.
The backlight control methods are hard coded, i.e. DDO3._BCM, DD03._BCL.
But BIOS uses BRTN method to decide which ACPI video device the notification should be sent to when hotkey is pressed.
Method (BRTN, 1, Serialized)
{
                    If (LEqual (And (DID1, 0x0F00), 0x0400))
                    {
                        Notify (DD01, Arg0)
                    }

                    If (LEqual (And (DID2, 0x0F00), 0x0400))
                    {
                        Notify (DD02, Arg0)
                    }

                    If (LEqual (And (DID3, 0x0F00), 0x0400))
                    {
                        Notify (DD03, Arg0)
                    }
                    ...
}
This is not smart at all.
BIOS knows which ACPI device is LCD, then it should send the notification to DD03 directly.
Plus, the DID1/DID2/DID3 are set by i915 driver, who doesn't know which ACPI video device is LCD.

The custom DSDT I attached should work for you.
But I'm afraid we can not fix it in Linux kernel.

Created an attachment (id=28034)
dmesg log

It doesn't work but it doesn't matter, adding acpi_brightness=vendor kernel parameter works for me but not for all laptop models so some people may have to try to find another workaround for this problem.

Thank you Rui for all your effort on solving this bug, many video driver bugs were bugging me for months but now all of them are fixed and this bug which is the only one left is no showstopper, performance and stability are great with 2.6.31 kernel.

Greetings from Serbia.

Created an attachment (id=28242)
dmesg from samsung nc 10 with verbose acpi_debug level

So is there any output or anything that you would need to do anything about this bug? So far there is zero *visible* progress since my report back in march.

This is not just intel video driver bug, many users with ati cards have this bug also, I think this is ACPI related bug and right now I don't think that intel dev's can do anything about it. Maybie we should reasign this bug to kernel and ACPI...

In fact after a lot of google-ing and reading lkml threads i'm not even sure if the problem lies in wmi modules, acpi, hal or something else, I even stumbled upon Rui's comments back in April and issuing a patch for 2.6.30-rc1 and thinkpad backlight controls, some people even got their brightness keys afterwords when they suspend and resume...

(In reply to comment #46)
> This is not just intel video driver bug,

right,

> many users with ati cards have this
> bug also, I think this is ACPI related bug and right now I don't think that
> intel dev's can do anything about it.

right, at least it's an ACPI BIOS bug. :)

> Maybie we should reasign this bug to
> kernel and ACPI...
>
sure.
please attach your dmidecode output.
IMO, the only way to fix it in kernel is to disable ACPI video backlight control via dmi check. :(
please reference the ATI card bug reports there as well. I want to verify if they are the same bug.

(In reply to comment #45)
> So is there any output or anything that you would need to do anything about
> this bug? So far there is zero *visible* progress since my report back in
> march.
>
There is no ACPI backlight control on this laptop, so that I can not help you.

Yakui,
can you look at this issue please?

Created an attachment (id=28282)
dmidecode log

Here is the link from archlinux forums, a user named stefek own Dell Studio with ATI graphics card and the backlight problem was solved by acpi_backlight=vendor kernel paramater.

http://bbs.archlinux.org/viewtopic.php?pid=593486#p593486

Here is someone with problem on Fedora 11 with Macbook Pro 4.1

https://bugzilla.redhat.com/show_bug.cgi?id=473588

>
> Here is the link from archlinux forums, a user named stefek own Dell Studio
> with ATI graphics card and the backlight problem was solved by
> acpi_backlight=vendor kernel paramater.
>
> http://bbs.archlinux.org/viewtopic.php?pid=593486#p593486
>
> Here is someone with problem on Fedora 11 with Macbook Pro 4.1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=473588
>
not sure if they are the same unless I have seen the acpidump output.
But if "acpi_backlight=vendor" works for them, then this is a Linux/acpi bug that should be reported in kernel bugzilla. :)

Scrath that one out with MBP, it's keyboard backlight, I was trying to search
for a bug that I found yesterday regarding a fix in Fedora 11 to the backlight
keys issue but I'm not sure if they temporarily disabled KMS or what, I can't
seem to find that bug report now :(

Will you report it please, I'm sure you will explain the situation better :)

Sorry for asking, but I have added myself to CC to follow the progress of fixing intel driver with KMS that does not handle backlight as it was before KMS. I did not report any debug because I have the same samsung nc10 as the original reporter. Somehow this bug has passed to ATI, keycodes etc.

Is this still a relevant issue:

  ------- Comment #3 From Jesse Barnes 2009-03-31 08:11:00 PST [reply] -------
On the driver side, we just need to hook up support for sysfs backlight in the
KMS code. We don't want to do any direct register access though... If
platforms are missing backlight support we should add new sysfs backlight
support for them in the kernel. The i915 driver probably needs to get new code
here to support i2c based backlight control on pre-opregion platforms. The VBT
has info about where the backlight controller is and what commands to issue.

thank you

Hallo everybody, I can confirm this bug on Sony Vaio Z21XN (Intel GME45 chipset) when KMS enabled. It is present in 2.6.29, 2.6.30 and 2.6.31-rc kernel lines that i've tried. When KMS is disabled, backlight control works correctly.

acpi_backlight=vendor kernel option solves this problem for me.

On my second Vaio SZ1XP (Intel 945 chipset) backlight control works OK with or without KMS on 2.6.31-rc5 kernel.

Greetings from Slovakia

(In reply to comment #54)
> Hallo everybody, I can confirm this bug on Sony Vaio Z21XN (Intel GME45
> chipset) when KMS enabled. It is present in 2.6.29, 2.6.30 and 2.6.31-rc kernel
> lines that i've tried. When KMS is disabled, backlight control works correctly.
>
please attach the acpidump output of your laptop.

Created an attachment (id=28332)
vaio_sz1xp.dump

here is acpidump from older machine (sz1xp) that works fine OOB. Bios is little bit modified to enable Intel VMX :)

Newer vaio is at home, I'll attach that dump this evening.

I forgot to mention that distro is Ubuntu 9.04 with custom kernel.

Milan

(In reply to comment #57)
> here is acpidump from older machine (sz1xp) that works fine OOB. Bios is little
> bit modified to enable Intel VMX :)
>
there is no ACPI backlight control methods on this laptop.
so I don't think "acpi_backlight=vendor" will bring any difference on this laptop.

You may by right. On this one backlight control works fine with KMS (or without KMS) and without any additional settings, only i915.modeset=1 on kernel boot line.

Milan

Created an attachment (id=28345)
vaio_z21xn.dump

Here is acpidump from vaio z21xn.

I have the same problem on a Samsung Q45 notebook.

Without KMS I can set brightness using xbacklight.
With KMS enabled and using xbacklight I get the "No outputs have backlight property" error and I can only set brightness using the setpci method.

/sys/class/backlight is completely empty on this machine.

I'll attach the acpidump and the contents of the sys and proc files mentioned earlier.

Created an attachment (id=28357)
samsung-q45_acpidump

Created an attachment (id=28358)
samsung-q45 output of proc and sysfs

i'm a nc10 user too

currently i disable KMS, because changing brigthness with setpci -s 00:02.0 is as fast as brightness keys

if you need some output result, i can help too ;)

Russell Green (r.green) wrote :

This is also present with me on Karmic with my AA1.

Bryce, since I cant add logs automatically through ubuntu-bug without creating a new report, if you give me a list of files that would be helpful I would me more than willing to collect and upload them. :)

Timo Aaltonen (tjaalton) wrote :

you can use 'apport-collect 397617'

I'm a Samsung NP Q45 user, I can provide some output too.
Using "setpci -s 00:02.0 f4.b=<value>" (value from 00 to ff) works well for now when KMS is enabled.

Bryce Harrington (bryce) on 2009-08-13
tags: added: karmic

(In reply to comment #66)
> I'm a Samsung NP Q45 user, I can provide some output too.
> Using "setpci -s 00:02.0 f4.b=<value>" (value from 00 to ff) works well for
> now when KMS is enabled.
>

I now have a kernel driver that works on my Samsung N130 device, and it should also work for your device as well.

But I need the DMI data from your machine (or anyone else's whose machines can be controlled by reading/writing this specific pci value). Can you provide the output of:
  grep . /sys/devices/virtual/dmi/id/*

/sys/devices/virtual/dmi/id/bios_date:12/11/2008
/sys/devices/virtual/dmi/id/bios_vendor:Phoenix Technologies Ltd.
/sys/devices/virtual/dmi/id/bios_version:04CA.MP00.20081211.KTW
/sys/devices/virtual/dmi/id/board_name:NC10
/sys/devices/virtual/dmi/id/board_serial:
/sys/devices/virtual/dmi/id/board_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/board_version:Not Applicable
/sys/devices/virtual/dmi/id/chassis_asset_tag:No Asset Tag
/sys/devices/virtual/dmi/id/chassis_serial:None
/sys/devices/virtual/dmi/id/chassis_type:10
/sys/devices/virtual/dmi/id/chassis_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/chassis_version:N/A
/sys/devices/virtual/dmi/id/modalias:dmi:bvnPhoenixTechnologiesLtd.:bvr04CA.MP00.20081211.KTW:bd12/11/2008:svnSAMSUNGELECTRONICSCO.,LTD.:pnNC10:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNC10:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A:
/sys/devices/virtual/dmi/id/product_name:NC10
/sys/devices/virtual/dmi/id/product_serial:FP5993AS202421
/sys/devices/virtual/dmi/id/product_uuid:60B6C327-D21D-B211-8000-EE21157EC1D2
/sys/devices/virtual/dmi/id/product_version:Not Applicable
/sys/devices/virtual/dmi/id/sys_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLtd.:bvr04CA.MP00.20081211.KTW:bd12/11/2008:svnSAMSUNGELECTRONICSCO.,LTD.:pnNC10:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNC10:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A:

(In reply to comment #69)
> /sys/devices/virtual/dmi/id/bios_date:12/11/2008

<snip>

Thanks, I've added support for your laptop in the driver now.

A stand-alone version of the driver, that can be built on its own,
can be found at:
 http://github.com/gregkh/samsung-backlight/tree/master

Here is the output for Samsung NP-Q45 :

/sys/devices/virtual/dmi/id/bios_date:05/17/2008
/sys/devices/virtual/dmi/id/bios_vendor:Phoenix Technologies LTD
/sys/devices/virtual/dmi/id/bios_version:15ST
/sys/devices/virtual/dmi/id/board_name:SQ45S70S
/sys/devices/virtual/dmi/id/board_serial:123490EN400015
/sys/devices/virtual/dmi/id/board_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/board_version:
/sys/devices/virtual/dmi/id/chassis_asset_tag:No Asset Tag
/sys/devices/virtual/dmi/id/chassis_serial:None
/sys/devices/virtual/dmi/id/chassis_type:10
/sys/devices/virtual/dmi/id/chassis_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/chassis_version:N/A
/sys/devices/virtual/dmi/id/modalias:dmi:bvnPhoenixTechnologiesLTD:bvr15ST:bd05/17/2008:svnSAMSUNGELECTRONICSCO.,LTD.:pnSQ45S70S:pvr15ST:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSQ45S70S:rvr:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A:
/sys/devices/virtual/dmi/id/product_name:SQ45S70S
/sys/devices/virtual/dmi/id/product_serial:EJ2293JQ800549
/sys/devices/virtual/dmi/id/product_uuid:00E68829-D21D-B211-8000-8D7E038DE16E
/sys/devices/virtual/dmi/id/product_version:15ST
/sys/devices/virtual/dmi/id/sys_vendor:SAMSUNG ELECTRONICS CO., LTD.
/sys/devices/virtual/dmi/id/uevent:MODALIAS=dmi:bvnPhoenixTechnologiesLTD:bvr15ST:bd05/17/2008:svnSAMSUNGELECTRONICSCO.,LTD.:pnSQ45S70S:pvr15ST:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSQ45S70S:rvr:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A:

Great job Greg and thanks a billion!

[root@sammy gregkh-samsung-backlight-9045774edddaf373f5d3359911bc01692a0ca96a]# uname -a
Linux sammy 2.6.29-ARCH #1 SMP PREEMPT Wed May 20 07:06:02 UTC 2009 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
[root@sammy gregkh-samsung-backlight-9045774edddaf373f5d3359911bc01692a0ca96a]# dmidecode | grep -i product
        Product Name: NC10
        Product Name: NC10
[root@sammy gregkh-samsung-backlight-9045774edddaf373f5d3359911bc01692a0ca96a]# cat /sys/class/backlight/samsung/brightness
26

like a charm!

(In reply to comment #71)
> Here is the output for Samsung NP-Q45 :

Thanks, I've added this to the driver now.

(In reply to comment #72)
> Great job Greg and thanks a billion!

Glad it's working for you, thanks for testing and letting me know.

(In reply to comment #73)
> (In reply to comment #71)
> > Here is the output for Samsung NP-Q45 :
>
> Thanks, I've added this to the driver now.
>

When I tried to "insmod samsung-backlight.ko" I got this error message :
insmod: error inserting 'samsung-backlight.ko': -1 No such device

dmesg output :
[11237.758864] samsung_backlight: found laptop model 'NP-Q45'

Did I missed something ?

(In reply to comment #75)
> (In reply to comment #73)
> > (In reply to comment #71)
> > > Here is the output for Samsung NP-Q45 :
> >
> > Thanks, I've added this to the driver now.
> >
>
> When I tried to "insmod samsung-backlight.ko" I got this error message :
> insmod: error inserting 'samsung-backlight.ko': -1 No such device
>
> dmesg output :
> [11237.758864] samsung_backlight: found laptop model 'NP-Q45'
>
> Did I missed something ?
>

Hm, what is the pci id of the video device that you need to control? Odds are, that's the problem here.

Can you provide the output of 'lspci' and 'lspci -n'?

Download full text (3.4 KiB)

(In reply to comment #76)
> Hm, what is the pci id of the video device that you need to control? Odds are,
> that's the problem here.
>
> Can you provide the output of 'lspci' and 'lspci -n'?
>
The pci id should be 00:02.0 (that's the id I use with setpci).

 ~ # lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 04)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 04)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 04)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f4)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 04)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 04)
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8039 PCI-E Fast Ethernet Controller (rev 15)
04:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)
04:09.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09)
04:09.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)
04:09.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller
04:09.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 09)
04:09.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 04)
 ~ # lspci -n
00:00.0 0600: 8086:2a00 (rev 03)
00:02.0 0300: 8086:2a02 (rev 03)
00:02.1 0380: 8086:2a03 (rev 03)
00:1a.0 0c03: 8086:2834 (rev 04)
00:1a.1 0c03: 8086:2835 (rev 04)
00:1a.7 0c03: 8086:283a (rev 04)
00:1b.0 0403: 8086:284b (rev 04)
00:1c.0 0604: 8086:283f (rev 04)
00:1c.1 0604: 8086:2841 (rev 04)
00:1d.0 0c03: 8086:2830 (rev 04)
00:1d.1 0c03: 8086:2831 (rev 04)
00:1d.2 0c03: 8086:2832 (rev 04)
00:1d.7 0c03: 8086:2836 (rev 04)
00:1e.0 0604: 8086:2448 (rev f4)
00:1f.0 0601: 8086:2815 (rev 04)
00:1f.2 0101: 8086:282...

Read more...

(In reply to comment #77)
> (In reply to comment #76)
> > Hm, what is the pci id of the video device that you need to control? Odds are,
> > that's the problem here.

> 00:02.0 0300: 8086:2a02 (rev 03)

Yes, the driver is looking for a different pci id. I'll work on it to add support for this device. The offset is still the same, right? 0xf4, right?

(In reply to comment #78)
> (In reply to comment #77)
> > (In reply to comment #76)
> > > Hm, what is the pci id of the video device that you need to control? Odds are,
> > > that's the problem here.
>
> > 00:02.0 0300: 8086:2a02 (rev 03)
>
> Yes, the driver is looking for a different pci id. I'll work on it to add
> support for this device. The offset is still the same, right? 0xf4, right?
>

I use setpci like this : setpci -s 00:02.0 f4.b=<value>
Did this answer your question ?

(In reply to comment #79)
> (In reply to comment #78)
> > (In reply to comment #77)
> > > (In reply to comment #76)
> > > > Hm, what is the pci id of the video device that you need to control? Odds are,
> > > > that's the problem here.
> >
> > > 00:02.0 0300: 8086:2a02 (rev 03)
> >
> > Yes, the driver is looking for a different pci id. I'll work on it to add
> > support for this device. The offset is still the same, right? 0xf4, right?
> >
>
> I use setpci like this : setpci -s 00:02.0 f4.b=<value>
> Did this answer your question ?
>

Yes it does, thanks. I've checked in, and emailed you, an updated version
of the driver that should fix this issue. Please let me know how it works.

(In reply to comment #80)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > (In reply to comment #77)
> > > > (In reply to comment #76)
> > > > > Hm, what is the pci id of the video device that you need to control? Odds are,
> > > > > that's the problem here.
> > >
> > > > 00:02.0 0300: 8086:2a02 (rev 03)
> > >
> > > Yes, the driver is looking for a different pci id. I'll work on it to add
> > > support for this device. The offset is still the same, right? 0xf4, right?
> > >
> >
> > I use setpci like this : setpci -s 00:02.0 f4.b=<value>
> > Did this answer your question ?
> >
>
> Yes it does, thanks. I've checked in, and emailed you, an updated version
> of the driver that should fix this issue. Please let me know how it works.
>
Hi, Greg
    Where can I find the patch you have checked in? In your git branch?
   Thanks.

Geir Ove Myhr (gomyhr) on 2009-08-16
tags: added: backlight

The method this driver is using is no way Samsung specific, it's just the old legacy method. This is applicable to *all* intel chips (i830 and up). However, the driver should also program the native method (also i830 and up). See i830_lvds.c from xf86-video-intel.

So the driver shouldn't actually be selective to subvendor ids. It's actually up to the X driver which of the backlight interfaces to use (ACPI preferred).

(In reply to comment #81)
> Where can I find the patch you have checked in? In your git branch?

Look in comment #70

(In reply to comment #82)
> The method this driver is using is no way Samsung specific, it's just the old
> legacy method. This is applicable to *all* intel chips (i830 and up). However,
> the driver should also program the native method (also i830 and up). See
> i830_lvds.c from xf86-video-intel.
>
> So the driver shouldn't actually be selective to subvendor ids. It's actually
> up to the X driver which of the backlight interfaces to use (ACPI preferred).
>

But this is the only way to control the Samsung laptops, as they do not provide
any other interface (like the "correct" ACPI one.)

If it also works on other machines, that's great, I'll take that as a case-by-case basis.

intel driver now supports BACKLIGHT property in KMS case. So xbacklight will work in KMS case as well now.

(In reply to comment #85)
> intel driver now supports BACKLIGHT property in KMS case. So xbacklight will
> work in KMS case as well now.

Hrm, really? As of what versions of the kernel and xf86-video-intel?

(In reply to comment #86)
> (In reply to comment #85)
> > intel driver now supports BACKLIGHT property in KMS case. So xbacklight will
> > work in KMS case as well now.
>
> Hrm, really? As of what versions of the kernel and xf86-video-intel?

To answer my own question:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a50916530426a662f5ed262892080b860a445da3

and a few subsequent commits.

Ok, so it turns out that the Samsung N130 and N120 need to do something else
to "properly" set and get the brightness values.

The git tree for the driver as listed above in my github.com repo, in the "laptop" branch has the initial work on this.

tags: added: regression-potential

The following commit already exists in the latest intel graphics driver.
commit a50916530426a662f5ed262892080b860a445da3
Author: Matthias Hopf <email address hidden>
Date: Mon Aug 17 15:53:15 2009 +0200

    Add BACKLIGHT property support in KMS case.

After this commit is shipped, the backlight can be adjusted by using xrandr tool if there exists the generic ACPI backlight interface under /sys/class/backlight/.

So this bug will be marked as resolved.

If there is no backlight interface under /sys/class/backlight/, please file a new bug.

thanks.

Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
trendzetter (trendzetter) wrote :

I have an aspire timeline with intel grafics running the latest daily build karmic.
I am unable to control brightness except for the method explained in comment #2 (setpci -s 00:02.0 F4.B=66)
When running xrandr --prop it does not have support for backlight control:
# xrandr --prop
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 345mm x 194mm
 EDID_DATA:
  00ffffffffffff0030e4020200000000
  00130103802313780a28659759548e27
  1e505400000001010101010101010101
  010101010101561d56c6500020303020
  350059c2100000190000000000000000
  00000000000000000000000000fe004c
  4720446973706c61790a2020000000fc
  004c503135365748332d544c41310039
 scaling mode: Fullscreen
  supported: Non-GPU Fullscreen No scale Aspect
   1366x768 60.0*+
   1360x768 59.8
   1024x768 60.0
   800x600 60.3
   640x480 59.9
DVI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

$ xbacklight -time 0 -set 20
No outputs have backlight property

nicky.7 (nickkkk7) wrote :

I have the same problem with intel graphic.
For me does not work eather the "setpci" method, nor the nomodeset one (it has no effects).

Architecture: i386
DistroRelease: Ubuntu 9.10
MachineType: Apple Computer, Inc. MacBook1,1
Package: xserver-xorg-video-intel 2:2.8.1-1ubuntu1
PackageArchitecture: i386
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=a356af08-5642-43a0-a744-1ac5ec073c50 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-10.32-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu3
 libdrm2 2.4.13-1ubuntu1
 xserver-xorg-video-intel 2:2.8.1-1ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090825.fc74e119-0ubuntu1
Uname: Linux 2.6.31-10-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 10/12/06
dmi.bios.vendor: Apple Computer, Inc.
dmi.bios.version: MB11.88Z.0061.B03.0610121324
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Mac-F4208CC8
dmi.board.vendor: Apple Computer, Inc.
dmi.board.version: PVT
dmi.chassis.asset.tag: Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Computer, Inc.
dmi.chassis.version: Mac-F4208CC8
dmi.modalias: dmi:bvnAppleComputer,Inc.:bvrMB11.88Z.0061.B03.0610121324:bd10/12/06:svnAppleComputer,Inc.:pnMacBook1,1:pvr1.0:rvnAppleComputer,Inc.:rnMac-F4208CC8:rvrPVT:cvnAppleComputer,Inc.:ct10:cvrMac-F4208CC8:
dmi.product.name: MacBook1,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Computer, Inc.
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.31-10-generic

tags: added: apport-collected
Benoit Garret (benoit.garret) wrote :

I have the same problem with a first generation Macbook. Disabling KMS makes brightness work again.

Changing the brightness with ACPI doesn't work, the /sys/class/backlight directory is empty.

Benoit Garret (benoit.garret) wrote :

And I'm really sorry for the flood, I thought apport-collect would bundle the data in one post...

trendzetter (trendzetter) wrote :

I'm not sure if I really use KMS but I added an option to the kernelboot in order to disable it:
Sep 13 19:41:55 ubuntu kernel: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=d9aeca27-f2de-4b4b-ac98-9ff714300820 ro quiet splash libata.force=noncq nomodeset

Still unable to dim the display. When using the hotkeys on my laptop I get a notificationwindow showing the dimming of the backlight but it does not actually happen.

nicky.7 (nickkkk7) wrote :

The bug is not the same for me as the one assigned to. I have no interface in /sys/class/backlight.

nicky.7 (nickkkk7) wrote :

After the last upgrade.. Now is there! Thanks!

Thomas Markus (thomas-markus) wrote :

I have the brightness issues on Karmic with kms as well with a Samsung x360 laptop.

/sys/class/backlight/... is populated and looks okay, but there is no visible change in brightness when altering the values. Booting the kernel with 'nomodeset' makes brightness work again.

xbacklight says "No outputs have backlight property"

Przemek K. (azrael) wrote :

This bug is fixed upstream. Will this new intel driver xf86-video-intel 2.9.0 be used in Karmic?

Bryce Harrington (bryce) on 2009-10-08
Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.9.0-1ubuntu1

---------------
xserver-xorg-video-intel (2:2.9.0-1ubuntu1) karmic; urgency=low

  [Tormod Volden]
  * Merge with Debian. Remaining Ubuntu changes:
    + debian/control: Add lpia architecture
  * Drop patches now included upstream:
    + 100_8xx_perf_pict_a8.patch
    + 101_reload_cursors.patch
    + 102_dont_destroy_bufmgr_at_closescreen_time.patch
  * Ubuntu bugs fixed in this release:
    + Calculate the DVO relative offset in LVDS data entry to get the DVO
      timing. Fixes black screen at boot on i855 due to not finding LVDS
      modes.
      (LP: #410455)
    + Fix brightness by enabling BACKLIGHT property for KMS.
      (LP: #397617)

 -- Bryce Harrington <email address hidden> Wed, 07 Oct 2009 20:09:54 -0700

Changed in xserver-xorg-video-intel (Ubuntu):
status: In Progress → Fix Released
Mathieu Marquer (slasher-fun) wrote :

Bug still occurs at least with Samsung NC10. There is also a patch to include in the kernel to have this bug fixed, see bug 409889 (and particularly comment #5 about the fix)

Thomas Markus (thomas-markus) wrote :

The new xserver-xorg-video-intel - 2:2.9.0-1ubuntu1 does make xbacklight _report_ the display brightness, but there is no way to actually change it using xbacklight/gnome-brightness-applet. This problem occurs a samsung x360 laptop.

Mathieu Marquer (slasher-fun) wrote :

xbacklight still reports "No outputs have backlight property" on a Samsung NC10.

trendzetter (trendzetter) wrote :

The bug is not resolved. Please reopen.

Mathieu Marquer (slasher-fun) wrote :

Reopening since several users still report this bug as unresolved. Please see my comment 38, there is a patch for fixing the kernel side of the bug.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Fix Released → Confirmed
tags: added: xorg-needs-kernel-fix
Thiago Martins (martinx) wrote :

Guys,

 The screen of my Macbook Air 1,1 is totally black, I mean, the brightness is 0% by default and I can't adjust it with the F1/F2 keys.

 The Karmic that I'm using was upgraded right now.

 The boot option "nomodeset" solves the problem but now, the boot process have a lot of flickers...

 Nevertheless, the Desktop Effects is still working!

Thanks!
Thiago

Thiago Martins (martinx) wrote :

Guys!

 The F1/F2 is working with "nomodeset" option enabled in GRUB's menu!

Cheers!
Thiago

There seem to be a number of people, including Macbook users, reporting that their backlight is non-functional in Karmic. This bug seems the most relevant and most comments seemed to point to this one as well.

I'm using a Macbook 2,1 and don't have a usable backlight, leaving me stuck at max brightness (AAAH, my poor eyes!). The backlight existed and worked with Hardy, Intrepid, and Jaunty (with a couple issues that aren't relevant here).

$ xbacklight
No outputs have backlight property
 $ ls -a /sys/class/backlight/
. ..
$

This occurs when using kernel linux-image-2.6.31-14-generic (current Karmic default) or linux-image-2.6.32-020632rc5-generic (most recent from the kernel ppa)

Also tried xserver-xorg-video-intel 2:2.9.0-1ubuntu2 (current Karmic default) and 2:2.9.0+git20091019.751e0a3e-0ubuntu0tormod2 (from xorg-edgers ppa).

Using 'nomodeset' when booting either kernel drops me into a terminal login that flickers unendingly.

It's been mentioned a couple times this was fixed through a kernel patch but I'm unsure if it's made it into linux-image-2.6.32-020632rc5-generic. Is there anything else I can do to try and help pin down this bug?

Philip Lowman (philip-yhbt) wrote :

Could someone @canonical add a word of caution to the release notes? If policy doesn't allow fixing these types of "minor" glitches before release at least a word of warning would be nice before a bunch of users upgrade and experience regressions.

trtl (pdersjant) wrote :

I have a NC10, BIOS 11CA, and cannot reproduce this problem. Out-of-the-box clean install of beta2, then updated. Brightness keys just work.
If I can provide any information to further identify the bug, let me know.

Philip, also, please do take a look at comment #3 (..disable KMS with "nomodeset"..) and see whether the fix described there works for you. It did help in the case of my Samsung Q45.

Mathieu Marquer (slasher-fun) wrote :

"According to Google", it seems that BIOS 11CA fixes the issue on the Samsung NC10. I'll try it today and give you some feedback. For now, I have the issue with BIOS 07CA.

Cedric F. (c-fachinetti) wrote :

Ok but,

Why this bug appears with Karmic with NC10? Brightness works well on the jaunty...
And I have 06CA

Mathieu Marquer (slasher-fun) wrote :

OK, confirming that BIOS 11CA fixes the bug on Samsung NC10, I can now set the brightness with KMS enabled.
@Cedric F. : because Karmic implements KMS.

trendzetter (trendzetter) wrote :

I just noticed Acer made available a bios-update on 2009/10/09 that fixes the issue of controlling the backlight when using KMS on the timeline 5810T. Download bios version 2.30 and install using freedos on a usbstick.

Przemek K. (azrael) wrote :

I can confirm too that setting brightness doesn't work on Macbook 2,1, using Karmic ISO from 2009-10-22.
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Philip Lowman (philip-yhbt) wrote :

@Muharem and others

I didn't notice the comment about the bios update because I have been following a duplicate bugreport where it wasn't mentioned and only just recently switched to this one. Probably should have read all the comments in this report before posting here, sorry about that.

I'll give the bios update a shot later today. It sounds promising based on what others have said.

Philip Lowman (philip-yhbt) wrote :

I can confirm that the brightness up/down keys now work after updating to BIOS revision 11CA

Eric (etmeek) wrote :

Setting LCD brightness doesn't work on a MacBook Pro 1,1 using the latest Karmic (updated this morning). XOrg recognizes the keys however xbacklight reports "No outputs have backlight property" and /sys/class/backlight/ is empty. Only way currently to control the backlight for me is to install pommed.

sudo /lib/udev/keymap -i input/event5 does recognize the keys correctly.

spaetz (spaetz) wrote :

Issue also still occuring on a MacBook 4,1
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

uxinity (uxinity) wrote :

Brightness keys (Fn + arrow up/down) are still NOT working on my Samsung NC10 despite latest daily updates from Update Manager and using latest Samsung BIOS version 04CA / MICOM version 11CA.

(Brightness keys work while in BIOS (F2 key while power on), but you do not want to reboot the computer to adjust display brightness.)

Using the nomodeset parameter in GRUB forces the brightness keys to work (didn’t work some weeks ago when I tried that for the first time). But I really liked Kernel-based mode setting, so it would be slightly disappointing to use nomodeset to turn it off. Of course, non-functional brightness settings are a bigger hassle than screen flickering, so I am forced to nomodeset.

As others are reporting brightness keys working on NC10: Could the LPIA instead of i386 be the problem for me? (kernel 2.6.31-14-lpia)

Not sure if this explains why it's not working, but after updating the BIOS
on my NC10 I had both a NICOM and BIOS version of 11CA.

On Oct 25, 2009 11:01 AM, "uxinity" <email address hidden> wrote:

Brightness keys (Fn + arrow up/down) are still NOT working on my Samsung
NC10 despite latest daily updates from Update Manager and using latest
Samsung BIOS version 04CA / MICOM version 11CA.

(Brightness keys work while in BIOS (F2 key while power on), but you do
not want to reboot the computer to adjust display brightness.)

Using the nomodeset parameter in GRUB forces the brightness keys to work
(didn’t work some weeks ago when I tried that for the first time). But I
really liked Kernel-based mode setting, so it would be slightly
disappointing to use nomodeset to turn it off. Of course, non-functional
brightness settings are a bigger hassle than screen flickering, so I am
forced to nomodeset.

As others are reporting brightness keys working on NC10: Could the LPIA
instead of i386 be the problem for me? (kernel 2.6.31-14-lpia)

-- brightness no more working on karmic (KMS)
https://bugs.launchpad.net/bugs/397617 You received ...

uxinity (uxinity) wrote :

Philip, thanks for your information. I flashed the Samsung NC10 BIOS again and now both, BIOS and MICOM, show version 11CA. The brightness keys work in Kernel-based mode setting (i.e. no nodemodeset). Thanks!

bigjimlefou (bigjimlefou) wrote :

Brightness on Samsung N110 now work properly with bios 07D0

pittipatti (pittipatti) wrote :

To get an idea of what the bios update for the NC10 does, can one of the
NC10 users please tell what "xbacklight" says after the
upgrade.
Does it still say "No outputs have backlight property" or does it report
the current brightnesslevel?

trendzetter (trendzetter) wrote :

The backlightproperty has indeed come up after bios update on acer timeline 5800t. It was missing as reported in here:
bug 428054 (duplicates)

trtl (pdersjant) wrote :

xbacklight reports the current brightnesslevel on my NC10 with updated BIOS.

chris (christian-schaefer) wrote :

Karmic with the latest upgrades from today. Hardware is a MacBook 3,1. Backlight is also not working with KMS enabled. Using the "nomodeset" option during boot at least gets xbacklight to work again. Although closing the lid is not turning off the backlight. This used to work with Jaunty.

With BIOS and MICOM version 04CA, the brightness was not working on my Samsung NC 10 as well, a BIOS update indeed fixed the problem. That said, even without the BIOS update, the backlight (and modesetting) worked using nc10-backlight from this PPA: https://launchpad.net/~voria/+archive/ppa
So, it is principally fixable for old BIOSes as well.

Bryce Harrington (bryce) wrote :

It appears that the X task was reopened but actually this needs a kernel task. It seems while the X side of things got a fix, a patch is still needed for the kernel.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Fix Released
Manoj Iyer (manjo) wrote :

If you look in the bios settings there is a setting for Brightness control, and it is set to Auto by default, try changing that to manual and see if you are able to use the brightness keys.

executorvs (executorvs) wrote :

as many people are commenting on this issue I doubt greatly that all have brightness settings in their bios. I know I do not. I may need to start a new bug report though as I am getting an all new response after doing a clean install updates and bios update with karim final. brightness keys work... as long as you ignore the fact that they also seem to cause a system freeze :-(
this is with a timeline 5810TZ

I have the same problem on my acer Extensa 5230 notebook with intel driver 2.9 and kernel 2.6.31.

Without KMS, "xrandr --props" shows properties "BACKLIGHT" and "BACKLIGHT_CONTROL", while with KMS, there are the properties "BACKLIGHT" and "Backlight", but no "BACKLIGHT_CONTROL". Setting brightness via xrandr or /sys/class/backlight both work with KMS, only the keys have no effect.

The acer Extensa 5230 has no "brightness" menu point in its BIOS.

Andreas: your issue appears to be different than the one reported in this bug. Users affected by this bug have no "Backlight", "BACKLIGHT", "BACKLIGHT_CONTROL" or devices in /sys/class/backlight/

*when using KMS

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
tags: added: regression-release
removed: regression-potential
LA (radiobuzzer) wrote :

I suggest a temporary fix to this problems, issued in PPA repository. Instructions following
http://www.voria.org/forum/viewtopic.php?f=3&t=296

Same problem here on Macbook 1,1 with Lucid daily cdimage.

Also still broken on Macbook 2,1 with Lucid alpha-3

Changed in linux (Ubuntu):
status: Triaged → Fix Released

This is entirely fixed for my Macbook 2,1 using the latest Lucid liveCD (linux-generic 2.6.32.19.20)! Brightness goes all the way from fully bright to pleasantly off on the lowest notch with no modification and using the brightness keys built into the keyboard. I'd be tempted to call the brightness experience perfect out the gate.

The new fix also cleaned up the funky brightness slider bug that appeared back in Jaunty: https://bugs.launchpad.net/bugs/397309

Benoit Garret (benoit.garret) wrote :

It's still not working on a Macbook 1,1. Tested on a lucid installation and on the daily live cd.

Eric (etmeek) wrote :

I can confirm also it isn't working on a MacBook Pro 1,1. Tested with Lucid Beta 2 and all updates applied through 4/12/2010

eric@evil-twin:~$ sudo ls -al /sys/class/backlight/
total 0
drwxr-xr-x 2 root root 0 2010-04-13 14:30 .
drwxr-xr-x 50 root root 0 2010-04-13 14:30 ..
eric@evil-twin:~$ uname -a
Linux evil-twin 2.6.32-20-generic #30-Ubuntu SMP Mon Apr 12 15:19:41 UTC 2010 i686 GNU/Linux

Steffen Röcker (sroecker) wrote :

@Drew or other Macbook users, did it work without the patch from bug 417770 ?

For the other Macbook users where it doesn't work, please post the output of

sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
lspci | grep VGA

to bug 511965

Kai Krueger (kakrueger) wrote :

It works fine for me on a MacBook 4,1 and I didn't need any further patches. But I am running Karmic with only the kernel updated to 2.6.32-19-generic from the kernel-ppa and xorg still from karmic. Thanks for fixing this.

I haven't done extensive regression testing to prove it was the specific patch above but the issue was resolved between Lucid alpha-3 and beta-1. I suspect it was in the commit for bug 511965 in kernel 2.6.32-19.28. That patch may need to be expanded upon to include support for additional Macbook models or it may be another issue entirely for the 1,1 models. Since I only have a (working) 2,1 now I really can't confirm the issue with the 1,1s. Best to follow Steffen's instructions and keep reporting on bug 511965 with your hardware information until more information turns up.

Eric (etmeek) wrote :

@Steffen the backlight has not worked since Jaunty on my MacBook Pro 1,1

spaetz (spaetz) wrote :

There are different issues at work here for different laptops (from different vendors). I can confirm that Macbooks 4,1 work fine now in latest lucid (alledgedly 2,1-5,1 works while 1,1 does not).

The Samsung NC10 requires a BIOS update AFAIK. Can someone clarify about what model this bug is and close it if fixed,so others can open bugs against Lucid if required?

Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.