portable_audio_player.type,access_method

[Danny Kukawka]

On Mittwoch, 2. Mai 2007, Jeff Mitchell wrote:
> 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.

I meant values. And IMO mtp/ptp etc shouldn't be allowed because they say 
nothing about the type of the player, they say something about a possible 
protocol/access method.

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

I'm against add all possible product names/lines to the *.type key. This are 
IMO information which have nothing to do with type and are useless. You can 
get this information also from the product name.

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

Is this really needed? The user should simply chose a driver and use it, I 
don't see a need to tie something here in HAL.

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

No, I would add each protocol only one time. No direct connection between 
driver and supported protocols. You could also have a device with 3 different 
supported protocols for example, but with only one lib/driver which also only 
support only one protocol. I would see the protocol info only as info about 
the capability of the hardware and not about the system. The info about the 
driver should be enough for the user to choose one he want to use, or not? If 
really needed the driver can add more info in his private namespace.

Btw. We need maybe some new FDI derective to allow add a value to the list 
only if it is not already in, something like 'insert'. This would avoid to 
check again and again with contains_not if the value is already in the list.

Danny