From: Bastien Nocera <hadess@hadess.net>
To: Sonny Sasaka <sonnysasaka@chromium.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
Miao-chen Chou <mcchou@chromium.org>
Subject: Re: [PATCH BlueZ v3 4/7] doc: Add Battery Provider API doc
Date: Fri, 27 Nov 2020 13:31:47 +0100 [thread overview]
Message-ID: <ec514dae04260d4ef78ce56f3e0f78d4e2fb094c.camel@hadess.net> (raw)
In-Reply-To: <CAO271m=Bsz8NXtHzjAn5iYxMs0hxd17DW9QCUnXZACywTDVcvg@mail.gmail.com>
On Tue, 2020-11-24 at 13:29 -0800, Sonny Sasaka wrote:
>
> We need a convention to match the exposed object by the battery
> provider and BlueZ's device. I am suggesting that the simplest
> convention is to use the same path of the BlueZ's device object,
> which
> is easy to follow and implement by providers. Otherwise, we would
> still need another convention to match them, but I think any other
> convention is likely more complex to implement by battery providers.
> Can you suggest an alternative convention to match the battery and
> the
> device?
You should match on the interface being available, not the object
path.
UPower does that, it just watches for ObjectManager signals, and checks
whether the expected interface is available when a new object appears:
https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/linux/up-backend.c#L314-357
There's no reason to care about the object path.
next prev parent reply other threads:[~2020-11-27 12:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 20:57 [PATCH BlueZ v3 1/7] battery: Add the internal Battery API Sonny Sasaka
2020-11-20 20:57 ` [PATCH BlueZ v3 2/7] profiles/battery: Refactor to use battery library Sonny Sasaka
2020-11-20 20:57 ` [PATCH BlueZ v3 3/7] battery: Add Source property to Battery API Sonny Sasaka
2020-11-20 20:57 ` [PATCH BlueZ v3 4/7] doc: Add Battery Provider API doc Sonny Sasaka
2020-11-24 21:21 ` Luiz Augusto von Dentz
2020-11-24 21:29 ` Sonny Sasaka
2020-11-25 0:23 ` Luiz Augusto von Dentz
2020-11-25 1:20 ` Sonny Sasaka
2020-11-27 12:35 ` Bastien Nocera
2020-11-29 6:16 ` Luiz Augusto von Dentz
2020-11-30 20:02 ` Sonny Sasaka
2020-11-27 12:31 ` Bastien Nocera [this message]
2020-11-20 20:57 ` [PATCH BlueZ v3 5/7] test: Add test app for Battery Provider API Sonny Sasaka
2020-11-20 20:57 ` [PATCH BlueZ v3 6/7] adapter: Add a public function to find a device by path Sonny Sasaka
2020-11-20 20:57 ` [PATCH BlueZ v3 7/7] battery: Implement Battery Provider API Sonny Sasaka
2020-11-20 21:26 ` [BlueZ,v3,1/7] battery: Add the internal Battery API bluez.test.bot
2020-11-20 22:11 ` Sonny Sasaka
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=ec514dae04260d4ef78ce56f3e0f78d4e2fb094c.camel@hadess.net \
--to=hadess@hadess.net \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=mcchou@chromium.org \
--cc=sonnysasaka@chromium.org \
/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).