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

[Markus Burri <markus.burri@mt.com>]

On Tue, Feb 25, 2025 at 09:46:24AM -0800, Dmitry Torokhov wrote:
> 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 for feedback.
Yes, this is what the patch does. All changes before read the initial state are
handled in the current scan. Changes during scan are detected by the compare at
the end and trigger a re-scan. Since this is done every time at the end of the
scan function, it is done until we have a stable state and not only once. 

> 
> Thanks.
> 
> -- 
> Dmitry