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

result of grep -r . /proc/acpi/video

May I suggest changing the bug's title to something more generic like "brightness problems in 2.6.27-11 kernels" because people searching for bugs might not check this one because of the misleading title.

Stefan, your kernel update solved the problem for me, brightness change now works, thanks!

@Oliver

Did you try with:
options video acpi_backlight=vendor
in your /etc/modprobe.d/options?

@Oliver

Or maybe instead add
acpi_backlight=vendor
as an kernel option?

No, I have not tried the "options video acpi_backlight=vendor" with the 2.6.27-11.23smb2 kernel.

@Stefan, regarding your comment 30 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/311716/comments/30) I just tried setting "options video acpi_backlight=vendor" in /etc/modules.d/options for kernel 2.6.27-11.22 and it did work. However, the brightest I can go feels like the lowest setting in 2.6.27-11.23 or 2.6.27-10. In a bright room the highest setting is barely readable. Also, there is no /proc/acpi/video/ directory so I can't really check the value am I at.

@Terrax

Just tried "options video acpi_backlight=vendor" in /etc/modprobe.d/options for kernel 2.6.27-11.23smb2 and I have the same behavior I just reported for 2.6.27-11.22 above. The brightness controls work but its not bright enough even at the max.

@Oliver,

if the previously released -11.23 was fine for you, please try acpi_backlight=video with my kernel. This should give you the default of the previous -11.23.

after the latest update (a day or two ago) i've experience two problems (one mentioned already)

1) my fn up+down don't change brightness
2) when gnome-power-manager dims the backlight, it dims slowly and clunkily and spikes my CPU usage to 100% and makes any playing audio skip

however adding acpi_backlight=video fixes this

but this is a major regression for me

i'm running 8.10 x64 on a dell xps m1530

@Stefan,

Yes, with "options video acpi_backlight=video" in /etc/modprobe.d/options using kernel 2.6.27-11.23smb2 the brightness works as it should.

I tried 2.6.27-11.23smb2 on my lenovo t61, which had brightness broken on -11.21 and -11.22. Brightness controls did not work at all with 2.6.27-11.23smb2; however, rebooting with "option thinkpad_acpi brightness_enable=1" caused the brightness controls to start working once again.

"options video acpi_backlight=video" in /etc/modprobe.d/options just gave me "kernel: [ 14.960104] video: Unknown parameter `acpi_backlight'" in my dmesg output, so I don't think that's an accurate test. I haven't tried rebooting with that option on the command line.

Attached is the output of dmesg, grep -r . /proc/acpi/video. and grep -Sr . /sys/devices/virtual/backlight/ for run where I gave the kernel no additional options.

And here's the result of those commands when I booted 2.6.27-11.23smb2 with the thinkpad_acpi brightness_enable option set.

And for one last spam, dmidecode output.

@Steve Beattie, could you also add the output of "grep -r . /proc/acpi/video" from the non-working case.

@Olivier, I am sorry to have told the wrong method. Though strange it made a difference. The module should fail to load in either case... Might I ask you to try out "acpi_backlight=video" as a kernel parameter and to remove that options entry and report whether this is ok as well? Sory again for the confusion.

@Steve, sorry I should have read the attachments all to the end. Got everything there.

This bug was fixed in the package linux - 2.6.28-4.10

---------------
linux (2.6.28-4.10) jaunty; urgency=low

  [ Andy Whitcroft ]

  * update kernel bootloader recommends: to prefer grub
    - LP: #314004
  * SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control
    - LP: #311716
  * SAUCE: test-suspend -- add the suspend test scripts
    - LP: #316419

  [ Colin Watson ]

  * Enable udebs for armel

  [ Tim Gardner ]

  * SAUCE: Dell laptop digital mic does not work, PCI 1028:0271
    - LP: #309508
  * Enable CIFS_XATTR=y and CONFIG_CIFS_POSIX=y
    - LP: #220658

 -- Tim Gardner <email address hidden> Thu, 08 Jan 2009 10:38:22 -0700

I checked dmesg and I do get:
[ 11.294297] video: Unknown parameter `acpi_backlight'
...
[ 11.485042] video: Unknown parameter `acpi_backlight'

in dmesg but it still makes a difference for my backlight behaviour since 2.6.27-11.23smb2 without the option doesn't work and with the option works.. I'm puzzled.

@Stefan
I tried adding acpi_backlight=video as a kernel parameter and it didn't do it. Brightness is broken in the same way I described earlier. I did that on 2.6.27-11.23smb2. This is strange since you said that it should be the behaviour of 2.6.23-11.23-generic which works fine for me. I attached dmesg output and will attach grep -r . /proc/acpi/video right after.

I noticed that you updated your PPA (http://launchpadlibrarian.net/21134071/linux_2.6.27-11.23smb4_source.changes), I'll give it a try right now and report my experience.

Thanks for all your efforts!

With 2.6.27-11.23smb4 brightness doesn't work. Same behavior as described before.

Some clarification for all. I think this went a bit confusing:
2.6.27-10: will have acpi and vendor backlight active
2.6.27-11: started to use only one of those (mostly because acer and sony vendor drivers are incorrect)
2.6.27-11.*smb: should behave like 2.6.27-10 by default

So when 2.6.27-10 worked for anyone, my test kernels should work the same. If -11 worked it has to be tweaked.

@Olivier, when I verified the module option te result was the acpi video module did not get loaded at all. This could explain that adding the module option help but not why it makes a difference to say vendor or video. After all in both cases the modules should not get loaded.
Regardless of this, I just noticed your laptop is a T61. In which case it told me my last patch was also rubbish since it should have detected this and have forced it to the right behavior. Let me try to fix this. I post back as soon as I get the kernels up.

New kernel has been compiled by now.

@Stefan, the brightness controls in the 2.6.27-11.23smb5 kernel are
working fine on my t61 without needing any arguments for the video or
thinkpad_acpi modules. Attached is the usual dmesg, /proc/acpi/video,
and /sys/class/backlight information.

Thanks!

As the latest code has now worked for another T61. I commited that code into a new kernel update.

This last kernel still works for me.

Kernel 2.6.28-4.10 fixes this problem for me in Jaunty.

For the first time the brightness keys work correctly on my Asus B50A laptop.

However in /var/log/messages these messages appear when pressing brightness up/down keys:

Jan 13 22:13:54 asus kernel: [ 181.876404] ACPI Error (dswstate-0097): Result stack is empty! State=ffff880128a22000 [20080926]
Jan 13 22:13:54 asus kernel: [ 181.876417] ACPI Exception (dsutils-0645): AE_AML_NO_RETURN_VALUE, Missing or null operand [20080926]
Jan 13 22:13:54 asus kernel: [ 181.876426] ACPI Exception (dsutils-0762): AE_AML_NO_RETURN_VALUE, While creating Arg 1 [20080926]
Jan 13 22:13:54 asus kernel: [ 181.876437] ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.VGA_.UPBL] (Node ffff88013f81de60), AE_AML_NO_RETURN_VALUE
Jan 13 22:13:54 asus kernel: [ 181.876588] ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_._Q0F] (Node ffff88013f842440), AE_AML_NO_RETURN_VALUE

@Stefan, Just to confirm you that 2.6.17-11.23smb5 works great on my T61! Thanks!

I'm on the Jaunty kernel Version: 2.6.28-4.10, and this last upgrade just broke ACPI backlight control on my EliteBook 8530w, which happens not to have any "vendor" module for backlight control. The /sys/class/backlight dir is now empty. Interestingly enough, I also have another laptop where the "video" module works, but gives only 3 brightness levels... but the toshiba_acpi module (in the kernels that happen to have it -- see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/261318 -- gives 5 or 7 or so. It seems like we should not blacklist the _BCM and _BCL modules entirely; we should instead prefer vendor drivers over the video module -- exactly the reverse of the way the upstream kernel seems to be going.

(curse the lack of an edit feature....)
More specifically, the EliteBook is using the x86-64 "generic" kernel.

@Stefan

Your newest kernel works fine :-)

2.6.27-11.24 solves my problem too.

newest kernel fixes my issue =]

2.6.27-11.23 had working brightness controls for me on my Lenovo R61 with Intel graphics.

2.6.27-11.24 does not sadly. The controls don't function at all.

2.6.27-11.22 did not work either. Again the controls did not function at all.

as far as I can remember kernel 2.6.27-11.21 and kernels prior to that were fine.

@Tom,
Can you please try "options thinpad_acpi brightness_enable=1" in
/etc/modprobe.d/options?

I assume you meant "options thinkpad_acpi brightness_enable=1"

That worked a treat though. All good now.

Cheers.

Tom, it might be good if you could add your
dmesg
grep -r . /proc/acpi/video/
cat /proc/acpi/DSDT

here (from the working -11.24 case). So we can look into that more closely. Thanks.

dsdt is an empty file, 0 bytes so I'm not sure about that one.

grep -r . /proc/acpi/video/ :

/proc/acpi/video/VID/DVI0/EDID:<not supported>
/proc/acpi/video/VID/DVI0/brightness:<not supported>
/proc/acpi/video/VID/DVI0/state:state: 0x1d
/proc/acpi/video/VID/DVI0/state:query: 0x00
/proc/acpi/video/VID/DVI0/info:device_id: 0x0300
/proc/acpi/video/VID/DVI0/info:type: UNKNOWN
/proc/acpi/video/VID/DVI0/info:known by bios: no
/proc/acpi/video/VID/CRT0/EDID:<not supported>
/proc/acpi/video/VID/CRT0/brightness:<not supported>
/proc/acpi/video/VID/CRT0/state:state: 0x0d
/proc/acpi/video/VID/CRT0/state:query: 0x00
/proc/acpi/video/VID/CRT0/info:device_id: 0x0100
/proc/acpi/video/VID/CRT0/info:type: UNKNOWN
/proc/acpi/video/VID/CRT0/info:known by bios: no
/proc/acpi/video/VID/LCD0/EDID:<not supported>
/proc/acpi/video/VID/LCD0/brightness:levels: 100 100 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 100
/proc/acpi/video/VID/LCD0/brightness:current: 100
/proc/acpi/video/VID/LCD0/state:state: 0x1f
/proc/acpi/video/VID/LCD0/state:query: 0x01
/proc/acpi/video/VID/LCD0/info:device_id: 0x0400
/proc/acpi/video/VID/LCD0/info:type: UNKNOWN
/proc/acpi/video/VID/LCD0/info:known by bios: no
/proc/acpi/video/VID/DOS:DOS setting: <7>
/proc/acpi/video/VID/POST:<not supported>
/proc/acpi/video/VID/POST_info:<not supported>
/proc/acpi/video/VID/ROM:<TODO>
/proc/acpi/video/VID/info:Switching heads: yes
/proc/acpi/video/VID/info:Video ROM: no
/proc/acpi/video/VID/info:Device to be POSTed on boot: no

dmesg is attached.

Its a proc file so it is always 0. But you have to be root to read it. It will be a binary blob.

works fine now :)

-----------------------------------------------------------------------
This email and any attachments are for the exclusive use of the intended
recipient(s), and may contain confidential, or otherwise privileged,
information. Kindly note that any unauthorised distribution, copying or use
of this communication or the information in this e-mail message is strictly
prohibited. If you have received this email erroneously, please notify the
sender immediately, and delete this email and any attachments from the
system. Although reasonable precautions have been taken to ensure the email
to be virus free, the sender accepts no responsibility for any loss or
damage arising from the presence of an infection.
P Help save the environment. Please print this email only if absolutely
necessary.
-----------------------------------------------------------------------

2009/1/16 Stefan Bader <email address hidden>

> Its a proc file so it is always 0. But you have to be root to read it.
> It will be a binary blob.
>
> --
> The slider brightness Applet has value inverted after the last update
> (2.6.27-11)
> https://bugs.launchpad.net/bugs/311716
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Linux Kernel: Incomplete
> Status in "linux" source package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Committed
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> The slider brightness Applet has value (%) inverted after the last update.
> When moves slider to up (plus) the screen brightness goes down. When moves
> slider to down (minus) the screen brightness goes up. I'm using version is
> 2.24.0-0ubuntu 8.1.
>
>
>
> SRU Justification
>
> Justification: ACPI brightness handling inverted or not functioning for
> several systems. acpi fixes committed to the proposed kernels expanded use
> of ACPI calls to handle brightness. This however exposes a number of
> systems which have broken ACPI brightness handling
>
> Impact: a number of laptops reported either inverted brightness handling or
> totally non-functional brightness control
>
> Fix Description: the fix adds an ACPI brightness validator which suppresses
> use of ACPI calls which are deemed broken.
>
> Patch:
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=096be4a4f49d781c0e7e8a54f9c0ff086570236a
>
> Risks: as we are supressing ACPI brightness support we may suppress it
> where it is required
>
> TEST CASE: see bug report
>

I am having the same problems that Tom has (same kernels result in same functionality) but with a Thinkpad X61s. I first noticed it a couple of days before Xmas and tried to upgrade my BIOS from the almost oldest to the current one. Did not make a difference though.

dmesg, /proc/acpi/video and dsdt are attached

BTW, the modprobe option does restore the functionality for me as well.

linux (2.6.27-11.24) intrepid-proposed; urgency=low

  [ Stefan Bader ]

  * Revert "SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control"
    - LP: #311716
  * SAUCE: acpi: Hack to enable video and vendor backlight implementations
    - LP: #311716
  * SAUCE: Force vendor backlight control on ThinkPad T61
    - LP: #311716

  [ Upstream Kernel Changes ]

  * Revert "thinkpad_acpi: fingers off backlight if video.ko is serving
    this functionality"
    - LP: #311716

Since this only affected -proposed, I close the intrepid task.

Please report back here if -11.24 still regresses for you. Thanks!

My earlier comments were all regarding -11.24. On a X61s vendor backlight control has to be used. Without the modprobe option I can write any value to the brightness controls in /sys or /proc w/o getting any changes.

GNOME brightness control worked in 2.6.28-4.10 but is no longer functional in 2.6.28-5.15.

Just two brightness settings are left and both are quite unusable.

This seems to be the corresponding changelog entry:

linux (2.6.28-5.13) jaunty; urgency=low

  [ Andy Whitcroft ]

  * Revert "SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control"

The above posted fix https://bugs.launchpad.net/ubuntu/intrepid/+source/linux/+bug/311716/comments/5 solves also the bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319654 on my x300.

@Stefan @Andy

Sorry guys. Its not all perfekt yet. My brightness control in kubuntu intrepid (kde 4.2 RC1) is inverted. That said, my brightness keys work perfektly. But when the laptop switch to performance mode, my brightness is decreased. When my laptop switch to battery mode, my laptops brightness increase. -> Inverted. But again, my brightness FN keys works perfektly.

You got an idea for a fix? :D

-----------

My computer:
Asus M50SA

Attacked my dmesg.

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