Bug 20963 - [KMS] need backlight property control
[KMS] need backlight property control
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86 (IA32) Linux (All)
: medium normal
Assigned To: ykzhao
Xorg Project Team
:
: 21904 22573 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-30 23:27 UTC by Soeren Sonnenburg
Modified: 2009-08-31 23:15 UTC (History)
16 users (show)

See Also:


Attachments
acpidump (108.53 KB, text/plain)
2009-03-31 02:57 UTC, Soeren Sonnenburg
no flags Details
backlight.py (2.04 KB, text/plain)
2009-05-24 00:33 UTC, jeromepoulin@gmail.com
no flags Details
backlight.py (2.29 KB, text/plain)
2009-05-25 09:38 UTC, jeromepoulin@gmail.com
no flags Details
acpidump (147.69 KB, text/plain)
2009-07-20 01:21 UTC, Ivan Bulatovic
no flags Details
acpi grep output (5.27 KB, text/plain)
2009-07-21 00:12 UTC, Ivan Bulatovic
no flags Details
customized DSDT (259.59 KB, application/octet-stream)
2009-07-21 00:54 UTC, zhang rui
no flags Details
Acpidump of Sony Vaio TT11LN (192.53 KB, application/octet-stream)
2009-07-22 08:39 UTC, Guido Guenther
no flags Details
customized DSDT (260.33 KB, application/octet-stream)
2009-07-23 00:31 UTC, zhang rui
no flags Details
dmesg log (242.21 KB, text/plain)
2009-07-23 01:08 UTC, Ivan Bulatovic
no flags Details
customized DSDT with more debug info (261.79 KB, application/octet-stream)
2009-07-26 18:42 UTC, zhang rui
no flags Details
dmesg log (240.96 KB, text/plain)
2009-07-26 23:28 UTC, Ivan Bulatovic
no flags Details
costom DSDT (261.93 KB, application/octet-stream)
2009-07-27 00:02 UTC, zhang rui
no flags Details
dmesg log (217.39 KB, text/plain)
2009-07-27 00:18 UTC, Ivan Bulatovic
no flags Details
dmesg for attachment id=28019 on samsung nc10 (453.29 KB, application/octet-stream)
2009-07-27 00:24 UTC, Soeren Sonnenburg
no flags Details
custom DSDT. (259.59 KB, application/octet-stream)
2009-07-27 01:34 UTC, zhang rui
no flags Details
dmesg log (203.79 KB, text/plain)
2009-07-27 01:56 UTC, Ivan Bulatovic
no flags Details
dmesg from samsung nc 10 with verbose acpi_debug level (453.29 KB, application/octet-stream)
2009-08-01 01:39 UTC, Soeren Sonnenburg
no flags Details
dmidecode log (9.54 KB, text/plain)
2009-08-03 00:36 UTC, Ivan Bulatovic
no flags Details
vaio_sz1xp.dump (137.45 KB, application/octet-stream)
2009-08-04 00:03 UTC, Milan Oravec
no flags Details
vaio_z21xn.dump (217.75 KB, application/octet-stream)
2009-08-04 13:00 UTC, Milan Oravec
no flags Details
samsung-q45_acpidump (154.02 KB, application/octet-stream)
2009-08-04 22:10 UTC, pittipatti
no flags Details
samsung-q45 output of proc and sysfs (2.75 KB, text/plain)
2009-08-04 22:11 UTC, pittipatti
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Soeren Sonnenburg 2009-03-30 23:27:43 UTC
I am on kernel 2.6.29 and xf86-intel 2.6.3 on debian expermimental. As soon as I enable KMS brightness adjustments (from within gnome) don't work.

setpci -s 00:02.1 F4.B=XX

(XX ranging from 00 to FF) though just work fine...
Comment 1 zhang rui 2009-03-31 01:05:14 UTC
please attach the acpidump output,
you can use the latest pmtools here:
http://www.lesswatts.org/projects/acpi/utilities.php
Comment 2 Soeren Sonnenburg 2009-03-31 02:57:55 UTC
Created attachment 24394 [details]
acpidump
Comment 3 Jesse Barnes 2009-03-31 08:11:00 UTC
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.
Comment 4 zhang rui 2009-04-01 19:32:04 UTC
(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?

Comment 5 Soeren Sonnenburg 2009-04-01 20:26:52 UTC
it is a samsung nc 10.

booting the same kernel with 'nomodeset' gets brightness to work again.
Comment 6 zhang rui 2009-04-01 23:15:02 UTC
This doesn't sound like an ACPI problem to me.
Comment 7 Jesse Barnes 2009-04-02 09:42:07 UTC
(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.
Comment 8 ykzhao 2009-04-02 19:56:42 UTC
(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.
  > 

Comment 9 zhang rui 2009-04-03 00:15:30 UTC
(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...
Comment 10 Jesse Barnes 2009-04-03 09:33:12 UTC
(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.



Comment 11 ykzhao 2009-04-04 21:18:37 UTC
(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.
Comment 12 Jesse Barnes 2009-04-06 09:34:19 UTC
(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.
Comment 13 Gordon Jin 2009-05-23 22:45:31 UTC
*** Bug 21904 has been marked as a duplicate of this bug. ***
Comment 14 jeromepoulin@gmail.com 2009-05-24 00:33:19 UTC
Created attachment 26160 [details]
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!
Comment 15 jeromepoulin@gmail.com 2009-05-25 09:38:37 UTC
Created attachment 26206 [details]
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?
Comment 16 Gordon Jin 2009-07-01 19:05:46 UTC
*** Bug 22573 has been marked as a duplicate of this bug. ***
Comment 17 Ivan Bulatovic 2009-07-17 10:01:00 UTC
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
Comment 18 Guido Guenther 2009-07-18 03:06:31 UTC
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
Comment 19 zhang rui 2009-07-19 18:57:22 UTC
re comment #16 and #17
please attach the acpidump output.
this is an ACPI problem because the ACPI backlight control methods don't work.
Comment 20 Ivan Bulatovic 2009-07-20 01:21:58 UTC
Created attachment 27840 [details]
acpidump
Comment 21 zhang rui 2009-07-20 01:49:23 UTC
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?
Comment 22 Ivan Bulatovic 2009-07-20 02:44:03 UTC
[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
Comment 23 zhang rui 2009-07-20 22:26:28 UTC
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.
Comment 24 Ivan Bulatovic 2009-07-21 00:12:44 UTC
Created attachment 27867 [details]
acpi grep output

This is output I get before and after several hotkeypresses (level up/down) without the acpi_brightness=vendor kernel parametar..
Comment 25 zhang rui 2009-07-21 00:54:25 UTC
Created attachment 27869 [details]
customized DSDT

please apply this customized DSDT and see if it helps.
please also attach the output of "cat /proc/acpi/video/GFX0/*/state".
Comment 26 zhang rui 2009-07-21 00:59:52 UTC
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?
Comment 27 Ivan Bulatovic 2009-07-21 01:52:49 UTC
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
Comment 28 Ivan Bulatovic 2009-07-21 02:16:48 UTC
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?
Comment 29 zhang rui 2009-07-21 20:22:49 UTC
(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



Comment 30 Ivan Bulatovic 2009-07-22 02:30:19 UTC
[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
Comment 31 Guido Guenther 2009-07-22 08:39:34 UTC
Created attachment 27918 [details]
Acpidump of Sony Vaio TT11LN
Comment 32 zhang rui 2009-07-22 19:11:28 UTC
(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.

Comment 33 Ivan Bulatovic 2009-07-22 23:19:31 UTC
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
Comment 34 Ivan Bulatovic 2009-07-22 23:31:57 UTC
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...
Comment 35 zhang rui 2009-07-23 00:31:30 UTC
Created attachment 27937 [details]
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.
Comment 36 Ivan Bulatovic 2009-07-23 01:08:35 UTC
Created attachment 27941 [details]
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...
Comment 37 Soeren Sonnenburg 2009-07-26 13:58:16 UTC
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.
Comment 38 zhang rui 2009-07-26 18:42:44 UTC
Created attachment 28019 [details]
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. :)
Comment 39 Ivan Bulatovic 2009-07-26 23:28:03 UTC
Created attachment 28027 [details]
dmesg log

I sure hope so :)
Comment 40 zhang rui 2009-07-27 00:02:48 UTC
Created attachment 28028 [details]
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.
Comment 41 Ivan Bulatovic 2009-07-27 00:18:11 UTC
Created attachment 28029 [details]
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...
Comment 42 Soeren Sonnenburg 2009-07-27 00:24:22 UTC
Created attachment 28030 [details]
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.
Comment 43 zhang rui 2009-07-27 01:34:46 UTC
Created attachment 28032 [details]
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.
Comment 44 Ivan Bulatovic 2009-07-27 01:56:20 UTC
Created attachment 28034 [details]
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.
Comment 45 Soeren Sonnenburg 2009-08-01 01:39:34 UTC
Created attachment 28242 [details]
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.
Comment 46 Ivan Bulatovic 2009-08-01 12:57:26 UTC
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...
Comment 47 Ivan Bulatovic 2009-08-02 02:22:48 UTC
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...  
Comment 48 zhang rui 2009-08-02 18:21:18 UTC
(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.

Comment 49 zhang rui 2009-08-02 18:25:12 UTC
(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?
Comment 50 Ivan Bulatovic 2009-08-03 00:36:24 UTC
Created attachment 28282 [details]
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
Comment 51 zhang rui 2009-08-03 00:50:07 UTC
> 
> 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. :)
Comment 52 Ivan Bulatovic 2009-08-03 01:01:37 UTC
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 :)
Comment 53 gfdsa 2009-08-03 01:43:54 UTC
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
Comment 54 Milan Oravec 2009-08-03 06:07:42 UTC
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
Comment 55 zhang rui 2009-08-03 18:45:49 UTC
(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.

Comment 56 Milan Oravec 2009-08-04 00:03:49 UTC
Created attachment 28332 [details]
vaio_sz1xp.dump
Comment 57 Milan Oravec 2009-08-04 00:05:05 UTC
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
Comment 58 zhang rui 2009-08-04 00:33:22 UTC
(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.
Comment 59 Milan Oravec 2009-08-04 02:53:45 UTC
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
Comment 60 Milan Oravec 2009-08-04 13:00:32 UTC
Created attachment 28345 [details]
vaio_z21xn.dump
Comment 61 Milan Oravec 2009-08-04 13:01:40 UTC
Here is acpidump from vaio z21xn. 
Comment 62 pittipatti 2009-08-04 22:06:26 UTC
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.
Comment 63 pittipatti 2009-08-04 22:10:22 UTC
Created attachment 28357 [details]
samsung-q45_acpidump
Comment 64 pittipatti 2009-08-04 22:11:09 UTC
Created attachment 28358 [details]
samsung-q45 output of proc and sysfs
Comment 65 Alain Tavan 2009-08-10 06:49:52 UTC
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 ;)
Comment 66 Jérémie Huchet 2009-08-12 05:26:38 UTC
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. 
Comment 67 Greg Kroah-Hartman 2009-08-14 12:36:35 UTC
(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/*

Comment 68 Greg Kroah-Hartman 2009-08-14 12:51:21 UTC
Driver can be found here:
  http://article.gmane.org/gmane.linux.kernel/877678
Comment 69 Soeren Sonnenburg 2009-08-14 13:49:45 UTC
/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:
Comment 70 Greg Kroah-Hartman 2009-08-14 14:50:19 UTC
(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

Comment 71 Jérémie Huchet 2009-08-14 14:59:49 UTC
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:
Comment 72 gfdsa 2009-08-14 15:27:32 UTC
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!
Comment 73 Greg Kroah-Hartman 2009-08-14 15:50:22 UTC
(In reply to comment #71)
> Here is the output for Samsung NP-Q45 :

Thanks, I've added this to the driver now.
Comment 74 Greg Kroah-Hartman 2009-08-14 15:51:46 UTC
(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.
Comment 75 Jérémie Huchet 2009-08-14 17:02:28 UTC
(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 ?
Comment 76 Greg Kroah-Hartman 2009-08-14 17:06:42 UTC
(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'?
Comment 77 Jérémie Huchet 2009-08-14 17:32:21 UTC
(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:2828 (rev 04)
00:1f.3 0c05: 8086:283e (rev 04)
02:00.0 0280: 8086:4222 (rev 02)
03:00.0 0200: 11ab:4353 (rev 15)
04:09.0 0607: 1180:0476 (rev b4)
04:09.1 0c00: 1180:0552 (rev 09)
04:09.2 0805: 1180:0822 (rev 18)
04:09.3 0880: 1180:0843
04:09.4 0880: 1180:0592 (rev 09)
04:09.5 0880: 1180:0852 (rev 04)
Comment 78 Greg Kroah-Hartman 2009-08-14 20:15:30 UTC
(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?

Comment 79 Jérémie Huchet 2009-08-15 04:04:30 UTC
(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 ?
Comment 80 Greg Kroah-Hartman 2009-08-16 15:13:46 UTC
(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.
Comment 81 ykzhao 2009-08-16 19:10:49 UTC
(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.
    
Comment 82 Matthias Hopf 2009-08-17 05:33:17 UTC
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).
Comment 83 Greg Kroah-Hartman 2009-08-17 09:14:50 UTC
(In reply to comment #81)
>     Where can I find the patch you have checked in? In your git branch?

Look in comment #70
Comment 84 Greg Kroah-Hartman 2009-08-17 09:15:50 UTC
(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.

Comment 85 Matthias Hopf 2009-08-18 09:48:34 UTC
intel driver now supports BACKLIGHT property in KMS case. So xbacklight will work in KMS case as well now.
Comment 86 Mike Kelly 2009-08-18 10:36:43 UTC
(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?
Comment 87 Mike Kelly 2009-08-21 12:28:48 UTC
(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.
Comment 88 Greg Kroah-Hartman 2009-08-21 12:46:10 UTC
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.
Comment 89 ykzhao 2009-08-31 23:15:48 UTC
The following commit already exists in the latest intel graphics driver.
commit a50916530426a662f5ed262892080b860a445da3
Author: Matthias Hopf <mhopf@suse.de>
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.