Hi Jonah, Luiz and all,
On 14.07.2017 14:02, Jonah Petri wrote:
Exposing the ATT MTU through Bluez D-BUS API would solve my issue
even if it
is a workaround in term of GATT specification. For diagnostic
purpose, it
might still be helpful to have the MTU exposed in D-BUS API.
I am happy to have a try to add the support for ATT MTU to Bluez
D-BUS
Device API myself if you think it is feasible and the patches will be
accepted (obviously after being approved on the mailing-list).
It would have the same treatment as AcquireWrite and AcquireNotify so
at the start it would probably be marked as experimental. Note that
I have a patch for this exact need (reading the negotiated MTU), which
I can submit later today for consideration.
I also started to look at adding this support this morning. But I had to
interrupt my work. So I will be happy to have a look and review your
patch as I have a clearer idea of the code now.
Thanks to Luiz and after doing a little break, I realised I need to
change my application protocol to take advantage of AcquireWrite and
AcquireNotify.
I am quite convince now I will have a better throughput using these
methods than using my current application protocol.
--
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
