Re: a question about lid input device

[Zhang Rui <rui.zhang@intel.com>]

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