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

Tom Gundersen teg at jklm.no
Sun Jun 12 09:29:34 PDT 2011


Hi Christophe,

On Sun, Jun 12, 2011 at 6:08 PM, Christophe Fergeau <cfergeau at gmail.com> wrote:
> 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).

I was indeed looking into doing this from the beginning, and it makes
sense. The reason I didn't was that I could not get these properties
set on my device (iPhone 3GS). If I can get this working locally, then
I'd be happy to use this for supporting iDevices, and only use
media-player-info for mass storage devices (we don't have this either
atm, we only support mtp).

This is what udevadm tells me (I have libgpod 0.8.0):

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2
N: bus/usb/001/007
S: libmtp-1-2
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2
E: MAJOR=189
E: MINOR=6
E: DEVNAME=/dev/bus/usb/001/007
E: DEVTYPE=usb_device
E: DRIVER=usb
E: DEVICE=/proc/bus/usb/001/007
E: PRODUCT=5ac/1292/1
E: TYPE=0/0/0
E: BUSNUM=001
E: DEVNUM=007
E: SUBSYSTEM=usb
E: ID_MTP_DEVICE=1
E: ID_MEDIA_PLAYER=apple_iphone-3g
E: ID_VENDOR=Apple_Inc.
E: ID_VENDOR_ENC=Apple\x20Inc.
E: ID_VENDOR_ID=05ac
E: ID_MODEL=iPhone
E: ID_MODEL_ENC=iPhone
E: ID_MODEL_ID=1292
E: ID_REVISION=0001
E: ID_SERIAL=Apple_Inc._iPhone_e12b5344a358cabade0e7326a581b341b12c2a0c
E: ID_SERIAL_SHORT=e12b5344a358cabade0e7326a581b341b12c2a0c
E: ID_BUS=usb
E: ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01:
E: ID_GPHOTO2=1
E: GPHOTO2_DRIVER=PTP
E: USBMUX_SUPPORTED=1
E: DEVLINKS=/dev/libmtp-1-2
E: TAGS=:udev-acl:

>> 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.

At the moment all we need is to figure out that a certain device
supports the "ipod" protocol, if I can find this out from some other
udev properties, then that's fine with me as well.

> As for your 3rd patch, The AccessProtocol line is wrong for all iOS
> devices,

Just to make sure I understand; the correct line should simply say "ipod"?

> 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.

Agreed, I was going to finish that work if this one was accepted.

> 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.

An intermediate solution might be to have three files: one for ipods,
one for ipas and one for iphones. Just so the names are fairly
reasonable (in case libgpod is not installed to do it properly).

> 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.

If I can get it to work, I'll do that (should be much simpler from my POV).

> 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 :)

I'll try to find you there.

Cheers,

Tom


More information about the devkit-devel mailing list