portable_audio_player.type,access_method

[Jeff Mitchell]

David Zeuthen wrote:
> On Tue, 2007-05-01 at 11:05 -0400, Jeff Mitchell wrote:
>   
>> The 10-usb-music-players.fdi file has for each device a 
>> portable_audio_player.access_method key which is defined in the spec as 
>> mandatory, as well as portable_audio_player.type key that isn't in the 
>> spec at all.  Both are defined as strings.
>>     
>
> Yeah, it seems
>
>  portable_audio_player.type
>
> right now can assume these values
>
>  ipod
>  psp
>  generic
>
> and it looks like libnjb [1] can also set it to 
>
>  njb
>
> Probably it would be good to some definition of it to the spec. Maybe
> searching the mailing list will help clarify this? Because I can't
> remember on the top of my head. Or grepping through Rhythmbox, Banshee
> will tell? Or maybe Danny, who does most of the music player fdi files
> merging, knows? Danny?
>
> [1] :
> https://patches.ubuntu.com/libn/libnjb/libnjb_2.2.5-4.1ubuntu2.patch
>   
I hadn't seen that Ubuntu patch before; libnjb by itself doesn't have 
any fdi file (or at least, not until I'm done with it :-)  ) but my 
entries look similar to the Ubuntu ones, only with more detail.  
portable_audio_player.type right now in my files I have set to 
(including your values from above):

ipod
psp
generic
njb
mtp
karma
iriver


>   
>> I've run into a situation where both libifp and libmtp claim they can 
>> play the iRiver T10.  I'm trying to get more information, such as 
>> whether this is always true, or only with certain firmware revisions (in 
>> which case if they're exported I can try to match against that) or what, 
>> but there's also always the possibility that in the future more players 
>> will come up with more than one access_method.
>>
>> So I'm wondering whether both of those keys should be changed to a 
>> strlist to accommodate this possibility.  Thoughts?
>>     
>
> So first of all I think it's a great idea for libifp and libmtp to
> provide HAL information files so a big thank you for working on this! 
>
> I think that the way these libraries (user space drivers in fact) should
> provide information is that they need not to step over each other. It's
> probably sufficient that each library just merges properties in a
> private name space to identify whether it's supports the device or not?
> For example, 
>
>  libifp.supported = TRUE
>  libmtp.supported = TRUE
>
>   
I fully agree that most properties should be in a private name space, 
however, the ones I mentioned above already seem defined at a global 
layer.  (libifp.supported = TRUE is unnecessary since the fact that 
libifp is in there at all is enough to know that the device is 
supported.)  But simply specifying library namespaces seems awkward, 
especially because an application might not care if a library can handle 
it, but rather what underlying protocol is used -- for instance, if it 
handles various protocols itself, but within the application (which is 
not separated as a library).  So it could use information if it's in 
HAL, either from another library, or if these files ever get merged 
upstream.

I've been thinking about it, and it seems like there are two scenarios 
that could occur.  At the risk of being too lengthy/detailed, I'll step 
through a current version of my proposed fdi entry in the context of 
these scenarios.

The first is if two libraries handle the same device using the same 
protocol.  We'll call them libfoo and libbar, which both handle a device 
using protocol foobar.  Starred entries are the possible problem ones.

1)         <match key="info.capabilities" 
contains_not="portable_audio_player">
2)           <append key="info.capabilities" 
type="strlist">portable_audio_player</append>
3)         </match>
4)         <merge key="info.category" 
type="string">portable_audio_player</merge>
5)         <merge key="portable_audio_player.access_method" 
type="string">user</merge>
6*)        <merge key="portable_audio_player.type" 
type="string">foobar</merge>
7)         <append key="portable_audio_player.access_handlers" 
type="strlist">libfoo</append>
8*)        <append key="portable_audio_player.output_formats" 
type="strlist">audio/mpeg</append>
9*)        <append key="portable_audio_player.output_formats" 
type="strlist">audio/x-ms-wma</append>
10)        <append key="libfoo.name" type="string">Foobar Device</append>
11)        <append key="libfoo.xyz" type="string">Foobar Attribute 
XYZ</append>

1-3: No problem.
4-6: No problem - the second one to be processed would simply overwrite 
the first with the same value.
7: After the second library was added, you'd end up with a stringlist 
containing libfoo and libbar -- a good thing, can use this to tell 
what's available and what namespaces to look for.
8-9: These should be wrapped in contains_not like lines 1-3.  These 
would presumably be similar, but one library may have better information 
than the other -- so a possible candidate for putting in a library 
namespace?  Right now this is a *required* HAL attribute though.
10: No problem, these are in library specific namespaces.

So in the case of two libraries handling the same device, assuming they 
can choose a common portable_audio_player.type name (let's all play 
nicely now), there isn't an issue -- except for possibly the mime types, 
which should be checked so as not to double-append, and which maybe 
should be moved to library specific ones?  As has been discussed before 
on #hal and in my discussions with various libraries, relying on the 
mime-types reported by HAL from library fdi files is not reasonable, at 
least not at this poing -- it's just a good guideline.

Now is the other case: two libraries that claim to handle the same 
device, but with different access methods.  For instance, libfoo uses 
the foo protocol, and libbar uses the bar protocol:

1)         <match key="info.capabilities" 
contains_not="portable_audio_player">
2)           <append key="info.capabilities" 
type="strlist">portable_audio_player</append>
3)         </match>
4)         <merge key="info.category" 
type="string">portable_audio_player</merge>
5)         <merge key="portable_audio_player.access_method" 
type="string">user</merge>
6*)        <merge key="portable_audio_player.type" 
type="string">foobar</merge>
7)         <append key="portable_audio_player.access_handlers" 
type="strlist">libfoo</append>
8*)        <append key="portable_audio_player.output_formats" 
type="strlist">audio/mpeg</append>
9*)        <append key="portable_audio_player.output_formats" 
type="strlist">audio/x-ms-wma</append>
10)        <append key="libfoo.name" type="string">Foobar Device</append>
11)        <append key="libfoo.xyz" type="string">Foobar Attribute 
XYZ</append>

It's mostly the same -- same issues with the mime types (but as it's a 
function of the player, not the protocol, it's really the same as the 
other scenario).  The type is the problem here, though.  As it's defined 
as a string, whichever file gets evaluated last trumps the others.  So 
even if there really are two access protocols (libmtp and libnjb both 
claim the 3rd generation Dell DJ, for instance, and libmtp and libifp 
both claim the iRiver T10 -- and for all I know it really can use both 
(still trying to determine that)) only one will end up being reported.  
And it's not really realistic to assume that there won't be a device -- 
if the Dell DJ and iRiver T10 aren't already examples, instead of just 
mistakes by one library or the other -- that can handle more than one 
access method.  Such as, possibly, MTP and Generic.

So the ways around that are either making the portable_audio_player.type 
(which isn't even in the HAL spec, though it's used in 
10-usb-music-players.fdi everywhere) a strlist, or removing 
portable_audio_player.type entirely in favor of something like my 
access_handlers key, perhaps with (mandatory?) libfoo.protocol=foo and 
libbar.protocol=bar entries.

Whatever of these methods people think would be better I'll be 
"standardizing" in the sense of making libmtp, libnjb, libifp, libgpod 
and libkarma all look the same, and hopefully other libraries will 
follow suit.

Just as a recap, the three things I need to get opinions about (plus one 
bonus):

1) MIME types -- simply enclose all of them in contains_not checks, or 
make them attributes of a library's namespace (in which case the HAL 
spec needs updating)?

2) portable_audio_player.type -- turn into a strlist, or deprecate?  It 
doesn't seem to make sense the way it is now.

3) portable_audio_player.handlers -- David seemed to like this idea 
before, but to the broader audience, do you like this idea?  I think it 
makes sense, rather than doing some random searching through keys.  
Check this to see what libraries are installed that support it, then you 
know which keys to check for (and only need to look at a particular 
library's keys if you prefer one over the other).  Plus it's info the 
user could find handy, and it doesn't really stand a risk of bad 
interactions between libraries as they'd just be appending.

Bonus) Should portable_audio_player be renamed to portable_media_player 
since so many of them these days can handle photos and videos?

Thanks,
Jeff