Hi Marcel, > On Jul 18, 2017, at 2:42 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > >>>> The negotiation of the MTU can be a significant event to the client interacting via dbus, so how should the completion of that negotiation be exposed, if not via an attribute as I proposed above? Some boolean "MaxPayloadNegotiationCompleted" method? >>> >>> there will be PropertiesChanged signal once the MTU has been altered. Otherwise it will start out with 23 in case of LE or the minimum of whatever L2CAP has configured for BR/EDR. We do the same for RFCOMM btw. where it takes the minimum value from the two MTUs. >>> >> >> I understand. However, there is no way for a dbus client to tell the difference between these two scenarios: >> >> 1) The MTU has been negotiated to 23 (in the case of LE) >> 2) The MTU negotiation has not been completed >> >> I expect many clients making use of this information will want to wait until the MTU negotiation is complete, and then begin normal operation. A single attribute representing the current MTU seems to not be sufficient to implement such a dbus client. > > the other option is to leave the property out until the MTU has been negotiated. So in case of LE and Exchange MTU has not yet happened, that property does not exist. In BR/EDR it will always exist since L2CAP has finished already. > > So clients can start whenever they see the PropertiesChanged signal or get the property in the first place. > This seems fine to me. Thanks for the feedback. I will submit a new patch. Jonah -- 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
