Ubuntu

brightness no more working on karmic (KMS)

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

Bug Description

Binary package hint: xorg

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

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

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

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

running xbacklight gave me this output

No outputs have backlight property

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

Created an attachment (id=24394)
acpidump

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

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

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

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

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

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

it is a samsung nc 10.

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

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

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

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

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

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

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

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

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

   Thanks.
  >

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

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

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

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

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

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

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

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

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

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

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

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

(In reply to comment #10)

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

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

   Thanks.

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

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

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

Created an attachment (id=26160)
backlight.py

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

Created an attachment (id=26206)
backlight.py

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

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

Binary package hint: xorg

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

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

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

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

running xbacklight gave me this output

No outputs have backlight property

alain57 (alain57) wrote :

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

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

alain57 (alain57) wrote :

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

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

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

alain57 (alain57) wrote :

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

how can i be so sure ?

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

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

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

Bryce Harrington (bryce) wrote :

Let us know what you find

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

I added the upstream bugreport.

This problem only occurs when using KMS.

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

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

version info:

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

In reply to comment #17:

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

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

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

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

Created an attachment (id=27840)
acpidump

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

does poking these I/F changes the backlight?

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

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

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

Created an attachment (id=27867)
acpi grep output

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

Created an attachment (id=27869)
customized DSDT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bryce Harrington (bryce) on 2009-08-13
tags: added: karmic
Geir Ove Myhr (gomyhr) on 2009-08-16
tags: added: backlight
tags: added: regression-potential
Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released
tags: added: apport-collected
Bryce Harrington (bryce) on 2009-10-08
Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → In Progress
Changed in xserver-xorg-video-intel (Ubuntu):
status: In Progress → Fix Released
Changed in xserver-xorg-video-intel (Ubuntu):
status: Fix Released → Confirmed
tags: added: xorg-needs-kernel-fix
93 comments hidden view all 173 comments
Thiago Martins (martinx) wrote :

Guys!

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

Cheers!
Thiago

Drew Snellgrove (forkinme) wrote :

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

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

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

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

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

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

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

Philip Lowman (philip-yhbt) wrote :

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

trtl (pdersjant) wrote :

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

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

Mathieu Marquer (slasher-fun) wrote :

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

Cedric F. (c-fachinetti) wrote :

Ok but,

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

Mathieu Marquer (slasher-fun) wrote :

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

trendzetter (trendzetter) wrote :

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

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

Philip Lowman (philip-yhbt) wrote :

@Muharem and others

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

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

Philip Lowman (philip-yhbt) wrote :

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

Eric (etmeek) wrote :

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

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

spaetz (spaetz) wrote :

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

uxinity (uxinity) wrote :

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

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

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

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

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

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

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

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

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

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

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

uxinity (uxinity) wrote :

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

bigjimlefou (bigjimlefou) wrote :

Brightness on Samsung N110 now work properly with bios 07D0

pittipatti (pittipatti) wrote :

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

trendzetter (trendzetter) wrote :

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

trtl (pdersjant) wrote :

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

chris (christian-schaefer) wrote :

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

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

Bryce Harrington (bryce) wrote :

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

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

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

executorvs (executorvs) wrote :

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

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

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

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

Drew Snellgrove (forkinme) wrote :

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

Drew Snellgrove (forkinme) wrote :

*when using KMS

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

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

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

Drew Snellgrove (forkinme) wrote :

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

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Drew Snellgrove (forkinme) wrote :

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

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

Benoit Garret (benoit.garret) wrote :

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

Eric (etmeek) wrote :

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

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

Steffen Röcker (sroecker) wrote :

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

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

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

to bug 511965

Kai Krueger (kakrueger) wrote :

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

Drew Snellgrove (forkinme) wrote :

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

Eric (etmeek) wrote :

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

spaetz (spaetz) wrote :

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

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

Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 173 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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