hald detects a bluetooth network interface as a wired interface.
Created attachment 9529 [details] [review] net.bluetooth patch Make hald detect bluetooth network interface and gives net.bluetooth capability to it.
Created attachment 9566 [details] [review] Patch 1 of 5 Add a helper to recovery service record information from bluez.
Created attachment 9567 [details] [review] Patch 2 of 5 Changes to user the new helper.
Created attachment 9585 [details] [review] Patch 3 of 5 Use FindConnection to avoid dbus round trips.
Created attachment 9586 [details] [review] Patch 4 of 5 Removes net.bluetooth.description
Created attachment 9587 [details] [review] Patch 5 of 5 Updates hal spec to include net.bluetooth capability and related properties.
Created attachment 9588 [details] [review] Patch 1 of 2 Unified patch
Created attachment 9589 [details] [review] Patch 2 of 2 Unified patch
+ <entry> + <literal>net.bluetooth.name</literal> (string) + </entry> + <entry>example: Network Access Point Service</entry> + <entry> + Only if the <literal>net.bluetooth</literal> capability is set + </entry> + <entry>Displayable Name</entry> Where does this come from? What does it mean? + </row> + <row> + <entry> + <literal>net.bluetooth.uuid</literal> (string) + </entry> + <entry>example: 00001116-0000-1000-8000-00805f9b34fb</entry> + <entry> + Only if the <literal>net.bluetooth</literal> capability is set + </entry> + <entry>Universal Unique IDentifier</entry> What exactly is this identifier? + /* Leave those properties empty so helper may fill it up */ + hal_device_property_set_string (d, "net.bluetooth.name", ""); + hal_device_property_set_string (d, "net.bluetooth.uuid", ""); Probably no need to do this. + msg = dbus_message_new_method_call (BLUEZ_SERVICE, BLUEZ_PATH, + BLUEZ_MANAGER_IFACE, + "ActivateService"); Will this call have a side effect? What's the semantics of ActivateService? I'm asking because this smells a bit like policy; we cannot make HAL do any policy; it's just a mechanism.. and all settings/policy _need_ to originate from the desktop session otherwise this will never work for multi-user (e.g. fast-user- switching, multi-seat, hot-desking etc.) + dbus_message_get_args (reply, &error, DBUS_TYPE_STRING, &connection, + DBUS_TYPE_INVALID); + if (dbus_error_is_set (&error)) { + dbus_error_free (&error); + goto out; + } + + name = get_property (conn, id, connection, "GetName"); + if (name == NULL) + goto out; + + libhal_device_set_property_string (ctx, udi, "net.bluetooth.name", name, + &error); + + uuid = get_property (conn, id, connection, "GetUUID"); + if (uuid == NULL) + goto out; Hmm.. Probably the Bluez API should return both Name + UUID as part of ActivateService so we don't need to do roundtrips; but this is fine for now. Also, what happens if any of these calls fail? E.g. what if Bluez is not available? I think it may be good enough to just make hald remove the net.bluetooth capability if the helper returns with an exit code != 0. Thoughts?
The name property is basically a friendly name of the network service. It is part of the SDP record and so not exported through the kernel sysfs integration. The uuid property is the profile UUID of the used remote service. In this case it can be a NAP (network access point) or GN (group network). Using the UUID makes it really simple to integrate other profiles under the same capability. For example the old LAN access network or even ISDN. The ActivateService() method will start the network service daemon if needed. Nothing more. The call is needed since it returns the unique bus name of the network service. Currently we don't use well known names for Bluetooth services. All the information are provided by the network service and not the Bluetooth core daemon. We can add a dict based method to return all information at once to reduce the round trips to the network service. We have done this for the core daemon, but not yet for the service implementation. It will provide a GetInfo() method at some point. If any of these calls fail, we still should add net.bluetooth as capability. So the helper needs to be fixed to exit without an error code in this case. Maybe some error text through syslog or so is the better approach.
Currently the helper always return 0, so even if the interface was configured without bluez network service it will still be available and announced by hal. + /* Leave those properties empty so helper may fill it up */ + hal_device_property_set_string (d, "net.bluetooth.name", ""); + hal_device_property_set_string (d, "net.bluetooth.uuid", ""); What is best here, empty values or missing properties? I guess the rest marcel already explained
Created attachment 9637 [details] [review] Patch 1 of 2 Make helper to use GetInfo instead of properties one by one.
Created attachment 9638 [details] [review] Patch 2 of 2 Leave to helper create or not properties only available via bluez network service.
Committed, thanks. I also committed this on top http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=bf29b2f07dc05cf8b95463ad76b0b2ebe4ed596a since these properties are specific to Bluez.
These information and attributes are not specific to BlueZ. They are general Bluetooth attributes. So adding a "bluez_" prefix makes no sense. The only BlueZ specific is the way how these information are retrieved. So please revert this patch.
Those properties are present in the PAN profile, so I guess we could not consider them as a bluez specific. But the service record is not exposed in sysfs that why there is a need of a helper to try to recovery them from the bluez service. In case of the interface being configure without bluez we dont create any property present in the service record.
OK, fair enough; I misunderstood; reverted http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=8e6daa796eec0bf639567ed94a784838c1fc5fdb
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.