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