UDisks -> media-player-info

Alex Merry kde at randomguy3.me.uk
Sun Nov 21 15:49:12 PST 2010


(tl;dr: is there a nicer/better way to link a UDisks device with a .mpi file 
than using NativePath and walking up the parent tree of the disk using UDev?  
If not, should there be?)

Suppose we have the following situation: someone plugs in a portable USB media 
player that presents itself as a storage device.  A Sansa Clip+ in MSC mode, 
say (since that's actually what I have).

In the days of HAL, this would cause many devices to appear in HAL's device 
tree.  The topmost device would be recognised as a media player, and one of 
the subdevices would be registered as a block device, say sdc.  The media 
player properties set by 10-usb-music-player.fdi would be propagated down to 
this device, which would have both the storage_volume capability and the 
portable_audio_player capability.  The specific properties, such as what media 
formats the device supported, would all be available from this point.

No we no longer have HAL, and plugging in such a device will make a device 
(sdc, say) appear in UDisks' device tree.  However, UDisks knows nothing about 
media players.

Instead, there is media-player-info.  On Linux, it is possible to listen to 
UDev devices and find a device with the ENV{ID_MEDIA_PLAYER} property set to 
some value that allows you to find a .mpi file with the relevant info in.  Fine.

Typically, media applications will want these things to be linked - they want 
to know both the block device they should be accessing (or, rather, the folder 
that UDisks mounted it at) and what formats they can place on the device.  One 
way of doing this is to get the NativePath and walk up the tree in UDev 
looking for ENV{ID_MEDIA_PLAYER}.

My question is: is there a better way?  UDisks is ostensibly portable to non-
Linux systems.  As is media-player-info.  But UDev isn't.  So applications 
have to take two bits of platform-agnostic data and link them together with 
platform-specific glue.  This doesn't seem very nice.

Sorry for the long-winded email.

Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20101121/c508dc64/attachment.pgp>


More information about the devkit-devel mailing list