Bug 14432

Summary: backlight controls gone mad - ATI HD 3650
Product: ACPI Reporter: Nélson «VuDu» Cunha (vudu.curse)
Component: Power-VideoAssignee: acpi_power-video
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, corentin.chary, lenb, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: Yes Bisected commit-id:
Attachments: 2.6.31.4's dmesg
2.6.31.4's acpidump
2.6.31.4's /sys/class/backlight tree
2.6.27.37's dmesg
2.6.27.37's acpidump
2.6.27.37's /sys/class/backlight tree
2.6.31.5's dmesg without acpi_backlight=vendor
2.6.31.5's dmesg with acpi_backlight=vendor
23452: 2.6.31.4's /sys/class/backlight tree with acpi_backlight=vendor

Description Nélson «VuDu» Cunha 2009-10-17 20:33:06 UTC
Hello,

I'm using ArchLinux (here's the "downstream" bug report:
http://bugs.archlinux.org/task/16698) and with the last update to
kernel 2.6.31.4 my backlight/brightness controls have gone mad.

My laptop's screen keeps blinking, slowly increasing or decreasing its
luminosity randomly. Sometimes it stays still for a couple of minutes
at any random brightness level, but it's very uncomfortable for the
eyes when it's blinking.
Here's a video of what's happening:
http://www.mediafire.com/download.php?z4mi4uzidjn

I've tried to use /proc/acpi/video/VGA/LCDD/brightness and
/sys/class/backlight/acpi_video0/brightness but with no luck, because
they make no changes and when I cat them I get wrong values.

I tried using xbacklight but it gives me "No outputs have backlight property".

With the previous (2.6.30.6) version I had no problems and after
getting this problem I installed Arch's "kernel26-lts" package
(2.6.27.37) and I'm having no issues with that kernel.

My laptop is an ASUS M51VA with an Intel C2D and an ATI HD 3650. I
tried fglrx, radeon and radeonhd and it made no difference.

Another smaller issue, I dunno if its distro-specific but starting some months ago, the backlight gets pretty dim during the boot (maybe around udev loading, before the daemons start) and I had to add a couple of commands to my rc.local to put it back to the max brightness levels. That happens both with AC and DC.

If you need more details, please say so.

Best Regards.
Comment 1 Nélson «VuDu» Cunha 2009-10-17 20:34:11 UTC
Created attachment 23450 [details]
2.6.31.4's dmesg
Comment 2 Nélson «VuDu» Cunha 2009-10-17 20:34:55 UTC
Created attachment 23451 [details]
2.6.31.4's acpidump
Comment 3 Nélson «VuDu» Cunha 2009-10-17 20:35:47 UTC
Created attachment 23452 [details]
2.6.31.4's /sys/class/backlight tree
Comment 4 Nélson «VuDu» Cunha 2009-10-17 20:42:49 UTC
Created attachment 23453 [details]
2.6.27.37's dmesg
Comment 5 Nélson «VuDu» Cunha 2009-10-17 20:43:33 UTC
Created attachment 23454 [details]
2.6.27.37's acpidump
Comment 6 Nélson «VuDu» Cunha 2009-10-17 20:44:01 UTC
Created attachment 23455 [details]
2.6.27.37's /sys/class/backlight tree
Comment 7 Zhang Rui 2009-10-19 07:41:22 UTC
Nice bug report! Nelson.

does "sys/class/backlight/acpi_video0" work in 2.6.27.37?
does the backlight still change w/o X running?
Comment 8 Nélson «VuDu» Cunha 2009-10-19 10:08:37 UTC
Actually, now that you asked, I just realized the same happens in 2.6.27.37.
The difference seems to be that lapsus, which uses asus-laptop kernel module, worked until at least 2.6.30.6 and I never noticed the problem.

While on 2.6.27.37, I tried using /sys/class/backlight /acpi_video0 and /asus-laptop and neither worked. It changed values but no effect on the screen.
So I restarted to the same kernel but without laptop-mode, lapsusd and gdm and I realized it was blinking! /sys/class/backlight kept making no changes on the screen. As soon as I started lapsus, the brightness stood still and I could control it with the FN+F5/6 keys without X running. Now that I stopped lapsusd I can't change the brightness level, but it's not blinking. I'm guessing that running lapsus for a moment is enough to avoid the problem.

So, it seems that the problem comes from way behind but it was covered by lapsus until the last update that broke lapsus and brought the problem to light.
Comment 9 Nélson «VuDu» Cunha 2009-10-19 10:13:42 UTC
Also, I forgot to mention that the dimming on udev issue happens on 2.6.27.37 too.
Might be related to the blinking, no?
Comment 10 Zhang Rui 2009-10-22 03:47:06 UTC
please run cat /proc/acpi/event and see if there is any output when the screen is dimming.
Comment 11 Nélson «VuDu» Cunha 2009-10-22 09:24:50 UTC
Right now, on 2.6.27.37-lts, form X I'm getting:

[10:22:57][root@vudumachine vudu]# cat /proc/acpi/event 
cat: /proc/acpi/event: Device or resource busy
Comment 12 Nélson «VuDu» Cunha 2009-10-22 09:43:40 UTC
That was caused by acpid running.

Without acpid running I get:

hotkey ATKD 00000025 00000001
hotkey ATKD 00000016 00000002
hotkey ATKD 00000025 00000002
hotkey ATKD 00000016 00000003
hotkey ATKD 00000017 0000000d
hotkey ATKD 00000017 0000000e
hotkey ATKD 00000026 00000004

when I press the FN+ keys, on both kernels.
Comment 13 Zhang Rui 2009-10-26 08:46:27 UTC
is there any change of the /proc/acpi/event output when the backlight is changed?
If yes, the problem is caused by some spurious hotkey events.

does the backlight still change if you don't load the asus-laptop driver?
Comment 14 Nélson «VuDu» Cunha 2009-10-26 19:33:28 UTC
(In reply to comment #13)
> is there any change of the /proc/acpi/event output when the backlight is
> changed?
> If yes, the problem is caused by some spurious hotkey events.

I can't confirm that because I can only change the backlight with lapsusd and that requires acpid which doens't allow me to cat /proc/acpi/event.
Comment 15 Nélson «VuDu» Cunha 2009-10-26 19:55:55 UTC
Tried with 2.6.31.5 and no changes...

After
/etc/rc.d/lapsusd stop && /etc/rc.d/acpid stop && modprobe asus-laptop -r

cat /proc/acpi/event
no longer reacts to the FN+ keys.
Comment 16 Zhang Rui 2009-10-27 01:26:51 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > is there any change of the /proc/acpi/event output when the backlight is
> > changed?
> > If yes, the problem is caused by some spurious hotkey events.
> 
> I can't confirm that because I can only change the backlight with lapsusd and
> that requires acpid which doens't allow me to cat /proc/acpi/event.

you can stop lapsusd because I just want to check if there are any hotkey events when pressing the hotkeys.

(In reply to comment #15) 
> After
> /etc/rc.d/lapsusd stop && /etc/rc.d/acpid stop && modprobe asus-laptop -r
> 
> cat /proc/acpi/event
> no longer reacts to the FN+ keys.

you mean there is no output when pressing the hotkeys, right?
this seems like an asus-laptop driver problem to me.
Corentin,
can you look at this issue please?
I think we need to verify if there are any spurious asus hotkey events when the screen blinks.
Comment 17 Corentin Chary 2009-10-27 07:30:50 UTC
2.6.27 dmesg says that you were using both asus_acpi and asus-laptop, strange (maybe first loading asus_acpi, then rmmod acpi_acpi + modprobe asus-laptop ..).

2.6.32 dmesg says:
asus_laptop: Brightness ignored, must be controlled by ACPI video driver

so the brightness is controled by acpi/video module in your case.

On 2.6.32: can you check with xev if asus-laptop module generate XF86XK_MonBrightnessUp/XF86XK_MonBrightnessDown keys ? It should'nt because when the standard backlight interface is used, ASUS dsdst stop sending backlight events to asus-laptop.

You can also try to boot with acpi_backlight=vendor to check how asus-laptop control the brightness.
Comment 18 Nélson «VuDu» Cunha 2009-10-27 13:33:27 UTC
(In reply to comment #16)
> (In reply to comment #15) 
> > After
> > /etc/rc.d/lapsusd stop && /etc/rc.d/acpid stop && modprobe asus-laptop -r
> > 
> > cat /proc/acpi/event
> > no longer reacts to the FN+ keys.
> 
> you mean there is no output when pressing the hotkeys, right?
> this seems like an asus-laptop driver problem to me.
Yes. It produces no output at all when pressing the FN+ keys.
Comment 19 Nélson «VuDu» Cunha 2009-10-27 15:44:37 UTC
(In reply to comment #17)
> On 2.6.32: can you check with xev if asus-laptop module generate
> XF86XK_MonBrightnessUp/XF86XK_MonBrightnessDown keys ? It should'nt because
> when the standard backlight interface is used, ASUS dsdst stop sending
> backlight events to asus-laptop.
> 
It doesn't generate output for the brightness keys. It does for the other keys though... XF86WLAN, XF86WebCam and the sound keys and others are caught too.

> You can also try to boot with acpi_backlight=vendor to check how asus-laptop
> control the brightness.

Doesn't seem to make any difference with that on the kernel boot line. :(
Comment 20 Nélson «VuDu» Cunha 2009-10-27 15:46:51 UTC
Btw, I'm on 2.6.31.5, not 2.6.32.
Comment 21 Corentin Chary 2009-10-27 16:00:32 UTC
Then asus-laptop works as expected: it let acpi/video.ko handle the backlight

But .. acpi_backlight=vendor should force asus-laptop to control the backlight, could you send a dmesg ?

Zhang,
Actually it may be something in acpi/video, or in the dsdt, but believe this is not related to asus-laptop.
Comment 22 Nélson «VuDu» Cunha 2009-10-27 16:34:52 UTC
Created attachment 23546 [details]
2.6.31.5's dmesg without acpi_backlight=vendor
Comment 23 Nélson «VuDu» Cunha 2009-10-27 16:35:17 UTC
Created attachment 23547 [details]
2.6.31.5's dmesg with acpi_backlight=vendor
Comment 24 Nélson «VuDu» Cunha 2009-10-27 16:40:45 UTC
Here's the colored diff of the 2.6.31.5's dmesgs with and without acpi_backlight=vendor:
http://pastebin.com/m5a4c12e9
Comment 25 Corentin Chary 2009-10-27 19:11:57 UTC
With this parameter, dmesg says that asus-laptop control the backlight.

Is there a asus-laptop dir in /sys/class/backlight/ ?
Are X events reproted ? acpi events ?
Is there still an issue ? (with and without lapsus).
Comment 26 Nélson «VuDu» Cunha 2009-10-27 20:32:57 UTC
The only difference I notice is the fact that without the acpi_backlight=vendor the backlight doesn't dim during boot at the udev loading.

I still can't change brightness levels, although now the blinking seems to have stopped.
Comment 27 Nélson «VuDu» Cunha 2009-10-27 21:13:39 UTC
Created attachment 23553 [details]
23452: 2.6.31.4's /sys/class/backlight tree with acpi_backlight=vendor
Comment 28 Nélson «VuDu» Cunha 2009-10-27 21:27:54 UTC
Ups... I made a mistake. The last attachment is from 2.6.31.5 and not .4!

So, on 2.6.31.5 with acpi_backlight=vendor I get the backlight tree on the attachment.
With acpid off, cat /proc/acpi/event outputs events for the brightness keys.
I get no X events for the brightness keys with xev.
Echo'ing values to /sys/class/backlight/asus_laptop/brightness makes no changes.
Comment 29 Corentin Chary 2009-10-28 13:11:27 UTC
Oups .. eeepc-laptop generate X events for backlight, asus-laptop don't.

So no brightness blinking ? Then it might be a bug in the acpi/video.ko module.

Echo'ing values to /sys/class/backlight/asus_laptop/brightness makes no
changes, but did you try reading brightness and actual_brightness after echoing ?
Could you try that ? (with values from 1 to 15)
Comment 30 Nélson «VuDu» Cunha 2009-10-28 13:33:00 UTC
Well, actually after spending a lot of time on the 2.6.31.5 I noticed the brightness still changed by its own. It seems to be completely random but it wasn't as often as before, so it wasn't blinking, it just changed levels a couple of times on a 10mins period.

Yes, changing values on brightness reflect on the actual_brightness but no physical change happens on the screen.

Might it have anything to do with the light sensor? I think this laptop comes with a ambient light sensor next to webcam.
Comment 31 Corentin Chary 2009-10-28 13:52:54 UTC
Yep, it might be related
try to disable the light sensor with ls_switch  file that can be found in asus-laptop dir (/sys/device/platform . )
See http://git.iksaif.net/?p=acpi4asus.git;a=blob;f=Documentation/ABI/testing/sysfs-platform-asus-laptop;h=a1cb660c50cfb4fcc8b685853a2b599e39d75f85;hb=HEAD for more information on the sysfs files.
Comment 32 Nélson «VuDu» Cunha 2009-10-29 12:05:14 UTC
Ok, now I'm pretty sure the blinking is the light sensor's fault.

Still there's the other issues... I still can't change the brightness on newer kernels and in some cases the brightness dims to a low level when loading udev events.
Comment 33 Corentin Chary 2009-10-29 13:06:54 UTC
(In reply to comment #32)
> Still there's the other issues... I still can't change the brightness on
> newer
> kernels

Can you do a bisection ? Or at least give a list of working and non-working kernels ?

> and in some cases the brightness dims to a low level when loading udev
> events.

using acpi_backlight=vendor ? or only using the acpi video module ?
Comment 34 Zhang Rui 2009-11-17 03:04:26 UTC
ping nelson...
Comment 35 Nélson «VuDu» Cunha 2009-11-17 09:50:50 UTC
pong :)


Sorry, I've been very busy lately. As soon as I find some time to test this further I'll post back some more info. ;)
Comment 36 Zhang Rui 2009-12-04 03:50:34 UTC
any updates?
Comment 37 Nélson «VuDu» Cunha 2009-12-04 11:45:17 UTC
Hello.
Sorry but recently, I've been very busy with the studies.

About the bisection, as far as I noticed, lapsus stopped working when I updated from 2.6.30.6 to 2.6.31.4. That was what made me realize the "mad controls" which turned out to be the light sensor reacting to my shadow or other lightning changes.
Also, the dimming on the loading of udev event seems to be the sensor starting to work and it has been that way many kernel updates ago, without any flag on the kernel line.
Comment 38 Nélson «VuDu» Cunha 2009-12-04 12:06:23 UTC
I've went "back" and tried the Arch's last "stable" kernel26 (currently 2.6.31.6) with and without acpi_backlight=vendor and it seems to be the same considering the light sensor working and lapsus not working.
I dunno if the light sensor works on it's own (not software controlled) or if it may be under the influenced of the same problem that is affecting lapsus, but besides reacting too fast to tiny lightning changes, the screen brightness level is always too dimm.
I'm on a room with good ambient light and with a desk light and if I don't stay still it keeps "blinking" up and down the brightness levels but always around 15%, 25%, maybe 40% of the maximum brightness level.
AC or DC seems to make no difference.
Comment 39 Nélson «VuDu» Cunha 2009-12-04 12:23:21 UTC
Sorry to spam with another comment, but there seems to be no way to edit the comments.

Now I'm at the kernel26-lts (2.6.27.39) and so that we can compare 2.6.27 with 2.6.31, with the acpi_backlight=vendor the screen no longer dims when loading udev events and if I cover the light sensor the brightness level stays the same, so I assume the light sensor is disabled.
On this kernel, lapsus works, so I can use the FN+ keys to change the brightness level. I can't change the brightness levels without lapsus.
Removing the acpi_backlight from 2.6.27 line the sensor works but I still can't change the brightness levels without lapsus.
Comment 40 Corentin Chary 2009-12-04 18:15:06 UTC
Ok, there was a change between 2.6.30.6 and 2.6.31.4, I think asus-laptop sysfs directory was renamed asus_laptop (it was a side effect, not really wanted, but now that the change is done for 2.6.31 and 2.6.32 I'll keep that as it is).

This may break lapsus.

I don't know what lapsus do, but it may enable or disable the light sensor.

You can control this by hand using /sys/devices/platform/asus_laptop/ls_switch and ls_level files.
Comment 41 Nélson «VuDu» Cunha 2009-12-05 11:32:14 UTC
Yes that seems to be an issue for lapsus (worst of all, it's currently not compiling and the project seems abandoned), but still... I should be capable of changing those settings even without lapsus. Like I said before, changing /sys/class/backlight/* produces no real changes.

All the blinking and automatic brightness level changes are due to the light sensor, so that no longer be a problem... although I don't really think the default behavior should be the current one, that's making the screen too dark and blink too much.
Comment 42 Corentin Chary 2009-12-05 17:22:46 UTC
Did you try to tweak light sensor settings using the ls_level file ?


Maybe you can't change the backlight settings because the light sensor is enabled, did you try to disable it before using /sys/class/backlight ?
Comment 43 Nélson «VuDu» Cunha 2009-12-06 13:51:16 UTC
That was it! Thank you very much. ;)

Since that sensor removes the brightness control from the user and it's behavior is near useless, could you consider making it off by default? It probably was that way on older kernels because I remember the time when screen didn't dim when loading udev events.
Comment 44 Nélson «VuDu» Cunha 2009-12-06 14:00:30 UTC
I forgot to mention that I simple did:

# echo 0 > /sys/devices/platform/asus_laptop/ls_switch

and now even gnome reacts to the FN+ keys and I no longer need lapsus for that ;)

the echoing to /sys/class/backlight/acpi_video0/brightness works too ;)
Comment 45 Corentin Chary 2009-12-06 14:49:48 UTC
I think that lapsus disabled it.
I'm working on it, as soon as I've got a good patch I'll send that back to you.
Comment 46 Nélson «VuDu» Cunha 2009-12-13 16:31:43 UTC
You're working on a patch for the default settings?
Well, out of nothing, I found "/etc/modprobe.d/video.conf" that had "options video brightness_switch_enabled=1".
I changed it to 0 and now I no longer need to "echo 0 > /sys/devices/platform/asus_laptop/ls_switch" on rc.local and I have no brightness changes when loading udev events. :)

Who creates/sets that file? This way is incredibly simple to disable the sensor :)
Comment 47 Nélson «VuDu» Cunha 2009-12-13 17:10:57 UTC
Well... the sensor is still working after that. I replied too early. :(
I'm re-adding the "echos" to /etc/rc.local because "video brightness_switch_enabled=0" seems to let it enabled after all.
Comment 48 Corentin Chary 2009-12-13 18:07:45 UTC
I've sent a patch to linux-acpi, should be merged in 2.6.33, also sent it to stable@kernel.org. I think I cced, if it isn't the case, the patch is here:  http://patchwork.kernel.org/patch/65584/
Comment 49 Nélson «VuDu» Cunha 2009-12-13 18:25:25 UTC
Thanks ;)
lol @ the comment vs. code on asus-laptop.c :D

Btw, do you have any info to share on the /etc/modprobe.d/video.conf ? ;)
Comment 50 Len Brown 2009-12-16 06:08:02 UTC
commit d951d4cc84e8b5ddb8e0ab81cf6a72cc73fdd668
Author: Corentin Chary <corentincj@iksaif.net>
Date:   Mon Dec 7 22:05:50 2009 +0100

    asus-laptop: change light sens default values.

is in acpi-test
Comment 51 Len Brown 2009-12-17 03:38:47 UTC
shipped in linux-2.6.33 before -rc1
closed.

please re-open if there is still an issue here.