brightness no more working on karmic (KMS)

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. ***

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 ;)

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.

(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/*

Driver can be found here:
  http://article.gmane.org/gmane.linux.kernel/877678

/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'?

(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...

(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.

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.

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.