portable_audio_player.type,access_method

[Jeff Mitchell]

Danny Kukawka wrote:
> On Mittwoch, 2. Mai 2007, 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
>>     
>    --> this is a iPod or a device with iTunes capability (as e.g. some
>        Motorola v3 mobile phones)
>   
>>  psp
>>     
>    --> this is a PSP (not shure what this imply)
>   
>>  generic
>>     
>    --> this mean you can have a normal USB mp3 player, nothing special
>        about the access method
>
>   
>> and it looks like libnjb [1] can also set it to
>>
>>  njb
>>     
>
> Here we have maybe the problem (same with mtp etc.). Currently we set generic 
> also for several devices where portable_audio_player.access_method=user. I 
> think we need to discuss the possible values for this property. 
>
> IMO we should only allow the 3 keys above (maybe plus mobile to differ between 
> mp3 player and mobile phones with mp3 play capablility).
Do you mean 3 keys, or 3 values?  I count two keys listed above, but 
three values you list (psp, ipod, generic).  If you meant values, I 
don't see a reason why those three should be allowed but mtp, ptp (the 
proper value for njb...the protocol is PTP), and the rest shouldn't.

> Everything other as 
> e.g. njb/mtp should maybe better go into 
> portable_audio_player.access_method.* properties as proposed in my other 
> mail, since this info is not about the type of player, but about the access 
> method. For the type it should not matter how to access the device.
>   
But type (which, remember, isn't defined in the HAL spec) is tied to the 
access method.  Otherwise they're all just portable music players, 
period.  Unless you want to define a bunch of values for type like iPod, 
Sansa, iFP, Zen, Gigabeat, DJ, on and on and on, for every line that 
every manufacturer has.  After all, iPods aren't special -- they're just 
Apple's line of music players, just like Zens are Creative's line, and 
Gigabeats are Toshiba's line.  So there can't be a double standard in 
terms of what's allowed in type -- either all need to be supported, or none.

The useful information for type is really the access method, which right 
now isn't really defined in portable_audio_player.access_method to any 
granularity.  I think that having the entries you proposed in 
portable_audio_player.access_method.[drivers, protocols] in strlists is 
actually pretty good.  The only thing I wonder about that is whether or 
not it'd be hard for a user, looking at it, to tie a driver to a 
protocol.  If different drivers advertise different protocols, then you 
could presume that the order they're in the entry would match up -- but 
if they advertise the same protocol (or worse, if you have three 
handlers, two of which advertise the same, one of which is different), 
would you want to double-append values to keep the two keys matching, or 
would you want to aggregate the similar values and not worry about it?

--Jeff