Hi Alex, >> 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. I might have should answered this email with an acknowledged and understood comment. Sorry about that. My original comment still stands. I am fine with this patch set, but leave it up to Johan to make the final to apply it. > 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. Sounds good. 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
