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

[Pavel Machek]

Hi!

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

Unless it was in obsolete-feature-removal file for a year.... changing userspace
interface is bad idea in the middle of stable series.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

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

[Pavel Troller]

> I deleted /proc/acpi/button on purpose,
> did you have a use for those files?
> 
Hi Len!
  I already wrote 2 mails that I have use for the LID switch status file and
that I don't know how to handle its absence. However, they seem to be dropped
on the floor somewhere :-).
  BTW I have written a small C program which uses dev_acpi module and
evaluates an object, which I'm using to evaluade the _LID method, thus reading
the status of the switch. However, I think that this should be done by the
kernel. So at least, if the buttons allow to read their status, I'm voting for
keeping the possibility to read it.
                                  With regards, Pavel Troller

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] 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

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

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