GNOME Bugzilla – Bug 612616
Needs udev backend for HAL deprecation
Last modified: 2010-08-25 19:35:38 UTC
HAL has been deprecated, so a hardware backend for udev needs to be created so that banshee can continue to be a great player in GNOME 3
Just to make things clear : the HAL deprecation doesn't have anything to do with the library deprecation/clean-up for GNOME 3. But of course Banshee (is and) must continue to be a great player, in GNOME 3 and elsewhere ! ;)
Status update: udev has been wrapped- https://launchpad.net/gudev-sharp Will start real work now :)
Progress can be followed at http://gitorious.org/~lamalex/banshee/lamalex-udev
If anyone wants to help, the afore mentioned branch is now in the build system and runs without exceptions (here). There are some unimplemented parts which should mostly be marked by a TODO in the source. Any help will be appreciated!
http://gitorious.org/~lamalex/banshee/lamalex-udev now has working audio cds using gio/udev. DAP support is in progress. If you're curious, PLEASE feel free to clone/hack.
And we're done! Kind of! Maybe! Our code needs tested. The git repo has moved to http://gitorious.org/+banshee-hw/banshee/banshee-iphone It requires gudev-sharp, which is hosted in bzr at launchpad.net/gudev-sharp (lp:gudev-sharp), libgpod-sharp from git://gitorious.org/~npmccallum/libgpod/npmccallum-sandbox.git which is still waiting merge into the real libgpod-sharp, gkeyfile-sharp http://gitorious.org/gkeyfile-sharp/gkeyfile-sharp, and the other deps that go with the banshee gio backend. The autofoo is not rigged up to run installed, so it must be ran via make run. I think that's all. Happy testing!
Here are a few comments/questions : 1/ Dependencies There's two types of managed dependencies : a/ the assembly is in the GAC, we just have a reference to it. Example : gtk-sharp b/ the assembly is not in the GAC, we make a copy into the banshee dir during installation. Example : ipod-sharp For libgpod it's b/, which is OK. For gio-sharp, gudev-sharp and gkeyfile-sharp, they all install themselves in the GAC. Is that OK ? See : http://www.mono-project.com/Assemblies_and_the_GAC#What_Should_Be_Installed_to_the_GAC Once this is settled, I'll be happy to submit patches to the relevant build system(s) 2/ In the banshee-iphone branch, the Banshee.Gio backend is now both a IOProvider and a HardwareManager. Are there any inter-dependencies between those 2 parts, other than sharing some dependencies ? 3/ I'm a bit fuzzy about which bit in the Dap stuff, if any, need the bits in the Gio backend to work properly.
gudev-sharp and gkeyfile-sharp should both be api-stable. I don't see the api for GKeyFile or Gudev changing. Ditto for gio but I have nothing to do with the administration of gio-sharp. If you think it'd be better to not, that's fine. I can change them to not install in the gac. 2. No, just deps. 3. I'm not sure what you're asking. I don't think that anything in Dap should be dependent on Gio.
3) I'm a bit fuzzy about which bit in the Dap stuff, if any, need the bits in the Gio backend to work properly. If i understand you correctly, the answer is that MTP support will work better with two properties which I'm pulling from udev (usb bus number and usb device number). They are exposed to banshee via the existing IUsbDevice interface so as long as any hardware backend (i.e. HAL) can supply those properties, MTP detection and mounting will work great. iPhones rely on the udev/gio backend to be hotpluggable. The actual requirement for libgpod to work is just to have the mount point for the iDevice. This is what gio gives us. The libgpod plugin *could* work with a plain HAL backend if we were ok with getting users to manually browse to their iphone or by monitoring the ~/.gvfs folder for changes and checking new directories to see if they're iPhone mounts. Again, this is work which is unnecessary if banshee is ok with ditching HAL.
Alan, I've already updated the HAL backend to supply those properties.
Looks like http://git.gnome.org/browse/banshee/commit/?id=a3dc5844e08c9e010e8ddfc9004d2fe1a215496f gets a long way to getting this bug "fixed"? Great work!
Yep, the udev/gio backend was merged into git master and should now be usable. You can enable it with the follwing configure options : --disable-hal --enable-gio-hardware Regressions or any other issue should go into their own bug. Thanks Alex and Alan !
(In reply to comment #12) > You can enable it with the follwing configure options : --disable-hal Can't this be detected by the configure script?
(In reply to comment #13) > (In reply to comment #12) > > You can enable it with the follwing configure options : --disable-hal > > --enable-gio-hardware > Can't this be detected by the configure script? It is, I forgot to mention it : the new GIO hardware support will be enabled automatically if all the dependencies are there. The "--disable-hal" is just there to make sure you will really be using it and not falling back to HAL.