a question about lid input device

a question about lid input device

[Zhang Rui]

Hi, Dmitry,

I have a question about the ACPI lid button input device.

By reading commit c0968f0e, I think the acpi lid button is registered as
a switch (EV_SW set), and the lid status is reported via SW_LID bit,
e.g. lid closed when SW_LID is set and vice versa.
Then we update the lid switch status when a Lid notification comes.
right?

Then, IMO, userspace can get the lid status
via /sys/class/input/inputX/uevent, right?

here is a the output of this file on my laptop,
/sys/class/input/input1/modalias:input:b0019v0000p0005e0000-e0,5,kramlsfw0,
/sys/class/input/input1/name:Lid Switch
/sys/class/input/input1/phys:PNP0C0D/button/input0
/sys/class/input/input1/uevent:PRODUCT=19/0/5/0
/sys/class/input/input1/uevent:NAME="Lid Switch"
/sys/class/input/input1/uevent:PHYS="PNP0C0D/button/input0"
/sys/class/input/input1/uevent:EV==21
/sys/class/input/input1/uevent:SW==1
/sys/class/input/input1/uevent:MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0,

Lid is opened but SW is set, I tried to close/open the lid and found
that this bit never changes. is there something I misunderstand? can we
get the lid status in userspace?

thanks,
rui

Re: a question about lid input device

[Henrique de Moraes Holschuh]

On Sun, 13 Jun 2010, Zhang Rui wrote:
> Then we update the lid switch status when a Lid notification comes.
> right?

Yes.

> Then, IMO, userspace can get the lid status
> via /sys/class/input/inputX/uevent, right?

No, only through an IOCTL.

> /sys/class/input/input1/uevent:EV==21

That's an bitmap of al EV_EV it supports.

> /sys/class/input/input1/uevent:SW==1

That's an bitmap of al EV_SW it supports.

> Lid is opened but SW is set, I tried to close/open the lid and found
> that this bit never changes. is there something I misunderstand? can we
> get the lid status in userspace?

IOCTL(), only.

Since nobody got a input-utils standard package (or added something to
util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
shell scripts that want to query EV_SW state...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: a question about lid input device

[Len Brown]

Dmitry,
Is there a reason not to simply add a "state" attribute
to a LID input device?


thanks,
Len Brown, Intel Open Source Technology Center

On Sun, 13 Jun 2010, Henrique de Moraes Holschuh wrote:

> On Sun, 13 Jun 2010, Zhang Rui wrote:
> > Then we update the lid switch status when a Lid notification comes.
> > right?
> 
> Yes.
> 
> > Then, IMO, userspace can get the lid status
> > via /sys/class/input/inputX/uevent, right?
> 
> No, only through an IOCTL.
> 
> > /sys/class/input/input1/uevent:EV==21
> 
> That's an bitmap of al EV_EV it supports.
> 
> > /sys/class/input/input1/uevent:SW==1
> 
> That's an bitmap of al EV_SW it supports.
> 
> > Lid is opened but SW is set, I tried to close/open the lid and found
> > that this bit never changes. is there something I misunderstand? can we
> > get the lid status in userspace?
> 
> IOCTL(), only.
> 
> Since nobody got a input-utils standard package (or added something to
> util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
> shell scripts that want to query EV_SW state...
> 

Re: a question about lid input device

[Dmitry Torokhov]

On Mon, Jun 21, 2010 at 09:56:37PM -0400, Len Brown wrote:
> Dmitry,
> Is there a reason not to simply add a "state" attribute
> to a LID input device?
> 

Len,

There is no LED input device, there is an input device that happens to
report EV_SW/SW_LID state. If we did that we'd need to add attributes
for all types of switches, keys, current values of REL and ABS axis,
min/max/fuzz/flat settings of ABS axis and so forth that input device
might report. I do not think it is a good idea.

> 
> thanks,
> Len Brown, Intel Open Source Technology Center
> 
> On Sun, 13 Jun 2010, Henrique de Moraes Holschuh wrote:
> 
> > On Sun, 13 Jun 2010, Zhang Rui wrote:
> > > Then we update the lid switch status when a Lid notification comes.
> > > right?
> > 
> > Yes.
> > 
> > > Then, IMO, userspace can get the lid status
> > > via /sys/class/input/inputX/uevent, right?
> > 
> > No, only through an IOCTL.
> > 
> > > /sys/class/input/input1/uevent:EV==21
> > 
> > That's an bitmap of al EV_EV it supports.
> > 
> > > /sys/class/input/input1/uevent:SW==1
> > 
> > That's an bitmap of al EV_SW it supports.
> > 
> > > Lid is opened but SW is set, I tried to close/open the lid and found
> > > that this bit never changes. is there something I misunderstand? can we
> > > get the lid status in userspace?
> > 
> > IOCTL(), only.
> > 
> > Since nobody got a input-utils standard package (or added something to
> > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
> > shell scripts that want to query EV_SW state...
> > 
> 

-- 
Dmitry

Re: a question about lid input device

[Zhang Rui]

On Sun, 2010-07-04 at 16:35 +0800, Dmitry Torokhov wrote:
> On Mon, Jun 21, 2010 at 09:56:37PM -0400, Len Brown wrote:
> > Dmitry,
> > Is there a reason not to simply add a "state" attribute
> > to a LID input device?
> > 
> 
> Len,
> 
> There is no LED input device, there is an input device that happens to
> report EV_SW/SW_LID state. If we did that we'd need to add attributes
> for all types of switches, keys, current values of REL and ABS axis,
> min/max/fuzz/flat settings of ABS axis and so forth that input device
> might report. I do not think it is a good idea.
> 
I agree.
How about adding a field in uevent file that reports the switch status?

thanks,
rui
> > 
> > thanks,
> > Len Brown, Intel Open Source Technology Center
> > 
> > On Sun, 13 Jun 2010, Henrique de Moraes Holschuh wrote:
> > 
> > > On Sun, 13 Jun 2010, Zhang Rui wrote:
> > > > Then we update the lid switch status when a Lid notification comes.
> > > > right?
> > > 
> > > Yes.
> > > 
> > > > Then, IMO, userspace can get the lid status
> > > > via /sys/class/input/inputX/uevent, right?
> > > 
> > > No, only through an IOCTL.
> > > 
> > > > /sys/class/input/input1/uevent:EV==21
> > > 
> > > That's an bitmap of al EV_EV it supports.
> > > 
> > > > /sys/class/input/input1/uevent:SW==1
> > > 
> > > That's an bitmap of al EV_SW it supports.
> > > 
> > > > Lid is opened but SW is set, I tried to close/open the lid and found
> > > > that this bit never changes. is there something I misunderstand? can we
> > > > get the lid status in userspace?
> > > 
> > > IOCTL(), only.
> > > 
> > > Since nobody got a input-utils standard package (or added something to
> > > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
> > > shell scripts that want to query EV_SW state...
> > > 
> > 
> 

Re: a question about lid input device

[Dmitry Torokhov]

On Jul 4, 2010, at 6:09 PM, Zhang Rui <rui.zhang@intel.com> wrote:

> On Sun, 2010-07-04 at 16:35 +0800, Dmitry Torokhov wrote:
>> On Mon, Jun 21, 2010 at 09:56:37PM -0400, Len Brown wrote:
>>> Dmitry,
>>> Is there a reason not to simply add a "state" attribute
>>> to a LID input device?
>>>
>>
>> Len,
>>
>> There is no LED input device, there is an input device that happens  
>> to
>> report EV_SW/SW_LID state. If we did that we'd need to add attributes
>> for all types of switches, keys, current values of REL and ABS axis,
>> min/max/fuzz/flat settings of ABS axis and so forth that input device
>> might report. I do not think it is a good idea.
>>
> I agree.
> How about adding a field in uevent file that reports the switch  
> status?
>


I think if you can listen to uevents you can just as easily open /dev/ 
input/eventX and listen to proper input events.

Thanks.

-- 
Dmitry

Re: a question about lid input device

[Zhang Rui]

On Mon, 2010-07-05 at 09:28 +0800, Dmitry Torokhov wrote:
> On Jul 4, 2010, at 6:09 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> 
> > On Sun, 2010-07-04 at 16:35 +0800, Dmitry Torokhov wrote:
> >> On Mon, Jun 21, 2010 at 09:56:37PM -0400, Len Brown wrote:
> >>> Dmitry,
> >>> Is there a reason not to simply add a "state" attribute
> >>> to a LID input device?
> >>>
> >>
> >> Len,
> >>
> >> There is no LED input device, there is an input device that happens  
> >> to
> >> report EV_SW/SW_LID state. If we did that we'd need to add attributes
> >> for all types of switches, keys, current values of REL and ABS axis,
> >> min/max/fuzz/flat settings of ABS axis and so forth that input device
> >> might report. I do not think it is a good idea.
> >>
> > I agree.
> > How about adding a field in uevent file that reports the switch  
> > status?
> >
> 
> 
> I think if you can listen to uevents you can just as easily open /dev/ 
> input/eventX and listen to proper input events.
> 
the question is users may want to get the lid switch STATUS,
asynchronously.

thank,
rui

Re: a question about lid input device

[Henrique de Moraes Holschuh]

On Mon, 05 Jul 2010, Zhang Rui wrote:
> > I think if you can listen to uevents you can just as easily open /dev/ 
> > input/eventX and listen to proper input events.
> > 
> the question is users may want to get the lid switch STATUS,
> asynchronously.

More often than not, you need to know the current state when dealing
with EV_SW, to be able to do anything sensbile with it in GUIs, etc.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: a question about lid input device

[Paul Fox]

henrique de moraes holschuh wrote:
 > On Mon, 05 Jul 2010, Zhang Rui wrote:
 > > > I think if you can listen to uevents you can just as easily open /dev/ 
 > > > input/eventX and listen to proper input events.
 > > > 
 > > the question is users may want to get the lid switch STATUS,
 > > asynchronously.
 > 
 > More often than not, you need to know the current state when dealing
 > with EV_SW, to be able to do anything sensbile with it in GUIs, etc.

indeed, this is true for almost any event-on-change interface -- tablet mode,
AC insertion, etc.  the change event alone is never enough.

paul
=---------------------
 paul fox, pgf@laptop.org

Re: a question about lid input device

[Dmitry Torokhov]

On Mon, Jul 05, 2010 at 04:49:45PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 05 Jul 2010, Zhang Rui wrote:
> > > I think if you can listen to uevents you can just as easily open /dev/ 
> > > input/eventX and listen to proper input events.
> > > 
> > the question is users may want to get the lid switch STATUS,
> > asynchronously.
> 
> More often than not, you need to know the current state when dealing
> with EV_SW, to be able to do anything sensbile with it in GUIs, etc.
> 

I understand the need of getting the current state of a lid
switch/key/etc (and for that someone just need to write a utility
useable from shell scripts). But I do not understand how adding switch
state to uevents (that are emitted normally only when a new device is
created) will help here.

-- 
Dmitry

Re: a question about lid input device

[Zhang Rui]

On Tue, 2010-07-06 at 04:27 +0800, Dmitry Torokhov wrote:
> On Mon, Jul 05, 2010 at 04:49:45PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 05 Jul 2010, Zhang Rui wrote:
> > > > I think if you can listen to uevents you can just as easily open /dev/ 
> > > > input/eventX and listen to proper input events.
> > > > 
> > > the question is users may want to get the lid switch STATUS,
> > > asynchronously.
> > 
> > More often than not, you need to know the current state when dealing
> > with EV_SW, to be able to do anything sensbile with it in GUIs, etc.
> > 
> 
> I understand the need of getting the current state of a lid
> switch/key/etc (and for that someone just need to write a utility
> useable from shell scripts). But I do not understand how adding switch
> state to uevents (that are emitted normally only when a new device is
> created) will help here.
> 
driver core creates a sysfs attribute for uevent. and users may query
this file to get the lid state, say:
$ cat /sys/class/input/input1/uevent 
PRODUCT=19/0/5/0
NAME="Lid Switch"
PHYS="PNP0C0D/button/input0"
EV==21
SW==1
MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0,

I'm not quite familiar with the uevent stuff, so please correct me if
I'm wrong. :)
IMO, for input switch device, it's reasonable to report the switch state
in uevent, in which HAL may also be interested. And users may get the
switch status by running "cat /sys/class/input/inputX/uevent" as well.

thanks,
rui

Re: a question about lid input device

[Dmitry Torokhov]

On Wed, Jul 07, 2010 at 11:08:05AM +0800, Zhang Rui wrote:
> On Tue, 2010-07-06 at 04:27 +0800, Dmitry Torokhov wrote:
> > On Mon, Jul 05, 2010 at 04:49:45PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Mon, 05 Jul 2010, Zhang Rui wrote:
> > > > > I think if you can listen to uevents you can just as easily open /dev/ 
> > > > > input/eventX and listen to proper input events.
> > > > > 
> > > > the question is users may want to get the lid switch STATUS,
> > > > asynchronously.
> > > 
> > > More often than not, you need to know the current state when dealing
> > > with EV_SW, to be able to do anything sensbile with it in GUIs, etc.
> > > 
> > 
> > I understand the need of getting the current state of a lid
> > switch/key/etc (and for that someone just need to write a utility
> > useable from shell scripts). But I do not understand how adding switch
> > state to uevents (that are emitted normally only when a new device is
> > created) will help here.
> > 
> driver core creates a sysfs attribute for uevent. and users may query
> this file to get the lid state, say:
> $ cat /sys/class/input/input1/uevent 
> PRODUCT=19/0/5/0
> NAME="Lid Switch"
> PHYS="PNP0C0D/button/input0"
> EV==21
> SW==1
> MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0,
> 
> I'm not quite familiar with the uevent stuff, so please correct me if
> I'm wrong. :)
> IMO, for input switch device, it's reasonable to report the switch state
> in uevent, in which HAL may also be interested. And users may get the
> switch status by running "cat /sys/class/input/inputX/uevent" as well.
> 

No, I am sorry, you are inventing a new interface. Uevents normally
signal device creation and removal and carry capabilities, not the
state; there can be more than one switch/button per device, and so on.

Just write an utility that queries state via ioctl.

Thanks,

-- 
Dmitry

Re: a question about lid input device

[Paul Fox]

henrique de moraes holschuh wrote:
 > On Sun, 13 Jun 2010, Zhang Rui wrote:
 > > Then we update the lid switch status when a Lid notification comes.
 > > right?
 > 
 > Yes.
 > 
 > > Then, IMO, userspace can get the lid status
 > > via /sys/class/input/inputX/uevent, right?
 > 
 > No, only through an IOCTL.
 > 
 > > /sys/class/input/input1/uevent:EV==21
 > 
 > That's an bitmap of al EV_EV it supports.
 > 
 > > /sys/class/input/input1/uevent:SW==1
 > 
 > That's an bitmap of al EV_SW it supports.
 > 
 > > Lid is opened but SW is set, I tried to close/open the lid and found
 > > that this bit never changes. is there something I misunderstand? can we
 > > get the lid status in userspace?
 > 
 > IOCTL(), only.
 > 
 > Since nobody got a input-utils standard package (or added something to
 > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
 > shell scripts that want to query EV_SW state...

i understand that it's not fully general, but for the case of
the lid:  is /proc/acpi/button/lid/LID/state going away?

paul
=---------------------
 paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 87.1 degrees)

Re: a question about lid input device

[Dmitry Torokhov]

On Wed, Jul 07, 2010 at 11:14:20AM -0400, Paul Fox wrote:
> henrique de moraes holschuh wrote:
>  > On Sun, 13 Jun 2010, Zhang Rui wrote:
>  > > Then we update the lid switch status when a Lid notification comes.
>  > > right?
>  > 
>  > Yes.
>  > 
>  > > Then, IMO, userspace can get the lid status
>  > > via /sys/class/input/inputX/uevent, right?
>  > 
>  > No, only through an IOCTL.
>  > 
>  > > /sys/class/input/input1/uevent:EV==21
>  > 
>  > That's an bitmap of al EV_EV it supports.
>  > 
>  > > /sys/class/input/input1/uevent:SW==1
>  > 
>  > That's an bitmap of al EV_SW it supports.
>  > 
>  > > Lid is opened but SW is set, I tried to close/open the lid and found
>  > > that this bit never changes. is there something I misunderstand? can we
>  > > get the lid status in userspace?
>  > 
>  > IOCTL(), only.
>  > 
>  > Since nobody got a input-utils standard package (or added something to
>  > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
>  > shell scripts that want to query EV_SW state...
> 
> i understand that it's not fully general, but for the case of
> the lid:  is /proc/acpi/button/lid/LID/state going away?
> 

Yes, according to feature-removal.txt ACPI procfs interface shoudl have
been gone back in 2008.

-- 
Dmitry

Re: a question about lid input device

[Paul Fox]

dmitry wrote:
 > On Wed, Jul 07, 2010 at 11:14:20AM -0400, Paul Fox wrote:
 > > henrique de moraes holschuh wrote:
 > >  > On Sun, 13 Jun 2010, Zhang Rui wrote:
 > >  > > Then we update the lid switch status when a Lid notification comes.
 > >  > > right?
 > >  > 
 > >  > Yes.
 > >  > 
 > >  > > Then, IMO, userspace can get the lid status
 > >  > > via /sys/class/input/inputX/uevent, right?
 > >  > 
 > >  > No, only through an IOCTL.
 > >  > 
 > >  > > /sys/class/input/input1/uevent:EV==21
 > >  > 
 > >  > That's an bitmap of al EV_EV it supports.
 > >  > 
 > >  > > /sys/class/input/input1/uevent:SW==1
 > >  > 
 > >  > That's an bitmap of al EV_SW it supports.
 > >  > 
 > >  > > Lid is opened but SW is set, I tried to close/open the lid and found
 > >  > > that this bit never changes. is there something I misunderstand? can we
 > >  > > get the lid status in userspace?
 > >  > 
 > >  > IOCTL(), only.
 > >  > 
 > >  > Since nobody got a input-utils standard package (or added something to
 > >  > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
 > >  > shell scripts that want to query EV_SW state...
 > > 
 > > i understand that it's not fully general, but for the case of
 > > the lid:  is /proc/acpi/button/lid/LID/state going away?
 > > 
 > 
 > Yes, according to feature-removal.txt ACPI procfs interface shoudl have
 > been gone back in 2008.

thanks.  i understand that adding sysfs entries for all the bells
and whistles on modern input devices might seem prohibitive.  on
the other hand, there are some basic interfaces that are very
usefully accessed from the shell.  i guess either way the
information is available, but having to rely on a utility package
for intermediate access always introduces new packaging
dependencies, release skew issues, etc, etc.

paul
=---------------------
 paul fox, pgf@laptop.org

Re: a question about lid input device

[Dmitry Torokhov]

On Wed, Jul 07, 2010 at 12:51:04PM -0400, Paul Fox wrote:
> dmitry wrote:
>  > On Wed, Jul 07, 2010 at 11:14:20AM -0400, Paul Fox wrote:
>  > > henrique de moraes holschuh wrote:
>  > >  > On Sun, 13 Jun 2010, Zhang Rui wrote:
>  > >  > > Then we update the lid switch status when a Lid notification comes.
>  > >  > > right?
>  > >  > 
>  > >  > Yes.
>  > >  > 
>  > >  > > Then, IMO, userspace can get the lid status
>  > >  > > via /sys/class/input/inputX/uevent, right?
>  > >  > 
>  > >  > No, only through an IOCTL.
>  > >  > 
>  > >  > > /sys/class/input/input1/uevent:EV==21
>  > >  > 
>  > >  > That's an bitmap of al EV_EV it supports.
>  > >  > 
>  > >  > > /sys/class/input/input1/uevent:SW==1
>  > >  > 
>  > >  > That's an bitmap of al EV_SW it supports.
>  > >  > 
>  > >  > > Lid is opened but SW is set, I tried to close/open the lid and found
>  > >  > > that this bit never changes. is there something I misunderstand? can we
>  > >  > > get the lid status in userspace?
>  > >  > 
>  > >  > IOCTL(), only.
>  > >  > 
>  > >  > Since nobody got a input-utils standard package (or added something to
>  > >  > util-linux) yet to do that (AFAIK anyway), it is a MAJOR annoyance for
>  > >  > shell scripts that want to query EV_SW state...
>  > > 
>  > > i understand that it's not fully general, but for the case of
>  > > the lid:  is /proc/acpi/button/lid/LID/state going away?
>  > > 
>  > 
>  > Yes, according to feature-removal.txt ACPI procfs interface shoudl have
>  > been gone back in 2008.
> 
> thanks.  i understand that adding sysfs entries for all the bells
> and whistles on modern input devices might seem prohibitive.  on
> the other hand, there are some basic interfaces that are very
> usefully accessed from the shell.  i guess either way the
> information is available, but having to rely on a utility package
> for intermediate access always introduces new packaging
> dependencies, release skew issues, etc, etc.
> 

I am not wasting kernel memory to export full state of an arbitrary
input device via sysfs just so someone out there might avoid writing or
installig a utility. The interface was there for many years and is quite
stable, I do not understand what release skew issues you are talking
about.

Thanks.

-- 
Dmitry

Re: a question about lid input device

[Paul Fox]

dmitry wrote:
 > On Wed, Jul 07, 2010 at 12:51:04PM -0400, Paul Fox wrote:
 > > dmitry wrote:
 > >  > On Wed, Jul 07, 2010 at 11:14:20AM -0400, Paul Fox wrote:
 ...
 > >  > > i understand that it's not fully general, but for the case of
 > >  > > the lid:  is /proc/acpi/button/lid/LID/state going away?
 > >  > 
 > >  > Yes, according to feature-removal.txt ACPI procfs interface shoudl have
 > >  > been gone back in 2008.
 > > 
 > > thanks.  i understand that adding sysfs entries for all the bells
 > > and whistles on modern input devices might seem prohibitive.  on
 > > the other hand, there are some basic interfaces that are very
 > > usefully accessed from the shell.  i guess either way the
 > > information is available, but having to rely on a utility package
 > > for intermediate access always introduces new packaging
 > > dependencies, release skew issues, etc, etc.
 > > 
 > 
 > I am not wasting kernel memory to export full state of an arbitrary
 > input device via sysfs just so someone out there might avoid writing or
 > installig a utility. The interface was there for many years and is quite
 > stable, I do not understand what release skew issues you are talking
 > about.

if, for example, the utility package available in a distro lags
behind the kernel.

but please consider my comments above as more of a lament than a
complaint.  i understand your design decision -- it will make
your life easier, at the expense of making mine somewhat more
difficult.  :-)

paul
=---------------------
 paul fox, pgf@laptop.org

Re: a question about lid input device

[Dmitry Torokhov]

On Wed, Jul 07, 2010 at 01:08:18PM -0400, Paul Fox wrote:
> dmitry wrote:
>  > On Wed, Jul 07, 2010 at 12:51:04PM -0400, Paul Fox wrote:
>  > > dmitry wrote:
>  > >  > On Wed, Jul 07, 2010 at 11:14:20AM -0400, Paul Fox wrote:
>  ...
>  > >  > > i understand that it's not fully general, but for the case of
>  > >  > > the lid:  is /proc/acpi/button/lid/LID/state going away?
>  > >  > 
>  > >  > Yes, according to feature-removal.txt ACPI procfs interface shoudl have
>  > >  > been gone back in 2008.
>  > > 
>  > > thanks.  i understand that adding sysfs entries for all the bells
>  > > and whistles on modern input devices might seem prohibitive.  on
>  > > the other hand, there are some basic interfaces that are very
>  > > usefully accessed from the shell.  i guess either way the
>  > > information is available, but having to rely on a utility package
>  > > for intermediate access always introduces new packaging
>  > > dependencies, release skew issues, etc, etc.
>  > > 
>  > 
>  > I am not wasting kernel memory to export full state of an arbitrary
>  > input device via sysfs just so someone out there might avoid writing or
>  > installig a utility. The interface was there for many years and is quite
>  > stable, I do not understand what release skew issues you are talking
>  > about.
> 
> if, for example, the utility package available in a distro lags
> behind the kernel.
> 

How can it lag? The interface to query the state is available at least
since 2.6.0 and is not likely to change for years to come.

> but please consider my comments above as more of a lament than a
> complaint.  i understand your design decision -- it will make
> your life easier, at the expense of making mine somewhat more
> difficult.  :-)
> 

It is not that it will make my life easier. Exporting state in sysfs is
easy, but do you really want your keyboard device to consume memory needed
for 100+ sysfs nodes that nobody cares about?

-- 
Dmitry

Re: a question about lid input device

[Len Brown]

> > the lid:  is /proc/acpi/button/lid/LID/state going away?

> Yes, according to feature-removal.txt ACPI procfs interface shoudl have
> been gone back in 2008.

Note that /proc/acpi/button/lid/*/state is not reliable
on a measurable portion of systems.

We suspect that other operating systems do not use it,
and thus when Linux tries to use it, sometimes we get burnt.

thanks,
-Len Brown, Intel Open Source Technology Center