Acer: Cannot change brightness with 2.6.27-11+ kernel

I can confirm this on my ThinkPad (dmidecode outputs below).
Lenovo
7668CTO
ThinkPad X61s

The laptop is only a few days old. When running the Intrepid Live CD (which I assume is an older kernel than 2.6.27-11), backlight control worked fine. Since installing and updating to current kernel, however, I cannot control the backlight level at all. I have tried the function keys, the gnome brightness applet, and the xbacklight CLI application.

It seems that whatever brightness I set in the power management settings GUI takes effect when I boot fresh (i.e. full boot, not a resume from suspend or hibernate). xbacklight also reports that setting.

If I try to change the setting via the function keys, the OSD appears and the bar will move as it should... but the backlight doesn't actually adjust. If I try to change via the brightness applet slider, it moves up and down and holds position... but the backlight doesn't actually adjust. If I try to set a new level via xbacklight -set XX, xbacklight -get will report the value that I set (well, it's actually off by a smidge, but by and large it's the same number)... but the backlight doesn't actually adjust.

Is there anything else I can provide to help debugging?

Aside from the obvious battery life concern, having the wrong LCD backlight level for the current ambient lighting condition can be a huge eyestrain and can even render the laptop unusable in some cases. (this is my pleading to avoid getting set at 'low' importance)

I've just looked at the changelog for the 2.6.27 kernel, and there's no mention of brightness in patch 10 and 11. Maybe something completely different is interfering. There seems to be some patch with brightness in the patch 15 and 16. For an unknown reason I can't compile kernels, but if you can try to see if it gets solved.

I managed to compile the 2.6.27-19 kernel with patch and the brightness adjust works again. I ran into a error with the image file but it seems to work anyway.

Any idea when 2.6.27-16 or newer will make it into Intrepid? I'm not comfortable compiling my own kernel.

I have no idea, but i think there's an update each week.

I tried installing the generic 2.6.27-19 mainline kernel as provided by the kernel team (https://wiki.ubuntu.com/KernelMainlineBuilds - even I can install a .deb!). Brightness changes work like a charm. I wish a developer would chime in and let us know if/when we'll get a newer kernel, since this regression seems to have been fixed upstream.

I placed test kernels (for Intrepid -proposed) to http://people.ubuntu.com/~smb/bug333386/. Could someone try that version and verify that this enables brightness again?

I tested your kernel (x64) and as result i just can't get even the applet animation working. no news in brightness control either...

I'm in jaunty right now, and 2.6.28-11 (output of uname -r, but not on kernel.org?!) doesn't work too. the brightness applet shows it raise and goes down, but there's no change on the screen

Same thing in 2.6.29-1. I forgot to add last post that the key to raise the brightness doesn't send "±" anymore

I tested mainline kernel 27-19 and
brightness control WORKS again, sending the "±" when is enhancing.

By the way I can't use mainline kernel since i have restricted drivers to use :\

Jaunty-beta3: doens't solve anything, only applet works again.

@Marc

It's bad Jaunty-beta3 doens't solve the issue. Are they giving up solving this issue for our pc?

@Marc

It's bad Jaunty-beta3 doens't solve the issue. Are they giving up solving this issue for our pcs?

I'm still pretty new to linux, but first I would say that since it works again in 27-29, it should someday in the 28 series also. I don't really understand what's the problem with restricted drivers and a mainline kernel since sound and compiz effects worked with no problem when I tried. Maybe you could try to compile your own kernel.

To make sure it gets solved, I would guess we need to also check kernels between 27-14 and 27-19 to know where it was solved and send that info to the kernel team. I don't know if it works that way, I'm just guessing.

I have a problem with NVIDIA drivers and mainline kernel. It is also written in "limitations" that restricted drivers will not work...and that's what happened to me.

Did you try Jaunty and brightness worked? You said in your previous posts that:

>I'm in jaunty right now, and 2.6.28-11 (output of uname -r, but not on kernel.org?!) doesn't work too. the brightness
> applet shows it raise and goes down, but there's no change on the screen

>Same thing in 2.6.29-1.

It means it DOESN'T work in *.29 series. And your experience is like mine (jaunty beta3 doesn't solve the issue, only the applet).

I agree with you we have to find diff between the two versions and send to the team. It's annoying not being able to change brightness on a laptop (poor eyes).

First, no we do not give up on this, but things can get delayed by the bulk of other things.

@gidantribal, I saw that the test kernel did not help (or made things worse?). Could you post the dmesg from that kernel and 'grep -r . /proc/acpi/video'. Is the brightness changing when changing the values in the acpi brightness attribute?

The Jaunty kernel should not have the same specific problem as Intrepid. Intrepid has a bug where acer-wmi stops controlling brightness when there is no acpi brightness support. But it should do that when there _is_ support. This is fixed in Jaunty but apparently there are other issues as well.

In the 2.6.29-1 mainline kernel, on jaunty, "grep -r ./proc/acpi/video" gets stuck. I looked in that folder and there is no file in it. For he dmsg part, i' not sure what I have to do, but raising or lowering the brightness didn't change the output of dmsg

Marc-André Turcotte wrote:
> In the 2.6.29-1 mainline kernel, on jaunty, "grep -r ./proc/acpi/video"

You need the space between . and /proc/acpi/video otherwise the grep won't
work. The . is the search argument.

> gets stuck. I looked in that folder and there is no file in it. For he

If there are no files in that folder, that means there is no generic acpi
interface active. So the grep won't show anything anyway.

> dmsg part, i' not sure what I have to do, but raising or lowering the
> brightness didn't change the output of dmsg

The dmesg is useful to see whether acer-wmi gets loaded and probably what
messages it prints and maybe other things that might be interesting.

The backlight control for acer should be found under
/sys/devices/platform/acer-wmi/backlight/acer-wmi/
 From the code I am not completely sure how the nodes will be called, you can
help me with that. Does reading/writing there change the brightness?

grep gave me nothing like you said. Here's the dmesg log.

In the acer-wmi folder, there's only: a link to device folder, power folder, a link to subsystem folder, and 5 files I cannot read with gedit: actual_brightness, bl_power, brightness, max_brightness, uevent. Is there another way you think I could write something in these files?

Marc-André Turcotte wrote:
> gedit: actual_brightness, bl_power, brightness, max_brightness, uevent.
> Is there another way you think I could write something in these files?

Did you try "cat" to read and "echo value >file" to write? (It can be possible
you have to get root with sudo -i before (depending on the access rights).

cat works( you're making me learn very usefull command thanks) with everything but uevent and the output is like it should, but echo says permission denied for actual_brightness and max_brightness (I tried 1 for each) even under root. There was no brightness modification in the process

echo x > file says permission dedied even in ubuntu 8.10 (for each file). Values are all set to '9'.

echo x > file says permission denied even in ubuntu 8.10 (for each file). Values are all set to '9'.

bl_power gave me 0. Add sudo before it, or to be sure log in as root ( sudo su or sudo -su) to take out some permission denied

FWIW, I loaded up the Jaunty Beta i386 LiveCD (well... on a USB stick) and brightness now works perfectly on my laptop.

@unclben have you got an acer 6920G? How can it be possible mine doesn't still work on Jaunty beta? Maybe it's because mine is a x64 distribution? By the way it soulds quite weird!!! By the way i tried only by applet, maybe i should try directly by commands...

If I'm right, maybe we are missing something that get's installed with jaunty. We upgraded to jaunty, so we may miss some package. Maybe a clean install would solve this. I have the beta jaunty live cd 64x somewhere on my desktop. I'll try tonight to see if it's 64bit related.

Found that bug which is close to ours: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/280518. I don't know if it's a real duplicate, I'll let someone who knows what he's doing mark it.

Brightness doesn't change on my beta jaunty 64x livecd. There was a message telling that it did, but nothing really happened.

@gidantribal: See earlier in this bug report. I have a ThinkPad X61s, but I was having the same problem as Marc-Andre. I'm currently running the generic 2.6.27-19 kernel from the mainline kernel PPA, which solved the problem for me.

@Marc-André Turcotte: then let me understand.. with jaunty live cd x64 brightness is not solved at all. But I don't know if it is the same with i386 Jaunty? Did you get any working recent distribution?

@unclben: I'm happy it worked for thinkpad.. I know linux team was working on Thinkpad problems and bug has been fixed in Jaunty (see bug #311716). Unfortunately it's not the same for ACER 6920G.

It worked in intrepid with kernel 2.6.27-7 and -9 and stopped at -11(never tried -10). I don't know for i386. We have limited bandwidth, i'll download the i386 live cd on the 25th when our month start over

@Marc-André Turcotte: Ok, definitely we have the same defect (completely overlapped). Hope we will get rid of it.

found another repport for the 6920g, which one should be marked as duplicate of which one?
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/344640

the last report you posted is not related to our issue. it's about applet problems, not really about ACPI problem itself... in our case it doesnt work even from command line :\

Sorry, I have just read that bug's EDIT:

"EDIT: Now (after ~150MB of updates) on-screen notification for brightness works (as respons to Fn + > and <), but nothing happens with actual brightness level... Hope you'll fix it soon"

it seems to be our problem reflected to jaunty. that's why i am sure it's not solved for jaunty either. Maybe it can be considered as a duplicate... btw hope they will fix it soon...

I don't a working kernel anymore but what would happen if we copied file from /proc/acpi/video of a working kernel into a non-working one, where these files are non-existing?

maybe it will not change anything since kernel has not reference to them? no idea, btw...

Marc-André Turcotte wrote:
> I don't a working kernel anymore but what would happen if we copied file
> from /proc/acpi/video of a working kernel into a non-working one, where
> these files are non-existing?
>
That would not help/work. The proc filesystem is a virtual filesystem that
reflects kernel information. A driver has to create the files there.

Let me try to give more information. The big problem with backlight control is that there are many ways to do it. There is a generic implementation in the acpi subsystem and then there are several vendor specific drivers that do the same with all the different interfaces vendors came up with.
With Acer laptops this driver is acer-wmi (And a Thinkpad uses thinkpad-acpi, so any feedback from non-Acer users is nicely meant but, sorry, totally useless).
Back in Intrepid (when it was working for you) both drivers (the generic and the vendor specific) were allowed to touch the backlight. But this caused problems for some (values changed twice on each keypress). To fix that some patches from upstream were backported that would only allow the acpi or the vendor driver but not both. Beside of other problems, this also did change the acer-wmi driver the wrong way. Now the driver would only work if the acpi generic driver was also there. But this bug is fixed in Jaunty.

So for Acer, and sorry if this is mostly duplicated, at some point long Launchpad bugs get confusing:
1. With the old Intrepid kernel that works, which directories are populated there?
    (/proc/acpi/video, /sys/devices/platform/acer-wmi/backlight, both?)
2. Then going to Jaunty (as this has the acer-wmi bug fixed at least), which of the places above are there.

Can you do a "grep -r . <dir>" and "ls -la <dir>" for the existing directories above (put all the output into one file and add comments which is from which kernel. Then attach it here as an uncompressed file, that is the most convenient form to look at).
The first thing that has to work would be the change when echoing into one of those interfaces. If that doesn't work, then the brightness applet cannot work.

ls -la /proc/acpi/video:

totale 0
dr-xr-xr-x 2 root root 0 2009-04-25 14:12 .
dr-xr-xr-x 11 root root 0 2009-04-25 14:06 ..

________________________________________________________
ls -la /sys/devices/platform/acer-wmi/backlight:

totale 0
drwxr-xr-x 3 root root 0 2009-04-25 14:06 .
drwxr-xr-x 5 root root 0 2009-04-25 14:06 ..
drwxr-xr-x 3 root root 0 2009-04-25 14:06 acer-wmi

________________________________________________________
ls -la /sys/devices/platform/acer-wmi/backlight/acer-wmi/:

totale 0
drwxr-xr-x 3 root root 0 2009-04-25 14:06 .
drwxr-xr-x 3 root root 0 2009-04-25 14:06 ..
-r--r--r-- 1 root root 4096 2009-04-25 14:14 actual_brightness
-rw-r--r-- 1 root root 4096 2009-04-25 14:14 bl_power
-rw-r--r-- 1 root root 4096 2009-04-25 14:07 brightness
lrwxrwxrwx 1 root root 0 2009-04-25 14:14 device -> ../../../acer-wmi
-r--r--r-- 1 root root 4096 2009-04-25 14:07 max_brightness
drwxr-xr-x 2 root root 0 2009-04-25 14:14 power
lrwxrwxrwx 1 root root 0 2009-04-25 14:07 subsystem -> ../../../../../class/backlight
-rw-r--r-- 1 root root 4096 2009-04-25 14:07 uevent

________________________________________________________
I'VE THE IMPRESSION IT'S RECURSIVE.

Yeah, sysfs has a lot of recursion. So that confirms the wmi driver is at least registering itself. The interesting variables would be actual_brightness, brightness, max_brightness and maybe bl_power.
From one of the earlier posts, I take it that all values are 9. And even if you "sudo -i" and then "echo 4 >brightness" nothing changes? Both actual_brightness and brightness stay at 9? Is the anything logged to dmesg at that point?

yes, all values are 9 by default.

if i do
echo 4 >brightness

laptop brightness isn't affected, brightness file changes to 4, but actual_brightness file keeps 9 value.

Hey guys, is there any news concerning this bug? I still have crazily to *fakely* switch to Vista to change startup brightness... It's really annoying and a waste of time... moreover my eyes are suffering for this problem.

Setting this to fix-commited for Intrepid for the acer-wmi fix regarding the inverted logic. There still are those problems on Jaunty. Still have to sort out the problems on Jaunty.

@gidantribal,

the problem is still a bit elusive. The things you see on Jaunty sound like the laptop is not responding to the wmi-calls. I think you said this works on a vanilla 2.6.27 version. Does this also work on a vanilla 2.6.28 or .30? In any case I would be interested if you could check the acer-wmi brightnss interface there and tell me whether you can change brightness by echoing values into there or not.

I don't know what you mean with 'elusive' problem. To replicate it you just need an Acer Aspire 6920G or 6930G (my friend has the same problem) and a FRESH installation of Jaunty 9.04 x64. And here we posted everything asked...

As said before, in kernel 2.6.27-9 everything worked fine, applet+brightness commands. At least I remember I had to switch to 2.6.27-4 in order to change brightness. Now I don't have this kernel image anymore and have to use Vista. Anyway if you really need more feedback from the previous kernel images I'll install them and see (problem is that i have to disable Nvidia drivers and so on)...

How is it possible ACPI-WMI are installed (directories do exist) and at the same time there's no trace of effective brightness change? Maybe a diff between ACPI in 2.6.27-9 and in 2.6.28-11 should be done?

gidantribal wrote:
> I don't know what you mean with 'elusive' problem. To replicate it you
> just need an Acer Aspire 6920G or 6930G (my friend has the same problem)
> and a FRESH installation of Jaunty 9.04 x64.

This is the first "problem". I do not have one. I only got an Acer Aspire One
for which the maintainer of acer-wmi claims has a completely non-working wmi
interface. So it is not much help in problem determination.
Sure, you posted anything that was asked. Still it is sometimes hard to get the
picture together in the head.

> As said before, in kernel 2.6.27-9 everything worked fine,
> applet+brightness commands. At least I remember I had to switch to
> 2.6.27-4 in order to change brightness. Now I don't have this kernel
> image anymore and have to use Vista. Anyway if you really need more
> feedback from the previous kernel images I'll install them and see
> (problem is that i have to disable Nvidia drivers and so on)...

I can understand this is annoying and also painful. Unfortunately, with
interruptions and distractions, the picture only builds slowly and then later
the are questions coming up. Like: was the sysfs interface working whith
2.6.27-9 or was something else in control. Wouldn't a live-cd run work? This
should be 2.6.27-7. That would safe you the hassle of installing/reconfiguring.

> How is it possible ACPI-WMI are installed (directories do exist) and at
> the same time there's no trace of effective brightness change? Maybe
> diff between ACPI in 2.6.27-9 and in 2.6.28-11 should be done?

Depending on which of the interfaces are used (another thing that just appeared
which might be good to know "cat /sys/devices/platform/acer-wmi/interface") the
driver seems to write to the embedded controller or uses the acpi wmi
interface. wmi.c did not change much ec.c did while it is more likely that the
wmi interface is used. acpi in general changed a lot. As the acer-wmi driver
did not change much (only on places that relate to wireless and 3g), that would
require something in the interface itself to be changed. But that does not seem
to have happened. Also this should then have more impact on other drivers as well.

The driver also seems to have a debugfs interface, though the AAO does not
anything there (maybe because it is broken). After "mounr -tdebugfs none
/sys/kernel/debug" you would find an acer-wmi/devices there.

--

When all other means of communication fail, try words!

Thank you for the quick reply. I'll try my best to get rid of this bug...

cat /sys/devices/platform/acer-wmi/interface:
WMID

>Like: was the sysfs interface working whith
>2.6.27-9 or was something else in control. Wouldn't a live-cd run work? This
>should be 2.6.27-7. That would safe you the hassle of installing/reconfiguring.
How to test which sysfs interface is working? i'll download a liveCD and try...

I am currently travelling, so responses can be slow.

> cat /sys/devices/platform/acer-wmi/interface:
> WMID
>
Thanks, so that rules out the other interfaces.

> How to test which sysfs interface is working? i'll download a liveCD and try...
>

When, using the Intrepid liveCD, brightness control works from the GUI, try to
echo values into the /sys/.../acer-wmi/brightness file. If that changes the
screen brightness as well, then this proves that the acpi wmi interface has
broken at least for these acer laptops.

Accepted linux into intrepid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Which package?

> Accepted linux into intrepid-proposed, the package will build now and be available in a few hours.
> Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for
> documentation how to enable and use -proposed. Thank you in advance!

I tried to install the proposed linux image and all other packages as well: still NO GOOD NEWS. Problem still present (no responsive brightness, only applet).
Here you have results:
__________________________________________
cat /sys/devices/platform/acer-wmi/interface:
WMID
__________________________________________
ls -la /proc/acpi/video:
totale 0
dr-xr-xr-x 2 root root 0 2009-06-06 00:13 .
dr-xr-xr-x 11 root root 0 2009-06-06 00:06 ..
__________________________________________

ls -la /sys/devices/platform/acer-wmi/backlight:
totale 0
drwxr-xr-x 3 root root 0 2009-06-06 00:06 .
drwxr-xr-x 5 root root 0 2009-06-06 00:06 ..
drwxr-xr-x 3 root root 0 2009-06-06 00:06 acer-wmi
__________________________________________

ls -la /sys/devices/platform/acer-wmi/backlight/acer-wmi/:
totale 0
drwxr-xr-x 3 root root 0 2009-06-06 00:06 .
drwxr-xr-x 3 root root 0 2009-06-06 00:06 ..
-r--r--r-- 1 root root 4096 2009-06-06 00:15 actual_brightness
-rw-r--r-- 1 root root 4096 2009-06-06 00:15 bl_power
-rw-r--r-- 1 root root 4096 2009-06-06 00:07 brightness
lrwxrwxrwx 1 root root 0 2009-06-06 00:15 device -> ../../../acer-wmi
-r--r--r-- 1 root root 4096 2009-06-06 00:06 max_brightness
drwxr-xr-x 2 root root 0 2009-06-06 00:15 power
lrwxrwxrwx 1 root root 0 2009-06-06 00:06 subsystem -> ../../../../../class/backlight
-rw-r--r-- 1 root root 4096 2009-06-06 00:06 uevent
__________________________________________

brightness, actual_brightness, etc have 9 value by default....
If i do
echo 4 > brightness
laptop brightness isn't affected, brightness file changes to 4, but actual_brightness file keeps 9 value.

If you can also provide the same data for a working case (either with a kernel from https://wiki.ubuntu.com/KernelMainlineBuilds or with the last working kernel) this would help to determine which part broke (and maybe got fixed upstream).

Okay, I'm providing required data from WORKING, LIVE version of Ubuntu 8.10:
______________________________
uname -a:
  Linux ubuntu 2.6.27-4-generic #1 SMP Wed Sep 24 01:29:06 UTC 2008 x86_64 GNU/Linux
______________________________
cat /sys/devices/platform/acer-wmi/interface:
  WMID
______________________________
ls -la /proc/acpi/video:
  totale 0
  dr-xr-xr-x 3 root root 0 2009-06-10 15:29 .
  dr-xr-xr-x 11 root root 0 2009-06-10 15:22 ..
  dr-xr-xr-x 10 root root 0 2009-06-10 15:29 GFX0
______________________________
ls -la /sys/devices/platform/acer-wmi/backlight:
  ls: impossibile accedere a /sys/devices/platform/acer-wmi/backlight: Nessun file o dir..)
  (sorry, it's italian and it means "NO SUCH FILE OR DIRECTORY")
______________________________

ls -la /sys/devices/platform/acer-wmi/backlight/acer-wmi/:
  (same as previous directory, no such file or directory)
______________________________

Moreover, i found these files related to BRIGHTNESS (for complete list see attached log):
  /etc/acpi/thinkpad-brightness-down.sh
  /etc/acpi/thinkpad-brightness-up.sh
  /etc/acpi/video_brightnessdown.sh
  /etc/acpi/video_brightnessup.sh
  /etc/acpi/events/asus-brightness-down
  /etc/acpi/events/asus-brightness-up
  /etc/acpi/events/panasonic-brightness-down
  /etc/acpi/events/panasonic-brightness-up
  /etc/acpi/events/sony-brightness-down
  /etc/acpi/events/sony-brightness-up
  /etc/acpi/events/thinkpad-brightness-down
  /etc/acpi/events/thinkpad-brightness-up
  /etc/acpi/events/tosh-brightness-down
  /etc/acpi/events/tosh-brightness-up
  /etc/acpi/events/video_brightnessdown
  /etc/acpi/events/video_brightnessup
  /etc/acpi/resume.d/50-tosh-restore-brightness.sh
  /etc/acpi/suspend.d/50-tosh-save-brightness.sh
  /etc/laptop-mode/conf.d/lcd-brightness.conf
  /usr/lib/gnome-power-manager/gnome-brightness-applet
  /usr/lib/hal/scripts/hal-system-lcd-get-brightness
  /usr/lib/hal/scripts/hal-system-lcd-set-brightness
  /usr/lib/hal/scripts/linux/hal-system-lcd-get-brightness-linux
  /usr/lib/hal/scripts/linux/hal-system-lcd-set-brightness-linux
  /usr/share/laptop-mode-tools/modules/lcd-brightness

and for instance, inside video_brightnessdown.sh, you can see the following script:
  #!/bin/sh
  test -f /usr/share/acpi-support/key-constants || exit 0
  . /usr/share/acpi-support/key-constants
  acpi_fakekey $KEY_BRIGHTNESSDOWN

but if I execute this script it doesn't do anything. I dunno what BRIGHT-FN keys are mapped to, but they DO work in this kernel.

Now _that_ is a step forward! Stupid me. So not the wmi driver is broken. It was not used before. But the acpi driver does not handle the laptop anymore. Ok, one more thing then. Regardless from which kernel. Please add the output of "sudo acpidump -o acpidump.txt". Thanks.

Ok, attached you can find the requested output.
Please note this is from *NON WORKING* 9.04 kernel img (Linux gidan-notebook 2.6.28-11-generic x86_64 GNU/Linux).

from a custom 2.6.30-rc8 kernel in Xorg.0.log:

(WW) NVIDIA(0): ACPI: Error: Unable to find the DOS (Enable/Disable output
(WW) NVIDIA(0): switching) file path under /proc/acpi/video. The NVIDIA X
(WW) NVIDIA(0): driver will not be able to respond to ACPI display change
(WW) NVIDIA(0): hotkey events.

I have the lattest nvidia driver (185.18). In case it wasn't clear, brightness doesn't work.

@Marc-André Turcotte :
I don't know what you want to point out exactly. We already know brightness works under kernel "2.6.27-4-generic" and doesn't under jaunty 9.04 (i.e. kernel 2.6.28-11). if we don't fix this bug it will not be solved in any kernel > 2.6.28-11 ...

@gidantribal:
It was more to state that it was not fixed in that one. I'm trying to give the more information I can.

@Marc-André Turcotte:
I thought it was to point out brightness problem was related to nvidia drivers. My fault, sorry.

Please let me know if I can help debugging this, or provide more information. This problem also exists on a Thinkpad T61. Just can't seem to change the brightness. Period.

The same here..it's one of the worst bug I'm affected... I still have to switch to *vista* just to change brightness... it's a shame... :\

FYI, 2.6.28-13-generic x86_64 kernel didnt solve this issue yet.

@gidantribal, no, that would require to know what to change. So far I know the in the working kernels, there was a GFX0 object in /proc/acpi/video (and likely that hat the brightness control). The acpidump shows that there should be the required methods to detect the brightness control (although the method to return the brightness levels is incorrect as it omits the definitions for the ac and battery brightness). So I created kernel packages that will print more debug messages.You can find them at: http://people.ubuntu.com/~smb/bug333386/
I tried to supply a modified DSDT but re-compilation of the disassembled DSDT fails for some strange reason.

ok i will test them asap...

Here you can find attached the requested output of 'acpidump' from your modified kernel image.

Linux gidan-notebook 2.6.28-13-generic #44bug333386v1 SMP Wed Jun 24 10:29:48 CEST 2009 x86_64 GNU/Linux

I have the same problem with Lenovo Ideapad Y450 laptop. With Jaunty Live CD, the brightness control worked. But after installation and update, it doesn't wok anymore. The file "/proc/acpi/video/VGA/LCD/brightness" is updated with the Fn+arrow_keys, but the bightness just don't change.

If any input is required, I can help too.

An update.

I was using the nvidia proprietary driver. After removing this driver and instead using the open source driver, the brightness control works. I would still want to use the nvidia driver as the open source driver does not give me the full resolution. Seems my case is similar to gidantribal's. Hope to see a solution soon!

@gidantribal, Err, sorry, my fault of not being specific enough. The acpidump dumps your ACPI BIOS, so it will remain the same, regardless of the kernel. What I was interested in was the dmesg output which contains the messages from the boot.

@Jaya, while the effects are similar, I'd like to keep different Laptop vendors separate as they use different vendor methods to get backlight control. For ThinkPads (Ideapads might be similar) you often seem to get better results by forcing the kernel to use the vendor method. For that you need: "acpi_backlight=vendor" on the kernel command line and "options thinkpad_acpi brightness_enable=1" in a file in /etc/modprobe.d. If that does not work, can you please open a new bug with "ubuntu-bug linux"?

Thanks for the suggestions, I will try setting the kernel command line.

I found another solution that worked for me. With my nvidia driver enabled, I tried running the script from,
http://www.thouret.co.uk/blog/2008/12/shell-script-for-linux-nvidia-kernel-module-laptop-brightness-workaround/

and it changes the brightness. Though it is temporary solution, gives me peace of mind till the issue is resolved!

I can try creating another bug, but will that be classified as duplicate to this?

It doesn't help with our acer's, I've just tryed, so It should not be classified as a duplicate.

The option suggested by Stefan did not work for me. So I will make a new bug report.

@Stefan Bader:
Okay, now i'm posting all DMESG output with your modified kernel version. Please let me know what else do you need.

Hm, with that info I understand what is going on. But I cannot see how Linux could safely make this working. The problem is that graphic devices are detected by certain methods in the ACPI BIOS. From all available alternatives only _DOS and _DOD methods are defined for the GFX0 device. So far, so good. Unfortunately the GFX0 definition contains an _ADR element that claims the related PCI device would be device number 2. However the dmesg shows that this should be device number 1 (you can verify that with "lspci|grep 00:02.0"). The code to check for a physical pci device being present was added around the time when brightness controll stopped working for you.
Though it might be possible to add code to skip this test to Jaunty, this just would hit you again with Karmic and later. I would have provided a modified DSDT to test but for some reason the acpi compiler is not able to recompile the disassembled DSDT.
On the Acer site I just saw that there is an updated BIOS available (1.14 dated 2009/06/03). Unfortunately I saw nowhere what exactly it should change but it might be worth a try.

this sounds really bad... as far as I understood, there's supposed to be a bug on acer bios? that sounds quite bad... is it possible kernel code that discriminates the right PCI device is buggy? isn't it possible to perform any action but a simple workaround?

I believe the BIOS is buggy with that respect (not sure why the DSDT compiler
freaks out but that might be a different issue). I manually looked up those
values in the DSDT you provided, so based on that data the kernel takes the
right steps. The question is whether the new BIOS fixes this or whether this
needs a general exemption for being a special (known broken) machine.
It seemed to have worked in the past. There certainly can be a solution to
Jaunty (though it needs a kernel change), but that cannot be the sole solution
as it will likely break with every newer kernel. I cannot exactly say how to
proceed from here. But I try to ask around. Meanwhile to complete the data
gathered here, could you add the output of "sudo lspci -vvvnn" to the bug
report please?

Ok, I can post the results, does it make the difference if I post results
from the 'normal' distribution and not from yours (modified)? That's so
weird, so previously it was working because no programmatic check was done
by DSDT? I agree, new bios should be tried, but since it's a critical step
and I have critical projects with upcoming deadlines and can't afford the
risk... next time I'll use warranty I will ask for an update...

2009/7/7 Stefan Bader <email address hidden>

>
> I believe the BIOS is buggy with that respect (not sure why the DSDT
> compiler
> freaks out but that might be a different issue). I manually looked up those
> values in the DSDT you provided, so based on that data the kernel takes the
> right steps. The question is whether the new BIOS fixes this or whether
> this
> needs a general exemption for being a special (known broken) machine.
> It seemed to have worked in the past. There certainly can be a solution to
> Jaunty (though it needs a kernel change), but that cannot be the sole
> solution
> as it will likely break with every newer kernel. I cannot exactly say how
> to
> proceed from here. But I try to ask around. Meanwhile to complete the data
> gathered here, could you add the output of "sudo lspci -vvvnn" to the bug
> report please?
>
> --
> Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Confirmed
> Status in linux in Ubuntu Intrepid: Fix Committed
> Status in linux in Ubuntu Jaunty: In Progress
>
> Bug description:
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

I can understand that. No it makes no difference from which kernel this is run.
To be exact, it was somehow working as Linux did not check the information in
the DSDT close enough. So GFX0 might be the right device to look at but it
points to another pci device (supposedly one that does not exist) and newer
kernels back off then. As I understand the issue, the problem is that in
general the same ACPI BIOS is used for all different hardware configurations.
So often it contains several video devices but only some are really present.
For that reason the kernel code was added. In this case it seems to have broken
a case which worked before.

After talking with Matthew about this, there probably is a way to relax the check for available video devices. I added those changes and build a test kernel which can be found at http://people.ubuntu.com/~smb/bug333386/ (the v2 versions). Maybe you could try to install this kernel and see whether this makes a difference. Thanks.

I updated the bios to 1.14 (last) version. NO effects on brightness. Attached you can find lspci output.

gidantribal wrote:
> I updated the bios to 1.14 (last) version. NO effects on brightness.
> Attached you can find lspci output.

Thanks for confirming that this has no change. Did you see my post with the
test kernel? This has a good chance of getting your brightness working again
and it would be something we need to let upstream know, if it does. Thanks

the v2 versions of kernel posted at http://people.ubuntu.com/~smb/bug333386/ does not seem to change anything in brightness control (*unfortunately*).

please find attached the DMESG output with modified kernel. let me know if I can help you anyhow.

Doh, it seems there was another check somewhere else to prevent getting to the other check. I changed that as well and made a v3 version. I hope this was the last place which restricts the stuff from working.

@Stefan Bader
I'm glad to inform you that now brightness *DO* react to brightnessup and brightnessdown scripts (/etc/acpi/video_*
) and seems fixed. The second check was the problem, definitely =).
Also "brightness gnome applet" and "brightness gnome control" (as gnome panel add-on) wok well.

Btw, there is a secondary issue with FN keys. Even if brightness reacts well to scripts, FN+keys seem broken. Let me explain what happens:

[Initial status of the machine is BRIGHTNESS_MAX]
If I press FN+BRIGHTNESS_DOWN just once
       > It increases (correctly) to BRIGHTNESS_MAX-1 but then *immediately*
           goes to BRIGHTNESS_MIN (wrong)

[Initial status of the machine is BRIGHTNESS_MIN]
If I press FN + BRIGHTNESS_UP just once
       > It increases to BRIGHTNESS_MAX+1 (correctly) but then immediately
           increases again, so finally it goes to BRIGHTNESS_MAX+2 (wrong)
If I press FN + BRIGHTNESS_UP again
       > It returns to BRIGHTNESS_MAX+1 (wrong)

The only way to increase brightness with the FN keys it's to keep FN+BRIGHTNESS_UP pressed for long, so that in the end it raises BRIGHTNESS_MAX level.

It's like if there's a wrong mapping with the keys or, worse, a wrong key event management. Anyway it has no link with the main issue, which seems completely solved.

I reported that partial success back. To get that into Jaunty I need to come up with a patch that only matches specific laptops. Can you post me the output from your "sudo demidecode", please?

For the strange behavior of the keys: Was this happening before as well or only with the never kernels? I cannot say for sure, but there is another problem in these acpi bios definitions, which is that the spec says brightness level definitions contain two special values at the beginning. The brighness for ac and battery mode. The definitions for this laptop do not have these values and immediately enumerate the brightness levels.

Here's my dmidecode output. I experienced wrong value change with brigthness too, but it's a start

I am running kubuntu 9.10 alpha 3 on Lenovo 3000 N100 and I can't change the brightness of the screen.

When trying to change it using the fn keys, dmesg says:
ACPI Failed to switch the brightness

Lenovo is quite a different working site. You can try "acpi_backlight=vendor" on the grub command line, plus

options thinkpad_acpi brightness_enable=1

somewhere in /etc/modprobe.d

Though if that does not help, please open another bug as the solution needs a different approach than for the Acers. Thanks.

@Marc-André, thanks for the dmidecode. I hope I get time soon to work on this.

Here's my dmidecode output, hope it helps. Great job done so far btw!

Ps. Now kernel version is *.14 but I can't update if I want to keep my notebook ready for debug.. how can I proceed? a new modified kernel version could be a temporary solution, but maybe it would be better to just have a modified module version.

I think from the debugging point you could update, but as I did not have time to work on a special patch, you would be back to no brightness control. Which probably matters more.

yes, i'll keep the patched version until issue is solved i think.

I finally found time to think of a version that might be acceptable to get into Jaunty. I placed the kernels at the usual location at http://people.canonical.com/~smb/bug333386/. In theory this should detect your system, print a "Using less strict video detection" message in dmesg and the brightness control should work. If this fails (because I messed up the check) there is a second way by using "acpi_video_strict_detect=0" as a boot parameter. Please let me know how this works for you.

oki i'm going to install it

brightness works out of the box (without boot parameter) with your proposed kernel... here DMESG detail:
[ 8.769760] acer-wmi: Acer Laptop ACPI-WMI Extras
[ 8.770046] ACPI: Using less restrictive video detection
[ 8.770047] acer-wmi: Brightness must be controlled by generic video driver
[ 8.770119] acer-wmi: software RFKILL enabled

Anyway FN-keys issue is still present, the same as before:

[Initial status of the machine is BRIGHTNESS_MAX]
If I press FN+BRIGHTNESS_DOWN just once
       > It increases (correctly) to BRIGHTNESS_MAX-1 but then *immediately*
           goes to BRIGHTNESS_MIN (wrong)

[Initial status of the machine is BRIGHTNESS_MIN]
If I press FN + BRIGHTNESS_UP just once
       > It increases to BRIGHTNESS_MAX+1 (correctly) but then immediately
           increases again, so finally it goes to BRIGHTNESS_MAX+2 (wrong)
If I press FN + BRIGHTNESS_UP again
       > It returns to BRIGHTNESS_MAX+1 (wrong)

[...] view old message for details...

Thanks for the quick test. I'll try to get that into the default kernel then.
Unfortunately for the problem with the key I would not put too much hope into
getting it fixed in Jaunty. Karmic is nearing its Beta and more effort will go
into that.

Could you explain to me what should I do to install de kernel?
Please think in a step by step explanation.
Thanks,

Pablo Ferrari

2009/8/27 Stefan Bader <email address hidden>

> I finally found time to think of a version that might be acceptable to
> get into Jaunty. I placed the kernels at the usual location at
> http://people.canonical.com/~smb/bug333386/. In theory this should
> detect your system, print a "Using less strict video detection" message
> in dmesg and the brightness control should work. If this fails (because
> I messed up the check) there is a second way by using
> "acpi_video_strict_detect=0" as a boot parameter. Please let me know how
> this works for you.
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Confirmed
> Status in linux in Ubuntu Intrepid: Fix Committed
> Status in linux in Ubuntu Jaunty: In Progress
>
> Bug description:
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

Sorry, when I saw it was a .deb file I had already sent de message.
I had no problem to install and it worked fine.
I have an Acer Aspire 5738

Fn keys work too, but I found a couple of isues:
* when using the Fn keys and you're near the less bright side it moves very
slowly (doesn't occur near the more bright side)
* It has a curious behaviour when connecting and disconnecting the power
adapter: sometimes changes brightness, sometimes not. Sometimes changes too
much, sometimes just to the half bright. And sometimes it changes even if
you don't do anything.

I hope it would help. I'm not an expert user, buy I offer my simple-user
experience.

Thanks to all of you

2009/8/28 Pablo Javier Ferrari Ferrando <email address hidden>

> Could you explain to me what should I do to install de kernel?
> Please think in a step by step explanation.
> Thanks,
>
> Pablo Ferrari
>
>
>
>
> 2009/8/27 Stefan Bader <email address hidden>
>
> I finally found time to think of a version that might be acceptable to
>> get into Jaunty. I placed the kernels at the usual location at
>> http://people.canonical.com/~smb/bug333386/. In theory this should
>> detect your system, print a "Using less strict video detection" message
>> in dmesg and the brightness control should work. If this fails (because
>> I messed up the check) there is a second way by using
>> "acpi_video_strict_detect=0" as a boot parameter. Please let me know how
>> this works for you.
>>
>> --
>> Acer: Cannot change brightness with 2.6.27-11+ kernel
>> https://bugs.launchpad.net/bugs/333386
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>> Status in “linux” package in Ubuntu: Confirmed
>> Status in linux in Ubuntu Intrepid: Fix Committed
>> Status in linux in Ubuntu Jaunty: In Progress
>>
>> Bug description:
>> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
>> backlight brightness anymore. In the latest kernel, it seems there's no more
>> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
>> still change brightness. I'm new to linux so if you need information give me
>> the command to run. It's an acer 6920G laptop.
>>
>
>

@Pablo: can you experience the same behaviour of FN keys I experienced (please see my comment above [#88] on FN keys)...... Have you got an Acer Aspire 6920G?

@Stefan Bader:
I'm glad to hear this patch will be put in the default kernel... it means it will be included also in karmic, doesn't it?
About FN keys... do you mean it will be faced in Karmic as new bug and just ignored in jaunty?

Not automatically as it is in the process at a time when it not gets into
2.6.31 final but rather 2.6.32. But I currently try to get it pro-actively into
Karmic as well.
The function keys might probably work. I did see that your BIOS definitions
have another bug with the brightness levels, which I believe is handled in
Karmic (normally the first two values are supposed to be the levels for on-ac
and on-battery and are handled differently, but your bios just has real levels
in it). So I would suggest to try out karmic (not yet but next alpha or beta).
If it has brightness control but still the FN-key problem, it would be good to
open a new bug for that. The problem is different and the more specific we are
in a bug, the better to handle it.

Pablo wrote:
> Sorry, when I saw it was a .deb file I had already sent de message.
> I had no problem to install and it worked fine.
> I have an Acer Aspire 5738

Thanks for trying, too. Just wondering: did it work right away or had you to
use the command line option? (as I have not encoded a 5738).

@gidantribal:

@Pablo: can you experience the same behaviour of FN keys I experienced
> (please see my comment above [#88] on FN keys)...... Have you got an
> Acer Aspire 6920G?
>
> I didn't experience the same behaviour you told. Fn keys work fine but with
a very small increment on each key-stroke, which makes it quite irritating
(it's worse while you go to the less-bright side), but I've managed whith
the panel bright-control.
I've found strange behaviour when connecting and disconnecting the
power-adapter, but just don't care about this:

@Stefan:

Thanks for trying, too. Just wondering: did it work right away or had you to
> use the command line option? (as I have not encoded a 5738).
>

It worked right away. Thanks

Hi all, I have the same problem you have described with my Aspire 8930g. Brightness works with Intrepid beta live cd (2.6.27-4) but doesn't works with Jaunty live cd. I've tried also with Sabayon and Arch with post 2.6.27 kernel and it doesn't work, so it seems that it's a kernel issue and it has to be fixed in the vanilla sources.
I haven't tried the patched kernel yet because now I have Arch installed.
So I ask: will this bug be fixed only in Ubuntu version of the kernel or also in the official Linux sources?

Sorry for the status change, i'm new in launchpad :\

With a similar BIOS problem, brightness will not work on kernels after 2.6.28 and before the submitted patch hits upstream. It has been submitted but probably gets not included before 2.6.32

The fixed kernel worked for me too, without command line option at boot! (Jaunty, aspire 8930g)
Thank you

I move this to "won't fix" for Intrepid as that release is too old to justify a backport effort.

This bug was fixed in the package linux - 2.6.31-10.30

---------------
linux (2.6.31-10.30) karmic; urgency=low

  [ Amit Kucheria ]

  * [Config] Enable CONFIG_USB_DEVICEFS
    - LP: #417748
  * [Config] Populate the config-update template a bit more

  [ Andy Whitcroft ]

  * rebase to v2.6.31-rc9
  * [Config] update configs following rebase to v2.6.31-rc9
  * [Config] update ports configs following rebase to v2.6.31-rc9

  [ Colin Ian King ]

  * SAUCE: wireless: hostap, fix oops due to early probing interrupt
    - LP: #254837

  [ Jerone Young ]

  * [Upstream] ACPI: Add Thinkpad T400 & Thinkpad T500 to OSI(Linux)
    white-list
    - LP: #281732
  * [Upstream] ACPI: Add Thinkpad X200, X200s, X200t to OSI(Linux)
    white-list
    - LP: #281732
  * [Upstream] ACPI: Add Thinkpad X300 & Thinkpad X301 to OSI(Linux)
    white-list
    - LP: #281732
  * [Upstream] ACPI: Add Thinkpad R400 & Thinkpad R500 to OSI(Linux)
    white-list
    - LP: #281732
  * [Upstream] ACPI: Add Thinkpad W500, W700, & W700ds to OSI(Linux)
    white-list
    - LP: #281732

  [ John Johansen ]

  * SAUCE: AppArmor: Fix profile attachment for regexp based profile names
    - LP: #419308
  * SAUCE: AppArmor: Return the correct error codes on profile
    addition/removal
    - LP: #408473
  * SAUCE: AppArmor: Fix OOPS in profile listing, and display full list
    - LP: #408454
  * SAUCE: AppArmor: Fix mapping of pux to new internal permission format
    - LP: #419222
  * SAUCE: AppArmor: Fix change_profile failure
    - LP: #401931
  * SAUCE: AppArmor: Tell git to ignore generated include files
    - LP: #419505

  [ Stefan Bader ]

  * [Upstream] acpi: video: Loosen strictness of video bus detection code
    - LP: #333386
  * SAUCE: Remove ov511 driver from ubuntu subdirectory

  [ Tim Gardner ]

  * [Config] Exclude char-modules from non-x86 udeb creation
  * SAUCE: Notify the ACPI call chain of AC events
  * [Config] CONFIG_SATA_VIA=m
    - LP: #403385
  * [Config] Build in all phylib support modules.
  * [Config] Don't fail when sub-flavour files are missing
    - LP: #423426
  * [Config] Set CONFIG_LSM_MMAP_MIN_ADDR=0
    - LP: #423513

  [ Upstream ]

  * Rebased against v2.6.31-rc9

 -- Andy Whitcroft <email address hidden> Mon, 07 Sep 2009 11:33:45 +0100

This bug was fixed in the package linux - 2.6.27-14.41

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

  [ Stefan Bader ]

  * Revert "SAUCE: input: Blacklist digitizers from joydev.c"
    - LP: #300143

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

  [ Amit Kucheria ]

  * Disable DEVKMEM for all archs on Intrepid
    - LP: #354221
  * SAUCE: Quirk for BT USB device on MacbookPro to be reset before use
    - LP: #332443

  [ Andy Isaacson ]

  * LIRC_PVR150: depends on VIDEO_IVTV
    - LP: #341477
  * SAUCE: FSAM7400: select CHECK_SIGNATURE
    - LP: #341712

  [ Andy Whitcroft ]

  * SAUCE: hotkey quirks for various Zepto Znote and Fujitsu Amilo laptops
    - LP: #330259
  * SAUCE: unusual devs: add an entry for the ScanLogic SL11R-IDE 0.78
    - LP: #336189

  [ Anton Veretenenko ]

  * SAUCE: sony-laptop: add support for Sony Vaio FW series function/media
    keys
    - LP: #307592

  [ Ayaz Abdulla ]

  * SAUCE: forcedeth: msi interrupt fix
    - LP: #288281

  [ Chuck Short ]

  * SAUCE: [USB] Unusual Device support for Gold MP3 Player Energy
    - LP: #125250

  [ Ike Panhc ]

  * squashfs: correct misspelling
    - LP: #322306
  * SAUCE: Fixing symbol name in HECI module
    - LP: #336549
  * Copy header files for various kernel media driver
    - LP: #322732

  [ Stefan Bader ]

  * SAUCE: vgacon: Return the upper half of 512 character fonts
    - LP: #355057
  * SAUCE: input: Blacklist digitizers from joydev.c
    - LP: #300143

  [ Upstream Kernel Changes ]

  * libata: make sure port is thawed when skipping resets
    - LP: #269652
  * x86-64: fix int $0x80 -ENOSYS return
    - LP: #339743
  * rt2x00: Fix race conditions in flag handling
    - LP: #258985
  * USB: cdc-acm: Add another conexant modem to the quirks
    - LP: #323829
  * Bluetooth: Add fine grained mem_flags usage to btusb driver
    - LP: #268502
  * Bluetooth: Handle bulk URBs in btusb driver from notify callback
    - LP: #268502
  * Bluetooth: Submit bulk URBs along with interrupt URBs
    - LP: #268502
  * hwmon: (abituguru3) Match partial DMI board name strings
    - LP: #298798
  * x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
    - LP: #292619
  * sis190: add identifier for Atheros AR8021 PHY
    - LP: #247889
  * ath9k: implement IO serialization
    - LP: #373034
  * ath9k: AR9280 PCI devices must serialize IO as well
    - LP: #373034
  * acer-wmi: fix regression in backlight detection
    - LP: #333386

 -- Stefan Bader <email address hidden> Wed, 26 Aug 2009 11:48:11 +0200

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

---------------
linux (2.6.28-15.52) jaunty-proposed; urgency=low

  [ Stefan Bader ]

  * Revert "SAUCE: ACPI: Populate DIDL before registering ACPI video device
    on Intel"
    - LP: #423296
  * SAUCE: Allow less restrictive acpi video detection
    - LP: #333386

  [ Upstream Kernel Changes ]

  * include drivers/pci/hotplug/* in -virtual package
    - LP: #364916
  * ext4: don't call jbd2_journal_force_commit_nested without journal
    - LP: #418197
  * ext4: fix ext4_free_inode() vs. ext4_claim_inode() race
    - LP: #418197
  * ext4: fix bogus BUG_ONs in in mballoc code
    - LP: #418197
  * ext4: fix typo which causes a memory leak on error path
    - LP: #418197
  * ext4: Fix softlockup caused by illegal i_file_acl value in on-disk
    inode
    - LP: #418197
  * ext4: Fix sub-block zeroing for writes into preallocated extents
    - LP: #418197
  * jbd2: Call journal commit callback without holding j_list_lock
    - LP: #418197
  * ext4: Print the find_group_flex() warning only once
    - LP: #367065
  * ext4: really print the find_group_flex fallback warning only once
    - LP: #367065

linux (2.6.28-15.51) jaunty-proposed; urgency=low

  [ Colin Ian King ]

  * SAUCE: wireless: hostap, fix oops due to early probing interrupt
    - LP: #254837

  [ Leann Ogasawara ]

  * Add the atl1c driver to support Atheros AR8132
    - LP: #415358
  * Updating configs to enable the atl1c driver
    - LP: #415358

  [ Stefan Bader ]

  * Revert "SAUCE: input: Blacklist digitizers from joydev.c"
    - LP: #300143
  * SAUCE: Fix the exported name for e1000e-next
    - LP: #402890
  * SAUCE: Fix incorrect stable backport to bas_gigaset
    - LP: #417732
  * SAUCE: Remove the atl2 driver from the ubuntu subdirectory
    - LP: #419438

linux (2.6.28-15.50) jaunty-proposed; urgency=low

  [ Colin Ian King ]

  * SAUCE: radio-maestro: fix panics on probe failure
    - LP: #357724
  * SAUCE: HDA Intel, sigmatel: Enable speakers on HP Mini 1000
    - LP: #318942

  [ Jerone Young ]

  * SAUCE: Fix Soltech TA12 volume hotkeys not sending key release in
    Jaunty
    - LP: #397499

  [ John Johansen ]

  * SAUCE: remove AppArmor debug check for calls from interrupt context
    - LP: #350789

  [ Manoj Iyer ]

  * SAUCE: Fix kernel panic when SELinux is enabled.
    - LP: #395219

  [ Matthew Garrett ]

  * SAUCE: ACPI: Populate DIDL before registering ACPI video device on
    Intel

  [ Michael Frey (Senior Manager, MID ]

  * SAUCE: Fix for internal microphone for Dell Mini10V
    - LP: #394793

  [ Tim Gardner ]

  * SAUCE: Added e1000e from sourceforge.
    - LP: #402890

  [ Upstream Kernel Changes ]

  * Input: synaptics - report multi-taps only if supported by the device
    - LP: #399787
  * ftdi_sio: fix kref leak
    - LP: #396930, #376128
  * IPv6: add "disable" module parameter support to ipv6.ko
    - LP: #351656

 -- Stefan Bader <email address hidden> Thu, 27 Aug 2009 15:09:06 +0200

I'm sorry to bother...

Yesterday I accepted the updates proposed by the Update Manager, which
included a kernel update (version 2.6.28-15.52) and the brightness problem
came back.

(I know I should have known it could happen but... I have already done it)

The main problem now is that I don't knok how to go back.
I've tried to install the patch again but the package installer says that
there is a newer version installed and doesn't proceed.

I'll thank you any help

                     Pablo

2009/8/31 Stefan Bader <email address hidden>

> Pablo wrote:
> > Sorry, when I saw it was a .deb file I had already sent de message.
> > I had no problem to install and it worked fine.
> > I have an Acer Aspire 5738
>
> Thanks for trying, too. Just wondering: did it work right away or had you
> to
> use the command line option? (as I have not encoded a 5738).
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Committed
> Status in linux in Ubuntu Intrepid: Fix Committed
> Status in linux in Ubuntu Jaunty: In Progress
> Status in linux in Ubuntu Karmic: Fix Committed
>
> Bug description:
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

@Pablo,

sorry to hear that and strange. Because the patch should be included in -15.52
as far as I can see. Do you get a message when doing "dmesg |grep 'less
restr'"? If not, you might try to boot with acpi_video_strict_detect=0 and see
whether that helps.

Maybe you had a version installed, that did not do a check for a certain system
(I already wondered why the latest one worked for you as you had a slightly
different laptop, iirc).

Going back to that kernel version should work with "dpkg -i" but on the other
hand would keep you from getting any updates that came along with the newer
version.

Please let me know whether the boot option above helps.

Where should I type the "acpi_video_strict_detect=0" option? You'll see I'm
not very experimented user...
Thanks

2009/10/3 Stefan Bader <email address hidden>

> @Pablo,
>
> sorry to hear that and strange. Because the patch should be included in
> -15.52
> as far as I can see. Do you get a message when doing "dmesg |grep 'less
> restr'"? If not, you might try to boot with acpi_video_strict_detect=0 and
> see
> whether that helps.
>
> Maybe you had a version installed, that did not do a check for a certain
> system
> (I already wondered why the latest one worked for you as you had a slightly
> different laptop, iirc).
>
> Going back to that kernel version should work with "dpkg -i" but on the
> other
> hand would keep you from getting any updates that came along with the newer
> version.
>
> Please let me know whether the boot option above helps.
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Released
> Status in linux in Ubuntu Jaunty: Fix Released
> Status in linux in Ubuntu Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

Dear Stefan,

I've tried "dmseg | grep 'less restr'" as you suggested and got nothing.
Where should I type the "acpi_video_strict_detect=0" option? You'll see I'm
not very experimented user...
Thanks

2009/10/3 Stefan Bader <email address hidden>

> @Pablo,
>
> sorry to hear that and strange. Because the patch should be included in
> -15.52
> as far as I can see. Do you get a message when doing "dmesg |grep 'less
> restr'"? If not, you might try to boot with acpi_video_strict_detect=0 and
> see
> whether that helps.
>
> Maybe you had a version installed, that did not do a check for a certain
> system
> (I already wondered why the latest one worked for you as you had a slightly
> different laptop, iirc).
>
> Going back to that kernel version should work with "dpkg -i" but on the
> other
> hand would keep you from getting any updates that came along with the newer
> version.
>
> Please let me know whether the boot option above helps.
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Released
> Status in linux in Ubuntu Jaunty: Fix Released
> Status in linux in Ubuntu Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

Temporary in Jaunty, when you see the grub screen go to the kernel you want to
boot, type "e", go to the (I think 3rd) line containing the "quiet splash" and
press "e" again, then add the argument and press enter, then "b".

Permanent "sudo vi /boot/grub/menu.lst" then add it to the commented line
"defoptions=quiet splash". After that is saved run "sudo update-grub"

Dear Stefan,

Thanks for your time, but unfortunately it didn't worked.
I've tried both ways (temporary and permanent)
By the way, I noticed another slight change: when connect or disconnect the
power adapter it no longer shows the upper right message showing that
brightness had been changed
I wait for more instructions to going on trying solutions.

(forgive my english if it's not very clear)

2009/10/9 Stefan Bader <email address hidden>

> Temporary in Jaunty, when you see the grub screen go to the kernel you want
> to
> boot, type "e", go to the (I think 3rd) line containing the "quiet splash"
> and
> press "e" again, then add the argument and press enter, then "b".
>
> Permanent "sudo vi /boot/grub/menu.lst" then add it to the commented line
> "defoptions=quiet splash". After that is saved run "sudo update-grub"
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Released
> Status in linux in Ubuntu Jaunty: Fix Released
> Status in linux in Ubuntu Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

Please attach the ouput of dmesg (while using one of the two ways of specifying
the options) and attach it here.

Here it is:

[ 0.000000] BIOS EBDA/lowmem at: 0009d400/0009d400
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.28-15-generic (buildd@yellow) (gcc version
4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009
(Ubuntu 2.6.28-15.52-generic)
[ 0.000000] Command line: root=UUID=687c5346-c444-44b6-a971-807d56823273
ro quiet splash acpi_video_strict_detect=0
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
[ 0.000000] BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000d2000 - 00000000000d8000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000007b6a1000 (usable)
[ 0.000000] BIOS-e820: 000000007b6a1000 - 000000007b6a7000 (reserved)
[ 0.000000] BIOS-e820: 000000007b6a7000 - 000000007b7b9000 (usable)
[ 0.000000] BIOS-e820: 000000007b7b9000 - 000000007b80f000 (reserved)
[ 0.000000] BIOS-e820: 000000007b80f000 - 000000007b908000 (usable)
[ 0.000000] BIOS-e820: 000000007b908000 - 000000007bb0f000 (reserved)
[ 0.000000] BIOS-e820: 000000007bb0f000 - 000000007bb19000 (usable)
[ 0.000000] BIOS-e820: 000000007bb19000 - 000000007bb1f000 (reserved)
[ 0.000000] BIOS-e820: 000000007bb1f000 - 000000007bb5f000 (usable)
[ 0.000000] BIOS-e820: 000000007bb5f000 - 000000007bb9f000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000007bb9f000 - 000000007bbe2000 (usable)
[ 0.000000] BIOS-e820: 000000007bbe2000 - 000000007bbff000 (ACPI data)
[ 0.000000] BIOS-e820: 000000007bbff000 - 000000007bc00000 (usable)
[ 0.000000] BIOS-e820: 000000007bc00000 - 000000007be00000 (reserved)
[ 0.000000] BIOS-e820: 000000007c000000 - 0000000080000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[ 0.000000] BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
[ 0.000000] DMI present.
[ 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working it
around.
[ 0.000000] last_pfn = 0x7bc00 max_arch_pfn = 0x3ffffffff
[ 0.000000] Scanning 0 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000010000 (reserved)
[ 0.000000] modified: 0000000000010000 - 000000000009d400 (usable)
[ 0.000000] modified: 000000000009d400 - 00000000000a0000 (reserved)
[ 0.000000] modified: 00000000000d2000 - 00000000000d8000 (reserved)
...

If you prefer, here is attached

2009/10/9 Stefan Bader <email address hidden>

> Please attach the ouput of dmesg (while using one of the two ways of
> specifying
> the options) and attach it here.
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Released
> Status in linux in Ubuntu Jaunty: Fix Released
> Status in linux in Ubuntu Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

@Pablo, looking at your dmesg it seems you got the option correctly set and it
is using the less restrictive mode for the brightness control. So acer-wmi
leaves that untouched. Now, when running exactly that mode, can you do a "sudo
grep -r . /proc/acpi/video" and attach that output as well?

Attached...

2009/10/12 Stefan Bader <email address hidden>

> @Pablo, looking at your dmesg it seems you got the option correctly set and
> it
> is using the less restrictive mode for the brightness control. So acer-wmi
> leaves that untouched. Now, when running exactly that mode, can you do a
> "sudo
> grep -r . /proc/acpi/video" and attach that output as well?
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Fix Released
> Status in linux in Ubuntu Jaunty: Fix Released
> Status in linux in Ubuntu Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>

Dear Stefan,

Reading the dmesg log I founded this in line #34:
[ 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working it
around.

Does it mean is there anything wrong with my laptop's BIOS or RAM?

Have you done any progress on the brightness problem?
I'm about installing Karmic beta to test it and will tell you what happens

2009/10/13 Pablo Javier Ferrari Ferrando <email address hidden>

> Attached...
>
>
>
> 2009/10/12 Stefan Bader <email address hidden>
>
> @Pablo, looking at your dmesg it seems you got the option correctly set and
>> it
>> is using the less restrictive mode for the brightness control. So acer-wmi
>> leaves that untouched. Now, when running exactly that mode, can you do a
>> "sudo
>> grep -r . /proc/acpi/video" and attach that output as well?
>>
>> --
>> Acer: Cannot change brightness with 2.6.27-11+ kernel
>> https://bugs.launchpad.net/bugs/333386
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>> Status in “linux” package in Ubuntu: Fix Released
>> Status in linux in Ubuntu Intrepid: Fix Released
>> Status in linux in Ubuntu Jaunty: Fix Released
>> Status in linux in Ubuntu Karmic: Fix Released
>>
>> Bug description:
>> SRU justification:
>>
>> Impact: After I carelessly pulled in some updates to the ACPI video code,
>> we were faced with some regressions. One was (at least) a certain Acer
>> laptop model that suddenly had no backlight control.
>>
>> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
>> definition will be accepted by acpi-video as the right definition lacks an
>> attribute to be considered, the fix is to have less strict requirements to
>> that check, so the definition for the right graphics device gets accepted (a
>> patch doing that unconditionally, has been submitted upstream and has been
>> acked, but might not make it until 2.6.32). For the stable tree I created
>> more code which makes sure the less strict tests only take effect on that
>> laptop or when the user really wants to.
>>
>> Testcase: Booting on another laptop will not activate the code (which
>> prints a "Using less strict video detection..." message) but will do with
>> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
>> affected laptop boots and selects the new check which gives back the
>> backlight control.
>>
>> ---
>>
>> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
>> backlight brightness anymore. In the latest kernel, it seems there's no more
>> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
>> still change brightness. I'm new to linux so if you need information give me
>> the command to run. It's an acer 6920G laptop.
>>
>
>

Pablo wrote:

Sorry for getting back that late.

> Reading the dmesg log I founded this in line #34:
> [ 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working it
> around.
>
> Does it mean is there anything wrong with my laptop's BIOS or RAM?

Sort of. It is a common "problem" that some BIOS are using parts of
the lower RAM as storage and the kernel just marks a certain area of the
memory as not usable to work around this. So your RAM is ok, your BIOS
just happens to be one that does use a bit of the lower memory but you
should be alright with that.

> Have you done any progress on the brightness problem?
> I'm about installing Karmic beta to test it and will tell you what happens

I have not have time to specifically work on this. However, all the changes
went upstream and into Karmic. Actually a few more. So you should definitely
try Karmic. Also, as we move ahead, things that are not really critical will
not get fixed in Jaunty. Even Karmic will receive a little less care as the
main effort goes into making the next LTS.

@Stefan Bader:

I can confirm bug is definitely solved with Koala Karmic x64 out-of-the-box. Really great job, well done.

Dear Stefan,

I've installed Karmic from new and the bringhtness problem persists.
But now I can't find the menu.lst file to set the boot option.
Before installing, I had tried to go back to the last patched kernel version
with dkpg. I successfully changed the kernel, but the brightness control
didn't come back.
I'm attaching the dmesg output.
My eyes will thank your efforts.

2009/11/17 Pablo Javier Ferrari Ferrando <email address hidden>

> Dear Stefan,
>
> I've installed Karmic from new and the bringhtness problem persists.
> But now I can't find the menu.lst file to set the boot option.
> Before installing, I had tried to go back to the last patched kernel
> version with dkpg. I successfully changed the kernel, but the brightness
> control didn't come back.
> I'm attaching the dmesg output.
> My eyes will thank your efforts.
>

Tonight I upgrade the kernel with the last version for Karmic. It said there
was a solution for the brightness problem but it didn't work. I've tried
with and without the "acpi_video_strict_detect=0" option and nothing
changed.
I keep waiting for a solution.
Thanks for your efforts.

2009/11/24 Pablo Javier Ferrari Ferrando <email address hidden>

>
>
> 2009/11/17 Pablo Javier Ferrari Ferrando <email address hidden>
>
> Dear Stefan,
>>
>> I've installed Karmic from new and the bringhtness problem persists.
>> But now I can't find the menu.lst file to set the boot option.
>> Before installing, I had tried to go back to the last patched kernel
>> version with dkpg. I successfully changed the kernel, but the brightness
>> control didn't come back.
>> I'm attaching the dmesg output.
>> My eyes will thank your efforts.
>>
>
>

Hi Pablo, sorry for responding that late. The boot option (acpi_video_strict_detect=0) is only useful in Jaunty. Karmic is less restrictive by default and from the dmesg I see that the acpi video driver detects a gfx device. So in all this looks like a different problem and it should get into a new bug report (beside this one being so big one can hardy find information).
So can you please open a new bug by calling "ubuntu-bug linux" on the command line. This will gather basic information and opens the bug. Give it a description like "Acer <your laptop model>: Cannot change brightness (at all | with hotkeys)".
Then attach the output of

- "sudo acpidump -o acpidump.txt"
- "grep -r . /proc/acpi/video >acpi-video.txt"

And finally assign me to that bug. You can also try to use "acpi_backlight=vendor" on the grub commandline and if that changes anything, please note that in the new bug as well.

Ok Stefan, I've already done it.
Hope it would help
Wish to hear good news
Thanks again

            Pablo

2009/11/26 Stefan Bader <email address hidden>

> Hi Pablo, sorry for responding that late. The boot option
> (acpi_video_strict_detect=0) is only useful in Jaunty. Karmic is less
> restrictive by default and from the dmesg I see that the acpi video driver
> detects a gfx device. So in all this looks like a different problem and it
> should get into a new bug report (beside this one being so big one can hardy
> find information).
> So can you please open a new bug by calling "ubuntu-bug linux" on the
> command line. This will gather basic information and opens the bug. Give it
> a description like "Acer <your laptop model>: Cannot change brightness (at
> all | with hotkeys)".
> Then attach the output of
>
> - "sudo acpidump -o acpidump.txt"
> - "grep -r . /proc/acpi/video >acpi-video.txt"
>
> And finally assign me to that bug. You can also try to use
> "acpi_backlight=vendor" on the grub commandline and if that changes
> anything, please note that in the new bug as well.
>
> --
> Acer: Cannot change brightness with 2.6.27-11+ kernel
> https://bugs.launchpad.net/bugs/333386
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Fix Released
> Status in “linux” source package in Intrepid: Fix Released
> Status in “linux” source package in Jaunty: Fix Released
> Status in “linux” source package in Karmic: Fix Released
>
> Bug description:
> SRU justification:
>
> Impact: After I carelessly pulled in some updates to the ACPI video code,
> we were faced with some regressions. One was (at least) a certain Acer
> laptop model that suddenly had no backlight control.
>
> Fix: As the ACPI BIOS is broken on a way that only the *wrong* graphics
> definition will be accepted by acpi-video as the right definition lacks an
> attribute to be considered, the fix is to have less strict requirements to
> that check, so the definition for the right graphics device gets accepted (a
> patch doing that unconditionally, has been submitted upstream and has been
> acked, but might not make it until 2.6.32). For the stable tree I created
> more code which makes sure the less strict tests only take effect on that
> laptop or when the user really wants to.
>
> Testcase: Booting on another laptop will not activate the code (which
> prints a "Using less strict video detection..." message) but will do with
> "acpi_video_strict_detect=0". In both cases nothing bad happened. The
> affected laptop boots and selects the new check which gives back the
> backlight control.
>
> ---
>
> Since the 2.6.27-11 generic kernel (also in 2.6.27-12) I cannot change the
> backlight brightness anymore. In the latest kernel, it seems there's no more
> file in /proc/acpi/video, but GFX0 still apears in 2.6.27-9 where I can
> still change brightness. I'm new to linux so if you need information give me
> the command to run. It's an acer 6920G laptop.
>