Bug 15182

Hi,
Could you send more information (uname -a, dmesg, dsdt) ?
Could you try with the latest eeepc-laptop version (from http://git.iksaif.net/?p=acpi4asus.git;a=shortlog;h=refs/heads/eeepc-laptop ) ?
Thanks

Corentin, thank you for your comment.  For some reason I was made aware of it until today (via Launchpad, strange).

uname and dmesg are available via http://wiki.debian.org/DebianEeePC/Model/1005P.  I'm not familiar with dsdt.  Google suggests it's some kind of file that can be buggy, but I'm not sure how to get dsdt-related information.  Please kindly let me know.  I'm not sure when I can get around to recompiling kernel from the branch you suggested.  I'm out of practice and it will take me some time.  Not sure when I can schedule that time.  Is there anything in particular that makes you believe it may be fixed in that particular tree?  How long is the usual delay before things in there hit mainline?

> I'm not familiar with dsdt. 
> Google suggests it's some kind of file that can be buggy, but I'm not sure
> how
> to get dsdt-related information.  Please kindly let me know.

See
http://dev.iksaif.net/projects/acpi4asus/wiki/Dumping_dsdt

> Is there anything in particular that makes you believe it may be fixed
> in that particular tree?

Not really, but it's always best to try with the latest bios and kernel.

> How long is the usual delay before things in there
> hit mainline?

Well, it seems that debian is using a 2.6.32 kernel, there should not be a lot of changes between my tree and 2.6.32.

You can also try to boot with "acpi_backlight=vendor" kernel parameters.

Thank you, Corentin.  I tried a lucid live CD which has the 2.6.32-11-generic kernel.  I also added acpi_backlight=vendor at boot time.  The result was that the display brightness adjustment keys stopped to work completely.  Without the boot parameter the issue is the same in lucid with 2.6.32 as it is in karmic with 2.6.31.

The DSDT information should be available from http://pastebin.com/f41fac148  I hope that's what you need.

Hum ... are you sure that eeepc-laptop module is loaded ?
When you kill gnome-power-manager, is the bug still here (you can try to stop X and do the test in a terminal) ?

a couple of observations

1) adding acpi_osi=Linux to the kernel boot parameters seems to fix this issue
2) eeepc_laptop module is loaded
3) the same issue happens on the console as well

please attach the acpidump output

(In reply to comment #6)
> a couple of observations
> 
> 1) adding acpi_osi=Linux to the kernel boot parameters seems to fix this
> issue
> 2) eeepc_laptop module is loaded
> 3) the same issue happens on the console as well

Without acpi_osi=Linux, I don't think eeepc-laptop was loaded.

We can find this in the dsdt:
                        Method (_STA, 0, NotSerialized)
                        {
                            If (LGreaterEqual (MSOS (), MSW7))
                            {
                                Return (Zero)
                            }
                            Else
                            {
                                Return (0x0F)
                            }
                        }

See http://dev.iksaif.net/projects/acpi4asus/wiki/Eeepc-wmi for more information.

(In reply to comment #7)
> please attach the acpidump output

http://pastebin.com/f2ca56ac1

(In reply to comment #8)
> Without acpi_osi=Linux, I don't think eeepc-laptop was loaded.

Hm, yes, eeepc-laptop was loaded even without acpi_osi=Linux.  My latest tests were on a 1001P, though.  I believe the only difference between the 1001P and the 1005P is

1001P: WinXP, carbon-imitation case
1005P: Win7, glossy case

I'd say, they are completely identical when it comes to hardware.

Well, there is a difference because 1005P have Win7 support, not 1001P.
On 1001P eeepc-laptop should load without problem.
On 1005P eeepc-laptop won't load without acpi_osi=Linux.

(In reply to comment #10)
> Well, there is a difference because 1005P have Win7 support, not 1001P.

I can't comment on that since I no longer have access to a 1005p.  I would be surprised if the 1001P would not run a clone image of a Win7 partition copied from a 1005P, for example.

The issue at hand, namely that the display brightness keys work in nonlinear fashion and that acpi_osi=Linux as boot param fixes this, is exactly the same on both devices.  I can confirm that much.

Could you send the acpidump for 1001P too ?
Thanks,

Method (_Q0B, 0, NotSerialized)
                        {
...
                            If (LEqual (MSOS (), MSW7))
                            {
                                Notify (^^^VGA.LCDD, 0x87)
                            }
...
                        }

We can see that in eeepc 1005p, ATKD doesn't work and the hotkey events go to the ACPI video device. so acpi_backlight="vendor" doesn't work.

Rolf,
In https://bugs.launchpad.net/linux/+bug/513921/comments/4
do you mean that when pressing hotkeys,
1. backlight changes
2. /sys/class/backlight/acpi_video0/actual_brightness doesn't change
3. no ACPI hotkey events

(In reply to comment #12)
> Could you send the acpidump for 1001P too ?

http://pastebin.com/f2ca56ac1 is indeed the 1001P.  Anything up to comment 4 is related to the 1005P, comments after that are about the 1001P.  But as I said, I believe they are essentially the same hardware inside, just a different number.

Zhang, I wasn't able to completely reproduce what I said in https://bugs.launchpad.net/linux/+bug/513921/comments/4 today with the latest lucid live CD.  I'm just following instructions to the best of my abilities without always understanding what it is that I'm currently doing.  My apologies if my previous reports should have been erroneous (I'm not sure they were or not).

Yes, the backlight changes brightness when the hotkeys are pressed, but it's changing non-linear, seemingly erratic.  When I press the hotkeys, the value in /sys/class/backlight/acpi_video0/actual_brightness decreases and increases monotonically by a value of 2 per press.  Maximum is 15, minimum is 0.  So, you might see 10-12-14-15-13-11 or 3-1-0-2-4.  The real display brightness does not seem to have anything to do with it.  When I reran the test with xev and sed from https://wiki.ubuntu.com/Hotkeys/Troubleshooting and pressing the Hotkeys a few times, this is what I got

keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 64 = (keysym 0xffe9, Alt_L), state = 0x0

Keypresses appear double, IOW, I press up once and down once before closing xev with Alt+F4.

I guess that makes Gnome rather than the kernel the likely candidate, correct?

(In reply to comment #14)
> I guess that makes Gnome rather than the kernel the likely candidate,
> correct?

I don't think so.
I think the root cause is that two hotkey events generated for a single hotkey press.
please run "lsof /proc/acpi/evevnt", and kill all the processes that are polling this file. Then run "cat /proc/acpi/event" and attach the output after pressing the hotkey for one time.

it seems like the only file that was polling /proc/acpi/event was acpid.  I stopped it with "sudo /etc/init.d/acpid stop".  I then ran cat on the file and pressed the brightness-up key once followed by brightness-down once, followed by Ctrl-C to detach.

$ sudo cat /proc/acpi/event 
video LCDD 00000086 00000000
video LCDD 00000087 00000000
^C

Weird, only one ACPI video hotkey event for a single hotkey press.
so there should be only one input key event...

if you blacklist ACPI video driver and then run xev like you do in comment #14, does the "keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0" still pop up when pressing the hotkey any more?
BTW: you can add "blacklist video" in /etc/modprobe.d/blacklist.conf to blacklist the ACPI video driver if ACPI video driver is built as a module.

*** Bug 15347 has been marked as a duplicate of this bug. ***

ping...

What additional information would be helpful at this point?

I noticed that in the changelog for the .34-rc1 that the eeepc module was merged with the general asus laptop module, Im going to build and test it today

(In reply to comment #20)
> What additional information would be helpful at this point?

See 
> Weird, only one ACPI video hotkey event for a single hotkey press.
> so there should be only one input key event...
>
> if you blacklist ACPI video driver and then run xev like you do in comment
> #14,
> does the "keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state =
> 0x0"
> still pop up when pressing the hotkey any more?
> BTW: you can add "blacklist video" in /etc/modprobe.d/blacklist.conf to
> blacklist the ACPI video driver if ACPI video driver is built as a module.


> I noticed that in the changelog for the .34-rc1 that the eeepc module was
> merged with the general asus laptop module, Im going to build and test it
> today

No it's not, it's just a git commit, a branch (eeepc-laptop) was merged into the kernel, but this has nothing to do with asus-laptop.

Same issue. After booting with blacklist video in the bloacklist.conf, killing gnome settings and power manager, and testing with xev I have the same issue, the key event being repeated twice

please do the test in comment #15 and attach the output, both when ACPI video driver is running and when ACPI video driver is blacklisted.

Sorry for the delayed response, but I dont have an /proc/acpi/event. Debian unstable acpi uses netlink

then you can use the acpi_genl tool at http://www.lesswatts.org/projects/acpi/utilities.php

(In reply to comment #25)
> then you can use the acpi_genl tool at
> http://www.lesswatts.org/projects/acpi/utilities.php

This doesn't work for ACPI video hotkeys, please ignore this comment.

Created attachment 25701 [details]
tool to get intput event

please download the read-input-event.c attached.
and do the following test
1. gcc read-input-event.c
2. ./a.out /dev/input/eventX (X equals {0, 1, ..., the maximum input device index})
3. press the hotkey and see which input device generates the input event.

Just fyi. I wrote a WMI driver for ASUS 1005PE which can be found at http://www.spinics.net/lists/linux-input/msg07615.html. It only supports hotkeys at this moment and I plan to add other supports like backlight, rfkill, etc incrementally over time when I have time.

Rolf,
does the problem still exist without any acpi_osi boot options?
can you change the backlight via /sys/class/backlight/acpi_video0/brightness in this case?

Corentin,

                    Method (_BCM, 1, NotSerialized)
                    {
                        Store (Arg0, Local0)
                        ^^^^ATKD.PBLS (Local0)
                    }
it seems that the ACPI video driver invokes PBLS to change the backlight, doesn't this work when ATKD._STA returns 0?

My apologies for being so quiet lately.  I can't answer right now but will try to do that next week.

(In reply to comment #29)
> Rolf,
> does the problem still exist without any acpi_osi boot options?
> can you change the backlight via /sys/class/backlight/acpi_video0/brightness
> in
> this case?
> 
> Corentin,
> 
>                     Method (_BCM, 1, NotSerialized)
>                     {
>                         Store (Arg0, Local0)
>                         ^^^^ATKD.PBLS (Local0)
>                     }
> it seems that the ACPI video driver invokes PBLS to change the backlight,
> doesn't this work when ATKD._STA returns 0?

Honestly I don't know, but I think it should.

Please update to latest version of BIOS available from http://support.asus.com/download/download.aspx?model=EEE+PC+1005PE&f_name=1005p-asus-0804.zip&SLanguage=en-us. To be more specific, BIOS v0804 updates brightness table which was a mess in previous versions and resulted in brightness not increasing monotonically.

I have same basic issues with non-linear setting of backlight on 1005PE.  Here is some information I found related to it.

I've upgraded to both 0901 and 1003 firmware.  With both of those, the Fn-keys for dimming work as expected on default boot into linux 2.6.33 (Fedora 13 beta kernel).  I pretty much upgraded to this firmware from initial purchase so I can't report on behavior of Fn-keys before upgrade.

In default linux boot case, eeepc-laptop is not loaded because of WMI feature for Windows 2009 in DSDT mentioned above.  During this boot, any software based controls of backlight work non-linearly.  Also gnome-power-manager gets confused and keeps undo-ing any changes made by Fn-keys and also doesn't give that visual percentage bar feedback.

If I boot with acpi_osi="!Windows 2009" or acpi_osi="Linux" then eepc-laptop loads.  In both cases it prints out a message about ACPI controls backlight and then disable its own support for that.  gnome-power-manager still has same issues mentioned above.

Finally, if I boot with acpi_osi="!Windows 2009" and acpi_backlight=vendor then all starts to work as expected.  Both Fn-keys work nicely and software based controls also work nicely (as well as getting visual percentage bar feedback in Gnome when its changing).  The highest brightness setting doesn't seem as high as Windows but that could be based on darker background image on Linux.

Based on review of eeepc-wmi.c, I think it will have same issue because it will disable backlight support since ACPI claims its during acpi_osi="Windows 2009".

So when given a chance, eeepc-laptop works OK.  Probably this means fixes (if any) will be in acpi-video area?

This issue sounds very similar to bug report id=15532 .

I have some more research results.  First, let me restate the good parts.  If I boot with acpi_osi="!Windows 2009" and acpi_backlight=vendor then things work normally.  So thats my reference point.

Now, if I boot with no ACPI options, I notice the following important information in dmesg:

ACPI Warning: _BQC returned an invalid level (20091214/video-638)
acpi device:0d: registered as cooling_device2
input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)

So it was having problems getting the current brightness level.

eeepc-laptop uses PLBG and PLBS to get and set brightness levels and they work; as described in first paragraph.  The module seems to not modify the values it passes so its strictly a value of 1-15.

ACPI Video uses _BQC and _BCM to get and set brightness; which isn't working.  In DSDT, these are just remaps to PLBG and PLBS:

                    Method (_BQC, 0, NotSerialized)
                    {
                        Return (^^^^ATKD.PBLG ())
                    }

                    Method (_BCM, 1, NotSerialized)
                    {
                        Store (Arg0, Local0)
                        ^^^^ATKD.PBLS (Local0)
                    }

So as long as ACPI Video was passing values 1-15 to _BCM then you'd think they would work as well.  But they seem to load some table of levels that are supported using _BCL.  This table returns 15 values:

                    Method (_BCL, 0, NotSerialized)
                    {
                        Store (ShiftRight (BCLM, 0x08), Index (BBPS, 0x0F))
                        Store (ShiftRight (BCL1, 0x08), Index (BBPS, 0x0E))
                        Store (ShiftRight (BCL2, 0x08), Index (BBPS, 0x0D))
                        Store (ShiftRight (BCL3, 0x08), Index (BBPS, 0x0C))
                        Store (ShiftRight (BCL4, 0x08), Index (BBPS, 0x0B))
                        Store (ShiftRight (BCL5, 0x08), Index (BBPS, 0x0A))
                        Store (ShiftRight (BCL6, 0x08), Index (BBPS, 0x09))
                        Store (ShiftRight (BCL7, 0x08), Index (BBPS, 0x08))
                        Store (ShiftRight (BCL8, 0x08), Index (BBPS, 0x07))
                        Store (ShiftRight (BCL9, 0x08), Index (BBPS, 0x06))
                        Store (ShiftRight (BCLA, 0x08), Index (BBPS, 0x05))
                        Store (ShiftRight (BCLB, 0x08), Index (BBPS, 0x04))
                        Store (ShiftRight (BCLC, 0x08), Index (BBPS, 0x03))
                        Store (ShiftRight (BCLD, 0x08), Index (BBPS, 0x02))
                        Store (ShiftRight (BCLE, 0x08), Index (BBPS, One))
                        Store (ShiftRight (BCLF, 0x08), Index (BBPS, Zero))
                        Return (BBPS)
                    }

So when user gives a value of 1-15 ACPI Video does a lookup to values from above array and somehow this makes things get really confused.  Output of /proc/acpi/video/VGA/LCDD appears to show these levels:

levels:  1 4 7 10 13 16 20 23 26 29 32 36 41 46 50 56
current: 56

Based on eeepc-laptop logic, I think those levels should be 1-15.

If I am in fact understand this all then probably means buggy DSDT and needs to be resolved by BIOS update from ASUS.... or if that doesn't happen then needs to be blacklisted in ACPI Video to force .

In mean time, using acpi_backlight=vendor seems the best option and let eeepc-laptop or eeepc-wmi take control of backlight.

BTW: This issue seems specific to using /sys/class/backlight/acpi_video0/brightness interface.  If you get software out of the loop; except for ACPI Video (maybe do an "init 3"); then Fn-F4/F5 does work correctly.

(In reply to comment #34)

> So when user gives a value of 1-15 ACPI Video does a lookup to values from
> above array and somehow this makes things get really confused.  Output of
> /proc/acpi/video/VGA/LCDD appears to show these levels:
> 
> levels:  1 4 7 10 13 16 20 23 26 29 32 36 41 46 50 56
> current: 56
> 
> Based on eeepc-laptop logic, I think those levels should be 1-15.
> 
> If I am in fact understand this all then probably means buggy DSDT and needs
> to
> be resolved by BIOS update from ASUS.... or if that doesn't happen then needs
> to be blacklisted in ACPI Video to force .
> 
Very good findings.
I think this is the root cause of the problem.
The ACPI video driver wants to make use of the PBLG/PBLS method, but fails.
And I total agree that this should be fixed in the BIOS, i.e. provide a meaningful _BCL package for PBLG/PBLS.

> In mean time, using acpi_backlight=vendor seems the best option and let
> eeepc-laptop or eeepc-wmi take control of backlight.
> 
well, you're right, for this specific BIOS.
But we don't want too many dmi quirks in the kernel.
As win7 uses wmi driver instead of ACPI video driver, the problem may also exist in Windows XP/Vista, right?
We probably should push Asus to upgrade their BIOS.

I update to the 1103 BIOS and the nonlinearity problem is gone.  The maximum brightness will be less if I don't pass the boot parameter, though.  So, there is still some work left to be done, but it seems to be ASUS' responsibility.

I can also confirm updating to 1103 BIOS fixes nonlinearity problem.  A few additional comments.

* I must have lost email for Comment #35.  Sorry for late response but I wanted to reply that I couldn't test with Wins XP/Vista; only  under Win7 the keys worked as expected.

* If I remove acpi_backlight=vendor with 1103 BIOS, then Fn-Key's work but I get no visual response back from Gnome.  I think I saw another bug report related to eeepc-laptop/wmi needing to send events even when ACPI controls backlight.  I'll go look that one up and comment further there.

* The maximum display does seem darker now and is definitely darker then Windows 7.  I've not done many test yet with new BIOS to confirms its the use of _BCL thats darker then using PBLS... or even if there are a few higher brightness settings then level 15 that Windows is using to get so bright

I have upgraded my 1005PE netbook to Fedora 14 Beta which includes kernel 2.6.25.4 and more importantly the eeepc-wmi module.  I also am using BIOS 1103.

I can now boot WITHOUT any acpi_ options and both eeepc_laptop and eeepc_wmi modules get loaded.  This combination allows adjusting the backlight normally (including Gnome giving visual feedback).

I'd consider this bug report resolved.

Ignore the part about both eeepc_laptop and eeepc_wmi being loaded with no acpi_ options.  Only eeepc_wmi is loaded with no acpi_ options and works good.  

I can get both eeepc_laptop and eeepc_wmi to load though when I specify both acpi_ options documented above but that is not important for backlight behaviour.

FYI: F3 (touchpad off), F4 (screen resolution), F7 (screen OFF), and F9 (System Monitory) do not work with only eeepc_wmi but thats a different issue and I'll try to submit some patches to get them working since they simply need to be passed to userspace as keypresses and we do get nice "eeepc_wmi: Unknown key xx pressed" on console.

Pressing "Fn" and the following keys I get following list of unknown keys for those interested:

F3 - eeepc_wmi - Unkown key 6b pressed
F4 - e1
F7 - e9
F9 - e0
Space - 5c
Quickboot - 5c (embedded Linux boot button)

Not sure why these are returning something.  Probably from another model and were arrow keys are.

1 - 83
2 - eb
e - ec
s - ec
d - ed
f - ef

Please contact me if you need any help to write a patch to add these key, you should only need to change the keymap on top of the file.

When the patch is ready, please CC me.