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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
