RE: [gpm] Untangling the sleep hotkey mess

RE: [gpm] Untangling the sleep hotkey mess

[Yu, Luming]

 

>-----Original Message-----
>From: Richard Hughes [mailto:hughsient-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 
>Sent: 2006年1月9日 9:22
>To: Yu, Luming
>Cc: Matthew Garrett; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; 
>gnome-power-manager-list-rDKQcyrBJuzYtjvyW6yDsg@public.gmane.org; hal-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; 
>desktop_portables-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
>Subject: Re: [gpm] Untangling the sleep hotkey mess
>
>On Mon, 2006-01-09 at 09:10 +0800, Yu Luming wrote:
>> >  3. Use the new acpi kernel hotkeys stuff -- not that I 
>really understand
>> >  the interface, nor how to use it correctly. Plus I'm not 
>sure how much
>> >  of the vendor kernel modules can use this new interface, 
>or if it's
>> >  suitable. It all seemed a bit fragile last time I looked.
>> 
>> Please take a look at 
>> http://bugzilla.kernel.org/show_bug.cgi?id=5749
>> 
>> There are some examples to use hotkey.c for specific laptops 
>with dedicated
>> hotkey acpi device objects , and dedicated AML methods.
>> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c3
>> can be used to replace sony_acpi.c
>> 
>> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c4
>> can be used to support brightness control for panasonic laptop.
>> 
>> This patch: http://bugzilla.kernel.org/show_bug.cgi?id=5749#c5
>> can be used to support brighness contrl for ASUS laptop.
>> 
>> Please notes, I will update these patch against len's 
>testing tree, and 
>> ask for inclusion.
>
>Why do we want to use the new hotkey stuff when we can just process all
>the events in userspace using acpi events? The hotkey stuff seems
>overcomplicated and fragile in my opinion.
>
>Sending and receiving :::data:in:some::odd:format seems a 
>little unusual
>to me when we can just listen for the event in one place (like HAL) --
>but then maybe I don't understand all the details. It's not 
>like we will
>have different programs registering for different acpi button events,
>right?

The hotkey.c is NOT like what you said above.
It is used to support dedicated hotkey device and dedicated hotkey AML methods
that are used by ODM to implement hotkey function on their own laptops.
As for hotkey event, hotkey.c doesn't handle it yet.  
And so-called event_num in hotkey.c are mainly used as a key for searching and storing.
 
>
>Richard.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 09:37:01AM +0800, Yu, Luming wrote:

> The hotkey.c is NOT like what you said above.
> It is used to support dedicated hotkey device and dedicated hotkey AML methods
> that are used by ODM to implement hotkey function on their own laptops.
> As for hotkey event, hotkey.c doesn't handle it yet.  
> And so-called event_num in hotkey.c are mainly used as a key for searching and storing.

Can we please stop all this madness of trying to support twenty thousand 
weird and wonderful laptop configurations in the kernel, merge dev_acpi 
instead and then do it all in userspace? It strikes me as massively more 
maintainable. That way we don't need vendors to patch kernels every time 
a manufacturer tweaks something - a small userspace update can be pushed 
out instead.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Yu Luming]

On Monday 09 January 2006 09:43, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 09:37:01AM +0800, Yu, Luming wrote:
>  > The hotkey.c is NOT like what you said above.
>  > It is used to support dedicated hotkey device and dedicated hotkey AML
>  > methods that are used by ODM to implement hotkey function on their own
>  > laptops. As for hotkey event, hotkey.c doesn't handle it yet.
>  > And so-called event_num in hotkey.c are mainly used as a key for
>  > searching and storing.
>
>  Can we please stop all this madness of trying to support twenty thousand
>  weird and wonderful laptop configurations in the kernel, merge dev_acpi
>  instead and then do it all in userspace? It strikes me as massively more
>  maintainable. That way we don't need vendors to patch kernels every time
>  a manufacturer tweaks something - a small userspace update can be pushed
>  out instead.
>
>  --
>  Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

If you don't like the configure data in kernel source,  it can be moved to 
userspace. 

Re: dev_acpi:
The key point is AML code shouldn't be exposed in userspace. It is too ugly.

At this point, I admit hotkey.c is ugly too in the current stage.
But, it is because there are NOT standard defined  in ACPI spec, or ODMs just
ignore the Spec (for example, ACPI  Video Extension). 

-- 
Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 10:19:00AM +0800, Yu Luming wrote:

> Re: dev_acpi:
> The key point is AML code shouldn't be exposed in userspace. It is too ugly.

It may be ugly, but it /works/. We can't predict what vendors will do in 
terms of providing hotkey support in future, and exposing a limited 
interface to userspace would probably just result in it having to be 
extended later on, which again forces us into kernel patching.

With my Ubuntu hat on:

dev_acpi would make life a lot easier for us than the current solutions. 
A single userspace application has the advantage that it can be 
maintained in a nice cross-distribution way, and we can rapidly fold in 
extra support based on testing reports.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Yu Luming]

On Monday 09 January 2006 10:30, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 10:19:00AM +0800, Yu Luming wrote:
>  > Re: dev_acpi:
>  > The key point is AML code shouldn't be exposed in userspace. It is too
>  > ugly.
>
>  It may be ugly, but it /works/. We can't predict what vendors will do in
>  terms of providing hotkey support in future, and exposing a limited
>  interface to userspace would probably just result in it having to be
>  extended later on, which again forces us into kernel patching.
They should come up with some kinds of specs for hotkey in the future.
Otherwise, the problem won't go away.

>
>  With my Ubuntu hat on:
>
>  dev_acpi would make life a lot easier for us than the current solutions.
>  A single userspace application has the advantage that it can be
>  maintained in a nice cross-distribution way, and we can rapidly fold in
>  extra support based on testing reports.
Comparing with generic hotkey solution, dev_acpi solution cannot prevent any 
trouble in terms of supportability, and manageability.

For dev_acpi,  you won't need kernel patch. But you need to know everything in 
AML world from user space.

For hotkey.c, there is an auto-load-call-back function that will automatically 
detect and install configure data based on well-known acpi device object's 
PNP ID, and well-known hotkey AML method names.
And the manual configure interface is intended to be used as debug tool.

So, if you use hotkey.c you don't need to know anything in AML world from user 
space, if you are lucky. I expect in the future, the well-know acpi device 
PNP ID, and well-know AML methods names would become part of ACPI spec.

PS.  According to my testing, windows do have platform specific hotkey 
drivers.

>
>  --
>  Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-- 
Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 11:13:15AM +0800, Yu Luming wrote:

> Comparing with generic hotkey solution, dev_acpi solution cannot prevent any 
> trouble in terms of supportability, and manageability.
> 
> For dev_acpi,  you won't need kernel patch. But you need to know everything in 
> AML world from user space.

We need to know that in any case. The difference is that in the kernel 
case, adding support for new hotkeys requires upgrading the kernel. In 
the case of it adding a new button type that hasn't been seen before, it 
also requires upgrading userspace. If we do it all in userspace, we only 
have one application to fix up in most cases.

> PS.  According to my testing, windows do have platform specific hotkey 
> drivers.

In the Windows world, vendors can provide customised distributions on a 
per-laptop basis. That's not practical in the Linux world.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Yu Luming]

On Monday 09 January 2006 11:27, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 11:13:15AM +0800, Yu Luming wrote:
>  > Comparing with generic hotkey solution, dev_acpi solution cannot prevent
>  > any trouble in terms of supportability, and manageability.
>  >
>  > For dev_acpi,  you won't need kernel patch. But you need to know
>  > everything in AML world from user space.
>
>  We need to know that in any case. The difference is that in the kernel
>  case, adding support for new hotkeys requires upgrading the kernel. In
From practical point of view,  the acpi hotkey won't change for a quite 
long period. For example, I cannot find too much changes on acpi hotkey from
Thinkpad T21 and Thinkpad T42.  And, I don't see any reason for ODM to 
change their well-know ACPI device PNP ID and well-know AML methods names for
acpi hotkey on new platfrom, because they can just implement any platform 
changes in AML code. 
 
>  the case of it adding a new button type that hasn't been seen before, it
>  also requires upgrading userspace. If we do it all in userspace, we only
>  have one application to fix up in most cases.

>
>  > PS.  According to my testing, windows do have platform specific hotkey
>  > drivers.
>
>  In the Windows world, vendors can provide customised distributions on a
>  per-laptop basis. That's not practical in the Linux world.
My points is that if hotkey.c become sucessful, then linux won't need those 
platform specific hotkey drivers for common hotkeys  such as brightness 
control, volume control, and output switch.. 
Does it make sense?

Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 11:55:24AM +0800, Yu Luming wrote:

> From practical point of view,  the acpi hotkey won't change for a quite 
> long period. For example, I cannot find too much changes on acpi hotkey from
> Thinkpad T21 and Thinkpad T42.  And, I don't see any reason for ODM to 
> change their well-know ACPI device PNP ID and well-know AML methods names for
> acpi hotkey on new platfrom, because they can just implement any platform 
> changes in AML code. 

Toshiba have entirely changed their ACPI hotkey setup with the new Tecra 
range. The BIOS bears almost no resemblance to the previous one. Sony 
have changed their brightness handling code in newer machines - it seems 
to be impossible to change it through ACPI now.

Rule 1 of laptops: Vendors will do unpredictable and hard to understand 
things. They don't consider what they're providing to be well-known. As 
far as vendors are concerned, it's an internal implementation detail and 
they'll change it whenever they feel like it.

If Intel would like a single driver able to support all future laptops, 
then Intel need to specify hotkey behaviour in the ACPI spec and refuse 
to allow people to claim ACPI compliance unless they implement it. Until 
that happens there's no way of claiming that this stuff will just carry 
on working.

> >  In the Windows world, vendors can provide customised distributions on a
> >  per-laptop basis. That's not practical in the Linux world.
> My points is that if hotkey.c become sucessful, then linux won't need those 
> platform specific hotkey drivers for common hotkeys  such as brightness 
> control, volume control, and output switch.. 

It *will*, it's just they'll all be in a single driver that special 
cases a bunch of manufacturers. The fact that all of this is in one file 
rather than 20 doesn't make it inherently better.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Desktop_portables] Re: [gpm] Untangling the sleep hotkey mess

[Karol Kozimor]

Thus wrote Yu Luming:
> >From practical point of view,  the acpi hotkey won't change for a quite 
> long period. For example, I cannot find too much changes on acpi hotkey from
> Thinkpad T21 and Thinkpad T42.  And, I don't see any reason for ODM to 
> change their well-know ACPI device PNP ID and well-know AML methods names for
> acpi hotkey on new platfrom, because they can just implement any platform 
> changes in AML code. 

Tell me more...

There's already 3 or 4 major variations of method layout for ASUS laptops
hotkey device, subtle differences like method name changes notwithstanding.
One of the reasons the driver's development lags so much is that the
support code has become such a mess. I really wish their BIOS teams would
settle on one scheme, and there was a point when I thought they'd done just
that, but in the end it just didn't happen.

Personally, I'd love to see all the model support code moved to userspace,
and while I think it might just be possible using the generic driver, I
still didn't manage to make the necessary changes.

So as not to be completely off-topic: users expect (and I'm speaking from
experience here) the buttons to be able to generate both system-wide (as in
suspend) and per-session (as in launch firefox) events and given that, I
think uinput is a good direction, provided we keep acpid or at least a
functional replacement.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Desktop_portables] Re: [gpm] Untangling the sleep hotkey mess

[Yu Luming]

On Monday 09 January 2006 15:14, Karol Kozimor wrote:
> Thus wrote Yu Luming:
>  > >From practical point of view,  the acpi hotkey won't change for a quite
>  >
>  > long period. For example, I cannot find too much changes on acpi hotkey
>  > from Thinkpad T21 and Thinkpad T42.  And, I don't see any reason for ODM
>  > to change their well-know ACPI device PNP ID and well-know AML methods
>  > names for acpi hotkey on new platfrom, because they can just implement
>  > any platform changes in AML code.
>
>  Tell me more...

I just want to say the hot-keys on keyboard for brightness, sound
volume, display output switching won't change too much, 
because user needs these buttons. And almost all laptops implement them.

For each ODM, if they implement hot-keys with dedicated ACPI devices and
dedicated AML methods. It doesn't make any sense to change
the name on new platforms for supporting same hot-keys.
>
>  There's already 3 or 4 major variations of method layout for ASUS laptops
>  hotkey device, subtle differences like method name changes
> notwithstanding. One of the reasons the driver's development lags so much
> is that the support code has become such a mess. I really wish their BIOS
> teams would settle on one scheme, and there was a point when I thought
> they'd done just that, but in the end it just didn't happen.
>
We need a hotkey spec for those well-know hot-keys now,
Then, we can look forward to a clean hotkey driver in the future.

Thanks,
Luming

-- 
Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Desktop_portables] Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Mon, 2006-01-09 at 15:47 +0800, Yu Luming wrote:
> On Monday 09 January 2006 15:14, Karol Kozimor wrote:
> > Thus wrote Yu Luming:
> >  > >From practical point of view,  the acpi hotkey won't change for a quite
> >  >
> >  > long period. For example, I cannot find too much changes on acpi hotkey
> >  > from Thinkpad T21 and Thinkpad T42.  And, I don't see any reason for ODM
> >  > to change their well-know ACPI device PNP ID and well-know AML methods
> >  > names for acpi hotkey on new platfrom, because they can just implement
> >  > any platform changes in AML code.
> >
> >  Tell me more...
> 
> I just want to say the hot-keys on keyboard for brightness, sound
> volume, display output switching won't change too much, 
> because user needs these buttons. And almost all laptops implement them.
> 
> For each ODM, if they implement hot-keys with dedicated ACPI devices and
> dedicated AML methods. It doesn't make any sense to change
> the name on new platforms for supporting same hot-keys.
> >
> >  There's already 3 or 4 major variations of method layout for ASUS laptops
> >  hotkey device, subtle differences like method name changes
> > notwithstanding. One of the reasons the driver's development lags so much
> > is that the support code has become such a mess. I really wish their BIOS
> > teams would settle on one scheme, and there was a point when I thought
> > they'd done just that, but in the end it just didn't happen.
> >
> We need a hotkey spec for those well-know hot-keys now,
> Then, we can look forward to a clean hotkey driver in the future.

What spec would that be? Surely we *just* need a way to get the hotkeys
to userspace as early as possible? Be they KEY_BRIGHTNESSDOWN or some
random value like 0x140.
Why make this complicated, or am I missing a trick?

Thanks, Richard.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Richard Hughes]

On Mon, 2006-01-09 at 02:30 +0000, Matthew Garrett wrote:
> On Mon, Jan 09, 2006 at 10:19:00AM +0800, Yu Luming wrote:
> 
> > Re: dev_acpi:
> > The key point is AML code shouldn't be exposed in userspace. It is too ugly.
> 
> It may be ugly, but it /works/. We can't predict what vendors will do in 
> terms of providing hotkey support in future, and exposing a limited 
> interface to userspace would probably just result in it having to be 
> extended later on, which again forces us into kernel patching.
> 
> With my Ubuntu hat on:
> 
> dev_acpi would make life a lot easier for us than the current solutions. 
> A single userspace application has the advantage that it can be 
> maintained in a nice cross-distribution way, and we can rapidly fold in 
> extra support based on testing reports.

With my Redhat on*:

I think maybe dev_acpi may work well for the power-user case (if you
know *exactly* what you are doing), but just using the simple acpi
events (like we can do now on some machines) works well. This means that
we can get bug reports from users for obscure machines and keyboards
just from looking at an acpid log. Adding support for different keys can
be done just by adding values to an FDI xml file, or a small addon.
I think trying to pre-process the information in the kernel is a bad
thing to do -- debugging, and getting a user to test a kernel patch is
much harder than a similar userspace patch.

In my ideal world:

* All ACPI keyboard events would come through /proc/acpi/event as hkey's
* You could change the brightness on *any* lcdpanel by doing a simple
  #echo 3 > /proc/acpi/video/brightness
* You could get the number of brightness levels supported doing
  #cat /proc/acpi/video/brightness_levels

Richard.

* I don't work for Redhat, but I do lots of work with Fedora and HAL.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gpm] Untangling the sleep hotkey mess

[Dmitry Torokhov]

On 1/9/06, Richard Hughes <hughsient@gmail.com> wrote:
>
> * All ACPI keyboard events would come through /proc/acpi/event as hkey's
> * You could change the brightness on *any* lcdpanel by doing a simple
>  #echo 3 > /proc/acpi/video/brightness
> * You could get the number of brightness levels supported doing
>  #cat /proc/acpi/video/brightness_levels
>

And what do you do if:

1. You don't have ACPI available (other platforms)
2. APM works better for some reason
3. The hotkey (sleep, power, etc) does not come from ACPI?

--
Dmitry

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 04:14:40PM -0500, Dmitry Torokhov wrote:
> And what do you do if:
> 
> 1. You don't have ACPI available (other platforms)
> 2. APM works better for some reason
> 3. The hotkey (sleep, power, etc) does not come from ACPI?

With most APM machines, pressing the hotkey causes the BIOS to send a 
system suspend event. There's no real way for the OS to tell what's 
caused this (it could be low battery, a closed lid or a sleep key press) 
and so the correct thing to do is to tell userspace that a suspend is 
about to happen and then do it.

But yes, PMU sleep requests are (last time I checked) generally managed 
by keycode 142 being generated and userspace dealing with it. There's no 
equivalent to /proc/acpi/events. This is why I think standardising on 
the input layer is a more sensible approach than trying to turn input 
events into acpi ones.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [gpm] Untangling the sleep hotkey mess

[Dmitry Torokhov]

On 1/9/06, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Mon, Jan 09, 2006 at 04:14:40PM -0500, Dmitry Torokhov wrote:
> > And what do you do if:
> >
> > 1. You don't have ACPI available (other platforms)
> > 2. APM works better for some reason
> > 3. The hotkey (sleep, power, etc) does not come from ACPI?
>
> With most APM machines, pressing the hotkey causes the BIOS to send a
> system suspend event. There's no real way for the OS to tell what's
> caused this (it could be low battery, a closed lid or a sleep key press)
> and so the correct thing to do is to tell userspace that a suspend is
> about to happen and then do it.
>
> But yes, PMU sleep requests are (last time I checked) generally managed
> by keycode 142 being generated and userspace dealing with it. There's no
> equivalent to /proc/acpi/events. This is why I think standardising on
> the input layer is a more sensible approach than trying to turn input
> events into acpi ones.
>

I probably was not clear in my original message. The new input handler
for ACPI would be only used for compatibility with cirrent
installations relying on ACPID. This will allow gradual conversion of
ACPI drivers to use input layer instead of sending events dircetly to
/proc/acpi/events.

OTOH there should probably be anotehr generic power interface
filtering out power-related input events from the stream of all input
events in the system and making them available to userspace without
requiring applications (be it individual applications or HAL) to open
zillion of raw /dev/input/evenX devices.

--
Dmitry

Re: [gpm] Untangling the sleep hotkey mess

[Matthew Garrett]

On Mon, Jan 09, 2006 at 04:52:11PM -0500, Dmitry Torokhov wrote:

> I probably was not clear in my original message. The new input handler
> for ACPI would be only used for compatibility with cirrent
> installations relying on ACPID. This will allow gradual conversion of
> ACPI drivers to use input layer instead of sending events dircetly to
> /proc/acpi/events.

Ah, I see what you mean. However, there's still some slight awkwardness 
here, since userspace will be expecting the events to come from the 
button driver (the regexp used is generally button[ /]sleep), and 
that'll be registered even if there's no sleep button (the lid switch 
and power button are still handled via it). I don't believe you can 
register two drivers with the same name, so without gross hacks I can't 
see an easy way to provide this functionality through /proc/acpi without 
requiring userspace to be fixed up /anyway/...

> OTOH there should probably be anotehr generic power interface
> filtering out power-related input events from the stream of all input
> events in the system and making them available to userspace without
> requiring applications (be it individual applications or HAL) to open
> zillion of raw /dev/input/evenX devices.

Sure. As mentioned before, we basically just want keycodes 116, 142 and 
205 (POWER, SLEEP and SUSPEND) - I guess that's not too difficult?
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html