Re: [PATCH v5 7/7] Input: matrix_keypad - detect change during scan

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Feb 25, 2025 at 09:51:22AM +0100, Markus Burri wrote:
> On Mon, Feb 24, 2025 at 10:58:27PM -0800, Dmitry Torokhov wrote:
> > On Wed, Feb 19, 2025 at 05:56:10PM +0100, Manuel Traut wrote:
> > > On Fri, Jan 10, 2025 at 06:49:06AM +0100, Markus Burri wrote:
> > > > For a setup where the matrix keypad is connected over a slow interface
> > > > (e.g. a gpio-expansion over i2c), the scan can take a longer time to read.
> > > > 
> > > > Interrupts need to be disabled during scan. And therefore changes in this
> > > > period are not detected.
> > > > To improve this situation, scan the matrix again if the row state changed
> > > > during interrupts disabled.
> > > > The rescan is repeated until no change is detected anymore.
> > > 
> > > This is a quirk for a bad hardware design. For 'good' hardware it adds
> > > an additional read_row_state for no need. For even slower connected
> > > GPIOs this will also not help much. However it is obvious that it will
> > > be an improvement for some designs. 
> > > 
> > > Dmitry, would it make sense to make this configurable?
> > 
> > What if we do not disable interrupts after the first one, but record
> > the last interrupt time and rescan if it arrived after work handler
> > started executing?
> > 
> > Thanks.
> 
> I was also thinking about that.
> If we do not disable interrupts we will get a lot of interrupts during scan.
> The scanning process itself generate interrupts because of selecting the columns
> and read row state. Therefore after scan we will not know if the interrupts are
> caused by scanning or a change.

OK, then maybe we should keep re-submitting the work until we get to
stable state? My objection is repeating the scan once does not really
solve the issue....

Thanks.

-- 
Dmitry