Bug 36322

Created attachment 60162 [details]
DSDT, decompiled with iasl

Created attachment 60172 [details]
wmidump of _WDG

Hi Joern, 

Could you please attached on your dmesg after system boot?
Looks like there have a EC operation region declare problem in DSDT:

 OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100)
 Field (ERAM, ByteAcc, NoLock, Preserve)
 {

Should be:
 OperationRegion (ERAM, EmbeddedControl, 0x00, 0xFF)
 Field ....

As I remember, We also meet this problem on Acer TravelMate 8572 machine, I thought your ac-power status also not work on your machine. I mean there have no event when you unplug ac-power.

For brightness, there have _BCM method in your DSDT, it also write value to EC register for change brightness level, I thought it broken because the same root cause.

Created attachment 60212 [details]
dmesg after boot

In my DSDT I've got:
OperationRegion (VERM, EmbeddedControl, Zero, 0xFF)
Field (VERM, ByteAcc, NoLock, Preserve)
{ LNPS,   8 }
OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100) 
Field (ERAM, ByteAcc, NoLock, Preserve)
{ lotsofstuffhere }
I don't really understand what it means and why VERM should be named ERAM.

The acpid process receives some netlink message when I plug in/out the ac adapter.
recvmsg(11, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000001}, msg_iov(1)=[{"D\0\0\0\21\0\0\0\235\1\0\0\0\0\0\0\1\1\0\0000\0\1\0ac_adapter\0\0\0\0\0\0\0\0\0\0ACPI0003:00\0\ .......
I also see a notification in the gnome-power-manager applet. So there must be some kind of event?

Created attachment 60222 [details]
ec_acer_new.diff

For your machine, you need fix the OperationRegion declare problem in EC, first.
If you want, you can try this patch that was from Thomas Renninger.

It's works to us before a couple of months.

OK, sorry for I didn't see you already have a dummy declare:

                    OperationRegion (VERM, EmbeddedControl, Zero, 0xFF)
                    Field (VERM, ByteAcc, NoLock, Preserve)
                    {  
                        LNPS,   8
                    }

That can be workaround the old problem, please ignore my comment #6.

For your brightness control problem, I traced your DSDT, it follow standard acpi event to notify GFX0 video device to change brightness, acpi video driver write a value to EC register for brightness level change:

        Method (OBCM, 1, NotSerialized)
        {  
            Store ("_BCM : Arg0 = ", Debug)
            Store (Arg0, Debug)
            Store (Subtract (Divide (Arg0, 0x0A, ), One), Local0)
            Store (Local0, BRTN)
            Store (Local0, ^LPCB.EC0.BLVL)    /* change */
        }

EC must can handle the BLVL changed, but don't know why your brightness control not work.

If want to confirm the value in BLVL changed by _BCM,
please kindly enable CONFIG_ACPI_EC_DEBUGFS=m, then run Thomas's ec_access tool:
  ftp://ftp.suse.com/pub/people/trenn/sources/ec/

Check value:
  ./ec_access -b 0x51

Please check the value changed when you press brightness up/down key.

For the acer-wmi part, I will provide a patch to you for support acer-wmi on your machine.

Please "modprobe ec_sys" before you run ec_access the check the value.

Sorry, took me a while to compile the kernel and to find out why /sys/kernel/debug/ is empty.

./ec_access -b 0x51 will display values between 0x00 and 0x09; value changes when use brightness up/down keys.
But the actual brightness of my screen does not change.

(In reply to comment #10)
> Sorry, took me a while to compile the kernel and to find out why
> /sys/kernel/debug/ is empty.
> 
> ./ec_access -b 0x51 will display values between 0x00 and 0x09; value changes
> when use brightness up/down keys.
> But the actual brightness of my screen does not change.

Thank's for your testing, it's help to confirm our value write to EC register. 

Unfortunately,
I have no idea why the EC didn't change brightness level even the BLVL register was changed. I will try to trace DSDT hope can dig more information. This issue MIGHT not related to acer-wmi driver.

I wonder how does the brightness control key works on Windows 7, I thought we need EC expert's help.

On the other hand, 
For detect wireless/bluetooth device state and killswitch support, I need more time to clear up current acer-wmi source code to support your machine.

I will attached on acer-wmi patch for support your machine ASAP.

I did some reverse engineering and trying. Here are my results and some thoughts:

Calling _SB.PCI0.LPCB.EC0.BRXP "activates" the brightness which is set
in the BLVL.

The DSDT contains this code three times:

If (LAnd (LLess (OSYS, 0x07D6), LEqual (SGST, Zero)))
{
    BRXP ()
} Else {
    ...
}

OSYS on my machine is 0x07D9 ("Windows 2009"), while there is 0x03E8 ("Linux")
available in the os setup (_INI).
SGST, whatever that may be, is currently 0.

After changing OSYS to 0x03E8, backlight control works.
Now the question remains: How does Windows do it?

PNLT = { 0x17, 0x2E, 0x45, 0x5C, 0x6B, 0x8F, 0xAA, 0xC5, 0xE6, 0xFF };

BRXP is called from within my DSDT only in _WAK (acpi wakeup) and from
_Q8E, _Q8F. All three do the above check.

Method (BRXP, 0, NotSerialized)
{
    Multiply (DerefOf (Index (PNLT, BLVL)), 0x64, Local1)
    Divide (Local1, 0x0100, , Local2)
    ^^^GFX0.AINT (One, Local2)
}

So let's look for AINT. Only BRXP calls this method.

AINT, stripped down, is:
PARD()
Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
Or (BCLP, 0x80000000, BCLP)
Store (0x02, ASLC)
Store (One, ASLE)

The ISBC method looks very similar to this code and is the only other method
which touches those three registers.

Only AJBC calls ISBC. When PWSF (what's that?) is set and Windows is older
than 2009, some fixed backlight value is automatically set. Maybe it's that
feature which darkens the LCD when the user is idle?
For Win2k9, NBTP is called with different values, probably the requested
percentage of brightness.
NBTP contains loops, sleeps, etc., but no code to update the brightness. I don't really understand what it does, but I guess that it causes a cool effect where the brightness is not stepped to the new value but changes smoothly? It probably notifies the OS to update the brightness using ISBC or BRXP.

For fun, I've written a small method to get such a cool effect which first
darkens my LCD and then increases brightness to maximum again:
DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
{
    External (\_SB.PCI0.ISBC, MethodObj)
    Method (XXXX, 0, NotSerialized)
    {
        Store (255, Local0)
        While (LNotEqual(Local0, 0)) {
            \_SB.PCI0.ISBC (Local0)
            Sleep(4)
            Decrement (Local0)
        }
        \_SB.PCI0.ISBC(Local0)
        Sleep(1000)
        While (LNotEqual(Local0, 256)) {
            \_SB.PCI0.ISBC(Local0)
            Sleep(4)
            Increment (Local0)
        }
    }
}

It works :-)

I still don't know the correct way to set the brightness.
* Use the "Linux" OSYS?
* Call BRXP after each change to the brightness?
* Call ISBC? This would be cool because you don't have 10 but 256 different states.

I hope that this helps you with updating the driver.

It's a great hack.

Could you please also try acpi_osi="!Windows 2009"? maybe it also work like acpi_osi="Linux"?

(In reply to comment #12)
> I did some reverse engineering and trying. Here are my results and some
> thoughts:
> 

Thank's for your great hacker.

> Calling _SB.PCI0.LPCB.EC0.BRXP "activates" the brightness which is set
> in the BLVL.
> 
> The DSDT contains this code three times:
> 
> If (LAnd (LLess (OSYS, 0x07D6), LEqual (SGST, Zero)))
> {
>     BRXP ()
> } Else {
>     ...
> }
> 
> OSYS on my machine is 0x07D9 ("Windows 2009"), while there is 0x03E8
> ("Linux")
> available in the os setup (_INI).
> SGST, whatever that may be, is currently 0.
> 

Could you please also try acpi_osi"!Windows 2009" ?

> Method (BRXP, 0, NotSerialized)
> {
>     Multiply (DerefOf (Index (PNLT, BLVL)), 0x64, Local1)
>     Divide (Local1, 0x0100, , Local2)
>     ^^^GFX0.AINT (One, Local2)
> }
> 
> So let's look for AINT. Only BRXP calls this method.
> 
> AINT, stripped down, is:
> PARD()
> Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
> Or (BCLP, 0x80000000, BCLP)
> Store (0x02, ASLC)
> Store (One, ASLE)
> 

The AINT is the mathod the control the backlight base on Intel OpRegion spec.

> 
> I still don't know the correct way to set the brightness.
> * Use the "Linux" OSYS?

It can fix the brightness control problem on your machine, but conflict with current kernel acpi strategy: bit newest windows version (Windows 7)

> * Call BRXP after each change to the brightness?
> * Call ISBC? This would be cool because you don't have 10 but 256 different
> states.

I thought it's too specifically and I cann't direct evaluate a special acpi method in acer-wmi.
On the other hand, 
Per Windows 7 path, DSDT follow standard acpi way, brightness control must handle by acpi/video.c but not in acer-wmi :

 _Q8E/_Q8F -> Nodify GFX0.DD02 -> acpi/video.c -> evaluation _BCM -> LPCB.EC0.BLVL

> 
> I hope that this helps you with updating the driver.

I still want to know what _REAL_ way acer doing in Windows7, then we need find a way to do the same thing with Windows7.
I don't thing they direct access BRXP in their driver, it's very dirty.

(In reply to comment #13)
> Could you please also try acpi_osi="!Windows 2009"? maybe it also work like
> acpi_osi="Linux"?
acpi_osi="!Windows 2009" will cause OSYS==0x7D6,

with acpi_osi="Linux":
  ACPI: Added _OSI(Linux)
  [Firmware Bug]: ACPI: BIOS _OSI(Linux) query honored via cmdline
but OSYS==0x7d) is still set.

Brightness control does not work with either command line option.

(In reply to comment #14)
> I still want to know what _REAL_ way acer doing in Windows7, then we need
> find
> a way to do the same thing with Windows7.
> I don't thing they direct access BRXP in their driver, it's very dirty.
Maybe the intel video driver handels the acpi notification and then calls the AINT method?
I don't have windows available to confirm this (or any other theory). Even if I had, how would I reverse engineer it?

Adding Matthew and Rui, they might know more and may be able to help about OpRegion, _OSI("Windows 2009") brightness issues/regressions.

(In reply to comment #15)
> (In reply to comment #13)
> > Could you please also try acpi_osi="!Windows 2009"? maybe it also work like
> > acpi_osi="Linux"?
> acpi_osi="!Windows 2009" will cause OSYS==0x7D6,
> 
> with acpi_osi="Linux":
>   ACPI: Added _OSI(Linux)
>   [Firmware Bug]: ACPI: BIOS _OSI(Linux) query honored via cmdline
> but OSYS==0x7d) is still set.
> 
> Brightness control does not work with either command line option.
> 

That means AINT() not exactly work: 

Like your hacking, BRXP() call AINT() and it must can change brightness level on Vista, XP and Linux when user press Fn key:
                                                                                                                                    
    Method (_Q8F, 0, NotSerialized)             /* Brightness down */
    {
        Store (BLVL, Local0)
        Store (Local0, BRTN)
        If (LAnd (LLess (OSYS, 0x07D6), LEqual (SGST, Zero)))   /* if Vista, XP, Linux(0x03E8) */
        {
            BRXP ()
        }

> (In reply to comment #14)
> > I still want to know what _REAL_ way acer doing in Windows7, then we need
> find
> > a way to do the same thing with Windows7.
> > I don't thing they direct access BRXP in their driver, it's very dirty.
> Maybe the intel video driver handels the acpi notification and then calls the
> AINT method?

hmm.......

i915 driver must be handle to support Intel OpRegion, but if the OS is Windows 7, we didn't see any Windows7 path go to access AINT(), that means Winodws 7 on this machine doesn't change brightness level by OpRegion.

Need i915 expert's help.

> I don't have windows available to confirm this (or any other theory). Even if
> I
> had, how would I reverse engineer it?

I don't know either, but I will send out a mail to Carlos, he know more about reverse engineer on Windows side. 

Only trace DSDT is not enough understand how does it work on Windows 7.

I thought our target is understand how does it work on Windows 7, looks like not only one machine like this.

Hi Thomas, 

(In reply to comment #16)
> Adding Matthew and Rui, they might know more and may be able to help about
> OpRegion, _OSI("Windows 2009") brightness issues/regressions.

In comment #8, _BCM have logic to write value to BLVL register on EC0:

    Method (OBCM, 1, NotSerialized)
        {  
            Store ("_BCM : Arg0 = ", Debug)
            Store (Arg0, Debug)
            Store (Subtract (Divide (Arg0, 0x0A, ), One), Local0)
            Store (Local0, BRTN)
            Store (Local0, ^LPCB.EC0.BLVL)    /* change */
        }

I thought EC must to read the BLVL register when it modified then change LCD panel's brightness level, that means LVDS must wired to EC.

Do you have any idea why EC didn't change brightness level when BLVL changed? or my understand is totally wrong?

Created attachment 60752 [details]
DSDT of an Acer Extensa 5635

I got short access to an Extensa 5635 with Win7 installed. I started grml64-small and copied the DSDT off it (see attachment) before its owner got too suspious :)

There is neither a ISBC method nor a BRXP method, like there are on my model.
So it's unlikely that win7 makes use of the functions on my laptop.

_BCM method is this:
Method (_BCM, 1, NotSerialized) {
    If (LEqual (BOWN, Zero)) { 
        Store (Subtract (Divide (Arg0, 0x0A, ), One), Local0)
        Store (Local0, BRTN)    
        Acquire (^^^^LPCB.EC0.MUT1, 0xFFFF)
        Store (Local0, ^^^^LPCB.EC0.BLVL)
        Release (^^^^LPCB.EC0.MUT1)
        If (LEqual (OSYS, 0x03E8)) {
            Store (Multiply (Add (Local0, One), 0x18), Local1)
            If (LGreater (Local1, 0xFF)) { Store (0xFF, Local1) }  
            Store (Local1, ^^^^GFX0.LBES) 
        }
                                
        If (LLess (OSYS, 0x07D6)) {
            If (LEqual (^^^^^WMID.BAEF, One)) {
                Sleep (0xC8)            
                Store (0x05, ^^^^^WMID.WMIQ)
                Notify (WMID, 0x80) } } 
    } Else { Store (Zero, BOWN) }
}
So for linux, it does more than for windows. Win7 only stores the new value in BLVL. Same as on my laptop.

_B8E / _B8F are no-ops for Osi==Linux and do Notify DD02 for win7.

AINT exists on this laptop as well (but is not called by any other method).
It is exactly the same method but the last line which is probably not significant. Therefore I think that it *can* be used to set the brightness too.

I couldn't test the brightness control in X, because grml64-small doesn't have it. But I doubt that it would have worked, seeing that DSDT code.
So I still guess that win7 calls AINT to set the brightness, instead of _BCM.

I will ask the owner if he lets me install a debugger on his laptop, so I can "debug" his windows.

(In reply to comment #20)
> Created an attachment (id=60752) [details]
> DSDT of an Acer Extensa 5635
> 
> I got short access to an Extensa 5635 with Win7 installed. I started
> grml64-small and copied the DSDT off it (see attachment) before its owner got
> too suspious :)
> 
> There is neither a ISBC method nor a BRXP method, like there are on my model.
> So it's unlikely that win7 makes use of the functions on my laptop.
> 
> _BCM method is this:
> Method (_BCM, 1, NotSerialized) {
>     If (LEqual (BOWN, Zero)) { 
>         Store (Subtract (Divide (Arg0, 0x0A, ), One), Local0)
>         Store (Local0, BRTN)    
>         Acquire (^^^^LPCB.EC0.MUT1, 0xFFFF)
>         Store (Local0, ^^^^LPCB.EC0.BLVL)
>         Release (^^^^LPCB.EC0.MUT1)
>         If (LEqual (OSYS, 0x03E8)) {
>             Store (Multiply (Add (Local0, One), 0x18), Local1)
>             If (LGreater (Local1, 0xFF)) { Store (0xFF, Local1) }  
>             Store (Local1, ^^^^GFX0.LBES) 
>         }
> 

On Linux, it direct access the LBES pci register on video device.

>         If (LLess (OSYS, 0x07D6)) {
>             If (LEqual (^^^^^WMID.BAEF, One)) {
>                 Sleep (0xC8)            
>                 Store (0x05, ^^^^^WMID.WMIQ)
>                 Notify (WMID, 0x80) } } 
>     } Else { Store (Zero, BOWN) }
> }

On Vista or XP, it emit 0x80 wmi event.

> So for linux, it does more than for windows. Win7 only stores the new value
> in
> BLVL. Same as on my laptop.
> 
> _B8E / _B8F are no-ops for Osi==Linux and do Notify DD02 for win7.
> 
> AINT exists on this laptop as well (but is not called by any other method).
> It is exactly the same method but the last line which is probably not
> significant. Therefore I think that it *can* be used to set the brightness
> too.
> 
> I couldn't test the brightness control in X, because grml64-small doesn't
> have
> it. But I doubt that it would have worked, seeing that DSDT code.
> So I still guess that win7 calls AINT to set the brightness, instead of _BCM.
> 

I thought Acer still used standard acpi on Win7, not direct access AINT.

On my Acer Travelmate 8572, brightness works fine on Linux, but it access AINT method in _BCM:

    Method (_BCM, 1, NotSerialized)
    {   
        If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
        {  
            AINT (One, Arg0)        /* access AINT(OpRegion)*/
            Store (Arg0, BRTL)
        }
    }

There have no difference with Windows 7 and Linux on my Acer 8572, they are all access AINT() in _BCM, and brightness control works fine.

> I will ask the owner if he lets me install a debugger on his laptop, so I can
> "debug" his windows.

Acer have 4 ODM help them to manufacture notebook/netbook, different ODM have different DSDT when different timezone.

For brightness control, as I know:
 + Control by EC
or
 + Control by OpRegion (AINT)

I still thought Acer folllow standard acpi (call _BCM) on Windows 7, but might need send out a special EC command to initial EC, but I don't know how to reverse engineer EC, might need dump EC registers on Windows 7?

Read this:
http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx

I thought brightness control key works on Windows 7 because it have WDDM video
driver, but Linux didn't support WDDM.

Per the above spec, windows driver will try 2 ways to modify brightness:
 + WDDM video driver
 + if no WDDM video driver, then will follow ACPI standard.

So, the _BCM must be work on machine but it's fail on Acer Aspire 5750G and Acer Travelmate 5760.

Created attachment 68292 [details]
0001-acer-wmi-add-ACER_WMID_v2-interface-flag-to-represe.patch

This patch is for acer-wmi driver direct support (auto-probe) on Acer Travelmate 5760.

But,
This patch is not related to the brightness issue on this machine.

Hi Joern, 

Please check there have /sys/class/backlight/intel_backlight on your machine, and try 'acpi_backlight=vendor' kernel parameter.

If 'acpi_backlight=vendor' works to you, then I want to send a patch to acpi for add a quirk table the included Acer TravelMate 5760-2414G50Mnbk.

Hi Chun-Yi,

was quite busy, so sorry for very late response. Also, looks like I disabled old email because of too much spam so didn't see last comment.

running debian sid's "3.2.0-2-amd64" kernel. /sys/class/backlight/intel_backlight exists and works good. After adding acpi_backlight=vendor the brightness control (key combos) in gnome3 also works.

Thanks a lot!

(In reply to comment #25)
> Hi Chun-Yi,
> 
> was quite busy, so sorry for very late response. Also, looks like I disabled
> old email because of too much spam so didn't see last comment.
> 
> running debian sid's "3.2.0-2-amd64" kernel.
> /sys/class/backlight/intel_backlight exists and works good. After adding
> acpi_backlight=vendor the brightness control (key combos) in gnome3 also
> works.
> 
> Thanks a lot!

Great! 

Please kindly share your dmidecode to me, just attach on this bug:
 # dmidecode > dmidecode.log

I will add your machine to quirk table in acer-wmi driver, then you can remove 
'acpi_backlight=vendor' after applied new kernel.


Thanks

Created attachment 72995 [details]
acer TravelMate 5760-2410G50Mnbk dmidecode output

Attached, thanks!

Created attachment 73195 [details]
0001-acer-wmi-add-3-laptops-to-video-backlight-vendor-mo.patch

Sent to platform driver mail address for review.

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit 050eff39af6a395104df85b7ca59f0a4245e04f8
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Mon May 21 23:19:51 2012 +0800

    acer-wmi: add 3 laptops to video backlight vendor mode quirk table