On Sat, 2016-08-20 at 11:18 -0700, James Bottomley wrote: > On Sat, 2016-08-20 at 21:03 +0300, Tanu Kaskinen wrote: > > To clarify, is the problem that bluez has some arbitrary limitation > > that it's not possible to connect both HFP and HSP? AFAIK bluetooth > > doesn't allow two simultaneous audio streams, but I guess that's not > > the problem here? > > No, the problem is establishing the rfcomm link.  I *think* it's > actually an intrinsic limitation of the device. Mmh... I should spend some time with the bluetooth specs to get a better understanding of this stuff. Rfcomm gets mentioned often, but I don't really have any idea what it is beyond "some kind of communication channel". > >  Would it be possible to fix this in bluez? (I'm not asking you to > > fix it, I'm just trying to understand the situation - my old > > understanding was that bluez would support connecting both > > profiles.) > > I get a connection refused error directly from the device when I try to > establish a HSP rfcomm link after establishing a HFP one, so I don't > think bluez can work around this (except by managing the switching, I > suppose, which would be complex). In my world, profiles can be "connected" or "disconnected". Is "connected without rfcomm link" a valid thing? > > I'm not sure how bluez advertises the supported profiles to other > > devices, but if bluez doesn't advertise e.g. HSP support unless > > pulseaudio has first registered the profile, then I don't think > > option 2 is viable. > > Discovery gives us all the supported uuids and we then decide which > ones to register profiles for, so we know as soon as the device is > plugged in all the uuids for the profiles it supports. I meant advertising the local capabilities to remote devices. A laptop with bluez and pulseaudio installed should advertise audio support to other bluetooth devices, but I'd guess that won't happen if pulseaudio doesn't register the audio profiles first. > > Also, pulseaudio doesn't manage when profiles are connected or > > disconnected, and starting to do that (and potentially stomping on > > other components' toes) doesn't sound like a good idea. > > Yes, that's more my worry. > > > An option for disabling HFP seems much more feasible. > > OK, I'll code up option 1. Ok, sounds good. -- Tanu
