Bug 14432

Created attachment 23450 [details]
2.6.31.4's dmesg

Created attachment 23451 [details]
2.6.31.4's acpidump

Created attachment 23452 [details]
2.6.31.4's /sys/class/backlight tree

Created attachment 23453 [details]
2.6.27.37's dmesg

Created attachment 23454 [details]
2.6.27.37's acpidump

Created attachment 23455 [details]
2.6.27.37's /sys/class/backlight tree

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?

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.

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?

please run cat /proc/acpi/event and see if there is any output when the screen is dimming.

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

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.

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?

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

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.

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

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.

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

(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. :(

Btw, I'm on 2.6.31.5, not 2.6.32.

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.

Created attachment 23546 [details]
2.6.31.5's dmesg without acpi_backlight=vendor

Created attachment 23547 [details]
2.6.31.5's dmesg with acpi_backlight=vendor

Here's the colored diff of the 2.6.31.5's dmesgs with and without acpi_backlight=vendor:
http://pastebin.com/m5a4c12e9

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

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.

Created attachment 23553 [details]
23452: 2.6.31.4's /sys/class/backlight tree with acpi_backlight=vendor

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.

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)

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.

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.

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.

(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 ?

ping nelson...

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. ;)

any updates?

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.

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.

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.

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.

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.

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 ?

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.

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 ;)

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.

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 :)

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.

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/

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 ? ;)

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

shipped in linux-2.6.33 before -rc1
closed.

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