Hi, On Sat, Oct 11, 2014 at 10:32 PM, Georg Chini <georg at chini.tk> wrote: > Hello, > > I just pulled a current GIT and installed it. I find two issues with the > ofono backend: > > 1) When I connect my headset the device does not vanish > when I disconnect it. pactl list cards still shows > card #4 > Name: bluez_card.00_19_7F_41_DB_2E > Treiber: module-bluez5-device.c > Owner-Modul: 28 > Eigenschaften: > device.description = "590Plantronics" > device.string = "00:19:7F:41:DB:2E" > device.api = "bluez" > device.class = "sound" > device.bus = "bluetooth" > device.form_factor = "headset" > bluez.path = "/org/bluez/hci1/dev_00_19_7F_41_DB_2E" > bluez.class = "0x240404" > bluez.alias = "590Plantronics" > device.icon_name = "audio-headset-bluetooth" > device.intended_roles = "phone" > Profile: > headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, > sources: 1, priority: 20, available: no) > a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, > sources: 0, priority: 10, available: yes) > off: Aus (sinks: 0, sources: 0, priority: 0, available: yes) > Aktive Profile: off > Profile: > headset-output: Headset (priority: 0, latency offset: 0 > usec) > Part of profile(s): headset_head_unit, a2dp_sink > headset-input: Headset (priority: 0, latency offset: 0 usec, > not available) > Part of profile(s): headset_head_unit > > I cannot re-connect the headset before I restart pulse. > With my phone there is no such problem, the device appears > and disappears as expected. That should never happen, are you sure it disconnected? a2dp_sink still shows as available which indicates you are still connected. > 2) When I connect my phone and use it, the profile switches to > HFP and if it's no longer in use the profile switches to off after > a timeout (this was not the case with the initial ofono patches). > This is the same as with Bluez4. The problem is, that with Bluez5 > there is no D-Bus signal which indicates the profile switch. If you > have loopback modules connected to phone input/output, they > will fall back to the default source/sink without giving the software > a chance to react to this. Hmm, if you maintain the loopbacks externally that would be a problem but I guess you can watch for port availability, I tested it with module-bluetooth-policy this seems to be working fine perhaps because we do set a specific source/sink so once they are destroyed the loopbacks are also unloaded. -- Luiz Augusto von Dentz
