Hi Jonah, >>>> I think that exposing max payload is a better idea. >>> >>> I am fine with the revised naming, and revising the exposed device attribute to represent the max ATT payload. However, how can a dbus client know whether the MTU negotiation has occurred or not? The point of the patch is to allow for clients to take advantage of a larger negotiated MTU. >>> >>> 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. 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
