Gateway 200X (again) - No power button events

Gateway 200X (again) - No power button events

[Greg Sarjeant]

Hi,

    I have another question about my Gateway 200X. ACPI is working much
better now, but I just started playing with the power button, and it
turns out that I am not getting any events from it. I looked through the
DSDT, and could not find any Notify (\SW.PWRB, 0x80) statements for it,
so I imagine that that is the problem. Here (I think) are the relevant
DSDT sections:


    Scope (_GPE)
    {
        Method (_L05, 0, NotSerialized)
        {
            Notify (\_SB.PCI0.MODM, 0x02)
            Notify (\_SB.PWRB, 0x02)
        }

        Method (_L0B, 0, NotSerialized)
        {
            Notify (\_SB.PCI0.PCIB, 0x02)
            Notify (\_SB.PWRB, 0x02)
        }

        Method (_L1D, 0, NotSerialized)
        {
            Store (\_SB.PHS1 (0x8E, Zero), Local0)
            If (LEqual (Local0, One))
            {
                Notify (\_SB.PWRB, 0x02)
            }

            If (LEqual (Local0, 0x02))
            {
                Notify (\_SB.PWRB, 0x02)
            }
        }
    }


    Device (PWRB)
    {
        Name (_HID, EisaId ("PNP0C0C"))
        Name (_PRW, Package (0x02)
        {
            0x1D, 
            0x04
        })
    }


Do I have to add this Notify statement in the _GPE block? I'm also a bit
confused by the "Notify (\_SB.PWRB, 0x02)" lines. From the spec, I
thought that 0x80 and 0x200 were the expected values from Notify for the
power button. Am I missing something here?

Also, the BIOS does not supply an ECDT. I am using the patch at bug 1690
to get around this, could that be related? 

The power button does shut the macine down in Windows XP. I have tried
passing acpi_os_name="Microsoft Windows XP" to the kernel without
success. I did that because I noticed lines like this:

       If (LEqual (SizeOf (_OS), 0x14))

In the PCI0 device block after seeing the S3D method emails. I haven't
really had the chance to dig into what's going on there yet, so it was a
bit of a blind stab.

For reference, the complete DSDT is posted at
http://www.morningdave.org/acpi/dsdt.dsl


Thanks again for any help,
Greg




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Greg Sarjeant]

OK, I found the Notify call that I was looking for. It was in the
EmbeddedControl region, and they don't specify the \_SB. prefix:

   Method (_Q50, 0, NotSerialized)
   {
       Notify (PWRB, 0x80)
   }

So, it looks like it is specified in the DSDT. I'm not sure why I don't
get an event when I press the button. I do get events from the sleep
button, but the two are declared somewhat differently. Here they are for
comparison:

        Device (SLPB)
        {
            Name (_HID, EisaId ("PNP0C0E"))
            Method (_STA, 0, NotSerialized)
            {
                Return (0x0F)
            }
        }

        Device (PWRB)
        {
            Name (_HID, EisaId ("PNP0C0C"))
            Name (_PRW, Package (0x02)
            {
                0x1D, 
                0x04
            })
        }


Thanks again,
  Greg


On Mon, 2004-01-19 at 12:34, Greg Sarjeant wrote:
> Hi,
> 
>     I have another question about my Gateway 200X. ACPI is working much
> better now, but I just started playing with the power button, and it
> turns out that I am not getting any events from it. I looked through the
> DSDT, and could not find any Notify (\SW.PWRB, 0x80) statements for it,
> so I imagine that that is the problem. Here (I think) are the relevant
> DSDT sections:
> 
> 
>     Scope (_GPE)
>     {
>         Method (_L05, 0, NotSerialized)
>         {
>             Notify (\_SB.PCI0.MODM, 0x02)
>             Notify (\_SB.PWRB, 0x02)
>         }
> 
>         Method (_L0B, 0, NotSerialized)
>         {
>             Notify (\_SB.PCI0.PCIB, 0x02)
>             Notify (\_SB.PWRB, 0x02)
>         }
> 
>         Method (_L1D, 0, NotSerialized)
>         {
>             Store (\_SB.PHS1 (0x8E, Zero), Local0)
>             If (LEqual (Local0, One))
>             {
>                 Notify (\_SB.PWRB, 0x02)
>             }
> 
>             If (LEqual (Local0, 0x02))
>             {
>                 Notify (\_SB.PWRB, 0x02)
>             }
>         }
>     }
> 
> 
>     Device (PWRB)
>     {
>         Name (_HID, EisaId ("PNP0C0C"))
>         Name (_PRW, Package (0x02)
>         {
>             0x1D, 
>             0x04
>         })
>     }
> 
> 
> Do I have to add this Notify statement in the _GPE block? I'm also a bit
> confused by the "Notify (\_SB.PWRB, 0x02)" lines. From the spec, I
> thought that 0x80 and 0x200 were the expected values from Notify for the
> power button. Am I missing something here?
> 
> Also, the BIOS does not supply an ECDT. I am using the patch at bug 1690
> to get around this, could that be related? 
> 
> The power button does shut the macine down in Windows XP. I have tried
> passing acpi_os_name="Microsoft Windows XP" to the kernel without
> success. I did that because I noticed lines like this:
> 
>        If (LEqual (SizeOf (_OS), 0x14))
> 
> In the PCI0 device block after seeing the S3D method emails. I haven't
> really had the chance to dig into what's going on there yet, so it was a
> bit of a blind stab.
> 
> For reference, the complete DSDT is posted at
> http://www.morningdave.org/acpi/dsdt.dsl
> 
> 
> Thanks again for any help,
> Greg
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Greg Sarjeant]

A little more info for the Gateway 200X power button issue. The
acpi_button_notify method is not even called for the power button (nor
is acpi_button_notify_fixed), so whatever is causing the events not to
be raised must be at a lower level than that. I'm still guessing that
it's a DSDT issue, but this at least rules out a bug in the
acpi_button_notify functions.

Greg



On Mon, 2004-01-19 at 14:51, Greg Sarjeant wrote:
> OK, I found the Notify call that I was looking for. It was in the
> EmbeddedControl region, and they don't specify the \_SB. prefix:
> 
>    Method (_Q50, 0, NotSerialized)
>    {
>        Notify (PWRB, 0x80)
>    }
> 
> So, it looks like it is specified in the DSDT. I'm not sure why I don't
> get an event when I press the button. I do get events from the sleep
> button, but the two are declared somewhat differently. Here they are for
> comparison:
> 
>         Device (SLPB)
>         {
>             Name (_HID, EisaId ("PNP0C0E"))
>             Method (_STA, 0, NotSerialized)
>             {
>                 Return (0x0F)
>             }
>         }
> 
>         Device (PWRB)
>         {
>             Name (_HID, EisaId ("PNP0C0C"))
>             Name (_PRW, Package (0x02)
>             {
>                 0x1D, 
>                 0x04
>             })
>         }
> 
> 
> Thanks again,
>   Greg
> 
> 
> On Mon, 2004-01-19 at 12:34, Greg Sarjeant wrote:
> > Hi,
> > 
> >     I have another question about my Gateway 200X. ACPI is working much
> > better now, but I just started playing with the power button, and it
> > turns out that I am not getting any events from it. I looked through the
> > DSDT, and could not find any Notify (\SW.PWRB, 0x80) statements for it,
> > so I imagine that that is the problem. Here (I think) are the relevant
> > DSDT sections:
> > 
> > 
> >     Scope (_GPE)
> >     {
> >         Method (_L05, 0, NotSerialized)
> >         {
> >             Notify (\_SB.PCI0.MODM, 0x02)
> >             Notify (\_SB.PWRB, 0x02)
> >         }
> > 
> >         Method (_L0B, 0, NotSerialized)
> >         {
> >             Notify (\_SB.PCI0.PCIB, 0x02)
> >             Notify (\_SB.PWRB, 0x02)
> >         }
> > 
> >         Method (_L1D, 0, NotSerialized)
> >         {
> >             Store (\_SB.PHS1 (0x8E, Zero), Local0)
> >             If (LEqual (Local0, One))
> >             {
> >                 Notify (\_SB.PWRB, 0x02)
> >             }
> > 
> >             If (LEqual (Local0, 0x02))
> >             {
> >                 Notify (\_SB.PWRB, 0x02)
> >             }
> >         }
> >     }
> > 
> > 
> >     Device (PWRB)
> >     {
> >         Name (_HID, EisaId ("PNP0C0C"))
> >         Name (_PRW, Package (0x02)
> >         {
> >             0x1D, 
> >             0x04
> >         })
> >     }
> > 
> > 
> > Do I have to add this Notify statement in the _GPE block? I'm also a bit
> > confused by the "Notify (\_SB.PWRB, 0x02)" lines. From the spec, I
> > thought that 0x80 and 0x200 were the expected values from Notify for the
> > power button. Am I missing something here?
> > 
> > Also, the BIOS does not supply an ECDT. I am using the patch at bug 1690
> > to get around this, could that be related? 
> > 
> > The power button does shut the macine down in Windows XP. I have tried
> > passing acpi_os_name="Microsoft Windows XP" to the kernel without
> > success. I did that because I noticed lines like this:
> > 
> >        If (LEqual (SizeOf (_OS), 0x14))
> > 
> > In the PCI0 device block after seeing the S3D method emails. I haven't
> > really had the chance to dig into what's going on there yet, so it was a
> > bit of a blind stab.
> > 
> > For reference, the complete DSDT is posted at
> > http://www.morningdave.org/acpi/dsdt.dsl
> > 
> > 
> > Thanks again for any help,
> > Greg
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> > 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Nate Lawson]

On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> So, it looks like it is specified in the DSDT. I'm not sure why I don't
> get an event when I press the button. I do get events from the sleep
> button, but the two are declared somewhat differently. Here they are for
> comparison:
>
>         Device (SLPB)
>         {
>             Name (_HID, EisaId ("PNP0C0E"))
>             Method (_STA, 0, NotSerialized)
>             {
>                 Return (0x0F)
>             }
>         }
>
>         Device (PWRB)
>         {
>             Name (_HID, EisaId ("PNP0C0C"))
>             Name (_PRW, Package (0x02)
>             {
>                 0x1D,
>                 0x04
>             })
>         }

You have no _STA method for PWRB.  On FreeBSD, we say hw is always present
if there is no _STA method.  If it is present, it must return the proper
flags for the hw to be used.  Perhaps Linux always thinks it's not present
if _STA is not there.  Note that SLPB returns the proper _STA result.

-Nate


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Ducrot Bruno]

On Tue, Jan 20, 2004 at 12:03:34PM -0800, Nate Lawson wrote:
> On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> > So, it looks like it is specified in the DSDT. I'm not sure why I don't
> > get an event when I press the button. I do get events from the sleep
> > button, but the two are declared somewhat differently. Here they are for
> > comparison:
> >
> >         Device (SLPB)
> >         {
> >             Name (_HID, EisaId ("PNP0C0E"))
> >             Method (_STA, 0, NotSerialized)
> >             {
> >                 Return (0x0F)
> >             }
> >         }
> >
> >         Device (PWRB)
> >         {
> >             Name (_HID, EisaId ("PNP0C0C"))
> >             Name (_PRW, Package (0x02)
> >             {
> >                 0x1D,
> >                 0x04
> >             })
> >         }
> 
> You have no _STA method for PWRB.  On FreeBSD, we say hw is always present
> if there is no _STA method.  If it is present, it must return the proper
> flags for the hw to be used.  Perhaps Linux always thinks it's not present
> if _STA is not there.  Note that SLPB returns the proper _STA result.
> 

That would contradict the specs.  If _STA is not present, then assume, by
default, that the device is present, functional, etc like if _STA returned 0x0F.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Greg Sarjeant]

Hi again,

   I created a bug for this, but I think I screwed something up, because
it's not coming to acpi-bugzilla. In case anyone is interested, it's bug
1920.

   http://bugzilla.kernel.org/show_bug.cgi?id=1920

   Sorry for the trouble - guess I still have to work out proper
bugzilla usage.

   Thanks,
    Greg


On Tue, 2004-01-20 at 19:23, Grover, Andrew wrote:
>  
> > From: Greg Sarjeant [mailto:greg-QNIYhHqVzB9kr2E5YSwMOQ@public.gmane.org] 
> > Aha! That did the trick.
> 
> > And now dmesg reports:
> > So, it is picking up the Control Method Power Button, and I get events
> > from it now. Outstanding.
> 
> > Is this something that might find its way into the main kernel tree?
> > Should I submit a bug for this behavior?
> 
> Yes open a bug. Sounds like if both are present, CM should be preferred
> over FF. This is against what the spec says, so this may come down to a
> judgment call by Len. I don't know how common this problem is.
> 
> Regards -- Andy
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Greg Sarjeant]

On Wed, 2004-01-21 at 05:23, Ducrot Bruno wrote:

> 1- At first, does this info file give accurate informations?
Yes. When it detects the FF power button, I have this:

type:                    Power Button (FF)

When I comment out those lines in scan.c to get the CM button, it reads:

type:                    Power Button (CM)

> 2- What happens if in one terminal you do something like
> watch -d 'cat /proc/interrupts'
> then press this button?
I tried this with the FF button. Interestingly, it does generate
interrupts when I press it (I unloaded all of the ACPI modules except
for button, so I imagine that this must be what caused the requests on
the acpi interrupt). So, I do get some sort of response from the system.
Should button.c acpi_button_notify_fixed() be called when I press the FF
button? It isn't currently.

> 3- also look into the ASL
> if you have some Notify(PWRF, ...), then try to insert some
> debug statements via Store ("PWRF notify xx", Debug) with
> xx being the number of the notify.
I don't have any Notify(PWRF, ...) methods in the ASL. They are all
Notify(PWRB, ...). When the system detects the FF button, it refers to
it as PWRF, and when it detects the CM button, it refers to it as PWRB.
In fact, the DSDT doesn't define a PWRF at all. I imagine that that is
specified in the FADT? As Andy said, the system disregards the CM button
entirely when it finds the FF button. I submitted a bug (1920), so
perhaps the behavior will change in the future. But I guess that that
contradicts the spec, so maybe not. I wouldn't want to break a bunch of
other machines just for the sake of a little convenience on my laptop :)
Perhaps the real problem is that the FF button isn't generating events?

Thanks,
Greg



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Gateway 200X (again) - No power button events

[Ducrot Bruno]

On Tue, Jan 20, 2004 at 04:17:05PM -0500, Greg Sarjeant wrote:
> I also should mention that I do have a /proc/acpi/button/power/PWRF/info
> entry for the button. So the button is detected, I just get no events
> from it.
> 

1- At first, does this info file give accurate informations?

2- What happens if in one terminal you do something like
watch -d 'cat /proc/interrupts'
then press this button?

3- also look into the ASL
if you have some Notify(PWRF, ...), then try to insert some
debug statements via Store ("PWRF notify xx", Debug) with
xx being the number of the notify.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Grover, Andrew]

 

> From: Greg Sarjeant [mailto:greg-QNIYhHqVzB9kr2E5YSwMOQ@public.gmane.org] 
> Aha! That did the trick.

> And now dmesg reports:
> So, it is picking up the Control Method Power Button, and I get events
> from it now. Outstanding.

> Is this something that might find its way into the main kernel tree?
> Should I submit a bug for this behavior?

Yes open a bug. Sounds like if both are present, CM should be preferred
over FF. This is against what the spec says, so this may come down to a
judgment call by Len. I don't know how common this problem is.

Regards -- Andy


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Greg Sarjeant]

On Tue, 2004-01-20 at 18:27, Grover, Andrew wrote:
> That is correct. So, the code ignores a CM power button if a FF button
> is found. There is a bit in the FADT that declares if the power button
> is fixed or control-method.
> 
> PWR_BUTTON A zero indicates the power button is handled as a fixed
> feature programming model; a one indicates the power
> button is handled as a control method device. If the system
> does not have a power button, this value would be "1" and
> no sleep button device would be present.
> 
> (I think that "sleep" should be "power" but anyways...)
> 
> So the FF pwr button gets priority. You can comment out a few lines in
> scan.c acpi_bus_scan_fixed(), and it should not register the FF power
> button. That might be interesting to try.
> 
> Regards -- Andy

Aha! That did the trick.

I commented out these three lines:

	if (acpi_fadt.pwr_button == 0)
		result = acpi_bus_add(&device, acpi_root, 
			NULL, ACPI_BUS_TYPE_POWER_BUTTON);


And now dmesg reports:

ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states)
ACPI: Lid Switch [LID0]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Power Button (CM) [PWRB]
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
[ACPI Debug] String: Not Support
ACPI: Thermal Zone [THRM] (50 C)
ACPI: Fan [FAN0] (on)

So, it is picking up the Control Method Power Button, and I get events
from it now. Outstanding.

When I was googling around, I saw a lot of references to a patch for 2.4
that ignores Fixed Feature buttons when Control Method buttons are
found. For example:

http://www.funet.fi/pub/Linux/PEOPLE/Linus/v2.4/patch-html/patch-2.4.14/linux_drivers_acpi_ospm_button_bn_osl.c.html

Hm - now that I look at it again, the author name is familiar :)

Is this something that might find its way into the main kernel tree?
Should I submit a bug for this behavior?

Thanks for the suggestion!
Greg



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Grover, Andrew]

> From: Greg Sarjeant [mailto:greg-QNIYhHqVzB9kr2E5YSwMOQ@public.gmane.org] 
> I think it may be detecting a Fixed Feature power button. Here are the
> relevant dmesg lines:
> 
> ACPI: Power Button (FF) [PWRF]
> ACPI: Lid Switch [LID0]
> ACPI: Sleep Button (CM) [SLPB]
> ACPI: AC Adapter [ADP1] (on-line)
> ACPI: Battery Slot [BAT1] (battery present)
> [ACPI Debug] String: Not Support
> ACPI: Thermal Zone [THRM] (47 C)
> ACPI: Fan [FAN0] (on)
> 
> (That "Not Support" is raised by the thermal zone's _SCP Method in the
> DSDT. Guess I can't set the cooling policy on this machine).
> 
> So, unless the FF cleverly stands for something other than Fixed
> Feature, I imagine that that is what I've got. I was just starting to
> read up about Fixed vs Control Method Power Buttons, and I am a bit
> confused. It seems from the spec that a Fixed Feature Power Button
> shouldn't have an implementation in the DSDT. Is that correct, or am I
> misreading? I do see methods for the Power button in the DSDT. Here is
> the _Q50 method, which is defined in the Embedded Control block:

That is correct. So, the code ignores a CM power button if a FF button
is found. There is a bit in the FADT that declares if the power button
is fixed or control-method.

PWR_BUTTON A zero indicates the power button is handled as a fixed
feature programming model; a one indicates the power
button is handled as a control method device. If the system
does not have a power button, this value would be "1" and
no sleep button device would be present.

(I think that "sleep" should be "power" but anyways...)

So the FF pwr button gets priority. You can comment out a few lines in
scan.c acpi_bus_scan_fixed(), and it should not register the FF power
button. That might be interesting to try.

Regards -- Andy


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Greg Sarjeant]

I also should mention that I do have a /proc/acpi/button/power/PWRF/info
entry for the button. So the button is detected, I just get no events
from it.

Thanks again,
 Greg


On Tue, 2004-01-20 at 15:28, Greg Sarjeant wrote:
> Nate and Andy, thanks for the replies.
> 
> 
> On Tue, 2004-01-20 at 15:15, Grover, Andrew wrote:
> > > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> > > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > > Nate Lawson
> > > On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> > > > So, it looks like it is specified in the DSDT. I'm not sure 
> > > why I don't
> > > > get an event when I press the button. I do get events from the sleep
> > > > button, but the two are declared somewhat differently. Here 
> > 
> > > You have no _STA method for PWRB.  On FreeBSD, we say hw is 
> > > always present
> > > if there is no _STA method.  If it is present, it must return 
> > > the proper
> > > flags for the hw to be used.  Perhaps Linux always thinks 
> > > it's not present
> > > if _STA is not there.  Note that SLPB returns the proper _STA result.
> > 
> > The ACPI spec in fact says that the absence of _STA implies the device
> > is present and functioning. Linux has code for this case, which I am
> > assuming (?) works.
> > 
> > In the ASL, you might make sure there are _Qxx methods that call
> > Notify() on these respective devices. Also, does dmesg indicate the
> > presence of a fixed-feature power button?
> > 
> > Regards -- Andy
> > 
> 
> I had tried adding an _STA method earlier today with no success, but I
> may have done something wrong (I just copied the SLPB _STA method).
> 
> I think it may be detecting a Fixed Feature power button. Here are the
> relevant dmesg lines:
> 
> ACPI: Power Button (FF) [PWRF]
> ACPI: Lid Switch [LID0]
> ACPI: Sleep Button (CM) [SLPB]
> ACPI: AC Adapter [ADP1] (on-line)
> ACPI: Battery Slot [BAT1] (battery present)
> [ACPI Debug] String: Not Support
> ACPI: Thermal Zone [THRM] (47 C)
> ACPI: Fan [FAN0] (on)
> 
> (That "Not Support" is raised by the thermal zone's _SCP Method in the
> DSDT. Guess I can't set the cooling policy on this machine).
> 
> So, unless the FF cleverly stands for something other than Fixed
> Feature, I imagine that that is what I've got. I was just starting to
> read up about Fixed vs Control Method Power Buttons, and I am a bit
> confused. It seems from the spec that a Fixed Feature Power Button
> shouldn't have an implementation in the DSDT. Is that correct, or am I
> misreading? I do see methods for the Power button in the DSDT. Here is
> the _Q50 method, which is defined in the Embedded Control block:
> 
> Method (_Q50, 0, NotSerialized)
> {
>     Notify (PWRB, 0x80)
> }
> 
> According to the spec, I think that that should trigger the sleep event.
> 
> Interestingly, when I added the _STA method to the PWRB device, dmesg
> did not report an additional _STA method found. It reports 58 devices
> and 58 _STA methods regardless of whether or not I include a _STA
> method. Is it disregarding the DSDT device definition because it detects
> the fixed feature power button?
> 
> I apologize if this is a bit rambly, or if I'm butchering the
> terminology. I'm trying to work this out as I go along.
> 
> Thanks,
>  Greg
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Greg Sarjeant]

Nate and Andy, thanks for the replies.


On Tue, 2004-01-20 at 15:15, Grover, Andrew wrote:
> > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > Nate Lawson
> > On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> > > So, it looks like it is specified in the DSDT. I'm not sure 
> > why I don't
> > > get an event when I press the button. I do get events from the sleep
> > > button, but the two are declared somewhat differently. Here 
> 
> > You have no _STA method for PWRB.  On FreeBSD, we say hw is 
> > always present
> > if there is no _STA method.  If it is present, it must return 
> > the proper
> > flags for the hw to be used.  Perhaps Linux always thinks 
> > it's not present
> > if _STA is not there.  Note that SLPB returns the proper _STA result.
> 
> The ACPI spec in fact says that the absence of _STA implies the device
> is present and functioning. Linux has code for this case, which I am
> assuming (?) works.
> 
> In the ASL, you might make sure there are _Qxx methods that call
> Notify() on these respective devices. Also, does dmesg indicate the
> presence of a fixed-feature power button?
> 
> Regards -- Andy
> 

I had tried adding an _STA method earlier today with no success, but I
may have done something wrong (I just copied the SLPB _STA method).

I think it may be detecting a Fixed Feature power button. Here are the
relevant dmesg lines:

ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Sleep Button (CM) [SLPB]
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
[ACPI Debug] String: Not Support
ACPI: Thermal Zone [THRM] (47 C)
ACPI: Fan [FAN0] (on)

(That "Not Support" is raised by the thermal zone's _SCP Method in the
DSDT. Guess I can't set the cooling policy on this machine).

So, unless the FF cleverly stands for something other than Fixed
Feature, I imagine that that is what I've got. I was just starting to
read up about Fixed vs Control Method Power Buttons, and I am a bit
confused. It seems from the spec that a Fixed Feature Power Button
shouldn't have an implementation in the DSDT. Is that correct, or am I
misreading? I do see methods for the Power button in the DSDT. Here is
the _Q50 method, which is defined in the Embedded Control block:

Method (_Q50, 0, NotSerialized)
{
    Notify (PWRB, 0x80)
}

According to the spec, I think that that should trigger the sleep event.

Interestingly, when I added the _STA method to the PWRB device, dmesg
did not report an additional _STA method found. It reports 58 devices
and 58 _STA methods regardless of whether or not I include a _STA
method. Is it disregarding the DSDT device definition because it detects
the fixed feature power button?

I apologize if this is a bit rambly, or if I'm butchering the
terminology. I'm trying to work this out as I go along.

Thanks,
 Greg




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Nate Lawson]

On Tue, 20 Jan 2004, Grover, Andrew wrote:
> > From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
> > Nate Lawson
> > On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> > > So, it looks like it is specified in the DSDT. I'm not sure
> > why I don't
> > > get an event when I press the button. I do get events from the sleep
> > > button, but the two are declared somewhat differently. Here
>
> > You have no _STA method for PWRB.  On FreeBSD, we say hw is
> > always present
> > if there is no _STA method.  If it is present, it must return
> > the proper
> > flags for the hw to be used.  Perhaps Linux always thinks
> > it's not present
> > if _STA is not there.  Note that SLPB returns the proper _STA result.
>
> The ACPI spec in fact says that the absence of _STA implies the device
> is present and functioning. Linux has code for this case, which I am
> assuming (?) works.

Ok, sorry for the misdirection.

-Nate


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: Gateway 200X (again) - No power button events

[Grover, Andrew]

> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> Nate Lawson
> On Mon, 19 Jan 2004, Greg Sarjeant wrote:
> > So, it looks like it is specified in the DSDT. I'm not sure 
> why I don't
> > get an event when I press the button. I do get events from the sleep
> > button, but the two are declared somewhat differently. Here 

> You have no _STA method for PWRB.  On FreeBSD, we say hw is 
> always present
> if there is no _STA method.  If it is present, it must return 
> the proper
> flags for the hw to be used.  Perhaps Linux always thinks 
> it's not present
> if _STA is not there.  Note that SLPB returns the proper _STA result.

The ACPI spec in fact says that the absence of _STA implies the device
is present and functioning. Linux has code for this case, which I am
assuming (?) works.

In the ASL, you might make sure there are _Qxx methods that call
Notify() on these respective devices. Also, does dmesg indicate the
presence of a fixed-feature power button?

Regards -- Andy


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn