Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 29-05-2011 08:54, Hans de Goede escreveu:
> Hi,
> 
> On 05/29/2011 01:19 PM, Hans Verkuil wrote:
>> Hi Mauro,
>>
>> Thanks for the RFC! Some initial comments below. I'll hope to do some more
>> testing and reviewing in the coming week.
>>
> 
> <Snip>
> 
>>> c) get_not_associated_device: Returns the next device not associated with
>>>                   an specific device type.
>>>
>>> char *get_not_associated_device(void *opaque,
>>>                 char *last_seek,
>>>                 enum device_type desired_type,
>>>                 enum device_type not_desired_type);
>>>
>>> The parameters are:
>>>
>>> opaque:            media devices opaque descriptor
>>> last_seek:        last seek result. Use NULL to get the first result
>>> desired_type:        type of the desired device
>>> not_desired_type:    type of the seek device
>>>
>>> This function seeks inside the media_devices struct for the next physical
>>> device that doesn't support a non_desired type.
>>> This method is useful for example to return the audio devices that are
>>> provided by the motherboard.
>>
>> Hmmm. What you really want IMHO is to iterate over 'media hardware', and for
>> each piece of hardware you can find the associated device nodes.
>>
>> It's what you expect to see in an application: a list of USB/PCI/Platform
>> devices to choose from.
> 
> This is exactly what I was thinking, I was think along the lines of making
> the device_type enum bitmasks instead, and have a list devices functions,
> which lists all the "physical" media devices as "describing string",
> capabilities pairs, where capabilities would include things like sound
> in / sound out, etc.

A bitmask for device_type in practice means that we'll have just 32 (or 64)
types of devices. Not sure if this is enough in the long term.

Grouping the discovered information together is not hard, but there's one
issue if we'll be opening devices to retrieve additional info: some devices
do weird stuff at open, like retrieving firmware, when the device is waking
from a suspend state. So, the discover procedure that currently happens in 
usecs may take seconds. Ok, this is, in fact, a driver and/or hardware trouble, 
but I think that having a separate method for it is a good idea.

> And then a function to get a device string (be it a device node
> or an alsa device string, whatever is appropriate) for each capability
> of a device.

get_associated_device()/fget_associated_device() does it. It is generic enough to 
work with all types of devices. So, having an alsa device, it can be used
to get the video device associated, or vice-versa.

> This does need some more thought for more complex devices though ...

On complex devices, it may return more than one association.

Cheers,
Mauro.