Re: [PATCH] Input: Add REP_MAX_COUNT to autorepeat parameters

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

On Mon, Apr 21, 2014 at 03:06:32PM -0700, Petri Gynther wrote:
> Hi Dmitry,
> 
> On Mon, Apr 21, 2014 at 1:17 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Petri,
> >
> > On Mon, Apr 21, 2014 at 01:00:08PM -0700, Petri Gynther wrote:
> >> Add REP_MAX_COUNT to autorepeat parameters. This enables an input device to be
> >> configured for maximum autorepeat count, so that a keypress is not repeated
> >> forever. This is important for Bluetooth keyboards and remote controls that may
> >> lose the Bluetooth link at any time, e.g. right after sending a key-down event
> >> but before sending the corresponding key-up event.
> >
> > I think this should be solved in the drivers - if link is lost then they
> > should tear down the device (or generate keyup events if they want to
> > hand onto the device).
> 
> In my opinion, since the keypress autorepeat code lives in the input
> subsystem, it should provide some kind of mechanism to limit the
> autorepeat if the user wants to configure so. The delay and period are
> already configurable, so this just adds the upper limit, so that the
> autorepeat doesn't go on forever.

No, autorepeat should run until the key is released; that is your upper
bound. What you are trying to do is work around the issue in a given
driver that does not report key releases properly and such workaround is
not acceptable. Not it is sufficient: one can disable kernel-level
autorepeat and you'll end up with userspace autorepeating in the very
same fashion.

> 
> For Bluetooth LE remote controls (HID over GATT), BlueZ daemon uses
> uHID kernel driver (drivers/hid/uhid.c) to create the necessary HID
> device and pass the HID input events. This device is persistent over
> reconnects, so the HID and input devices are not destroyed and
> re-created on every disconnect and reconnect. On BLE device
> disconnect, BlueZ daemon cannot inject the necessary key-up event
> because it would have to know the HID input report details in order to
> do so. And, uHID driver doesn't support disconnect-reconnect unless
> the input pipeline is completely torn down and re-created (which is
> not desirable).

Maybe uhid needs another way to indicate that device was disconnected
and its state is no longer valid, it is still a driver issue as far as I
can see.

Thanks.

-- 
Dmitry