Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH BlueZ] device: add MTU D-Bus property
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20210826164211.2936133-1-david@lechnology.com>
 <CABBYNZK9-0b0O_FOzYQ8+iB-dDqC0RHxLCBkN8TibR2opJoD=A@mail.gmail.com>
From:   David Lechner <david@lechnology.com>
Message-ID: <d2341c21-eb1f-5e14-5420-eae5b0a872c6@lechnology.com>
Date:   Fri, 27 Aug 2021 10:19:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CABBYNZK9-0b0O_FOzYQ8+iB-dDqC0RHxLCBkN8TibR2opJoD=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/26/21 8:17 PM, Luiz Augusto von Dentz wrote:
> Hi David,
> 
> On Thu, Aug 26, 2021 at 9:45 AM David Lechner <david@lechnology.com> wrote:
>>
>> When using GATT write without response, it is useful to know how much
>> data can be sent in a single write. This value is the negotiated MTU
>> minus 3 bytes.
>>
>> The D-bus method org.bluez.GattCharacteristic1.AcquireWrite returns the
>> MTU exactly for this reason. However, when using the alternate API
>> org.bluez.GattCharacteristic1.WriteValue with the options dictionary
>> { "type": "command" }, there is no current way to get the MTU value.
>> If the value is too large, then the method returns "Failed to initiate
>> write" [org.bluez.Error.Failed].
> 
> In most cases the MTU is not that useful since each attribute has a

Access to the MTU has been a highly requested feature in
WebBluetooth[1] with reasonable use cases.

[1]: https://github.com/WebBluetoothCG/web-bluetooth/issues/383

> maximum length of just a few bytes, the MTU is only really useful for
> control points which I rather have using Acquire* variants. Note that
> for long values the attribute must support Write Long Procedure and
> afaik WriteValue does support that so it can fragment the data and
> send according to the MTU.

I'm coming at this from the cross-platform point of view. Windows,
Apple and Android don't have an equivalent of AcquireWrite. They have
device-level methods/properties to get the MTU [2][3][4]. So instead
of forcing WebBluetooth to have an API compatible with AcquireWrite
it would be very nice to be able to get the required information
in a different way that is similar to the existing methods on other
platforms.

Maybe there are better alternatives to get the same information?
For example, the Apple API doesn't actually mention MTU, but rather
allows you to get the maximum write size for Write Without Response,
which I think is the value most use cases need (it just happens to
be MTU - 3).

[2]: https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.genericattributeprofile.gattsession.maxpdusize?view=winrt-19041
[3]: https://developer.apple.com/documentation/corebluetooth/cbperipheral/1620312-maximumwritevaluelength
[4]: https://developer.android.com/reference/android/bluetooth/BluetoothGattCallback.html#onMtuChanged(android.bluetooth.BluetoothGatt,%20int,%20int)

> 
>> This adds an "MTU" property to the org.bluez.Device1 interface that
>> is emitted in gatt_client_ready_cb() which is after the MTU exchange
>> has taken place.
> 
> This would not work for the likes of EATT which don't require rx and
> tx MTU to be symmetric, with the likes of Acquire we could in theory
> even assign a dedicated EATT channel if we have to.
>