Return-Path: MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 5 Oct 2015 14:35:39 +0300 Message-ID: Subject: Re: Disabling deviceinfo plugin on chromebooks? From: Luiz Augusto von Dentz To: =?UTF-8?Q?Fran=C3=A7ois_Beaufort?= Cc: Marcel Holtmann , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 List-ID: Hi Fran=C3=A7ois, On Mon, Oct 5, 2015 at 2:25 PM, Fran=C3=A7ois Beaufort wrote: > On Sat, Oct 3, 2015 at 7:11 PM, Marcel Holtmann 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