Marcel,
Is it a good idea/Are there any plans to extend the current DBUS API to enable
Major/Minor/Service classes of the local Adapter to be available/settable in
integer form? The string representations are nice and user-friendly, however
we need to maintain internationalized versions of these, so doing conversion
ourselves is much easier.
This would also solve the problem of combination minor device numbers (e.g. in
case of peripherals). How would you set "Pointing device" + "Joystick" via
the current API? It would also bring the API closer in line with the
RemoteDevice API which uses uint32 to represent the class.
Perhaps SetClass(uint32) and
uint32 GetClass()?
If this is wanted, I can work on a patch.
-Denis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> What you say makes sense, but I'd like to raise the same question about the
> Remote device class. Currently the RemoteDeviceFound and RemoteClassUpdated
> signals use the numberic form of the device class. However,
> GetRemoteMajorClass, GetRemoteMinorClass and GetRemoteServiceClasses use the
> string format. Would it make sense to add the GetRemoteClass method which
> would return the uint32 format as well? Would certainly make some tasks
> easier to program than having to rely on RemoteClassUpdated signal.
actually I left it out on purpose at the moment. It is easier to extend
the API than remove a method. Send in a patch and then get opinions from
other people. I am open for it.
> Another question, I noticed that Manufacturer, Company, Revision, Version
> attributes are not discovered until an initial connection is made. A user
> might want to take extra steps to be presented with such information (e.g.
> remote device properties dialog), and it would be nice if I could force the
> DBUS API to get that information for me somehow, even if the device has not
> been previously connected to. Is there a solution?
It is not as easy as you think and we didn't had the time to schedule
HCI commands to retrieve this information if they are missing. Feel free
to send in a patch.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
What you say makes sense, but I'd like to raise the same question about the
Remote device class. Currently the RemoteDeviceFound and RemoteClassUpdated
signals use the numberic form of the device class. However,
GetRemoteMajorClass, GetRemoteMinorClass and GetRemoteServiceClasses use the
string format. Would it make sense to add the GetRemoteClass method which
would return the uint32 format as well? Would certainly make some tasks
easier to program than having to rely on RemoteClassUpdated signal.
Another question, I noticed that Manufacturer, Company, Revision, Version
attributes are not discovered until an initial connection is made. A user
might want to take extra steps to be presented with such information (e.g.
remote device properties dialog), and it would be nice if I could force the
DBUS API to get that information for me somehow, even if the device has not
been previously connected to. Is there a solution?
-Denis
On Tuesday 18 July 2006 20:54, Marcel Holtmann wrote:
> the choice for strings has been made to make it easier for languages
> like Python etc. to handle this. Another thing is that we only support
> the change of the minor class if the major class is "computer". No other
> change through the D-Bus API makes really sense.
>
> If another major class has to be supported, then this has to be set in
> hcid.conf and it will disable the ListAvailableMinorClasses() and
> SetMinorClass() methods. This will be true for all embedded devices
> running BlueZ. They will set the major and minor class through hcid.conf
> and then no more changes to it are needed. The only exception at the
> moment will be an access point where the minor class indicates the
> number of connected clients. However this should also not be changed
> through the D-Bus API. We will integrate another method for this once we
> started working on the access point daemon.
>
> The service classes are need to be under control of sdpd, because they
> depend on the registered services. So a generic method to change the
> class of device is not a good idea.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> Is it a good idea/Are there any plans to extend the current DBUS API to enable
> Major/Minor/Service classes of the local Adapter to be available/settable in
> integer form? The string representations are nice and user-friendly, however
> we need to maintain internationalized versions of these, so doing conversion
> ourselves is much easier.
>
> This would also solve the problem of combination minor device numbers (e.g. in
> case of peripherals). How would you set "Pointing device" + "Joystick" via
> the current API? It would also bring the API closer in line with the
> RemoteDevice API which uses uint32 to represent the class.
>
> Perhaps SetClass(uint32) and
> uint32 GetClass()?
>
> If this is wanted, I can work on a patch.
the choice for strings has been made to make it easier for languages
like Python etc. to handle this. Another thing is that we only support
the change of the minor class if the major class is "computer". No other
change through the D-Bus API makes really sense.
If another major class has to be supported, then this has to be set in
hcid.conf and it will disable the ListAvailableMinorClasses() and
SetMinorClass() methods. This will be true for all embedded devices
running BlueZ. They will set the major and minor class through hcid.conf
and then no more changes to it are needed. The only exception at the
moment will be an access point where the minor class indicates the
number of connected clients. However this should also not be changed
through the D-Bus API. We will integrate another method for this once we
started working on the access point daemon.
The service classes are need to be under control of sdpd, because they
depend on the registered services. So a generic method to change the
class of device is not a good idea.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel