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@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. 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 -- 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
