GNOME Bugzilla – Bug 743220
bluetooth modules need to track transport state
Last modified: 2015-08-16 13:36:35 UTC
Created attachment 294938 [details] [review] State tracking for avdtp The avdtpsrc and avdtpsink plugins use the MediaTransport1 interface from bluez, which includes a property "State": string State [readonly] Indicates the state of the transport. Possible values are: "idle": not streaming "pending": streaming but not acquired "active": streaming and acquired The source and sink modules should track this, since if the state ever falls below "active" the transport must be re-acquired (which includes updating the file descriptor used to transfer data). Attached is a patch that has been tested in the avdtpsrc module and appears to work correctly. I would appreciate wider review. Note that this patch removes support for bluez4 (I don't have any easy way to develop or test on bluez4, and the property management is significantly different n bluez4). It also moves from the low-level libdbus interface to glib gdbus, using generated code from gdbus-codegen for the introspection to the MediaTransport1 interface. This is a lot simpler, with all the nasty complexities of property cache management handled by the generated code.
Created attachment 298351 [details] [review] State tracking patch v2 I just noticed a bug in this patch ... I decrement the ref count of a GVariant without having first incremented it. This leads to mysterious assertion failures at a much later point when the underlying variant is actually freed (and presumably to a risk that the entire application could crash if it attempted to use it after the erroneous decrement). Patch updated.
Sorry about the delay in looking at this, I'll try to get to this in the next day or two.
Thanks Arun; we are using this in shipping product at present, so it has been fairly well tested at this point!
I made some minor fixes to the first patch and pushed them both out. Thanks, Nick!