On Wed, Dec 09, 2009 at 06:32:01PM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 09 Dec 2009, Dmitry Torokhov wrote:
> > > 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.
> > >
> >
> > It will not propagate events because until you register the device there
> > won't be any consumers attached to it. So the only thing that will
> > happen is that it will sync internal state of the device from input core
> > point of view with the true state of the hardware.
>
> Ah, I see. Cute trick, and yes, that would work just fine. I will do that,
> it certainly beats accessing the sw bitmap directly.
>
> Is it documented anywhere?
Not explicetiley, no.
>
> Still, please look at the patch below... Would something like this be a
> cleaner API? It is certainly more obvious, and it is cleaner on the driver
> side (one function call does everything, instead of a call to
> input_set_capability plus a call to whatever the driver needs to issue the
> initial EV_SW event)...
>
Yes, I think it is a good idea. However why don't we change it to:
input_setup_event(dev, type, code, value)
{
input_set_capability(...);
input_event(...);
}
So it would work for everything (who knows, maybe down the road some
driver wants to init its ABS axes properly and so on)?
--
Dmitry
--
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
