Hi Dmitry, On Mon, Apr 21, 2014 at 1:17 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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. 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). -- Petri > > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
