I have revised and updated the AVRCP API proposal, submitted in March.
I agree that the previous version was too complicated, and have encapsulated everything having to do with UnitInfo and SubUnitInfo into the internals (most of those elements are fixed anyway, and can be set in the audio.conf file).
With regards to the rest, I propose to provide two ways to handle Passthrough messages received; by uinput for integration with GStreamer and the like, and by signal, which will pass not only the keystroke itself, but the vendor dependent data allowed for in the spec (AVRCP with Metadata Transfer, published by the BT SIG).
I propose to handle Metadata as a sub-class or specialization of VendorDependent, without taking away the ability to create one's own VendorDependent messages. I am thinking that to send a batch of Metadata, one would create it as a string-variant dict, with the string being a key to identify what the thing to be transmitted is (and hence how to interpret/translate it, per the spec). The internal plumbing will take care of batching all of it into a VendorDependent and shipping it off.
With respect to handling basic Passthrough and Metadata, this should cover it, and provide very good functionality for most applications.
The spec also provides for numerous events and responses; I am still reviewing them to see how or if these can or should be implemented. It does appear that some of these would require a greater level of integration with the overall "playing" application to handle these within this module, which IMHO is not a good idea.
David Stockwell