Also depends on http://bugs.muiline.com/view.php?id=28

Ideally the hal volume monitor backend would automatically create a GVolume object that on it's mount() method just mounts the appropriate daemon mount for obex://. Then things should be automounted upon plug-in.

Bastien, just curious, what are you doing wrt. volume monitoring for obex over bluetooth?

(In reply to comment #2)
> Ideally the hal volume monitor backend would automatically create a GVolume
> object that on it's mount() method just mounts the appropriate daemon mount for
> obex://. Then things should be automounted upon plug-in.

(just a data point: this is how the gphoto2 and cdda volume monitoring works.)

(In reply to comment #2)
> Ideally the hal volume monitor backend would automatically create a GVolume
> object that on it's mount() method just mounts the appropriate daemon mount for
> obex://. Then things should be automounted upon plug-in.
> 
> Bastien, just curious, what are you doing wrt. volume monitoring for obex over
> bluetooth?

Right now, absolutely nothing.

FYI, there's also bug 518772 with info about getting the right icon for the device, and http://bugs.freedesktop.org/show_bug.cgi?id=9215 about detecting devices with obex over usb support.

Very cool to see things finally coming together for full USB obexftp support in Gnome. I wrote the openobex USB support, and its not-so-optimal API (blame libusb for that though :), and I have some Nokia phones for testing - I'll be glad to help.

I've proposed a patch that adds USB transport to obex-data-server, available at http://bugs.muiline.com/view.php?id=28
Please have a look and share your comments.

The USB patch to ods has been accepted - USB support is available in obex-data-server version 0.4.

Hal now also has support for USB OBEX interfaces - such interfaces have capability 'obex', and property obex.type that describes what the interface does (e.g. SyncML). They're also managed by hal's access control system, so proper permissions for user access are set. Patches (they were added to git, but it's currently not responding) are here:
http://lists.freedesktop.org/archives/hal/2008-October/012384.html

I'm currently adding support for USB to obexftp gvfs backend. URIs would look like this:
obex://[usb:aaa,bbb,ccc]
where aaa is usb bus number, bbb is device number, and ccc is interface number, all available from hal. A patch will be available soon.

The final piece in the puzzle would be obex volume monitor. I had a quick look at gphoto and hal volume monitors but the code is kinda baffling - hopefully someone can help, or just write it themselves. It would have to take two quirks into account:
1) Ignore SyncML OBEX interfaces (easy, information is available directly from HAL).
2) Some Nokia S40 phones have three functionally identical OBEX interfaces with empty interface descriptions and no way to distinguish them - only the first needs to be mounted.

USB support depends on resolution of http://bugs.freedesktop.org/show_bug.cgi?id=18184

Created attachment 121787 [details] [review]
USB support in gvfs obexftp backend

Since the hal problem seems to be stuck in discussion, I'll just attach the current work in progress version of gvfs obex USB patch here - please review.

Comment on attachment 121787 [details] [review]
USB support in gvfs obexftp backend

<snip>
>+#define USBADDR_LEN 15

I don't like that. You shouldn't have to pad the usb address with zeroes.

<snip>
>+  for (i = 0; i < n; i++) {
>+      if (dbus_g_proxy_call (obex_manager, "GetUsbInterfaceInfo", NULL,
>+                           G_TYPE_UINT, i, G_TYPE_INVALID, 
>+                           DBUS_TYPE_G_STRING_STRING_HASHTABLE, &hash, 
>+                           G_TYPE_INVALID) != FALSE)
>+        {
>+          const char* ods_manufacturer = g_hash_table_lookup (hash, "Manufacturer");
>+          const char* ods_product = g_hash_table_lookup (hash, "Product");
>+          const char* ods_interface = g_hash_table_lookup (hash, "ControlInterface");

Mind the indentation.

>+//return -(strlen(vendor));

This should be removed, and the code below could certainly be simplified.

>+          if (vendor == NULL)
>+            vendor = "";
>+          if (ods_manufacturer == NULL)
>+            ods_manufacturer = "";
>+          if (product == NULL)
>+            product = "";
>+          if (ods_product == NULL)
>+            ods_product = "";
>+          if (interface == NULL)
>+            interface = "";
>+          if (ods_interface == NULL)
>+            ods_interface = "";
>+          if (strcmp(ods_manufacturer, vendor) == 0 &&
>+            strcmp(ods_product, product) == 0 &&
>+            strcmp(ods_interface, interface) == 0)
<snip>

>+static gint
>+_get_usb_intfnum_and_properties (DBusGProxy *obex_manager, const char *device, char **display_name, char **icon_name)
>+{
>+  char **tokens;
>+  char *endp;
>+  char **obex_devices;
>+  int num_obex_devices;
>+  int usb_bus_num;
>+  int usb_device_num;
>+  int usb_intf_num;
>+  DBusError dbus_error;
>+  DBusConnection *dbus_connection;
>+  LibHalContext *hal_ctx;
>+  int n;
>+
>+  /* Parse the [usb:001,041,003] string */

You could use g_strsplit(), and need to remove the need for zero-padding on the interface.

<snip>
>   g_vfs_job_set_backend_data (G_VFS_JOB (job), backend, NULL);
>-  g_print ("  do_mount: %s mounted\n", op_backend->bdaddr);

Created attachment 123899 [details] [review]
new version of the gvfs obexftp usb patch

Here's the new version of the patch, with your comments taken into account. Let me know if anything else should be done. To use this, hal should be patched first with http://bugs.freedesktop.org/show_bug.cgi?id=18184

By the way, it must be a dumb question but I'm not sure how to simplify this:
>+          if (vendor == NULL)
>+            vendor = "";
>+          if (ods_manufacturer == NULL)
>+            ods_manufacturer = "";
>+          if (product == NULL)
>+            product = "";
>+          if (ods_product == NULL)
>+            ods_product = "";
>+          if (interface == NULL)
>+            interface = "";
>+          if (ods_interface == NULL)
>+            ods_interface = "";
>+          if (strcmp(ods_manufacturer, vendor) == 0 &&
>+            strcmp(ods_product, product) == 0 &&
>+            strcmp(ods_interface, interface) == 0)
<snip>

Please clarify.

GLib has a NULL-safe strcmp called g_strcmp0

Yeah, but I want NULL pointers to be equal to zero-length strings, and g_strcmp0 does not equate them.

Created attachment 127396 [details] [review]
gvfs-usb-obexftp-1.patch

This bug depends on the patch to obex-data-server at:
http://bugs.muiline.com/view.php?id=154

Works well.

Alexander, let me know if this works for you.

Arf, it doesn't need the patch I attached to the obex-data-server bug tracker, Serial is already exported fine.

We're just missing the HAL monitor changes.

Bastien, many phones, including my Nokia N95, do not provide a serial number and have several functionally different OBEX interfaces (e.g. FTP and SyncML). So matching has to be done by vendor/product/interface name, like in my original patch. So we're back to comment 12 :)

Just FYI, I'll attach the lsusb -v output for the N95.

Created attachment 127402 [details]
lsusb -v for Nokia N95

(In reply to comment #19)
> Bastien, many phones, including my Nokia N95, do not provide a serial number
> and have several functionally different OBEX interfaces (e.g. FTP and SyncML).
> So matching has to be done by vendor/product/interface name, like in my
> original patch. So we're back to comment 12 :)

Well, let's drain the swamp.

See the patches for obex-data-server and openobex at:
http://news.gmane.org/gmane.network.protocols.obex.openobex.user

New patch below.

Created attachment 127414 [details] [review]
gvfs-usb-obexftp-2.patch

obex-data-server and openobex patches at:
http://thread.gmane.org/gmane.network.protocols.obex.openobex.user/1377

My answer is at the same URL - basically openobex needs to be ported to libusb 1.0 API first. I will keep you posted about that. Marcel Holtmann, the openobex maintainer, seems a bit unresponsive lately :(

I'll apply obex-data-server patch as soon as patched openobex gets released.

Patch is in obex-data-server.

2009-02-02  Bastien Nocera  <hadess@hadess.net>

        Bug 511671 - Make obex-ftp work over usb connections

        * configure.ac: Require HAL for the ObexFTP backend
        * daemon/Makefile.am:
        * daemon/gvfsbackendobexftp.c (_get_numbers_from_usb_path),
        (_is_nokia_3650), (_get_bluetooth_name_and_icon),
        (_get_bluetooth_device_properties), (_is_same_path),
        (_find_ods_usb_intfnum), (_get_usb_intfnum_and_properties),
        (do_mount): Add support for USB ObexFTP devices, original
        patch from Alexander Kanavin <ak@sensi.org>, requires
        current obex-data-server trunk

Note that this won't be used yet, as we're missing a monitor for it. Alexander, any chance you could work on adding support for ObexFTP to the hal monitor (in monitor/hal in gvfs)?

Sure, I'll give it a shot. David, could you give me a bit of guidance? Or maybe you would like to add obexftp support yourself?

Created attachment 127854 [details] [review]
USB OBEX volume monitor for gvfs

So here's the OBEX volume monitor patch, which I made by copying code from GPhoto2 volume monitor, and then adapting and tweaking and fitting it to hal volume monitor. Seems to work for me.

(In reply to comment #26)

A couple comments:

*icon_name = "drive-removable-media-usb";
I'm not sure why, but this no longer seems to work - I get a default icon instead.

*display_name = g_strdup_printf ("%s - %s", libhal_ps_get_string (ps2, "usb_device.vendor"), libhal_ps_get_string (ps2, "usb_device.product"));
Maybe just the product name would be better? For my device I get "Nokia Mobile Phones - Nokia N95" which seems a bit excessive.

Any news? Does my monitor patch work for you? When will you review/integrate it?

Well, what's the current situation? Has gvfs been ported avay from hal?

For sake of completeness, I got this comment from Bacien over email in May:

"The reason is that HAL is deprecated, and we should be using libudev for
enumeration. Except that the libudev-gobject bindings aren't finished,
and we weren't sure which leg to stand on for this new monitor.

I'll get to it as soon as the libudev-gobject bindings are available
(and post my Sixaxis bluetoothd patch that uses that as well)."

Comment on attachment 127854 [details] [review]
USB OBEX volume monitor for gvfs

As mentioned in the past (though things have evolved since then), the volume monitor code needs to use libgudev instead of HAL.

(In reply to comment #32)
> For sake of completeness, I got this comment from Bacien over email in May:
<snip>
> I'll get to it as soon as the libudev-gobject bindings are available
> (and post my Sixaxis bluetoothd patch that uses that as well)."

I just didn't have time to work on this. I'd be happy to look over the code once you've updated it.

I have little idea about what should be added to udev itself, though. HAL does two things: adds a few attributes that make it easier to identify the OBEX interfaces and then sets up permissions for the parent USB device:
http://cgit.freedesktop.org/hal-info/tree/fdi/information/10freedesktop/10-usb-obex.fdi
http://cgit.freedesktop.org/hal/tree/fdi/policy/10osvendor/20-acl-management.fdi

What would be the equivalent thing in udev? Can you patch it yourself?

Look under /lib/udev/rules.d and /etc/udev/rules.d, there are examples there.

You'd use ENV{ACL_MANAGE}="1" to set the permissions. You could export the obex type as a property, but it's probably easier to do that in the volume monitor.

Created attachment 146576 [details] [review]
add ACL support to udev for USB OBEX devices

Here's a small patch for udev that adds ACL support for USB OBEX devices. Please forward it to the relevant mailing list, or apply it yourself.

Created attachment 146577 [details] [review]
add ACL support to udev for USB OBEX devices

The next step would be updating the obexftp daemon backend. I think we can remove HAL dependency altogether - the only thing it's used for is icon and display name, and I think it should be fine to hardcode those to "drive-removable-media-usb" and USB device name respectively. Bastien, is that ok? I'm ready to make a patch :) After that I'll re-do the volume monitor.

Created attachment 146859 [details] [review]
Remove unnecessary HAL dependency from obexftp daemon backend

Created attachment 146923 [details]
udev rule to label devices with OBEX capability

Here's an udev rule to label devices with OBEX capability, similar to a rule for gphoto2-supported devices. After some thought I decided it's better to do this at the udev level rather than have obex volume monitor check every usb device that gets plugged in. I'm not sure which package this should be placed in, so it's a file rather than a patch.

Comment on attachment 146577 [details] [review]
add ACL support to udev for USB OBEX devices


Here's a small patch for udev that adds ACL support for USB OBEX devices.
Please forward it to the relevant mailing list, or apply it yourself.

the previous attachment had wrong email address in the patch

Created attachment 147109 [details] [review]
OBEX volume monitor that's gudev-compatible

So here's the new OBEX volume monitor I made by copy-pasting the gphoto2 monitor and then doing lots of tweaking. It kinda sorta works, but has issues:

1) coldplugging (starting the monitor when a device is already plugged) is causing a crash. Apparently something in the proxy monitor code doesn't like that the obex monitor is doing d-bus operations (talking to obex-data-server to be exact) during initialization before d-bus is set up in the proxy code:
kanavin@hedonist:~/gvfs$ monitor/obex/gvfs-obex-volume-monitor 
(process:4367): GVFS-Obex-DEBUG: gudev_add_device: obex device /dev/bus/usb/005/019 (bus: 5, device: 19)
(process:4367): GVFS-Obex-DEBUG: gudev_add_device: ... adding interface obex://[usb:005,019,6]
**
GVFS:ERROR:gdbusutils.c:878:dbus_source_add_watch: assertion failed: (dbus_watch_get_data (watch) == NULL)
Aborted (core dumped)

(gdb) bt

+ Trace 218875

2) Unplugging the device isn't clean: if I have several nautilus windows open, then the one that was opened when the device was plugged in disappears, but the rest still show that the device is plugged in and mounted. If I unmount the device first, then it does disappear from all windows when I unplug it.

I'd really appreciate if you would help a bit me with these.

I would advise looking at the afc volume monitor instead. It's much more trimmed down, and modifying it for obex over usb would be trivial.

Adding a dep on the osso-gwobex powered backend.

Let me know when that backend is ready to be tested with USB connections. I'm confused by all the patches and changes :) 

After that I can have another go at the monitor - I suppose it needs to be redone from afc backend, and use libopenobex directly to find out about obex interfaces on a USB-device that was suppled by gudev.

Obexftp backend has been obsoleted in GNOME 3.10, because it is incompatible with Bluez 5, however limited bluetooth support is currently built-in in GNOME desktop.