[PATCH] more fine-grained iDevice support in media-player-info

[Christophe Fergeau]

Hi,

2011/6/12 Tom Gundersen <teg at jklm.no>:
> This mostly works, but I noticed that the support for iPhones/iPads
> could be nicer (now they are all called "iPods with video").

Hmm, indeed, I didn't see the commit doing pass through, and imo all
these IDs shouldn't have been added at all.

>
> The attached patches gives each iPhone/iPad its correct name, and also
> sets the iPod icon (maybe a better choice can be made, but it seemed
> better to me than the generic icon). With these patches applied
> (together with my patches against kdelibs) I get the behavior in the
> attached screenshot, as wanted.

You can look at UDISKS_PRESENTATION_ICON_NAME and
UDISKS_PRESENTATION_NAME (set by libgpod udev callout) to get the name
of the device as set in iTunes and to get the icon name to use for
this device (including its color).
There's also an udev "USBMUXD_SUPPORTED" property (or something like
that) which is set on all iOS devices if that can be useful to you
(but I wouldn't recommend using it unless you are doing low level
stuff with libimobiledevice or libusbmuxd)

>
> Do you think these patches could be applied to media-player-info?
>

It's still only my opinion, but I think m-p-i should only provide very
basic information about ipods (ie provide apple-ipod.mpi), which means
I'd drop the apple-ipod-video.mpi file. In particular, I don't want
apps to use media-player-info to detect ipod capabilities since
libgpod is needed anyway to do anything useful with these ipods, and
it will be able to provide much better information about the iPod
capabilities. This means that instead of adding more to
apple-video-ipod.mpi, I'd just drop it. Adding this information to
m-p-i would also mean one more place to update each time a new iPod is
out, and there are already too many such places (libgpod, potentially
usbmuxd, usb.ids)

The situation with iOS devices (iPod Touch/iPhone/iPad) is even more
complicated than that because you can't do anything with the device,
not even access the device content without additional tools
(ifuse/gvfs-afc/...). Imo m-p-i should be focused on giving more
information about usb mass storage devices that are actually
media-players and to help applications add music to these devices.
Regular iPod barely qualify for that because an additional library is
needed to do music handling, but iOS devices are not even mass storage
devices, they are hanging off the usb bus and needs to be talked to in
a special protocol, so I don't think we should add any information
about them in m-p-i.

As for your 3rd patch, The AccessProtocol line is wrong for all iOS
devices, and if we go to the "1 file per ipod model" road, then we
shouldn't stick all "regular" ipods in a single mpi file but also have
1 file per model in there for consistency. But I'm really against
doing any of this, and would much prefer if m-p-i only said "it's an
iPod", and if richer information about these iPods came from libgpod.

With iOS devices handling much more than music/videos/podcasts these
days, it may make sense to split the udev callout part of libgpod to a
separate module, but for now I'd recommend using this information. My
nick is "teuf" on IRC on freenode, and I'm always happy to discuss
iPod integration issues on linux, so feel free to ping me if you want
a live chat about your solid integration work :)

Hope that helps,

Christophe