Re: a question about lid input device

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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