The slider brightness Applet has value inverted after the last update (2.6.27-11)

I have the same problem after the update of the kernel from (2.6.27-10-generic to 2.6.27-11-generic).
I think it is a kernel problem since the is a lot of change is th release note concerning the brightness.
Which laptop do you have?
I have an asus laptop (may come from asus-acpi).

Hello! My laptop has a asus motherboard too.

I got an Asus M50SA laptop, and I got a similar problem. After same upgrade, my brightness is not working correctly.

When I try to adjust the brightness with the FN keys, the brightness is working all wrong. I won't call it inverted, but just wrong.

Forget my last statement. Its actually like Mauricio Tucci reported, the brightness is inverted compared to my FN keys.

Could you test the kernels at the URL below, it seems that some BIOSen have bad ACPI brightness interfaces which will now be being used, this kernel should detect and ignore these. It would be good to know if this fixes your issues:

    http://people.ubuntu.com/~apw/lp311716-intrepid/

It fixes the problem for me.
Good job ;)

Hello Andy.

It doesn't fix my.

Before the update:
- My brightness in gnome was inverted
- In kde 4 it was actually right???

After the update;
- The brightness seems correct in gnome, thought now I can't use my FN + F5 (up) or FN + F6 (down) keys?

So it fixes some of the problem, but can't use my brightness keys. It worked all very good before the upgrade Mauricio is talking about. Hmm in my case, could it just be the gnome power manager?

When I say before the upgrade, I mean the kernel upgrade with the attached patch. Before any upgrade I had no problems at all. After the upgrade descripted by Mauricio, every was inverted. Now after the patch/fix, my FN keys doesn't work anymore. Just to avoid misunderstandings with my post berfore.

It fixes the problem to me. Great Job! Thanks.

My FN keys, (fn + f5 (up) and fn + f6 (down)) have never worked. My
laptop has ASUS motherboard.

Mauricio Tucci

Terrax wrote:
> When I say before the upgrade, I mean the kernel upgrade with the
> attached patch. Before any upgrade I had no problems at all. After the
> upgrade descripted by Mauricio, every was inverted. Now after the
> patch/fix, my FN keys doesn't work anymore. Just to avoid
> misunderstandings with my post berfore.
>
>

I've tested the kernel suggested by Andy in comment #5 and the brightness started working again for me. Hotkeys are working also.

My problem was that after the update of the kernel from 2.6.27-10-generic to 2.6.27-11-generic (using proposed updates) the brightness on my laptop was not changeable.

To be specific, when I upgraded to 2.6.27-11-generic, the brightness was not changeable using the hotkeys, /proc/..., /sys/... or even the scroll bar in the power applet directly. Using the hotkeys the UI with the progress bar seemed to hang for one second each time a change was made but with no effect.

I have a Thinkpad T61 using the 32bit version of Intrepid Ibex 8.10.

Now everything is fine! Thanks Andy for packages easy to test.

May I suggest pushing this new kernel to intrepid-proposed?

Updated kernel accepted into intrepid-proposed:

 linux (2.6.27-11.23) intrepid-proposed; urgency=low
 .
   [ Andy Whitcroft ]
 .
   * SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control
     - LP: #311716, #314119
 .
   [ Jim Lieb ]
 .
   * SAUCE: atl2: add tx bytes statistic
     - LP: #268622
 .
   [ Upstream Kernel Changes ]
 .
   * i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45
     - LP: #276943

Closing intrepid task, since this regression only affected -proposed.

So this affects Jaunty, too?

Yes, fix was commited to Jaunty as well. It will get included into the next upload there.

Andy...

This fix breaks my brightness keys?

When I use you patched kernel, my FN keys doesn't work anymore.
The kernel 2.6.27-10-generic is working perfectly with my FN keys, and it isn't inverted.

So Ill say the kernel 2.6.27-11-generic contains a regression, and of this bug report, you made a fix to that regression. Unfortunately that fix breaks my FN keys completely. Any ideas? Anyway, thanks for your quick replies.

@Terrax,

can you try to boot with the kernel option "acpi_backlight=vendor" to see
whether this fixes your case?

@Stefan Bader

This does unfortunately not fix my problem. Still no response with my FN keys.

With or without "acpi_backlight=vendor" gnome and kde is able to adjust the backlight with the backlight applet, but just not with my FN keys. The weird is just, it all works perfectly with 2.6.27-10.

But thx for your try Stefan. Any other ideas? ;)

BTW, tried with the kernel option:
acpi_backlight=asus

> BTW, tried with the kernel option:
> acpi_backlight=asus

That would do nothing. The strings checked are either "vendor" or "video". As for the FN keys. It could well be something different between -10 and -11 but also that the asus driver seems to tie hotkeys tightly to the vendor specific backlight implementation. Do you get any message like "Could not register asus backlight device" in dmesg?

@Terrax -- could you attach dmesg output and lspci -nnvv output to this bug when running my kernels please.

@Stefan

Tried with the vendor param also, but didn't do any difference. Get nothing unusually in dmesg.

@Andy

Ofcourse. Here is the dmesg output:

And the lspci -nnvv output

The 2.6.27-11.23 kernel from intrepid-proposed makes my backlight settings go all funny. The lowest setting (both using xbacklight -set 0 and the Fn-Fx key combos) now corresponds to a black screen. My laptop was working fine with 2.6.27-11.22.

I've attached the output of lspci -nnvv; dmesg does not seem to contain "backlight" anywhere in it, so I'll leave it out.

@pablomme

Remember to test with the kernel packages attached to this bug report:
http://people.ubuntu.com/~apw/lp311716-intrepid/

@pablomme, @Terrax -- could you both attach a dmesg output from the
previous kernels you tested where your keys etc did work.

@Andy

Here you are.

After updating to 2.6.27-11.23 from intrepid-proposed, my backlight keys stopped working altogether. They had been working perfectly since 2.6.27-11 but now this:
cat /proc/acpi/video/VGA/LCD/brightness
< not supported >
After downgrading to 2.6.27-11.22:
cat /proc/acpi/video/VGA/LCD/brightness
levels: 100 60 20 28 36 44 52 60 68 76 84 92 100
current: 60
And the keys work perfectly again. It is likely related to this fix in the changelog:
 [ Andy Whitcroft ]

  * SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control
    - LP: #311716, #314119

I've attached the dmesgs for 2.6.27-11.22, 2.6.27-11.23 and 2.6.27-11.23~apw in a tarball. One more thing I've noticed: the maximum setting in (broken) -11.23 yields the same amount of backlight as the minimum setting in (working) -11.22.

Also, my /proc/acpi/video/IGFX/LCD/brightness behaves like aaron's: it reports "<not supported>" in -11.23, while it holds the correct device properties and state in -11.22.

Not fixed yet in intrepid, reopening. Seems this is too fiddly to fix without causing regressions?

The latest kernel update also broke both my Fn keys *and* brightness control altogether.

Lenovo 3000 N100 Ubuntu 8.10 x86-64
lspci -nnvv attached.

We currently seem to have to choice between tw evils. :( Question to Mauricio, Arnaud and Oliver (or anybody who has problems with the -11.22 kernel): will brightness settings work for you with that kernel and using "acpi_backlight=vendor". Since video is a module, it might be necessary to put the following line into /etc/modprobe.d/options instead of just using it as a boot option.

options video acpi_backlight=vendor

Stefan Bader [2009-01-09 12:04 -0000]:
> We currently seem to have to choice between tw evils. :(

Not really. If we have to pick between a regression in stable, and
fixing something that didn't work before, we'd always do the latter.

If I had 'options video acpi_backlight=vendor' to /etc/modprobe.d/options, then the brightness slider still works well but the fn keys for brightness do not work anymore (with an asus laptop).

Wait, I'm confused - which one is the regression? The OP's problem or my problem as a result of the fix for his problem?

This is three stage:
- fix for OP's problem (bug #257827) which resulted in regression for some others (initial report here and in the other
  report)
- avoid those problems and get regressions for yet other laptops

The main regression would be the initial change but reverting that would be again a bigger change (which causes another ABI bump which should also be rather avoided) and would also revert a state that is actually upstream, which also might be sub-optimal. The fix-for-the-fix though is still discussed upstream. So the best way to proceed I can see at the moment (if settings available by module options yield results everybody can live with) would be to revert the second patch and add some defaults bsaed on DMI information.
That was the reason to ask whether -11.22 with a certain acpi_backlight setting gives the same results as with -11.23 for those that have a working -11.23.

Hi!

Brightness change was correctly working for me until today's update (2.6.27-11.23). Now, the applet still shows up but the brightness does not change anymore.

I just uploaded a test kernel at https://launchpad.net/~stefan-bader-canonical/+archive (this still will take some time to complete the compile). The version will be 2.6.27-11.23smb2. I tried there to get something together which hopefully behaves like the -10 kernels by having acpi and vendor interface active. Please try this when build and report back

1. what works or not
2. if it doesn't work, could you please post 2 files,
    - the output of "dmesg"
    - the output of "grep -r . /proc/acpi/video"

Note: having "options video acpi_backlight=..." in /etc/modprobe.d/options will force either vendor or video, so to get both interfaces it should be removed.

@Stefan

I have tested your kernel, and everything seems to work again. Thank you. I don't have to specify "acpi_backlight=vendor".
It works like it was the 2.6.27-10 kernel.

Have you reverted everything related to brightness, back to the state of 2.6.27-10?

@Terrax,

sounds promising. :) Thanks for testing. I hope this goes similarly well for
the others. No I actually did not revert in that sense. I kept the new
infrastructure but added a new "default". With the new code added to -11 it was
either acpi or vendor backlight control. While before actually both were active
and thus causing problems for some others (values changed twice). Long term it
should be either the one or the other but it seems this easily breaks. Possibly
the hotkey functions in the laoptop specific drivers somehow are too tightly
relying on both interfaces to be active. But then trying to get this fixed
should be done rather in a development kernel.
The way it would be with that patch I made would be to have both interfaces
active by default (as before) but additionally allow to specify module options
to force only one of those two to be active.

@Stefan
Your kernel works great for me too.

@Stefan

Your kernel (2.6.27-11.23smb2) doesn't work for me. I am exactly at the same point as when I upgraded to the first proposed (2.6.27-11.22). Which was, for me, the first regression. Before everything was fine in 2.6.27-10 and is fine also in the recently released in -proposed 2.6.27-11.23.

What doesn't work:
Brightness is not changeable using the hotkeys, /proc/ or even the scroll bar in the power applet directly. When using the hotkeys, the applet with the brightness progress bar hangs for one second and the brightness doesn't change. Also the default brightness is *very* low (likely the lowest).

Also, I don't know if this is related but the build is identified as failed on the PPA page.

dmesg attached

@Terrax: I don't think your problem is related to this bug. I've seen the behaviour you describe for "battery mode", and it corresponds to having the "Reduce backlight brightness" option checked in the "On Battery Power" tab in gnome-power-preferences, then dimming the display on AC power using the corresponding FN key combo (or otherwise), then unplugging the AC cable.

It would appear that the "reduced brightness" is computed with respect to the *original* brightness on AC power, not the *current* brightness; that is why the screen turns brighter. You may file a new bug report for this behaviour if you wish, although it is debatable whether this is an actual bug... It's almost certainly not a bug in the kernel.

still no difference for months on my lenovo sl300 and probably every other sl series and ideapad.

I read somewhere it was possible to get the function of the keys back by using an older kernel. Is there anyway to tell acpi to get its hands off the brightness keys and video brightness without turning off acpi completely? I don't care if gnome can't control my brightness, I just want the convenience of being able to use the keys properly.

I have an R61i, and adding "options thinkpad_acpi brightness_enable=1" to /etc/modprobe.d/options solved my problem. What confuses me is that my problem showed up later than the other posters. Is there a way to auto-detect when this option is necessary? My pre-fix system is described in greater detail in the duplicate bug 323475.

Thanks a lot Scott. I own a X300 and your proposal really fixes my brightness adjustment problem
in 2.6.27-11.

On Tue, Feb 3, 2009 at 9:30 AM, odyseuss <email address hidden> wrote:

> Thanks a lot Scott. I own a X300 and your proposal really fixes my
> brightness adjustment problem
> in 2.6.27-11.

I'm glad it worked for you, but I can't take credit. I simply followed the
suggestion Stefan Bader gave to Tom Vetterlein earlier in the thread.

Still doesn't do anything for the thinkpad SL300, sl400, sl500, and all ideapads. Sl300 can't load thinkpad-acpi b/c the firmware is ideapad-based.

Still doesn't work for me either. Any workaround found here.

Acer Aspire 6920G and Ubuntu x64

So sad for this step backward..it worked on .11 proposed kernel before that "bad" update....

Uhm.. this bug seems fixed?! In my system is not fixed at all...

Unless there should actually be a separate bug, it seems that the most recent comments indicate that brightness control is broken on some machines, regressing from -9.
I can also confirm that on my Thinkpad X300.

So should we open another bug? do you need any detail to classify my Aspire 6920G system?

@Oliver and others

Hmm in Jaunty my brightness keys works perfectly, but the brightness applet in kde 4.2 is inverted? Should I open another bug, as this diesn't seem to be a kernel bug?

@Terrax

Well if you are 100% sure that the problem is not in the kernel but in the package then yes I think you should check for bugs against the kde power management package. First, maybe you want to try poking around in /proc (specific files mentionned in previous bug comments) and make sure that the behavior is right. Checking if the behavior on Gnome is right would also help to know if its a KDE thing or a kernel thing.

I haven't tried jaunty yet.. I guess I should look at it if it works for my T61.

Well...

grep -r . /proc/acpi/video/
/proc/acpi/video/VGA/LCDD/EDID:<not supported>
/proc/acpi/video/VGA/LCDD/brightness:levels: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
/proc/acpi/video/VGA/LCDD/brightness:current: 13
/proc/acpi/video/VGA/LCDD/state:state: 0x1f
/proc/acpi/video/VGA/LCDD/state:query: 0x01
/proc/acpi/video/VGA/LCDD/info:device_id: 0x0110
/proc/acpi/video/VGA/LCDD/info:type: UNKNOWN
/proc/acpi/video/VGA/LCDD/info:known by bios: no
/proc/acpi/video/VGA/DVID/EDID:<not supported>
/proc/acpi/video/VGA/DVID/brightness:<not supported>
/proc/acpi/video/VGA/DVID/state:state: 0x1d
/proc/acpi/video/VGA/DVID/state:query: 0x00
/proc/acpi/video/VGA/DVID/info:device_id: 0x0210
/proc/acpi/video/VGA/DVID/info:type: UNKNOWN
/proc/acpi/video/VGA/DVID/info:known by bios: no
/proc/acpi/video/VGA/CRTD/EDID:<not supported>
/proc/acpi/video/VGA/CRTD/brightness:<not supported>
/proc/acpi/video/VGA/CRTD/state:state: 0x1d
/proc/acpi/video/VGA/CRTD/state:query: 0x00
/proc/acpi/video/VGA/CRTD/info:device_id: 0x0100
/proc/acpi/video/VGA/CRTD/info:type: UNKNOWN
/proc/acpi/video/VGA/CRTD/info:known by bios: no
/proc/acpi/video/VGA/DOS:DOS setting: <0>
/proc/acpi/video/VGA/POST:<not supported>
/proc/acpi/video/VGA/POST_info:<not supported>
/proc/acpi/video/VGA/ROM:<TODO>
/proc/acpi/video/VGA/info:Switching heads: yes
/proc/acpi/video/VGA/info:Video ROM: no
/proc/acpi/video/VGA/info:Device to be POSTed on boot: no

Shouldn't the brightness levels start from 0 from left to 15 to the right? Well that could be a cause for the inverted brightness in the brightness applet and the normal brigtness adjustment with the FN keys?

What I meant is what happen if you do:

sudo echo 15 > /proc/acpi/video/VGA/LCDD/brightness
sudo echo 5 > /proc/acpi/video/VGA/LCDD/brightness

If 5 is brighter than 15 then it could still be a kernel problem but even then, maybe not..

On Tue, Feb 17, 2009 at 04:14:49PM -0000, Olivier Bilodeau wrote:
> What I meant is what happen if you do:

> sudo echo 15 > /proc/acpi/video/VGA/LCDD/brightness
> sudo echo 5 > /proc/acpi/video/VGA/LCDD/brightness

What happens is that you'll get a permissions failure, because the
redirection (> /proc...) is handled by the parent shell, not by sudo. ;)

You need:

sudo -s
echo 15 > /proc/acpi/video/VGA/LCDD/brightness
echo 5 > /proc/acpi/video/VGA/LCDD/brightness
exit

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Or more compactly,

echo 15 | sudo tee -a /proc/acpi/video/VGA/LCDD/brightness
echo 5 | sudo tee -a /proc/acpi/video/VGA/LCDD/brightness

Actually 5 makes my screen go darker and 15 lighter in intrepid.. I can't test it on my Jaunty right now, as Im not at home. I will test as soon I get home (Jaunty is installed on an external harddisk).

But kde powermanagement is working well in intrepid. Its in Jaunty I get the problems. Will be back with the results.

Jaunty has the same behaviour, so its probably not a kernel bug.

Actually when I start the system under 2.6.27-11-generic x64 GNU/Linux (on acer aspire 6920G)
    - my directory '/proc/acpi/video' is EMPTY
    - and LCD brightness can't be changed, both from terminal and FN keys.
    - Plus, if I use FN keys, the applet reacts to Brightness- but doens't react to Brightness+

when I start the 2.6.27-9-generic, instead, I have the proper directories and the system (and applet) working.

It's a pity the acpi has broken in this last kernel release.

not fixed in 2.6.27-12-generic

generic kernel 2.6.27-11.27 i386 on x61 tablet

backlight control is broken. none of the module options above fixed it. last known working kernel was linux-image-generic_2.6.27.11.14_i386.deb

works with linux-image-2.6.27-11-generic_2.6.27-11.23~lp311716apw1_i386

not fixed in 2.6.27-13-

Yes, John Chia, I confirm your comment:

backlight control is broken. none of the module options above fixed it. last known working kernel was linux-image-generic_2.6.27.11.14_i386.deb

Regression not solved in linux distrib. <2.6.27-14-generic>
I still have to use the <2.6.27-4-generic>

The Fn-keys don't work for me on a Lenovo X300 with linux-image-2.6.27-11-generic (intrepid). Changing throuhg guidance-power-manager in kde4 works, though. I realized that pressing the Fn-keys for brightness up and down changes the value of /proc/acpi/video/VID/LCD0/brightness instead of /proc/acpi/video/VID1/LCD0/brightness (VID instead of VID1). Manually changing the latter (echo 80 > /proc/acpi/video/VID1/LCD0/brightness) does change the brightness. This is also reported for arch linux (see http://wiki.archlinux.org/index.php/Lenovo_Thinkpad_X300#Backlight) so it might not be ubuntu-specific.

I have in /etc/modprobe.d/options
options thinkpad_acpi experimental=1 fan_control=1 brightness_enable=1

and tried withouth all these options, and with
options video acpi_backlight=vendor

always same behaviour. I also tried with a new kernel with
# CONFIG_THINKPAD_ACPI_VIDEO is not set
(read somewhere, that that could help, but it didn't).

I just installed ubuntu intrepid on that notebook, so I can't say, under which constellation exactly it worked, but I remember, that the keys worked when I first installed intrepid from the CD, before updating. But it didn't work with the 2.6.27-7-kernel, which I tried to boot as well.

Should I open a new bug for that?

Ben

Ben,

# xrandr --output LVDS --set BACKLIGHT_CONTROL native

put backlight brightness control back into work on my Lenovo X300 - for the current session. So I created a batch file to run at each startup (attached). Simply put it into /usr/local/share/ and add it in sytem settings -> sessions.

Might not be the most beautiful way to fix it, but hey - it works. :-)

Best,
Till

Hi Till,

thanks for that comment and the script. Unfortunately, it doesn't seem to have any effect on my system. It I run that under X in a term, the backlight_control changes, but Fn-Keys still won't work. Do you load thinkpad_acpi with specific options to make that happen? Do you have a custom kernel?

I also forgot to mention that I updatet the BIOS to the latest version (1.09 I guess), maybe that's related.

Ben

I would like to try to summarize the various issues as they appear to me reading the comments. Unfortunately we now seem to have a whole collection of similar but yet different problems in one huge bug and maybe we could untangle it by splitting of separate bugs for those.

1. an inverted brightness control (as initially reported in the bug)
    There has been a patch in 2.6.27-13.29 that, in theory, should address this by
    "ACPI: video: Fix reversed brightness behavior on ThinkPad SL series" (lp#330200)
   So, starting with the mentioned kernel, the values in the acpi brightness control should get sorted
   from small to large numbers.
2. No brightness control with the acpi brightness controls present.
    This, as far as I know, affects only ThinkPad/Lenovo laptops and it should be indicated by a dmesg
    entry from thinkpad_acpi saying "standard ACPI backlight interface available, not loading native
    one...". For those, the workaround would be to use "options thinkpad_acpi brightness_enable=1"
    in a file in /etc/modprobe.d. Maybe we should make this the default, though that should be tested
    well, in order not to break yet some other machines.
3. No brightness control without the acpi controls present
    The one case of that I saw was an acer and indeed there is a bug in Intrepi'ds acer-wmi that
    reverts the intended behavior (back off if no acpi support is there but stay if there is).
4. Brightness control working through the acpi interface (echoing values to the sysfs controls)
    but not through the Desktop interface. Maybe because there have been changes to prevent
    multiple acpi devices from creating the same VID entry n sysfs. So that could be a Desktop
    issue.

I would propose to open new bugs for 2-4 and verify and keep tracking 1 here. For 2, there seems to be a report open (lp#324061) and it would be best to track that issue there. For 3, lp#333386 seems the one matching best but for 4 I did not find a report that sounded like it described that issue. Maybe someone is more successful and could point others there or open a new report for it.
Finally 1: is this still an issue with the latest -proposed kernel? If yes, could you add the Laptop vendor and model as well as the output of "grep -r . /proc/acpi/video" here?

I confirm in my acer aspire 6920G the brightness control is BROKEN. I also tried the jaunty-beta3, and I can report the following:

- HotKeys are correctly recognized (and notification works properly)
- Brightness is not affected using hotkeys, it cannot be changed.

does it mean it has not been fixed even in jaunty? This page's header claimed it has been fixed in jaunty???

I just upgrade to jaunty and can confirm that it works there on a Lenovo X300. Fn-keys change brightness correctly, the KDE guidance-power-manager as well.

So I will open another bug for my ACER aspire 6920G... Because it seems they are two different issues.

@gidantriba, please look at my post and take bug #333386 for this one.
I added some Intrepid test kernels today.

You're right... it looks the same problem...

Status Incomplete?? after 130 comments on it? things are two: or all guys posting here are stupid or this bug is far from being incomplete...

@gidantribal, the status incomplete in this case looks like it came from the upstream bug report. But it could also be used by us to reflect that we asked for more information and are waiting for that. Unfortunately there is no launchpad state for that.

For this bug report, has anybody still issues on Intrepid with _reversed_ backlight levels?

As there seems to be no one having the inverted values problem any more I will close the Intrepid task. Won't fix because it is unclear whether it was fixed in Intrepid but won't qualify for an SRU after Jaunty is now released.