GNOME Bugzilla – Bug 586411
port bluetooth obexftp backend to libgudev
Last modified: 2010-01-19 23:14:19 UTC
With hal being deprecated, it would be nice to be able to build gvfs without hal. obexftp is one of the modules which need to be ported over to gudev.
Hm, this confuses me a little bit. The only real thing that the obex backend does with hal is obex_devices = libhal_find_device_by_capability (hal_ctx, "obex", &num_obex_devices, NULL); in _get_usb_intfnum_and_properties(); that is only called if if (!g_str_has_prefix(device, "[usb:")) Now, hal itself defines the "obex" capability, but doesn't implement it, and I don't see anything in bluez which does that either. I stopped hal, and I'm still able to connect to my mobile over bluetooth and get a proper gvfs mount: Mount(0): Pittis Kommunikator -> obex://[00:16:BC:04:C8:A1]/ Type: GDaemonMount Is there some hal addon by bluez or another project which adds this "obex" capability? If so, this needs to be ported to udev rules and an ID_OBEX="1" tag or something such, and then we can gudevify the gvfs backend accordingly. For now, I'll just conditionalize the hal specific bits, so that it's finally possible to build gvfs without hal.
Created attachment 137772 [details] [review] conditionalize hal support in obexftp backend This patch builds the hal querying only if libhal is available at build time.
Oh, just for the record, this patch needs to go on top of the cdda porting one in bug 586409 (which has the fundamental configure.ac changes).
Makes sense to me, pushed this for now. Bastien, your thoughts?
Is that supposed to be a working patch? It clearly won't be. You need to remove the whole USB Obex support when HAL isn't present.
See bug 511671 for explanations about the state of the USB Obex support.
> You need to remove the whole USB Obex support when HAL isn't present. Do you have some details why? It works perfectly well without hal, and I don't actually see any project which adds "obex" capability devices into hal. Please see comment 1 for details.
(In reply to comment #7) > > You need to remove the whole USB Obex support when HAL isn't present. > > Do you have some details why? Loads of unused variables, display_name and icon_name not set. > It works perfectly well without hal, and I don't > actually see any project which adds "obex" capability devices into hal. See http://bugs.freedesktop.org/show_bug.cgi?id=18184 This needs porting to gudev, so leaving this bug opened.
> See http://bugs.freedesktop.org/show_bug.cgi?id=18184 > This needs porting to gudev, so leaving this bug opened. Sorry for my ignorance, but I fail what that bug has to do with this one. You can already get the vendor/product ID of an USB device with nowadays udev/libgudev. > Loads of unused variables, display_name and icon_name not set. Sure, but I don't know of anything which would poke bluetooth devices (the "obex" capability) into hal, and thus the existing hal support in the gvfs obex module seems pretty much dead to me. Do you know such a thing?
You seem confused. The Bluetooth ObexFTP support obviously doesn't use HAL. The USB ObexFTP support uses HAL.
So can you please tell me which software sets the "obex" capability in hal, and thus needs to be ported to use gudev (or, respectively, how gvfs needs to be changed to detect it itself)? (FYI, I'll be on holidays the next two weeks, so my response will take a while)
The patch to remove the hal dependency altogether is available in bug 511671. You can close this as a duplicate ;)
Thanks Alexander. So I retitled this bug to be bluetooth specific, and we'll keep bug 511671 for the USB obexftp part, so that this one can be closed.