RE: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key support

[Anson Huang]

Hi, Pavel

> Subject: Re: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system
> controller key support
> 
> Hi!
> 
> > > > +	ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > > > +	if (ret) {
> > > > +		dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	state = (bool)msg.state;
> > > > +
> > > > +	if (!state && !priv->keystate)
> > > > +		state = true;
> > >
> > > This needs an explanation please.
> >
> > This is to handle the quick press of button, e.g., when button is
> > pressed and released very quickly, when the delay work is scheduled,
> > the button state read from SCU FW is actually a release state (0), the press
> state is (1), so the quick press/release will be ignored.
> >
> > However, after double check and test, I think this should be handled
> > by debounce time, if the button is pressed/release very quickly, the
> > event should be ignored, I will remove it and reduce the debounce time to
> 30mS, previous 100mS is too long, using 30mS as debounce time, I did NOT
> see similar issue no matter how quick I press/release the button.
> 
> Are you sure this is expected behaviour?
> 
> AFAIK microswitches can bounce when the button is pressed and released,
> but will not generate glitches when the button was not pressed, so even
> short presses are real and should be propagated...

Latest version of patch handle the quick press as below:

- When the button is pressed, the delayed work will be scheduled;
- In the delayed work, the button state will be read, once the state is different as previous
  state, it will be propagated;
- If the state is a press state, another delayed work will be scheduled for handling release
  event.

So there could be a small window of DEBOUNCE_TIME (30mS) between button press and the delayed
work scheduled for reading the button state, if the button is released in less than 30ms, then the
state read could be a release state which is same as previous state and it will be ignored.

Do you think in this case, we should also propagated the press event? If yes, then what about the
release event? Although from what I tested, no matter how quick I press the button, the driver
can always receive both the press and release event, as the 30mS is very short.

Thanks,
Anson