Hi Johannes, On Tue, Dec 15, 2020 at 11:58 AM Johannes Deisenhofer <jo.deisenhofer@xxxxxxxxx> wrote: > > 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. Yep, it is quite possible others OSes don't take advantage of big UUIDs like we do since we can discover more than one service at time that speeds up the discovery procedure quite a lot depending on MTU size. > 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. We should at least attempt to validate the response since it appears we don't detect there is more data than expected but if the total length is actually a multiple of the elements len it would still create invalid attributes in the database. Anyway I would reach to the manufacturer since they are clearly not following the Bluetooth Core spec to the letter here. > Thanks! > Jo > -- > Johannes Deisenhofer -- Luiz Augusto von Dentz
