Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1718699ybg; Sat, 19 Oct 2019 01:01:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyBfz8xJMQ91Hy81fyTeUXO/rNSxA/tFHjylF93un5dj7m8D9cJaUL21Yigm9Q2XR8EZhwp X-Received: by 2002:a05:6402:1612:: with SMTP id f18mr14061983edv.66.1571472108662; Sat, 19 Oct 2019 01:01:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571472108; cv=none; d=google.com; s=arc-20160816; b=A23xxAyGFjTedYK1JUU9iGmQrYEPEWzaL28fkT0wxR9NW0FNL5JQQBuPpDtzt2mhnw pn/IKCqtP28aPMIJtIJmVxEVrmqcoIzUNOntLYUQtMiajVPa3PCK5hsz2DfFYoVTD5FV 1pnee+A6DMO+f9sa3/ykA+9WuF8GUhqdxrIvawngM0CD1b23AAxDC8CUQaXOvBdO8CqP OYE0hqjRkjuOrqpQKOiyI9gdqc3a52+MFx1CDKSp6/60CTBwHr2PYav3iEmDI6YGHVC+ /0w3DDEWfhJoBMq4x8L/Z5/MR+BhseqcA76UlqN0hCXRuF8N96a0Wt2bELgk8SOVMbKp BhbQ== 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; bh=8fV1a9ik/tdMN+zBEaetkOgBlmvj1oOxc3jmwonGUAU=; b=chSYwbCe7x4fi4w2kPVZTj+/3YsxfygqwGCaTzy9cQzKfRAtopOiIqNU1nxR/iic46 E2K8ooRdWoDQlQU6mSfcxexD00GTUoanm7Pi0sMBZIytfp1THWRab8ApNVGJGvLayl2E HeVpSdkeW1zz3HHFgzx0AazFCq/tK5ut0FBUWXmCi37u4GotQoXa9tMVStTXS/x3WQB0 afBjNuFiZktSOiTk1QO6DiU6Kv4ZSR6S1+YZ0SQXi1bzpw25n6Q7v6RMK7h5psu24i/7 CEGWVFFm4ZpTpQnO5UmQH3qfy1YRJmOROOLii7b4OQQ8Dpd6Q8XuRIFRTIfxRXlkrjTs oHCA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=iki.fi Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si5144845edq.250.2019.10.19.01.01.24; Sat, 19 Oct 2019 01:01:48 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=iki.fi Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733263AbfJRIhe (ORCPT + 99 others); Fri, 18 Oct 2019 04:37:34 -0400 Received: from emh07.mail.saunalahti.fi ([62.142.5.117]:37292 "EHLO emh07.mail.saunalahti.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727903AbfJRIhe (ORCPT ); Fri, 18 Oct 2019 04:37:34 -0400 Received: from ydin.reaktio.net (reaktio.net [85.76.255.15]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id D49FBB00EA; Fri, 18 Oct 2019 11:37:31 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id CAE1036C0F8; Fri, 18 Oct 2019 11:37:31 +0300 (EEST) Date: Fri, 18 Oct 2019 11:37:31 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" Subject: Re: [PATCH BlueZ 1/4] doc/media-api: Add RegisterApplication method Message-ID: <20191018083731.GJ28704@reaktio.net> References: <20191003181855.GF28704@reaktio.net> <20191006100503.fsbttcschr6wgsdq@pali> <20191006120245.tkrooh45q7irtm6l@pali> <20191007143307.ez6g466afu3trlxn@pali> <20191008103333.rqn2btlkwtcrpouo@pali> <20191009131921.ysl3ianpv5e4m677@pali> <20191017095957.cce7jzejvn76kwkc@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191017095957.cce7jzejvn76kwkc@pali> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Thu, Oct 17, 2019 at 11:59:57AM +0200, Pali Roh?r wrote: > > > > > > > > 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. > +1 It would be nice to get bluez 5.52 released before 5.51 gets released by distros.. -- Pasi