On Tue, 08 Dec 2009, Dmitry Torokhov wrote: > On Tuesday 08 December 2009 05:36:30 pm Henrique de Moraes Holschuh wrote: > > Before we register the input device, sync the input layer EV_SW state > > directly by setting the bitmaps, to avoid issuing a gratuitous event > > for the initial state of these switches. > > > > I will propose a clean input layer API for this and change the driver > > to use it later, but I'd rather get the driver fix in mainline ASAP. > > > > Just do input_report_switch() before registering the device, it will do > the right thing. At device startup, the input core doesn't know the initial state of the switch. It assumes the switch is "off" (all bits clear in the sw bitmap). input_report_switch() will call input_event(), which will have a 50% chance of doing the wrong thing at startup (i.e. issue an event) since it will look at the state of the sw bitmap to decide whether to issue an event or not. > Input core guarantees (and will continue doing so) that it is safe to > pass events to the device as soon as it was allocated with > input_allocate_device(). Well, there really isn't a transparent way to do this... Either you change the core to use the first event reported to init the switch and never issue that first event outside the core (we will also have to make sure all drivers know they have to issue this initial event), or you add an API for the drivers to directly inform the core of the initial state of the switches (I have this already written) and check all drivers that export EV_SW events to make sure they use the API (I haven't done this yet). -- "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 ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
