El Monday 10 May 2010 10:42:50 José Antonio Santos Cadenas escribió: > Hi all, > > El Sunday 09 May 2010 17:14:39 Luiz Augusto von Dentz escribió: > > Hi, > > > > On Sat, May 8, 2010 at 12:08 AM, Elvis Pfützenreuter <epx@xxxxxxxxxxx> > > wrote: > > >> Device objects exists for each paired device. If the pairing is > > >> removed the object is also removed and a new pairing is needed before > > >> connecting to it (as imposed by the whole bluetooth stack logic > > >> anyway). > > > > > > AFAIK the HDP source and sink must be paired before any session can be > > > established, so the relevant device objects will always be there, so > > > the path can be (re)used. > > > > Exactly, I tried to explain this before that device objects is a > > better way to expose any relevant API since that would be created > > anyway. It also has integration with the sdp record cache and are > > reloaded during the initialization and I hardly see us doing anything > > to revert this, since pretty much every plugin depend on this to work. > > We agree that the best way to expose a remote device is using the path > already created by bluez. We are thinking, as Elvis suggested, in changing > some functions to that path for discovering remove services. > > The main problem here is that sessions exist in HDP even if bluez is not > concerned about them. Imagine that we perform an implementation without > session management, this not implies that other implementations do the same > so a remote device could expose multiple HDP session (each one of them > could expose a SDP record). Now if you are not concern of the sessions and > you try to connect to a remote device that holds more than one session, > you can't decide which one of that sessions connect. A simple example of > this situation is described in the HDP implementation whitepaper (page 18, > figure 2.4). > > > So, with this in mind, IMHO, the whole concept of exposure the > > sessions won't fit nicely in BlueZ API, first because it uses the > > adapter path to create session passing a device path, which btw > > already is associated with adapter anyway, > > We think that the main problem here is that we don't choose a good path > name. But we are open to suggestion for a better one. > > > second because any client > > seems to be able to create those sessions even if they are unable to > > control them because they don't hold an agent, > > We think that this is not a good reason, the same could happend with other > profiles. Any client could connect to an Audio or Serial device even if > they are unable to use them or the don't know how to do it. > > > and third I don't think > > we should be exposing protocol internals in a D-Bus API, > > We don't understand this. What do you mean with protocol internal? Nothing > exposed in D-Bus in internal we just propose to concert the client about > the remote session (remote hdp instance) because it need to decide with > one to connect, as it decides the device that it will connect with a > Serial connection. Probably we need a better name than "session id". > > > this id's > > make as much sense as the bdaddr in the ui (read _none_), it is as > > usable as we starting exposing local and remote seid (Stream Endpoint > > id, surprisingly similar to endpoint here) to pulseaudio to carry on > > with all avdtp protocol details, this will only fragment the logic > > around those bits and certainly won't make it work better. > > Ok, we shouldn't expose mdepid. But we still need to expose the remote hdp > session or instances. Sorry, I was wrong with this. I think that we need a way to identify the end point (or feature or something) that will be connected in the remote hdp session. Because the application should be able to select where to connect. > Note that in Audio profile the psm is fixed, so there > is just one listening on each device, but HDP is different because the psm > are not fixed and multiple instances can exist in the same device. > > Regards -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
