The class has been added, however (and as I will explain further in my sum up email) I can't test this one, so I don't know what really defines a PortableMediaPlayer.

http://svn.reviewboard.kde.org/r/5853/

I've tried to get the ball rolling on MTP support:
https://bugs.freedesktop.org/show_bug.cgi?id=31642
https://sourceforge.net/tracker/index.php?func=detail&aid=3109858&group_id=158745&atid=809061

Also, the issue with gphoto2 conflicting with media-player-info in the use of ID_MEDIA_PLAYER:
https://sourceforge.net/tracker/?func=detail&atid=108874&aid=3109848&group_id=8874
https://bugs.freedesktop.org/show_bug.cgi?id=31641

So, there's a slight issue with this approach.

Under HAL, we would get a device like this:
udi = '/org/freedesktop/Hal/devices/storage_serial_SanDisk_Sansa_Clip__8GB_0D15E4169992B6A80000000000000000_0_0'
  parent = '/org/freedesktop/Hal/devices/usb_device_781_74d1_0D15E4169992B6A80000000000000000_if0_scsi_host_0_scsi_device_lun0'  (string)
  vendor = 'SanDisk'  (string)
  product = 'Sansa Clip+ 8GB'  (string)
  description = 'Sansa Clip+ 8GB'  (string)
  Block.major = 8  (0x8)  (int)
  Block.minor = 32  (0x20)  (int)
  Block.device = '/dev/sdc'  (string)
  StorageDrive.bus = 'Usb'  (0x1)  (enum)
  StorageDrive.driveType = 'HardDisk'  (0x0)  (enum)
  StorageDrive.removable = true  (bool)
  StorageDrive.hotpluggable = true  (bool)
  StorageDrive.inUse = false  (bool)
  StorageDrive.size = 0  (0x0)  (qulonglong)
  PortableMediaPlayer.supportedProtocols = {'storage'}  (string list)
  PortableMediaPlayer.supportedDrivers = {}  (string list)


Under the split UDisks/UDev, we get two devices:
udi = '/org/freedesktop/UDisks/devices/sdc'
  parent = '/org/freedesktop/UDisks'  (string)
  vendor = 'SanDisk'  (string)
  product = 'Sansa Clip+ 8GB'  (string)
  description = 'SanDisk Sansa Clip+ 8GB'  (string)
  Block.major = 8  (0x8)  (int)
  Block.minor = 32  (0x20)  (int)
  Block.device = '/dev/sdc'  (string)
  StorageAccess.accessible = false  (bool)
  StorageAccess.filePath = ''  (string)
  StorageAccess.ignored = false  (bool)
  StorageDrive.bus = 'Usb'  (0x1)  (enum)
  StorageDrive.driveType = 'HardDisk'  (0x0)  (enum)
  StorageDrive.removable = true  (bool)
  StorageDrive.hotpluggable = true  (bool)
  StorageDrive.inUse = false  (bool)
  StorageDrive.size = 7916748800  (0x1d7e00000)  (qulonglong)
  StorageVolume.ignored = false  (bool)
  StorageVolume.usage = 'FileSystem'  (0x2)  (enum)
  StorageVolume.fsType = 'vfat'  (string)
  StorageVolume.label = 'SANSA CLIPP'  (string)
  StorageVolume.uuid = '3c73-b168'  (string)
  StorageVolume.size = 7916748800  (0x1d7e00000)  (qulonglong)

and

udi = '/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3'
  parent = '/org/kde/solid/udev'  (string)
  vendor = 'SanDisk'  (string)
  product = 'SanDisk Sansa Clip+'  (string)
  description = 'Portable Media Player'  (string)
  PortableMediaPlayer.supportedProtocols = {'storage'}  (string list)
  PortableMediaPlayer.supportedDrivers = {}  (string list)

From UDev's point of view, these are actually two different devices, but the latter is a grandparent of sdc.  HAL merged down the information, so the PMP info was available on the child devices, including the block devices.

Clearly the way the HAL backend presents this information is more useful.  At the very least, an application would want some way to link the PMP and the storage devices.

Hmm... I've changed my mind about http://svn.reviewboard.kde.org/r/5853/ and am discarding it.  It presents the PMP device as completely separate to the storage device, which is no use to clients.

I've asked on devkit-devel, and no-one has a better way of linking storage devices with media player information than using UDisks' NativePath with libudev to walk up the device tree and find ENV{ID_MEDIA_PLAYER}.  This could be done in the udisks backend (suitable IFDEF'd based on whether libudev was found).

As for MTP support, we have three options:
- Ignore MTP devices and let MTP-aware apps use libmtp's interface
- Have some sort of libmtp backend that links to libmtp or dynamically loads libmtp to find out info about devices that libmtp tags (currently by creating a libmtp%n symlink, but we could ask for some other tag)
- push libmtp to provide the information another way (how?)

IMO your patch was the right way to do it. Please don't give up on it, the adjustment we need to it *for now* is to have the UDev backend simply ignore the PMP which have the storage access method.

We can see later (likely post-4.6) how to deal with the storage kind of PMP. And yes it likely involves adjusting our udisks backend to probe for that.

But we don't really have information on non-storage PMPs.  media-player-info has only the following devices that aren't listed purely as AccessProtocol=storage:

apple_0x1261_0x1262.mpi:AccessProtocol=storage;ipod
apple_ipod.mpi:AccessProtocol=storage;ipod
motorola_itunes-phone.mpi:AccessProtocol=ipod;storage
motorola_v3i.mpi:AccessProtocol=ipod;storage
sonicblue_rio-karma.mpi:AccessProtocol=storage;karma

Other than that, we can list devices that have ENV{ID_MEDIA_PLAYER}==1 (ie: those tagged by gphoto2 and [after the next release] libmtp), but we can't say anything interesting about them.  Other than they can "probably" be accessed via libmtp, but even that's not guaranteed.

Sad state indeed... OTOH we have to provide the ipod support anyway. The storage protocol for those is a no-go in a PMP context IMO (it's ok for storing non-media files but that's it). Hopefully we can provide interesting information about those, at least the drive info...

For libmtp, indeed don't bother for now IMO.

Sorry, in previous comment I meant "at least the driver info".

Well, I think that we have this fixed, what you think? should we close the bug?

Doesn't look fixed at all to me. None of my PMP get reported at all. I'd prefer the "it gets duplicated situation" as a first step so that multimedia applications have a way to detect better protocol to access the device like mtp or ipod.

I think part of the mistake is that right now we assume ID_MEDIA_PLAYER==1 for PMP devices, while that case happens only if gphoto2 rules overruled the media-player-info one. I think we should settle on assuming gphoto2 didn't overwrite the rules, and for cases where that happen we'll consider that as upstream bug on the gphoto2 side.

(In reply to comment #10)
> Doesn't look fixed at all to me. None of my PMP get reported at all. I'd prefer
> the "it gets duplicated situation" as a first step so that multimedia
> applications have a way to detect better protocol to access the device like mtp
> or ipod.
> 
> I think part of the mistake is that right now we assume ID_MEDIA_PLAYER==1 for
> PMP devices, while that case happens only if gphoto2 rules overruled the
> media-player-info one. I think we should settle on assuming gphoto2 didn't
> overwrite the rules, and for cases where that happen we'll consider that as
> upstream bug on the gphoto2 side.

Same here, Amarok for example no longer recongnises my iPod. (I haven't gphoto2 installed) Any progress here?

Git commit 9d7ecb5a9c984b9a63ab340ca5d3536b52482a61 by Matěj Laitl.
Committed on 28/04/2012 at 22:33.
Pushed by laitl into branch 'master'.

IpodCollection: rework iPhone identification to prevent false-positives

...false-positives that would otherwise appear once the change [1] is
merged into kdelibs. (should happen for 4.8.4)

[1] https://git.reviewboard.kde.org/r/103028/

M  +32   -10   src/core-impl/collections/ipodcollection/IpodCollectionFactory.cpp

http://commits.kde.org/amarok/9d7ecb5a9c984b9a63ab340ca5d3536b52482a61

Git commit 3c1c788cc52e166278af2ed878e8a2f65874b1ac by Matěj Laitl.
Committed on 30/10/2011 at 13:53.
Pushed by laitl into branch 'KDE/4.8'.

udev PortableMediaPlayer: read protocols from media-player-info

This is a second attempt at implementing PortableMediaPlayer for udev
back-end using media-player-info [3], the first attempt was [2] by
Alex Merry and this patch is heavily based on it. This patch relates to
a discussion at [1] and is just a first step, the second would
be to forward PMP interface from udev backed to udisks backed somehow
(udisks...Device interface provides NativePath attribute that links to
sysfs path that can help - on Linux)

[1] http://mail.kde.org/pipermail/kde-hardware-devel/2011-October/001481.html
[2] https://svn.reviewboard.kde.org/r/5853/
[3] http://www.freedesktop.org/wiki/Software/media-player-info

Care is taken not to change existing behaviour - e.g. when udev env
ID_MEDIA_PLAYER equals 1, behaviour is unchanged.

PACKAGERS, solid udev backend now has following optional runtime-only
dependency that provides udev rules and other info for identification
of the portable media players:
 * media-player-info: for identifying USB storage devices and iPods

Following packages also provide relevant udev rules, but we suggest not
depending on them as they should by pulled by packages that actually
use them (such as Amarok, transitively):
 * usbmuxd: for identifying iOS-based iPods
 * libmtp >= 1.0.4: for identifying MTP players

[I will push similar change to frameworks branch, too]
Related: bug 269447, bug 269451
REVIEW: 103028
FIXED-IN: 4.8.4
DIGEST: groundwork for better portable media player detection
CCMAIL: kde-packager@kde.org

M  +26   -0    solid/solid/CMakeLists.txt
M  +1    -1    solid/solid/backends/udev/udevdevice.cpp
M  +1    -1    solid/solid/backends/udev/udevmanager.cpp
M  +98   -6    solid/solid/backends/udev/udevportablemediaplayer.cpp
M  +8    -0    solid/solid/backends/udev/udevportablemediaplayer.h
M  +17   -2    solid/solid/ifaces/portablemediaplayer.h
A  +135  -0    solid/solid/xdgbasedirs.cpp     [License: LGPL (v2+)]
A  +112  -0    solid/solid/xdgbasedirs_p.h     [License: LGPL (v2+)]

http://commits.kde.org/kdelibs/3c1c788cc52e166278af2ed878e8a2f65874b1ac

The last bit undone is the case of PortableMediaPlayers that also appear under udisks backend - you now get 2 separate entires, one with PortableMediaPlayer interface under udev backend and one with Storage* interfaces under udisks backend - certainly suboptimal.

Matěj Laitl I'm wondering, what if we only use UDev backend for MTP? Is there any case where a MTP device would show only in UDisk?

(In reply to comment #15)
> Matěj Laitl I'm wondering, what if we only use UDev backend for MTP? Is
> there any case where a MTP device would show only in UDisk?

No, there is no such case and using solely UDev for MTP devices is The Right Thing™.

Lemme make a summary what is already right and what should be done.

1. MTP devices:
 * libmtp adds ID_MEDIA_PLAYER=1 property to their udev device (/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2)
 * are talked to using libmtp which in turn uses libusb. You can get bus/device numbers out of Solid::GenericInterface properties which are recognized by libmtp.
 * solid attaches PortableMediaPlayer to the udev device:
   PortableMediaPlayer.supportedProtocols = {'mtp'}  (string list)
   PortableMediaPlayer.supportedDrivers = {'usb'}  (string list)

2. iOS devices:
 * media-player-info adds ID_MEDIA_PLAYER=ipod and usbmuxd adds USBMUX_SUPPORTED=1 to their udev device as above
 * are talked to using usbmuxd and libimobiledevice that in turn use libusb. You can get driverHandle() from the PortableMediaPlayer interface which is recognized by libimobiledevice.
 * solid attaches PortableMediaPlayer to the udev device:
   PortableMediaPlayer.supportedProtocols = {'ipod'}  (string list)
   PortableMediaPlayer.supportedDrivers = {'usbmuxd'}  (string list)
   PortableMediaPlayer.driverHandle = serial_numer_or_something_similar

3. Filesystem-based players that need special structure (e.g. classic iPods etc.):
 * media-player-info adds ID_MEDIA_PLAYER=$some_string their *udev* device (/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/host6/target6:0:0/6:0:0:0/block/sdc/sdc2)
 * are accessed by normally mounting them using udisks, but need something special to work properly, like maintaining a database of tracks etc.
 * with solid, udisks and udev backend, two devices are created:
/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/host6/target6:0:0/6:0:0:0/block/sdc/sdc2 (with the PortableMediaPlayer interface that tells what kind of special behaviour is needed)
/org/freedesktop/UDisks2/block_devices/sdc1 (with StorageAccess, StorageVolume...)


1. and 2. work just fine with current solid, udisks2 & udev, but the 3. doesn't because I have found no way to associate the udisks device with the udev one in client application like Amarok. From my PoV it would be best if the PortableMediaPlayer could be attached to /org/freedesktop/UDisks2/block_devices/sdc1 and if the udev device wouldn't show up at all in the case 3.

I imagine this could be done by the udev & udisks2 backends communicating with each other (probably tricky) or by teaching udisks2 backend a bit of PortableMediaPlayer interface (and a way to get udev properties of the underlying device) and teaching udev backend to ignore devices in the category 3, taking care not to exclude devices in category 2.

This bug is reported on libsolid which is the kdelibs4 version of the solid library.  It is now in maintenance mode.  If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid.

Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!