* Device class not writeable via dbus @ 2015-04-15 19:03 Marcus Redeker 2015-04-16 6:48 ` Szymon Janc 0 siblings, 1 reply; 10+ messages in thread From: Marcus Redeker @ 2015-04-15 19:03 UTC (permalink / raw) To: linux-bluetooth All, the class property is read only on the dbus interface of „org.blue.Adapter1“. Why is that? How can I change the device class from my program? Regards, -Marcus ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-15 19:03 Device class not writeable via dbus Marcus Redeker @ 2015-04-16 6:48 ` Szymon Janc 2015-04-16 7:09 ` Marcus Redeker 0 siblings, 1 reply; 10+ messages in thread From: Szymon Janc @ 2015-04-16 6:48 UTC (permalink / raw) To: Marcus Redeker; +Cc: linux-bluetooth Hi Marcus, On Wednesday 15 of April 2015 21:03:08 Marcus Redeker wrote: > All, > the class property is read only on the dbus interface of > „org.blue.Adapter1“. Why is that? > How can I change the device class from my program? > Regards, > -Marcus You can configure CoD in main.conf [General] Class = 0x000100 Note the comment that only major and minor bits are considered. Service bits are dynamically configured based on registered services. -- BR Szymon Janc ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 6:48 ` Szymon Janc @ 2015-04-16 7:09 ` Marcus Redeker 2015-04-16 8:01 ` Szymon Janc 0 siblings, 1 reply; 10+ messages in thread From: Marcus Redeker @ 2015-04-16 7:09 UTC (permalink / raw) To: Szymon Janc; +Cc: linux-bluetooth True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. Any chance this can be done in the near future? -Marcus > > You can configure CoD in main.conf > [General] > Class = 0x000100 > > Note the comment that only major and minor bits are considered. Service bits > are dynamically configured based on registered services. > > > -- > BR > Szymon Janc ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 7:09 ` Marcus Redeker @ 2015-04-16 8:01 ` Szymon Janc 2015-04-16 8:15 ` Luiz Augusto von Dentz 2015-04-16 8:44 ` Marcus Redeker 0 siblings, 2 replies; 10+ messages in thread From: Szymon Janc @ 2015-04-16 8:01 UTC (permalink / raw) To: Marcus Redeker; +Cc: linux-bluetooth Hi Marcus, On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: > True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. > Any chance this can be done in the near future? > -Marcus > Class of Device is rather static configuration as those describe form factor and that usually doesn't change. Why do you need to change CoD on the fly? PS Please don't top post on ML. > > > > You can configure CoD in main.conf > > [General] > > Class = 0x000100 > > > > Note the comment that only major and minor bits are considered. Service bits > > are dynamically configured based on registered services. > > > > > -- Best regards, Szymon Janc ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 8:01 ` Szymon Janc @ 2015-04-16 8:15 ` Luiz Augusto von Dentz 2015-04-16 8:53 ` Marcus Redeker 2015-04-16 8:44 ` Marcus Redeker 1 sibling, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2015-04-16 8:15 UTC (permalink / raw) To: Szymon Janc; +Cc: Marcus Redeker, linux-bluetooth Hi Szymon, Marcus, On Thu, Apr 16, 2015 at 11:01 AM, Szymon Janc <szymon.janc@tieto.com> wrote: > Hi Marcus, > > On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: >> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >> Any chance this can be done in the near future? >> -Marcus >> > > Class of Device is rather static configuration as those describe form factor > and that usually doesn't change. > > Why do you need to change CoD on the fly? It is possible to change at runtime by using systemd hostname plugin then change the org.freedesktop.hostname1.Chassis property, but Im not sure how easy is to change that. Anyway the point is that this should not changed by applications at will as it could break discovery filtering, even thought filtering by class is probably broken by design. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 8:15 ` Luiz Augusto von Dentz @ 2015-04-16 8:53 ` Marcus Redeker 2015-04-16 9:36 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Marcus Redeker @ 2015-04-16 8:53 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Szymon Janc, linux-bluetooth > On 16.04.2015, at 10:15, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Szymon, Marcus, > > On Thu, Apr 16, 2015 at 11:01 AM, Szymon Janc <szymon.janc@tieto.com> wrote: >> Hi Marcus, >> >> On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: >>> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >>> Any chance this can be done in the near future? >>> -Marcus >>> >> >> Class of Device is rather static configuration as those describe form factor >> and that usually doesn't change. >> >> Why do you need to change CoD on the fly? > > It is possible to change at runtime by using systemd hostname plugin > then change the org.freedesktop.hostname1.Chassis property, but Im not > sure how easy is to change that. Anyway the point is that this should > not changed by applications at will as it could break discovery > filtering, even thought filtering by class is probably broken by > design. > > -- > Luiz Augusto von Dentz This would allow to change the name of the bluetooth adapter but not the device class. The name can already be changed using the read/write alias property which is no problem. -Marcus ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 8:53 ` Marcus Redeker @ 2015-04-16 9:36 ` Luiz Augusto von Dentz 2015-04-16 10:08 ` Marcus Redeker 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2015-04-16 9:36 UTC (permalink / raw) To: Marcus Redeker; +Cc: Szymon Janc, linux-bluetooth Hi Marcus, On Thu, Apr 16, 2015 at 11:53 AM, Marcus Redeker <marcus@openremote.org> wrote: > >> On 16.04.2015, at 10:15, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: >> >> Hi Szymon, Marcus, >> >> On Thu, Apr 16, 2015 at 11:01 AM, Szymon Janc <szymon.janc@tieto.com> wrote: >>> Hi Marcus, >>> >>> On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: >>>> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >>>> Any chance this can be done in the near future? >>>> -Marcus >>>> >>> >>> Class of Device is rather static configuration as those describe form factor >>> and that usually doesn't change. >>> >>> Why do you need to change CoD on the fly? >> >> It is possible to change at runtime by using systemd hostname plugin >> then change the org.freedesktop.hostname1.Chassis property, but Im not >> sure how easy is to change that. Anyway the point is that this should >> not changed by applications at will as it could break discovery >> filtering, even thought filtering by class is probably broken by >> design. >> >> -- >> Luiz Augusto von Dentz > > This would allow to change the name of the bluetooth adapter but not the device class. > The name can already be changed using the read/write alias property which is no problem. Looks like you know more than us how BlueZ works, perhaps you want to tell me what is this code for: http://fpaste.org/211586/76181142/ Btw, BLE don't really have a class it has appearance which is not quite the same, we may actually have a different property for appearance along with a main.conf entry to set it and also a conversion from chassis to appearance. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 9:36 ` Luiz Augusto von Dentz @ 2015-04-16 10:08 ` Marcus Redeker 2015-04-16 10:35 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Marcus Redeker @ 2015-04-16 10:08 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Szymon Janc, linux-bluetooth > On 16.04.2015, at 11:36, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Marcus, > > On Thu, Apr 16, 2015 at 11:53 AM, Marcus Redeker <marcus@openremote.org> wrote: >> >>> On 16.04.2015, at 10:15, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: >>> >>> Hi Szymon, Marcus, >>> >>> On Thu, Apr 16, 2015 at 11:01 AM, Szymon Janc <szymon.janc@tieto.com> wrote: >>>> Hi Marcus, >>>> >>>> On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: >>>>> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >>>>> Any chance this can be done in the near future? >>>>> -Marcus >>>>> >>>> >>>> Class of Device is rather static configuration as those describe form factor >>>> and that usually doesn't change. >>>> >>>> Why do you need to change CoD on the fly? >>> >>> It is possible to change at runtime by using systemd hostname plugin >>> then change the org.freedesktop.hostname1.Chassis property, but Im not >>> sure how easy is to change that. Anyway the point is that this should >>> not changed by applications at will as it could break discovery >>> filtering, even thought filtering by class is probably broken by >>> design. >>> >>> -- >>> Luiz Augusto von Dentz >> >> This would allow to change the name of the bluetooth adapter but not the device class. >> The name can already be changed using the read/write alias property which is no problem. > > Looks like you know more than us how BlueZ works, perhaps you want to > tell me what is this code for: > > http://fpaste.org/211586/76181142/ > > Btw, BLE don't really have a class it has appearance which is not > quite the same, we may actually have a different property for > appearance along with a main.conf entry to set it and also a > conversion from chassis to appearance. > > > > -- > Luiz Augusto von Dentz Sorry, if I stated something wrong. I did not check the BlueZ code. I don’t know BlueZ at all and I am just trying to look at it from a user prospective who is trying to use dbus and BlueZ to create an application. Looking at the complete file hostname.c, I can see that changing the Chassis property would indeed change the device class but only to predefinded values desktop, server, laptop, handset and tablet. I will not be able to use it to change to HID device class 0x000540 -Marcus ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 10:08 ` Marcus Redeker @ 2015-04-16 10:35 ` Luiz Augusto von Dentz 0 siblings, 0 replies; 10+ messages in thread From: Luiz Augusto von Dentz @ 2015-04-16 10:35 UTC (permalink / raw) To: Marcus Redeker; +Cc: Szymon Janc, linux-bluetooth Hi Marcus, On Thu, Apr 16, 2015 at 1:08 PM, Marcus Redeker <marcus@openremote.org> wrote: > >> On 16.04.2015, at 11:36, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: >> >> Hi Marcus, >> >> On Thu, Apr 16, 2015 at 11:53 AM, Marcus Redeker <marcus@openremote.org> wrote: >>> >>>> On 16.04.2015, at 10:15, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: >>>> >>>> Hi Szymon, Marcus, >>>> >>>> On Thu, Apr 16, 2015 at 11:01 AM, Szymon Janc <szymon.janc@tieto.com> wrote: >>>>> Hi Marcus, >>>>> >>>>> On Thursday 16 of April 2015 09:09:28 Marcus Redeker wrote: >>>>>> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >>>>>> Any chance this can be done in the near future? >>>>>> -Marcus >>>>>> >>>>> >>>>> Class of Device is rather static configuration as those describe form factor >>>>> and that usually doesn't change. >>>>> >>>>> Why do you need to change CoD on the fly? >>>> >>>> It is possible to change at runtime by using systemd hostname plugin >>>> then change the org.freedesktop.hostname1.Chassis property, but Im not >>>> sure how easy is to change that. Anyway the point is that this should >>>> not changed by applications at will as it could break discovery >>>> filtering, even thought filtering by class is probably broken by >>>> design. >>>> >>>> -- >>>> Luiz Augusto von Dentz >>> >>> This would allow to change the name of the bluetooth adapter but not the device class. >>> The name can already be changed using the read/write alias property which is no problem. >> >> Looks like you know more than us how BlueZ works, perhaps you want to >> tell me what is this code for: >> >> http://fpaste.org/211586/76181142/ >> >> Btw, BLE don't really have a class it has appearance which is not >> quite the same, we may actually have a different property for >> appearance along with a main.conf entry to set it and also a >> conversion from chassis to appearance. >> >> >> >> -- >> Luiz Augusto von Dentz > > Sorry, if I stated something wrong. I did not check the BlueZ code. > I don’t know BlueZ at all and I am just trying to look at it from a user prospective who is trying to use dbus and BlueZ to create an application. > > Looking at the complete file hostname.c, I can see that changing the Chassis property would indeed change the device class but only to predefinded values desktop, server, laptop, handset and tablet. > I will not be able to use it to change to HID device class 0x000540 First think, is this HoG or HID profile for BT classic, I suppose it is the later but you commented about BLE for home automation so perhaps you are running Classic + BLE setup. Note that the class of device only applies to BT classic and for BLE if you act as central, the lamps would be peripheral, you don't really need to set an appearance, so you might just need to set 0x000540 in your main.conf or perhaps suggest another mapping to Chassis e.g. "Remote Controller" if you are planning to use systemd/hostnamed, but then you need to make it accept the new type. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Device class not writeable via dbus 2015-04-16 8:01 ` Szymon Janc 2015-04-16 8:15 ` Luiz Augusto von Dentz @ 2015-04-16 8:44 ` Marcus Redeker 1 sibling, 0 replies; 10+ messages in thread From: Marcus Redeker @ 2015-04-16 8:44 UTC (permalink / raw) To: Szymon Janc; +Cc: linux-bluetooth >>> >>> You can configure CoD in main.conf >>> [General] >>> Class = 0x000100 >>> >>> Note the comment that only major and minor bits are considered. Service bits >>> are dynamically configured based on registered services. >>> >>> >> True, but I would like todo that through dbus and not manually and have to restart bluetoothd afterwards. >> Any chance this can be done in the near future? >> -Marcus > Class of Device is rather static configuration as those describe form factor > and that usually doesn't change. > > Why do you need to change CoD on the fly? > > PS > Please don't top post on ML. > -- > Best regards, > Szymon Janc For home automation sometimes our home controller acta as a virtual keyboard and some devices need the coresponding major/minor device class or else they don’t show them during discovery. Another user might wants to use his home controller to control bluetooth LE lights which are coming out more and more. Or maybe Bluetooth LE (GATT) does not need the device class anymore ? —Marcus ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-04-16 10:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-15 19:03 Device class not writeable via dbus Marcus Redeker 2015-04-16 6:48 ` Szymon Janc 2015-04-16 7:09 ` Marcus Redeker 2015-04-16 8:01 ` Szymon Janc 2015-04-16 8:15 ` Luiz Augusto von Dentz 2015-04-16 8:53 ` Marcus Redeker 2015-04-16 9:36 ` Luiz Augusto von Dentz 2015-04-16 10:08 ` Marcus Redeker 2015-04-16 10:35 ` Luiz Augusto von Dentz 2015-04-16 8:44 ` Marcus Redeker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.