ACPI buttons in 2.6.12-rc4-mm2

ACPI buttons in 2.6.12-rc4-mm2

[Cameron Harris]

I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory
doesn't exist...

$ gzcat /proc/config.gz | grep BUTTON
CONFIG_ACPI_BUTTON=y


And the kernel is detecting my buttons....

$ dmesg | grep LID
[4294668.236000] ACPI: Lid Switch [LID]
$ dmesg | grep PWR
[4294668.235000] ACPI: Power Button (FF) [PWRF]
[4294668.235000] ACPI: Power Button (CM) [PWRB]
$ dmesg | grep SLP
[4294668.236000] ACPI: Sleep Button (CM) [SLPB]
$ find /sys -name "*LID*"
/sys/firmware/acpi/namespace/ACPI/_SB/LID
$ find /sys -name "*PWR*"
/sys/firmware/acpi/namespace/ACPI/_SB/PWRB
/sys/firmware/acpi/namespace/ACPI/PWRF
$ find /sys -name "*SLP*"
/sys/firmware/acpi/namespace/ACPI/_SB/SLPB

All the directories found are empty.

My dsdt is a bit screwed (damn microsoft.. I'm gonna fix it and see if
it make a difference) but it did work before.

$ dmesg | grep DSDT # fyi
[4294667.296000] ACPI: DSDT (v001 Clevo     648FX 0x06040000 MSFT
0x0100000e) @ 0x00000000

Also, sleep doesn't work and has never worked, but that could be
because of the dsdt maybe.

-- 
Cameron Harris

Re: ACPI buttons in 2.6.12-rc4-mm2

[Len Brown]

On Sun, 2005-05-22 at 07:25 -0400, Cameron Harris wrote:
> I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory
> doesn't exist...

I deleted /proc/acpi/button on purpose,
did you have a use for those files?

Note that over time everything in /proc/acpi is
going away.  In this case, there didn't seem to be
a case for making appear in /sys.

thanks,
-Len

Re: ACPI buttons in 2.6.12-rc4-mm2

[Matthew Garrett]

Len Brown <len.brown@intel.com> wrote:

> I deleted /proc/acpi/button on purpose,
> did you have a use for those files?

There are various cases where it's useful to know whether a laptop is
shut or not, and /proc/acpi/button seems to be the only place where that
information is made available at the moment.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

RE: [ACPI] Re: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

I agree that the value of _LID can be usefult to user-space
and I'll be sure it is restored as a property of the lid device
under sysfs -- available as a simple file read like it
was under /proc.

thanks,
-Len

Re: ACPI buttons in 2.6.12-rc4-mm2

[Andrew Morton]

Len Brown <len.brown@intel.com> wrote:
>
> On Sun, 2005-05-22 at 07:25 -0400, Cameron Harris wrote:
> > I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory
> > doesn't exist...
> 
> I deleted /proc/acpi/button on purpose,
> did you have a use for those files?

Can we put it back, please?

> Note that over time everything in /proc/acpi is
> going away.  In this case, there didn't seem to be
> a case for making appear in /sys.

That'll be hard.  I guess we could add the new /sys entries, make sure that
userspace tool developers have migrated and then remove the /proc entries
in a year or so.

We cannot go ripping out stuff which applications and users are currently
using without quite a lot of preparation.

RE: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

>Len Brown <len.brown@intel.com> wrote:
>> I deleted /proc/acpi/button on purpose,
>> did you have a use for those files?
>
>Can we put it back, please?

of course.

>We cannot go ripping out stuff which applications and users 
>are currently using without quite a lot of preparation.

Agreed.  Although the implementation of the /proc lid status
file is fundamentally flawed in that even its name in /proc
is able to change and thus it is a totally bogus user-space API,
it was not thoughtful to delete it.

I'm open to suggestions on how to approach this transition.
I can make ACPI_PROC a static build option -- what else
can I do to ease the transition in this, our stable release?

thanks,
-Len

Re: ACPI buttons in 2.6.12-rc4-mm2

[Andrew Morton]

"Brown, Len" <len.brown@intel.com> wrote:
>
> 
> >Len Brown <len.brown@intel.com> wrote:
> >> I deleted /proc/acpi/button on purpose,
> >> did you have a use for those files?
> >
> >Can we put it back, please?
> 
> of course.

Thanks.

> >We cannot go ripping out stuff which applications and users 
> >are currently using without quite a lot of preparation.
> 
> Agreed.  Although the implementation of the /proc lid status
> file is fundamentally flawed in that even its name in /proc
> is able to change and thus it is a totally bogus user-space API,
> it was not thoughtful to delete it.
> 
> I'm open to suggestions on how to approach this transition.
> I can make ACPI_PROC a static build option -- what else
> can I do to ease the transition in this, our stable release?

Well I don't know how awkward this would be from an implementation POV, but
can we just leave the legacy /proc stuff there until the /sys interface is
all in place and userspace is upgraded?  Then kill all the /proc stuff
later?

We could also print a rude message the first time someone tries to use a
deprecated /proc file, just to help push the userspace tool developers
along.  Although I note that sys_bdflush() is still with us ;)

RE: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

 
>> I'm open to suggestions on how to approach this transition.
>> I can make ACPI_PROC a static build option -- what else
>> can I do to ease the transition in this, our stable release?
>
>Well I don't know how awkward this would be from an 
>implementation POV, but can we just leave the legacy
>/proc stuff there until the /sys interface is
>all in place and userspace is upgraded?
>Then kill all the /proc stuff later?
>
>We could also print a rude message the first time someone 
>tries to use a deprecated /proc file, just to help push the
>userspace tool developers along.
>Although I note that sys_bdflush() is still with us ;)

/proc/acpi/event
/proc/acpi/sleep
are used the most.

/proc/acpi/<drivername>/<BIOS devname>/* are really screwed up
in that <BIOS devname> is an arbitrary internal BIOS string
that should have never been exposed to userspace.  Instead
we should have done what sysfs does -- look at the _type_
of device and then simply add a number to it -- cpu0, cpu1
so that a program could actually find stuff.

I'm constantly nagged that this layer in the /proc/tree
had arbitrary strings in pathnames.  Also, the /proc
file handling code is buggy -- so it wastes my time
maintaining it, when it should not exist at all...
Restoring the /proc code to the button driver will
increase button.c in size by over 60%...

So I'm in favor of whatever solution makes it all go away
as soon as possible.

-Len

Re: ACPI buttons in 2.6.12-rc4-mm2

[Bill Davidsen]

Brown, Len wrote:
> I agree that the value of _LID can be usefult to user-space
> and I'll be sure it is restored as a property of the lid device
> under sysfs -- available as a simple file read like it
> was under /proc.

You're missing the point, removing the /proc feature breaks existing 
code. You can add new features in /sys as you like, but when you remove 
existing featires you break system for no benefit.