On 12/15/20 6:51 PM, Luiz Augusto von Dentz wrote:
Hi Johannes,
Hi,
The spec doesn't allow mixing values of different sizes, or does it
first return the 16 bits one and then later 3 are return in a
different response?
No, all in one response (which is re-assembled from two HCI packets).
My working device (DIY, arduino, but probably based on nordic semi code)
does the right thing:
It returns all handles with 16 bit, the client requests a continuation,
which results in the MIDI I/O characteristic, 128Bit, in another response.
[ cut ]
Well if the device is returning mixed UUID sizes then there is nothing
we can do to figure out since as you said there is only one len so all
elements should be of the same length, perhaps Android doesn't use
Read By Type procedure and discover them, anyway it is perhaps worth
notifying them about this problem given that it doesn't seem to
conform to the spec.
Thanks for clarifying. So quite obvious a bug in their (Roland's)
implementation. I hope they care enough.
I contacted them through their customer support forum, but I don't have
much hope getting by the first-level support there.
If anybody has a better contact...
In this case, it would help to fetch the characteristics service by
service instead of all in one. All characteristic UUIDs for the MIDI
service are 128bit, the rest is all 16 bit. Could be the reason it works
with Windows, Android, OSX, and whatever else they test with.
From my limited understandig, that could probably be changed, but needs
to be done in the general code, slowing everybodys pairing time down. A
non-starter, I guess, for a single buggy device.
So I'll keep a fork with my super-ugly workaround and hope for roland.
I have to rebuild bluez anyway because my distro does not use
--enable-midi.
Thanks!
Jo
--
Johannes Deisenhofer
