On Tue, 2012-12-11 at 08:53 +0100, Mikel Astiz wrote:
> Hi Tanu,
>
> On Tue, Dec 11, 2012 at 5:40 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Mon, 2012-12-10 at 08:30 +0100, Mikel Astiz wrote:
> >> +typedef enum pa_bluetooth_transport_state {
> >> + PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED,
> >> + PA_BLUETOOTH_TRANSPORT_STATE_IDLE, /* Connected but not playing */
> >
> > Why "idle" instead of "connected"? "Connected" would be more consistent
> > in my opinion. Is the BlueZ 5 interface going to call this state "idle"?
>
> Yes, the reason was to be consistent with the terminology in BlueZ 5.
>
> Having said that, I'm not 100% convinced since I didn't actually
> follow BlueZ 5 by adding PA_BLUETOOTH_TRANSPORT_STATE_PLAYING, as
> opposed to two different states exposed in BlueZ 5: "pending" (audio
> playing but transport not acquired) and "active" (audio playing and
> transport acquired). The reason to merge these two inside PA was that
> you can't actually have such a separation in BlueZ 4.
>
> Therefore, I would also be fine with
> PA_BLUETOOTH_TRANSPORT_STATE_CONNECTED instead of _IDLE. I'm slightly
> in favor of the latter because it would eventually make it easier to
> support _PENDING, but this sounds nonsense while we have the support
> for BlueZ 4.
If it's "idle" in bluez, I don't mind having it in pulseaudio too. So
don't change it if you don't want to.
--
Tanu
