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
