Hi Alex, > It's me again. Let me insist with these input patches again for a good > reason. There is a qualification test (TP/HCE/BV-04-I [Host Initiated > Re-connection]) that requires a Bluetooth host to automatically > re-connect to a HID device when the device goes out of range (and comes > back in range, obviously). The HID 1.1 spec also states when a device > is supossed to accept re-connections from a host and now we export that > via the ReconnectMode property. I extended this patch with a retry timer > that attempts to reconnect to the HID device for a certain amount of > time. > > This patch set includes: Patch 1 and 2 are the new ReconnectMode property > and its documentation. Patch 3 is just some details about bool and gboolean. > Bonus: patch 4 includes a memory leak fix; and patch 5 uses all this > thing to automatically reconnect to HID device when its ReconnectMode is > "host" or "any", as required by the test plan. I am fine with these patches, but I leave the final say to Johan. However I do have a general question, do we need the new D-Bus API if we do an auto-reconnect handling? If so, do we need to indicate that the we are currently in auto-reconnect mode and/or cancel it when connecting attempts via other means happen. Regards Marcel -- 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
