On Wed, Apr 17, 2013 at 1:20 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > 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. We still need the new D-Bus API to let the UI know that it can't reconnect to the device because the device is not supposed to normally accept connections (ReconnectMode is "device" (or "none" if such a device exists)). This allows the UI to instruct the user to go and move the mouse to reconnect or press that hidden "connect" button in his device to reconnect it if the device had lost the pairing. If the ReconnectMode is "device", the meaning of Device1.Connected property changes a bit, since the fact that my mouse is disconnected right now doesn't mean that it is not working as intended or that it should be connected. The auto-reconnect is implied and required by the Bluetooth HID spec for example in cases where ReconnectMode is "host". I don't think we should indicate that we are currently following the spec. The auto-reconnect attempts are canceled when the device is reconnected for some reason (because of this auto-reconnect or not) or when the device is marked for deletion, even if the removal is during the auto-reconnect process. Regards, Alex. -- 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
