As the chromium team is building and testing the Web Bluetooth API to
let websites discover and interact with nearby Bluetooth devices
(https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web)
I would love to be able to access the Device Information Service
characteristics such as Serial Number String, Hardware Revision String
and so forth.
Sadly, from what I understood, this is not achievable for now on
Chromeboooks since Bluez comes with the deviceinfo plugin enabled by
default. I do wonder now what would be the implications of disabling
the deviceinfo plugin?
You will find more information at
https://code.google.com/p/chromium/issues/detail?id=532930
Thank you in advance,
Francois - a daily Bluez user.
On Wed, Sep 30, 2015 at 4:24 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi François,
>
> On Wed, Sep 30, 2015 at 4:54 PM, François Beaufort
> <[email protected]> wrote:
>> Thanks for your answer Luiz!
>
> Please comment inline in the ml.
>
>> From what I can see, Android and iOS Bluetooth Stack libraries don't
>> claim the device_information service.
>> Could it be possible to make it so that the plugin doesn't block other
>> clients (such as the Web Bluetooth API) from interacting with that
>> service.
>
> That probably a bad behavior in their own because it can only cause
> more traffic as this information can be cached and made available
> without causing any extra traffic, as I said I think we just need to
> expose the extra information over the device API, so we just have to
> add them here:
>
> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
> that it already contains part of device information)
>
As these characteristics might not be useful to everyone, I'm not sure
about the benefit of caching all these device_information service
characteristics in Bluez and exposing them to the bluetooth device
object.
>From a web developer point of view, I think I want to get back as
quick as possible the bluetooth device object and get characteristics
afterwards when I need to.
>> Also, do you know if other services (like device_information) are
>> blocked/claimed by other plugins?
>
> iirc GAP, GATT and HoG services are claimed by bluetoothd, and the
> fact that we claim these services is on purpose so applications cannot
> make conflicting changes or cause unnecessary traffic.
>
Thank you!
>> On Tue, Sep 22, 2015 at 12:05 PM Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>>
>>> Hi François,
>>>
>>> On Tue, Sep 22, 2015 at 11:41 AM, François Beaufort
>>> <[email protected]> wrote:
>>> > As the chromium team is building and testing the Web Bluetooth API to
>>> > let websites discover and interact with nearby Bluetooth devices
>>> > (https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web)
>>> > I would love to be able to access the Device Information Service
>>> > characteristics such as Serial Number String, Hardware Revision String
>>> > and so forth.
>>>
>>> Looks like we don't parse these characteristics just PnP ID which is
>>> expose via Modalias property that has the information of product id
>>> and vendor id, etc.
>>>
>>> > Sadly, from what I understood, this is not achievable for now on
>>> > Chromeboooks since Bluez comes with the deviceinfo plugin enabled by
>>> > default. I do wonder now what would be the implications of disabling
>>> > the deviceinfo plugin?
>>>
>>> The way it works is that the plugin claims this service which prevent
>>> it to be accessible over D-Bus, you could in theory disable the plugin
>>> but I think we would benefit more if we add support for the missing
>>> information directly in BlueZ saving each application the trouble to
>>> read this information themselves.
>>>
>>> If I would do it in BlueZ Id probably add them as properties to
>>> org.bluez.Device1 and make sure we store them as we do with PnP ID.
>>>
>>> > You will find more information at
>>> > https://code.google.com/p/chromium/issues/detail?id=532930
>>> >
>>> > Thank you in advance,
>>> > Francois - a daily Bluez user.
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> > the body of a message to [email protected]
>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz
Hi François,
On Wed, Sep 30, 2015 at 4:54 PM, François Beaufort
<[email protected]> wrote:
> Thanks for your answer Luiz!
Please comment inline in the ml.
> From what I can see, Android and iOS Bluetooth Stack libraries don't
> claim the device_information service.
> Could it be possible to make it so that the plugin doesn't block other
> clients (such as the Web Bluetooth API) from interacting with that
> service.
That probably a bad behavior in their own because it can only cause
more traffic as this information can be cached and made available
without causing any extra traffic, as I said I think we just need to
expose the extra information over the device API, so we just have to
add them here:
https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
that it already contains part of device information)
> Also, do you know if other services (like device_information) are
> blocked/claimed by other plugins?
iirc GAP, GATT and HoG services are claimed by bluetoothd, and the
fact that we claim these services is on purpose so applications cannot
make conflicting changes or cause unnecessary traffic.
> On Tue, Sep 22, 2015 at 12:05 PM Luiz Augusto von Dentz
> <[email protected]> wrote:
>>
>> Hi François,
>>
>> On Tue, Sep 22, 2015 at 11:41 AM, François Beaufort
>> <[email protected]> wrote:
>> > As the chromium team is building and testing the Web Bluetooth API to
>> > let websites discover and interact with nearby Bluetooth devices
>> > (https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web)
>> > I would love to be able to access the Device Information Service
>> > characteristics such as Serial Number String, Hardware Revision String
>> > and so forth.
>>
>> Looks like we don't parse these characteristics just PnP ID which is
>> expose via Modalias property that has the information of product id
>> and vendor id, etc.
>>
>> > Sadly, from what I understood, this is not achievable for now on
>> > Chromeboooks since Bluez comes with the deviceinfo plugin enabled by
>> > default. I do wonder now what would be the implications of disabling
>> > the deviceinfo plugin?
>>
>> The way it works is that the plugin claims this service which prevent
>> it to be accessible over D-Bus, you could in theory disable the plugin
>> but I think we would benefit more if we add support for the missing
>> information directly in BlueZ saving each application the trouble to
>> read this information themselves.
>>
>> If I would do it in BlueZ Id probably add them as properties to
>> org.bluez.Device1 and make sure we store them as we do with PnP ID.
>>
>> > You will find more information at
>> > https://code.google.com/p/chromium/issues/detail?id=532930
>> >
>> > Thank you in advance,
>> > Francois - a daily Bluez user.
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> > the body of a message to [email protected]
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
Thanks for your answer Luiz!
>From what I can see, Android and iOS Bluetooth Stack libraries don't
claim the device_information service.
Could it be possible to make it so that the plugin doesn't block other
clients (such as the Web Bluetooth API) from interacting with that
service.
Also, do you know if other services (like device_information) are
blocked/claimed by other plugins?
On Tue, Sep 22, 2015 at 12:05 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi François,
>
> On Tue, Sep 22, 2015 at 11:41 AM, François Beaufort
> <[email protected]> wrote:
> > As the chromium team is building and testing the Web Bluetooth API to
> > let websites discover and interact with nearby Bluetooth devices
> > (https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web)
> > I would love to be able to access the Device Information Service
> > characteristics such as Serial Number String, Hardware Revision String
> > and so forth.
>
> Looks like we don't parse these characteristics just PnP ID which is
> expose via Modalias property that has the information of product id
> and vendor id, etc.
>
> > Sadly, from what I understood, this is not achievable for now on
> > Chromeboooks since Bluez comes with the deviceinfo plugin enabled by
> > default. I do wonder now what would be the implications of disabling
> > the deviceinfo plugin?
>
> The way it works is that the plugin claims this service which prevent
> it to be accessible over D-Bus, you could in theory disable the plugin
> but I think we would benefit more if we add support for the missing
> information directly in BlueZ saving each application the trouble to
> read this information themselves.
>
> If I would do it in BlueZ Id probably add them as properties to
> org.bluez.Device1 and make sure we store them as we do with PnP ID.
>
> > You will find more information at
> > https://code.google.com/p/chromium/issues/detail?id=532930
> >
> > Thank you in advance,
> > Francois - a daily Bluez user.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Luiz Augusto von Dentz
Hi François,
On Tue, Sep 22, 2015 at 11:41 AM, François Beaufort
<[email protected]> wrote:
> As the chromium team is building and testing the Web Bluetooth API to
> let websites discover and interact with nearby Bluetooth devices
> (https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web)
> I would love to be able to access the Device Information Service
> characteristics such as Serial Number String, Hardware Revision String
> and so forth.
Looks like we don't parse these characteristics just PnP ID which is
expose via Modalias property that has the information of product id
and vendor id, etc.
> Sadly, from what I understood, this is not achievable for now on
> Chromeboooks since Bluez comes with the deviceinfo plugin enabled by
> default. I do wonder now what would be the implications of disabling
> the deviceinfo plugin?
The way it works is that the plugin claims this service which prevent
it to be accessible over D-Bus, you could in theory disable the plugin
but I think we would benefit more if we add support for the missing
information directly in BlueZ saving each application the trouble to
read this information themselves.
If I would do it in BlueZ Id probably add them as properties to
org.bluez.Device1 and make sure we store them as we do with PnP ID.
> You will find more information at
> https://code.google.com/p/chromium/issues/detail?id=532930
>
> Thank you in advance,
> Francois - a daily Bluez user.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
Hi Fran=C3=A7ois,
On Mon, Oct 5, 2015 at 2:36 PM, Fran=C3=A7ois Beaufort
<[email protected]> wrote:
> Do you want me to push a Pull Request?
Nope, I can probably do it myself, but take a look at my comments:
https://code.google.com/p/chromium/issues/detail?id=3D532930#c12
--=20
Luiz Augusto von Dentz
Do you want me to push a Pull Request?
On Mon, Oct 5, 2015 at 1:35 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Fran=C3=A7ois,
>
> On Mon, Oct 5, 2015 at 2:25 PM, Fran=C3=A7ois Beaufort
> <[email protected]> wrote:
>> On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann <[email protected]> wr=
ote:
>>>
>>> Hi Francois,
>>>
>>> >>> Thanks for your answer Luiz!
>>> >>
>>> >> Please comment inline in the ml.
>>> >>
>>> >>> From what I can see, Android and iOS Bluetooth Stack libraries don'=
t
>>> >>> claim the device_information service.
>>> >>> Could it be possible to make it so that the plugin doesn't block ot=
her
>>> >>> clients (such as the Web Bluetooth API) from interacting with that
>>> >>> service.
>>> >>
>>> >> That probably a bad behavior in their own because it can only cause
>>> >> more traffic as this information can be cached and made available
>>> >> without causing any extra traffic, as I said I think we just need to
>>> >> expose the extra information over the device API, so we just have to
>>> >> add them here:
>>> >>
>>> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (not=
e
>>> >> that it already contains part of device information)
>>> >>
>>> >
>>> > As these characteristics might not be useful to everyone, I'm not sur=
e
>>> > about the benefit of caching all these device_information service
>>> > characteristics in Bluez and exposing them to the bluetooth device
>>> > object.
>>> > From a web developer point of view, I think I want to get back as
>>> > quick as possible the bluetooth device object and get characteristics
>>> > afterwards when I need to.
>>>
>>> I am actually fine if we let Device Info services be read by any client=
. However it is a bit trickier since that means an exception in our code.
>>>
>>
>> That would be awesome actually!
>>
>>> Also only Device Info will fall ever into this category where you have =
a system service reading it and where it might be useful for non-system cli=
ents. When bluetoothd implement the profile side then we can not have anoth=
er client trying to mess around with it. Especially when it is security sen=
sitive like HID.
>>
>> That makes sense. Thank you Marcel!
>
> The easiest way to accomplish this is the following:
>
> diff --git a/profiles/deviceinfo/deviceinfo.c b/profiles/deviceinfo/devic=
einfo.c
> index a0e9951..501f791 100644
> --- a/profiles/deviceinfo/deviceinfo.c
> +++ b/profiles/deviceinfo/deviceinfo.c
> @@ -192,7 +192,8 @@ static struct btd_profile deviceinfo_profile =3D {
> .name =3D "deviceinfo",
> .remote_uuid =3D DEVICE_INFORMATION_UUID,
> .device_probe =3D deviceinfo_driver_probe,
> - .device_remove =3D deviceinfo_driver_remove
> + .device_remove =3D deviceinfo_driver_remove,
> + .external =3D true
> };
>
> static int deviceinfo_init(void)
> --
> Luiz Augusto von Dentz
Hi Fran=C3=A7ois,
On Mon, Oct 5, 2015 at 2:25 PM, Fran=C3=A7ois Beaufort
<[email protected]> wrote:
> On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann <[email protected]> wro=
te:
>>
>> Hi Francois,
>>
>> >>> Thanks for your answer Luiz!
>> >>
>> >> Please comment inline in the ml.
>> >>
>> >>> From what I can see, Android and iOS Bluetooth Stack libraries don't
>> >>> claim the device_information service.
>> >>> Could it be possible to make it so that the plugin doesn't block oth=
er
>> >>> clients (such as the Web Bluetooth API) from interacting with that
>> >>> service.
>> >>
>> >> That probably a bad behavior in their own because it can only cause
>> >> more traffic as this information can be cached and made available
>> >> without causing any extra traffic, as I said I think we just need to
>> >> expose the extra information over the device API, so we just have to
>> >> add them here:
>> >>
>> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
>> >> that it already contains part of device information)
>> >>
>> >
>> > As these characteristics might not be useful to everyone, I'm not sure
>> > about the benefit of caching all these device_information service
>> > characteristics in Bluez and exposing them to the bluetooth device
>> > object.
>> > From a web developer point of view, I think I want to get back as
>> > quick as possible the bluetooth device object and get characteristics
>> > afterwards when I need to.
>>
>> I am actually fine if we let Device Info services be read by any client.=
However it is a bit trickier since that means an exception in our code.
>>
>
> That would be awesome actually!
>
>> Also only Device Info will fall ever into this category where you have a=
system service reading it and where it might be useful for non-system clie=
nts. When bluetoothd implement the profile side then we can not have anothe=
r client trying to mess around with it. Especially when it is security sens=
itive like HID.
>
> That makes sense. Thank you Marcel!
The easiest way to accomplish this is the following:
diff --git a/profiles/deviceinfo/deviceinfo.c b/profiles/deviceinfo/devicei=
nfo.c
index a0e9951..501f791 100644
--- a/profiles/deviceinfo/deviceinfo.c
+++ b/profiles/deviceinfo/deviceinfo.c
@@ -192,7 +192,8 @@ static struct btd_profile deviceinfo_profile =3D {
.name =3D "deviceinfo",
.remote_uuid =3D DEVICE_INFORMATION_UUID,
.device_probe =3D deviceinfo_driver_probe,
- .device_remove =3D deviceinfo_driver_remove
+ .device_remove =3D deviceinfo_driver_remove,
+ .external =3D true
};
static int deviceinfo_init(void)
--=20
Luiz Augusto von Dentz
On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann <[email protected]> wrote=
:
>
> Hi Francois,
>
> >>> Thanks for your answer Luiz!
> >>
> >> Please comment inline in the ml.
> >>
> >>> From what I can see, Android and iOS Bluetooth Stack libraries don't
> >>> claim the device_information service.
> >>> Could it be possible to make it so that the plugin doesn't block othe=
r
> >>> clients (such as the Web Bluetooth API) from interacting with that
> >>> service.
> >>
> >> That probably a bad behavior in their own because it can only cause
> >> more traffic as this information can be cached and made available
> >> without causing any extra traffic, as I said I think we just need to
> >> expose the extra information over the device API, so we just have to
> >> add them here:
> >>
> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
> >> that it already contains part of device information)
> >>
> >
> > As these characteristics might not be useful to everyone, I'm not sure
> > about the benefit of caching all these device_information service
> > characteristics in Bluez and exposing them to the bluetooth device
> > object.
> > From a web developer point of view, I think I want to get back as
> > quick as possible the bluetooth device object and get characteristics
> > afterwards when I need to.
>
> I am actually fine if we let Device Info services be read by any client. =
However it is a bit trickier since that means an exception in our code.
>
That would be awesome actually!
> Also only Device Info will fall ever into this category where you have a =
system service reading it and where it might be useful for non-system clien=
ts. When bluetoothd implement the profile side then we can not have another=
client trying to mess around with it. Especially when it is security sensi=
tive like HID.
That makes sense. Thank you Marcel!
>
> Regards
>
> Marcel
>
On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Francois,
>
> >>> Thanks for your answer Luiz!
> >>
> >> Please comment inline in the ml.
> >>
> >>> From what I can see, Android and iOS Bluetooth Stack libraries don't
> >>> claim the device_information service.
> >>> Could it be possible to make it so that the plugin doesn't block other
> >>> clients (such as the Web Bluetooth API) from interacting with that
> >>> service.
> >>
> >> That probably a bad behavior in their own because it can only cause
> >> more traffic as this information can be cached and made available
> >> without causing any extra traffic, as I said I think we just need to
> >> expose the extra information over the device API, so we just have to
> >> add them here:
> >>
> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
> >> that it already contains part of device information)
> >>
> >
> > As these characteristics might not be useful to everyone, I'm not sure
> > about the benefit of caching all these device_information service
> > characteristics in Bluez and exposing them to the bluetooth device
> > object.
> > From a web developer point of view, I think I want to get back as
> > quick as possible the bluetooth device object and get characteristics
> > afterwards when I need to.
>
> I am actually fine if we let Device Info services be read by any client.
> However it is a bit trickier since that means an exception in our code.
>
>
That would be awesome actually!
Also only Device Info will fall ever into this category where you have a
> system service reading it and where it might be useful for non-system
> clients. When bluetoothd implement the profile side then we can not have
> another client trying to mess around with it. Especially when it is
> security sensitive like HID.
>
>
That makes sense. Thank you Marcel!
> Regards
>
> Marcel
>
>
On Sat, Oct 3, 2015 at 7:11 PM Marcel Holtmann <[email protected]> wrote:
> Hi Francois,
>
> >>> Thanks for your answer Luiz!
> >>
> >> Please comment inline in the ml.
> >>
> >>> From what I can see, Android and iOS Bluetooth Stack libraries don't
> >>> claim the device_information service.
> >>> Could it be possible to make it so that the plugin doesn't block other
> >>> clients (such as the Web Bluetooth API) from interacting with that
> >>> service.
> >>
> >> That probably a bad behavior in their own because it can only cause
> >> more traffic as this information can be cached and made available
> >> without causing any extra traffic, as I said I think we just need to
> >> expose the extra information over the device API, so we just have to
> >> add them here:
> >>
> >> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
> >> that it already contains part of device information)
> >>
> >
> > As these characteristics might not be useful to everyone, I'm not sure
> > about the benefit of caching all these device_information service
> > characteristics in Bluez and exposing them to the bluetooth device
> > object.
> > From a web developer point of view, I think I want to get back as
> > quick as possible the bluetooth device object and get characteristics
> > afterwards when I need to.
>
> I am actually fine if we let Device Info services be read by any client.
> However it is a bit trickier since that means an exception in our code.
>
>
That would be awesome actually!
> Also only Device Info will fall ever into this category where you have a
> system service reading it and where it might be useful for non-system
> clients. When bluetoothd implement the profile side then we can not have
> another client trying to mess around with it. Especially when it is
> security sensitive like HID.
>
That makes sense. Thank you Marcel!
>
> Regards
>
> Marcel
>
>
Hi Francois,
>>> Thanks for your answer Luiz!
>>
>> Please comment inline in the ml.
>>
>>> From what I can see, Android and iOS Bluetooth Stack libraries don't
>>> claim the device_information service.
>>> Could it be possible to make it so that the plugin doesn't block other
>>> clients (such as the Web Bluetooth API) from interacting with that
>>> service.
>>
>> That probably a bad behavior in their own because it can only cause
>> more traffic as this information can be cached and made available
>> without causing any extra traffic, as I said I think we just need to
>> expose the extra information over the device API, so we just have to
>> add them here:
>>
>> https://webbluetoothcg.github.io/web-bluetooth/#bluetoothdevice (note
>> that it already contains part of device information)
>>
>
> As these characteristics might not be useful to everyone, I'm not sure
> about the benefit of caching all these device_information service
> characteristics in Bluez and exposing them to the bluetooth device
> object.
> From a web developer point of view, I think I want to get back as
> quick as possible the bluetooth device object and get characteristics
> afterwards when I need to.
I am actually fine if we let Device Info services be read by any client. However it is a bit trickier since that means an exception in our code.
Also only Device Info will fall ever into this category where you have a system service reading it and where it might be useful for non-system clients. When bluetoothd implement the profile side then we can not have another client trying to mess around with it. Especially when it is security sensitive like HID.
Regards
Marcel