On 09/23/2013 11:50 AM, Tanu Kaskinen wrote:
Hi all,
With nodes, there will be two routing layers: the higher-level node
layer and the lower-level layer with sink inputs, sinks etc. The user
will be able to still use the old move sink input interface, but what
to do if the user tries to
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
The function was redundant, because all it did was call adapter_free()
for each adapter in the hashmap, and that can be delegated to
pa_hashmap when freeing or emptying it.
---
On Tue, 2013-10-01 at 13:12 +0200, David Henningsson wrote:
On 09/23/2013 11:50 AM, Tanu Kaskinen wrote:
Hi all,
With nodes, there will be two routing layers: the higher-level node
layer and the lower-level layer with sink inputs, sinks etc. The user
will be able to still use the old
On Sat, Sep 28, 2013 at 7:07 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-09-24 at 19:45 -0300, jprv...@gmail.com wrote:
@@ -371,11 +398,8 @@ static void adapter_remove_all(pa_bluetooth_discovery
*y) {
/* When this function is called all devices have already been
On Sat, Sep 28, 2013 at 7:25 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-09-24 at 19:45 -0300, jprv...@gmail.com wrote:
+static void parse_adapter_properties(pa_bluetooth_adapter *a,
DBusMessageIter *i, bool is_property_change) {
+DBusMessageIter element_i;
+
+
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
The string points to memory inside a DBusMessage, so we don't own the string.
---
src/modules/bluetooth/bluez5-util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 10/01/2013 02:51 PM, Tanu Kaskinen wrote:
On Tue, 2013-10-01 at 13:12 +0200, David Henningsson wrote:
On 09/23/2013 11:50 AM, Tanu Kaskinen wrote:
Hi all,
With nodes, there will be two routing layers: the higher-level node
layer and the lower-level layer with sink inputs, sinks etc. The
On Tue, 2013-10-01 at 15:09 +0200, David Henningsson wrote:
On 10/01/2013 02:51 PM, Tanu Kaskinen wrote:
I did not plan to allow dual-direction nodes. If you want to represent
sinks as dual-direction nodes in a UI, I'm fine with adding information
to the nodes that allows the UI to do the
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
Normally devices are created and their properties are parsed before
creating any transports for the device, and the
DEVICE_CONNECTION_CHANGED hook is fired when the first transport is
created. It's possible,
On Sat, Sep 28, 2013 at 6:06 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Thu, 2013-09-26 at 19:56 -0300, João Paulo Rechi Vita wrote:
On Wed, Sep 25, 2013 at 7:04 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-09-24 at 12:43 -0300, João Paulo Rechi Vita
On Sun, Sep 29, 2013 at 9:56 AM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
On Tue, 2013-09-24 at 19:45 -0300, jprv...@gmail.com wrote:
@@ -745,6 +748,15 @@ static void
parse_interfaces_and_properties(pa_bluetooth_discovery *y, DBusMessa
dbus_message_iter_next(element_i);
On 10/01/2013 03:30 PM, Tanu Kaskinen wrote:
On Tue, 2013-10-01 at 15:09 +0200, David Henningsson wrote:
On 10/01/2013 02:51 PM, Tanu Kaskinen wrote:
I did not plan to allow dual-direction nodes. If you want to represent
sinks as dual-direction nodes in a UI, I'm fine with adding information
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
The function did two things: set device_info_valid to -1 and called
device_free() for each device in the hashmap. Setting
device_info_valid to -1 was unnecessary. The main purpose of that was
to fire
On Sun, Sep 29, 2013 at 12:49 PM, Tanu Kaskinen
tanu.kaski...@linux.intel.com wrote:
When parsing device properties, missing adapter will result in
device_info_valid being set to -1. It is then logical that if the
adapter goes missing at a later point, device_info_valid gets set to
-1.
---
14 matches
Mail list logo
