From: "Pali Rohár" <pali.rohar@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: bluez: dbus method call for switching endpoint
Date: Sat, 15 Dec 2018 21:29:10 +0100 [thread overview]
Message-ID: <20181215202910.j24amjshrvjqprll@pali> (raw)
In-Reply-To: <20180711144501.ovdxc2expa4bg6sc@pali>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
On Wednesday 11 July 2018 16:45:01 Pali Rohár wrote:
> On Wednesday 11 July 2018 16:27:07 Luiz Augusto von Dentz wrote:
> > One way to solve all of these is that we would expose the remote
> > endpoints using MediaEndpoint1
>
> So client application (like pulseadio) would see list of remote
> endpoints (one for each codec) and choose one for connection?
>
> Looks like this should solve this problem.
Are there any progress on such API in bluez?
On pulseaudio mailing list other people proposed patches for other A2DP
codecs and basically bluez API for choosing A2DP codec is still missing
part...
> > though only SelectConfiguration would
> > be really useful here and that doesn't contain the remote capabilities
> > that probably should be made into properties, along with codec type
> > and uuid.
>
> Remote capabilities are needed. And for codec type == vendor it is needed
> to know also vendor id and codec id.
>
> > Besides a good headset would probably
> > remember what codec you selected the last time and just connect with
> > it, this btw is what I would do when operating as a sink.
>
> I hope that Linux would support also not-so-good headsets.
>
> Anyway, dual booting between systems which support different set of
> codecs makes those "good headset" with remember support just
> "no-so-good" one.
>
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2018-12-15 20:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 8:23 bluez: dbus method call for switching endpoint Pali Rohár
2018-07-11 13:27 ` Luiz Augusto von Dentz
2018-07-11 14:45 ` Pali Rohár
2018-12-15 20:29 ` Pali Rohár [this message]
2018-12-18 16:02 ` Luiz Augusto von Dentz
2018-12-28 19:11 ` Pasi Kärkkäinen
2018-12-28 22:10 ` Luiz Augusto von Dentz
2018-12-29 13:08 ` Pali Rohár
2019-01-08 16:44 ` Luiz Augusto von Dentz
2019-01-08 16:51 ` Pali Rohár
2019-01-08 16:56 ` Pali Rohár
2019-01-09 18:03 ` Pali Rohár
2019-01-09 18:14 ` Pali Rohár
2019-01-10 11:29 ` Luiz Augusto von Dentz
2019-01-10 11:59 ` Pali Rohár
2019-01-26 10:15 ` Pali Rohár
2019-01-19 17:15 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181215202910.j24amjshrvjqprll@pali \
--to=pali.rohar@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).