Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp763173ybg; Fri, 18 Oct 2019 07:05:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqz1F3TzlVpx7z4/xOSzYIMgFv7b8/9HzaTSb2LLXcfSNdA32Nhh535/Vw6rsCOrRkUBz/in X-Received: by 2002:a17:907:2095:: with SMTP id pv21mr8407661ejb.324.1571407513556; Fri, 18 Oct 2019 07:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571407513; cv=none; d=google.com; s=arc-20160816; b=v5ShwjPeGUi1vF7MqHFf8etoGtHL75jDoVCILxdMZxG/rLLq0IdgV/RrvD74+Nl3ye 49snAdxzkeBx9DBawZa6sZw5dpmVixknqrdmVVYUvyLWNwH0CkehAir6WLODW5z9ULFq /kmi0/VkcvCeB2KNzt3FIesKknlYVZIUZ4Bc9PKlSovDr4j2An9rNB031u6LwR1BM9B9 J8jw9VylGeZ+xk1QaT5xWF3Jw6A3sjOYaTjbztBl7HBD04bRPHN/2hqcPdcYZ6631k1T ugDDNiR6Ljy0CuocScIAWhxqDo1VSkSxckXidjhFQnM1l0HdRoBMZOQfRccvuburqvOQ KFAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kbdKXH3wuBvIyxNJP3QHRHENytY3C903+G+jZNVarW0=; b=HB4kV0ZBkuyL1G2lXOK1ijKXuQcByBqP9bRn/UEkY+JM/K1MP0RgspnYol3dZdT1UU Xfo2Gtt5msibBQ+HfFqupsmmfvXAvYSNHa8BHHmd3H9rfGGefVHO+WfRg0yFGPYH/4pz Wb8p6eHW9n55DN9gHE3pxJbI60rD8dMQPqMlPbZ6FnKXp6T13nrFOop1F47md4DTKwlT JULf5VEZird9MTVdGpmqy6pvno9inTd4HHi7f8rdBUzgJDdvDCiCWAHwA/BIk1s4znWH scgysJMJ5d879XuxkgGQ+h94oWbI1PZlvVq9qpWMgCBw4NIOEttx7bMGPDoj4eT1kSau 98nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="X0o5BmY/"; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i3si3521403edq.163.2019.10.18.07.04.30; Fri, 18 Oct 2019 07:05:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="X0o5BmY/"; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727692AbfJQKAC (ORCPT + 99 others); Thu, 17 Oct 2019 06:00:02 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:34234 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726638AbfJQKAC (ORCPT ); Thu, 17 Oct 2019 06:00:02 -0400 Received: by mail-wr1-f67.google.com with SMTP id j11so1628315wrp.1 for ; Thu, 17 Oct 2019 03:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=kbdKXH3wuBvIyxNJP3QHRHENytY3C903+G+jZNVarW0=; b=X0o5BmY/bLkGCahA8Pfs1pw3eLiMMDC5jQIaIFvn1ejqUIzKWp5FAvho2eCHnxFkyV kXFceNz2BY5SVHrvIPBhBmg4obWxVS26WXATWYSo3SrsOvw4e2z0IB+IqogYm3JVNdY+ 6eEAkmaCAs3kB5DcGARDf1ou0uqkE1/6Wvf6tSfmq5DGLjPBFzY65RG973+qbjc2Y77l pq/MqdxgD4m1bAi7JXGdM/+EV0QIoSPu/gLDe/86D1tfxnBzp87Gn3iRgHGZUR5WAGir p9QNd3WE2i7Kd9RrsaF+HOwiND+xpCXCG5kNUJ06XOq8p/8FOgtCaSoC66bbdMnRBJJ6 WDwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=kbdKXH3wuBvIyxNJP3QHRHENytY3C903+G+jZNVarW0=; b=AnG/gJq/ual05nhTfu6s95Ah/052AjoZ7Fn0MOhdqVpGLh4GrqXFjCG1Dx8az4Uzdt gfh7FAokmE9ueMCGPvuGBZdePwuynQ+wMNUxuXi+PsMiIbp0gepSaC219qQknXJ0WcI4 gp8WDEOOjzsAofYMWliEj1z+9P0Dcw6CNPKYmEQP2tI8mhnuesRruH68j6vi3XL97CSJ 762IXO2ddcdGIz03mrXPFNrBa4jec9aUWYGrdpmhFqN76Igy0PdR/NJNshIH1RN1eeI5 NRZN1oMeI0x+SIihZHfEKyu54RpisF0Q0ebxcj22KZQQQH3DRFoz+17U88wtSzlIa0hO WIwQ== X-Gm-Message-State: APjAAAXdmDcocq3QWF75gWq8Ti5cwWN6fcmGd2ZWwR/Ll80qx3q7FyJw Zjlet3sdBj/QMiqYCOkqI3I= X-Received: by 2002:a05:6000:1051:: with SMTP id c17mr2175019wrx.124.1571306399534; Thu, 17 Oct 2019 02:59:59 -0700 (PDT) Received: from pali ([2a02:2b88:2:1::5cc6:2f]) by smtp.gmail.com with ESMTPSA id z13sm1634255wrq.51.2019.10.17.02.59.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Oct 2019 02:59:58 -0700 (PDT) Date: Thu, 17 Oct 2019 11:59:57 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Luiz Augusto von Dentz Cc: Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= , "linux-bluetooth@vger.kernel.org" Subject: Re: [PATCH BlueZ 1/4] doc/media-api: Add RegisterApplication method Message-ID: <20191017095957.cce7jzejvn76kwkc@pali> References: <20190829200513.6xnta5jx3trbmgxp@pali> <20191003181855.GF28704@reaktio.net> <20191006100503.fsbttcschr6wgsdq@pali> <20191006120245.tkrooh45q7irtm6l@pali> <20191007143307.ez6g466afu3trlxn@pali> <20191008103333.rqn2btlkwtcrpouo@pali> <20191009131921.ysl3ianpv5e4m677@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191009131921.ysl3ianpv5e4m677@pali> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Wednesday 09 October 2019 15:19:21 Pali Rohár wrote: > On Wednesday 09 October 2019 16:15:59 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > On Tue, Oct 8, 2019 at 1:33 PM Pali Rohár wrote: > > > > > > On Tuesday 08 October 2019 13:28:53 Luiz Augusto von Dentz wrote: > > > > Hi Pali, > > > > > > > > On Mon, Oct 7, 2019 at 5:33 PM Pali Rohár wrote: > > > > > > > > > > On Sunday 06 October 2019 14:02:45 Pali Rohár wrote: > > > > > > On Sunday 06 October 2019 13:53:37 Luiz Augusto von Dentz wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Sun, Oct 6, 2019 at 1:05 PM Pali Rohár wrote: > > > > > > > > > > > > > > > > On Thursday 03 October 2019 21:18:55 Pasi Kärkkäinen wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On Thu, Aug 29, 2019 at 10:05:13PM +0200, Pali Rohár wrote: > > > > > > > > > > On Thursday 29 August 2019 15:57:34 Pasi Kärkkäinen wrote: > > > > > > > > > > > Pali: How does it look with porting the PA patches to use the new interfaces? > > > > > > > > > > > > > > > > > > > > Hello, I have not had a time yet to play with these pulseaudio patches > > > > > > > > > > and porting to the new interface. I guess that I could have more free > > > > > > > > > > time in the last week of next month. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems BlueZ 5.51 has been released meanwhile (http://www.bluez.org/release-of-bluez-5-51/) > > > > > > > > > So now at least the new interfaces are in a released bluez version. > > > > > > > > > > > > > > > > Ok! Today I have looked at this new Bluez API, but seems that there is > > > > > > > > not only missing some examples or usages with libdbus-1, but also > > > > > > > > documentation. I have tried to find something how to register endpoints > > > > > > > > throw GetManagedObjects() via libdbus-1, but seems that there is no > > > > > > > > usage of it and also unusable documentation for it in libdbus-1. So > > > > > > > > currently I'm stuck how to use this exotic API in pulseaudio... > > > > > > > > > > > > > > It is just another D-Bus method, the only difference is that it > > > > > > > carries the entire object tree, btw I did add an example of how to > > > > > > > register Endpoints in python: > > > > > > > > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-endpoint > > > > > > > > > > > > This example uses undocumented property "DelayReporting". What it is doing? > > > > > > > > > > Also this new Managed Objects API bring some inconsistency. Codec > > > > > switching API is available only when bluetoothd was started with > > > > > --experimental flag, but this new Object API is available also without > > > > > it. So it just complicated implementation. > > > > > > > > > > How could application (e.g. pulseaudio) check if A2DP codec switching is > > > > > available and based on this decide if via Managed Objects API export > > > > > more codecs or just only default SBC? > > > > > > > > The idea was that this API would be experimental as well but it seems > > > > it is not, > > > > > > No, it is not experimental. Managed Objects API is available also when > > > bluetoothd is started without --experimental argument. > > > > > > > they should go hand in hand with Endpoint objects to ensure > > > > they will be available as well so we might have to fix this in 5.52, > > > > too bad we didn't see this before 5.51 went out. > > > > > > So... what should applications expects and how they should implement > > > above decision? > > > > Actually the decision should be based on the presence of > > RegisterApplication method, if that exists then endpoint switching > > should be supported as well, so has nothing to do the > > GetManagedObjects API of the bluetoothd. That said RegisterApplication > > was not made experimental which kind makes 5.51 broken because it > > would appear that it endpoint objects would be exposed but when in > > fact there are not, anyway lets finally have the code to use this > > interface and then we can remove the experimental flag from > > MediaEndpoint. > > Ok, so can pulseaudio do following? > > Call RegisterApplication. If success then expects that codec switching > is possible and via GetManagedObjects exports all available codecs. > If RegisterApplication fails then fallback to RegisterEndpoint, expects > that codec switching is not possible and so register only one SBC codec. Also can we solve this problem in bluez ASAP? Last released bluez version is due to that non-experimental API broken and once applications (e.g. pulseaudio) starts using this new API then A2DP without bluetoothd -E would be broken. I would propose to remove experimental mark for codec switching API and release a new bugfix version of bluez, so people would not use released 5.51 broken version... which could prevent breakage of A2DP in future. > > > > > > > You can also have a look at how our gdbus internal library (uses > > > > > > > libdbus) utilize it: > > > > > > > > > > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/gdbus/client.c#n1269 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Pali Rohár > > > > > pali.rohar@gmail.com > > > > > > > > > > > > > > > > > > -- > > > Pali Rohár > > > pali.rohar@gmail.com > > > > > > > -- Pali Rohár pali.rohar@gmail.com