Hello Marcel and Luiz,
Thanks for looking at the patch!
> On Jul 15, 2017, at 2:03 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>
>>> --- a/doc/device-api.txt
>>> +++ b/doc/device-api.txt
>>> @@ -234,3 +234,8 @@ Properties string Address [readonly]
>>> array{byte} AdvertisingFlags [readonly, experimental]
>>>
>>> The Advertising Data Flags of the remote device.
>>> +
>>> + int16 NegotiatedMTU [readonly, optional, experimental]
>>> +
>>> + The ATT MTU negotiated with the connected host.
>>> + Available only once MTU negotiation is complete.
>>
>> Despite being odd that we start exposing transport specific details on
>> device interface, there maybe a chance this is useful if we can
>> properly detect BR/EDR MTU not only LE, though this means checking the
>> via bt_att API not bt_gatt_server. Obviously, this would have to be
>> exposed even before it is negotiated since LE start with 23 but on
>> BR/EDR this is negotiated via L2CAP signaling, and perhaps it should
>> not really be MTU that we expose but the actual payload without the
>> headers that bluetoothd takes care of adding.
>
> 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?
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
