portable_audio_player.type,access_method

[David Zeuthen]

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

Would that work?

     David