Comment 11 for bug 362182

On Tue, 2009-04-28 at 11:58 +0000, chris wrote:
> On 04/27/2009 10:54 PM, Nico wrote:
> > This is exactly what I descibe in the bug.
> >
>
> The upstream bug was very limited in scope. Look at its title. It was
> not intended to address the solid/hal issue, but to replace an internal
> recognition function that had been removed in amarok2 ("Probably a good
> first step is to get isIpod to return true for iPhone."). They fixed
> the bug, as it was reported to them (getting the amarok function isIpod
> to return true for iPhone), though they did not fix the underlying
> problem you reported here (amarok2 doesn't recognize an sshfs mounted
> iphone).

True.

I've been on the Amarok 2 ML.

The target they have at this time is to expose more media device to the
scripting API so that manual scans of mounted volumes can be made, not
using Solid, then iphones can be mounted using whatever mean is
available (iFuse, sshfs, etc...).

>
> > iFuse is just like SSHFS. Both use FUSE, and fuse does not declare
> > volumes in HAL.
> >
>
> ifuse is different because it is over a hardwired USB connection.

No it is not.

iFuse shows a network object multiplexed into USB as a disk.

iPhones do not show themselves as disks outside of the camera stuff. The
music stuff is through a network protocol.

So, once more, iFuse will not put anything in HAL.

>
> Note that ntfs-3g also uses fuse and its volumes are reported perfectly
> by HAL. HAL recognition of fuse volumes was implemented circa 2006
> (search the bug database at freedesktop.org).

Yes, sure, because it mounts real disks/partitions.

>
> The reason sshfs volumes are not detected by HAL has nothing to do with
> fuse. It is because sshfs volumes are not hardware.

It is the same for iFuse. iFuse deals with USBmux (network protocol) and
AFC (network service), not with disks.

> HAL is the
> HARDWARE abstraction layer. If there is no hardware involved, HAL is
> not involved. You wouldn't expect an NFS or SMB volume to show up in
> HAL, either. ;-)

So do not expect iFuse to do either.

>
> Moreover, HAL most certainly *does* detect USB iphone connections. You
> can prove this to yourself by running `lshal -m` and watching while you
> plug in your iphone.

Sure, it detects the only part that looks like a disk, and linux
supports it very well to give you acces to the pictures on the device.

>
>
> > This fdi file is for when HAL detects the USB device. It is no
> > declaration of the FUSE volume.

True, it detects the picture device and assumes that if that part is
there, then the rest will be too.

> >
>
>
> You are correct that the fdi file is for when HAL detects the iphone
> over USB

The pictures storing part of the iPhone.

> ; however, the fdi file most certainly does contain hal
> declarations for the ifuse volume. The debian helper script (which was
> adapted from fedora) even assigns major and minor numbers to the device
> to facilitate this functionality. I've gotten it partially working, but
> in my case hal is still slightly confused between the ifuse volume and
> the ptp-class camera device. (The fdi file contains some <remove>
> directives related to camera keys, but they don't seem to be working for
> me. Or they're not applying to the right usb device. It's a little
> hard to tell.)
>
> The main problem I'm seeing is that the <match> directives in the ifuse
> fdi file don't directly match the attributes reported from my iphone-3g
> to the kernel to hal. The fdi file is out-of-date relative to some
> combination of (1) my kernel (2.6.29.1), (2) my device (iphone 3g),
> and/or (3) my hal version (0.5.12git20090406).
>
> It's worth noting that the ifuse home page implies that iphone 3g
> support is uncertain. I am able to mount my 3g via ifuse, however, so
> hal support should be just a matter of tweaking the fdi directives to
> properly match the hardware info the 3g is sending to hal via the kernel.
>
>
> > I even tried compiling it from source, just in case I was wrong. I was
> > not.
>
>
> The problem isn't with compilation.

Oh, let's say I've installed it too. :o)

> The fdi directives are provided by
> upstream or the package maintainer. Play more with tweaking the fdi
> file and watching the results (after restarting hald) in the full output
> of lshal.
>

OK, I accept that I may be wrong on this. I will investigate that part
further. But yes, it looks like the iFuse stuff tries to declare storage
devices and volumes into HAL.

In any case, I do not like giving all my hope only to iFuse. It looks
great, but my guess is that it is far from production ready, a lot of
stuff is being re-addressed by the development team.

Nico