Hi guys, I've been working on a profile plugin for BlueZ[1] that implements the MIDI over BLE spec for some time now. I am close to release an initial implementation, but I still have some questions, since it seems that the profile plugin is not really working properly, or at least in a way that makes sense to me. This is what I expect from BlueZ: adapter_probe: called when a any new adapter is probed adapter_remove: called when the previous probed adapter is removed device_probe: called when a device that advertises supports to the `remote_uuid' property is probed device_remove: when that device is removed connect: called when a previously probed device is connected to. disconnect: called when a previously connected device is disconnected. accept: This is still an incognito for me, but I suppose this is a step after the `connect()', once BlueZ has all the gatt_db ready. What actually happens: Based on my expectations, adapter_probe/remove and device_probe/remove are the only callbacks that works. connect and disconnect are *never* called. accept is called when the device is connected, but before the gatt_db is actually populated so I can't `gatt_db_foreach_service()'. I noticed that btd_service.state is not properly updated, which means that accept is only called on the first connection. So in order for me to work, I have patched my branch with some code to make it work in the sense I have previously stated, but it is hacky since I don't really understand the proper states of this state machine. Based on this, I could say that we have few bugs happening: * btd_service state machine is not working properly, causing several side-effects. * gatt_db is been populated too late (it should be the first thing after a connection) * connect, disconnect and accept should be called in proper order Does it makes sense? I appreciate any comments. PS: I am always rebasing my code on top of origin/master. [1] https://github.com/ftonello/bluez Thanks in advance, Felipe
Attachment:
0x92698E6A.asc
Description: application/pgp-keys