portable_audio_player.type,access_method
Danny Kukawka
danny.kukawka at web.de
Wed May 2 03:00:34 PDT 2007
On Mittwoch, 2. Mai 2007, David Zeuthen wrote:
> On Tue, 2007-05-01 at 11:05 -0400, Jeff Mitchell wrote:
[..]
> > 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?
I think it would be more useful if there would be a key to collect all
possible access methodes or at least userspace libs/driver. The problem is:
we should not change the type of portable_audio_player.access_method this
would break every application using this key.
We could do this:
* portable_audio_player.access_method (string, mandatory):
--> contains the prefered default access method as e.g. storage/user
if a device support both methodes, set storage
* portable_audio_player.access_method.protocols (stringlist, not mandatory):
--> contains all possible alternative protocols to access the device.
Would be for example: {ifp; mtp; pde}
* portable_audio_player.access_method.drivers (stingrlist, not mandatory):
--> contains all possible alternative libs/driver to access the device.
Would be for example: {libifp; libmtp; libnjb}
By this you can easy check portable_audio_player.access_method.drivers for the
supported libs and access the related library specific namespace.
Danny
More information about the hal
mailing list