On Sun, 2012-09-16 at 16:56 -0400, David Dillow wrote: > On Sun, 2012-09-16 at 21:35 +0200, David Herrmann wrote: > > Regarding the lost keypresses during connection establishment: All HID > > drivers loose them. Any input data is actually lost as long as no > > driver is fully loaded. It's actually not that easy to change that > > (feel free to have a look at hid-core.c) but I also don't understand > > why you actually care about them so much? There is driver rebinding, > > delayed driver loading and similar. So even if you fix it, it can > > happen that your driver is loaded after a lot of communication has > > already been done. > > Could you explain why you actually need these? > > If it were only the first time after the driver is loaded, that's one > thing, but it seems like it's loosing the first button press on each > connection (ie, after an idle period of about 10 minutes.) The idle > periods are important for the battery life of the remote, but it's > really annoying to have to hit pause, wait a second, then hit pause > again when you are watching a TV show or movie... > > I'll double check that this behavior was on each re-connection and not > just the first time we load the module. I suspect it was each > connection, though. Adding some debug statements shows me that this is unlikely to be a bluetooth or HID issue -- I get the reports just fine. I suspect it is a timing issue, such that the event gets delivered to the input system before udev processing has finished informing X or eventlircd etc that a new device has appeared and they open /dev/input/eventX. Unfortunately, there doesn't seem to be a way to say "queue the first few events for a short while" when creating the input device, nor am I convinced that would be a good fix -- so much would need to change to use it, and I suspect it is the wrong interface. It seems like a bit of a hackish solution, but one could avoid the problem by having the hidp core keep (some) session information alive after a disconnect -- if requested by user space -- and reuse the HID devices if the BT device re-connects before the cached information expires. This would limit the race to once during the closed session expiration timeout, which I think would be acceptable -- users could configure the timeout to be weeks for their home entertainment centers. Would this approach be worth exploring to see if I can find a clean implementation? -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
