Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
On Sunday, May 29, 2011 14:11:05 Mauro Carvalho Chehab wrote:
Em 29-05-2011 08:19, Hans Verkuil escreveu:
Each device type that is known by the API is defined inside enum
device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
It doesn't make sense to add anything at the struct without having a code
for discovering it. This RFC were made based on a real, working code.
That's said, the devices I used to test didn't create any radio node. I'll
add it.
the current class parsers should be able to get it with just a trivial change.
With respect to V4L_SUBDEV, a separate patch will likely be needed for it.
No sure how this would appear at sysfs.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g. MEDIA_DVB_FRONTEND =
100
Ditto for SND. That makes it easier to insert new future device nodes.
Good point.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Should we have IR (input) nodes as well? That would associate a IR input
with
a particular card.
From the implementation POV, IR's are virtual devices, so they're not bound
to an specific board at sysfs. So, if this will ever need, a different logic
will be required.
From the usecase POV, I don't see why such type of relationship should be
useful. The common usecase is that just one RC receiver/transmitter to be
used on a given environment. The IR commands should be able to control
everything.
For example, I have here one machine with 2 cards installed: one with 2 DVB-C
independent adapters and another with one analog/ISDB-T adapter. I want to
control all three devices with just one remote controller. Eventually, 2
rc devices will be shown, but just one will be connected to a sensor.
In this specific case, I don't use the RC remotes, but I prefer to have a
separate USB HID remote controller adapter for them.
There are some cases, however, where more than one remote controller may be
desired, like having one Linux system with several independent consoles,
each one with its own remote controller. On such scenario, what is needed
is to map each mouse/keyboard/IR/video adapter set to an specific Xorg
configuration, not necessarily matching the v4l devices order. If not
specified, X will just open all input devices and mix all of them.
In other words, for event/input devices, if someone needs to have more than
one IR, each directed to a different set of windows/applications, he will
need to manually configure what he needs. So, grouping RC with video apps
doesn't make sense.
I'm not so sure about that. Wouldn't it be at least useful that an application
can discover that an IR exists? That may exist elsewhere already, though. I'm
no IR expert.
};
The first function discovers the media devices and stores the information
at an internal representation. Such representation should be opaque to
the userspace applications, as it can change from version to version.
2.1) Device discover and release functions
=
The device discover is done by calling:
void *discover_media_devices(void);
In order to release the opaque structure, a free method is provided:
void free_media_devices(void *opaque);
2.2) Functions to help printing the discovered devices
=
In order to allow printing the device type, a function is provided to
convert from enum device_type into string:
char *media_device_type(enum device_type type);
const char *?
Ok.
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
This would be much more useful if a callback is provided.
I can't see any usecase for a callback. Can you explain it better?
Right now display_media_devices outputs to stdout. But what if the apps wants
to output to stderr? To some special console? To a GUI?
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
On Sunday, May 29, 2011 14:11:05 Mauro Carvalho Chehab wrote:
Em 29-05-2011 08:19, Hans Verkuil escreveu:
Each device type that is known by the API is defined inside enum
device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
It doesn't make sense to add anything at the struct without having a code
for discovering it. This RFC were made based on a real, working code.
That's said, the devices I used to test didn't create any radio node. I'll
add it.
the current class parsers should be able to get it with just a trivial change.
With respect to V4L_SUBDEV, a separate patch will likely be needed for it.
No sure how this would appear at sysfs.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g. MEDIA_DVB_FRONTEND =
100
Ditto for SND. That makes it easier to insert new future device nodes.
Good point.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Should we have IR (input) nodes as well? That would associate a IR input
with
a particular card.
From the implementation POV, IR's are virtual devices, so they're not bound
to an specific board at sysfs. So, if this will ever need, a different logic
will be required.
From the usecase POV, I don't see why such type of relationship should be
useful. The common usecase is that just one RC receiver/transmitter to be
used on a given environment. The IR commands should be able to control
everything.
For example, I have here one machine with 2 cards installed: one with 2 DVB-C
independent adapters and another with one analog/ISDB-T adapter. I want to
control all three devices with just one remote controller. Eventually, 2
rc devices will be shown, but just one will be connected to a sensor.
In this specific case, I don't use the RC remotes, but I prefer to have a
separate USB HID remote controller adapter for them.
There are some cases, however, where more than one remote controller may be
desired, like having one Linux system with several independent consoles,
each one with its own remote controller. On such scenario, what is needed
is to map each mouse/keyboard/IR/video adapter set to an specific Xorg
configuration, not necessarily matching the v4l devices order. If not
specified, X will just open all input devices and mix all of them.
In other words, for event/input devices, if someone needs to have more than
one IR, each directed to a different set of windows/applications, he will
need to manually configure what he needs. So, grouping RC with video apps
doesn't make sense.
};
The first function discovers the media devices and stores the information
at an internal representation. Such representation should be opaque to
the userspace applications, as it can change from version to version.
2.1) Device discover and release functions
=
The device discover is done by calling:
void *discover_media_devices(void);
In order to release the opaque structure, a free method is provided:
void free_media_devices(void *opaque);
2.2) Functions to help printing the discovered devices
=
In order to allow printing the device type, a function is provided to
convert from enum device_type into string:
char *media_device_type(enum device_type type);
const char *?
Ok.
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
This would be much more useful if a callback is provided.
I can't see any usecase for a callback. Can you explain it better?
2.3) Functions to get device associations
The API provides 3 methods to get the associated devices:
a) get_associated_device: returns the next device associated with another
one
char *get_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
char *seek_device,
enum device_type seek_type);
const char *? Ditto elsewhere.
OK.
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
seek_device:name of the device with you want to get an association.
seek_type: type of the seek device. Using NONE produces the same
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
On Sunday, May 29, 2011 16:55:38 Mauro Carvalho Chehab wrote: Em 29-05-2011 10:30, Hans de Goede escreveu: Hi, On 05/29/2011 03:08 PM, Mauro Carvalho Chehab wrote: 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. Ok, so we may need to use a different mechanism. I'm trying to think from the pov of what the average app needs when it comes to media device discovery, and what it needs is a list of devices which have the capabilities it needs (like for example video input). As mentioned in this thread earlier it might be an idea to add an option to this new lib to filter the discovered devices. We could do that, but with a bitmask containing capabilities, the user of the lib can easily iterate over all found devices itself and discard unwanted ones itself. I think that one of the issues of the current device node name is that the kernel just names all video devices as video???, no matter if such device is a video output device, a video input device, an analog TV device or a webcam. IMO, we should be reviewing this policy, for example, to name video output devices as video_out, and webcams as webcam, and let udev to create aliases for the old namespace. What categories of video devices do we have? - video (TV, HDMI et al) input - video output - sensor input (webcam-like) - mem2mem devices (input and/or output) - MPEG (compressed video) input - MPEG (compressed video) output - Weird: ivtv still captures audio over a video node, there may be others. My understanding is that in practice the difference between webcam and video input isn't that important (since you could hook up a camera to a video input device I'm not even sure that you should make that difference). But input, output, mem2mem is important. And so is compressed vs uncompressed. Creating video_out and video_m2m nodes doesn't seem unreasonable to me. I don't know how to signal compressed vs uncompressed, though. Currently this is done through ENUM_FMT so it doesn't lend itself to using a different video node name, even though in practice video device nodes do not switch between compressed and uncompressed. But that's the case today and may not be true tomorrow. The whole UVC H.264 mess that Laurent is looking into springs to mind. 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. WRT detection speed I agree we should avoid opening the nodes where possible, so I guess that also means we may want a second give me more detailed info call which an app can do an a per device (function) basis, or we could leave this to the apps themselves. I'm in favour of a more detailed info call. +1 Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 30-05-2011 03:34, Hans Verkuil escreveu: On Sunday, May 29, 2011 14:11:05 Mauro Carvalho Chehab wrote: In other words, for event/input devices, if someone needs to have more than one IR, each directed to a different set of windows/applications, he will need to manually configure what he needs. So, grouping RC with video apps doesn't make sense. I'm not so sure about that. Wouldn't it be at least useful that an application can discover that an IR exists? That may exist elsewhere already, though. I'm no IR expert. ir-keytable does that. We may move part of its code to a library later. All discovered devices can be displayed by calling: void display_media_devices(void *opaque); This would be much more useful if a callback is provided. I can't see any usecase for a callback. Can you explain it better? Right now display_media_devices outputs to stdout. But what if the apps wants to output to stderr? To some special console? To a GUI? Good point. If all userspace wants is to redirect it, fdup() may be used. Another option would be to just pass the file descriptor as a parameter. Passing a printf-like callback may require some work. I'm not sure if this is the proper way for doing it. Could you please propose a patch for it? Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 30-05-2011 03:54, Hans Verkuil escreveu: On Sunday, May 29, 2011 14:11:05 Mauro Carvalho Chehab wrote: Em 29-05-2011 08:19, Hans Verkuil escreveu: It's what you expect to see in an application: a list of USB/PCI/Platform devices to choose from. A missing function is to return the device address, but it should be easy to add it if needed. This is the v4l2-sysfs-path output for an ivtv card (PVR-350): /sys/class/dvb: No such file or directory Video device: video1 video: video17 vbi: vbi1 radio: radio1 Video device: video17 video: video25 vbi: vbi1 radio: radio1 Video device: video25 video: video33 vbi: vbi1 radio: radio1 Video device: video33 video: video49 vbi: vbi1 radio: radio1 Video device: video49 vbi: vbi1 radio: radio1 This list of 'devices' is pretty useless for apps. Agreed. There are a few points to notice here: 1) ivtv does a very bad job with video devices, using a non-v4l2-api-compliance way of presenting their stuff: it requires userspace applications to know that some video device ranges have special meanings. I think that there are even a few mutually-exclusive video nodes; 2) v4l device namespace is messy: a video node can be used by video input, video output, webcams, etc. I think we should address that, by working into a new namespace, providing some ways for udev to create aliases for the old namespace; 3) We currently lack the uevent bits at the drivers to allow grouping devices. The kernelspace patches are simple, but are needed to allow mapping complex scenarios like the ones found at ivtv; 4) Clearly, there's a bug at the library: it should be showing all video/radio/vbi devices for all video nodes. E. g., a loop code like the one currently used inside v4l2-sysfs-path should be producing something like: Video device: video1 video: video17 video25 video33 video49 vbi: vbi1 radio: radio1 Video device: video17 video: video1 video25 video33 video49 vbi: vbi1 radio: radio1 ... 5) For the v4l2-sysfs-path tool itself, their internal logic should be suppressing the device group repetitions. (BTW: note the initial 'No such file or dir' error at the top: it's perfectly fine not to have any dvb devices) Yes. This is caused by the absence of dvb-core module. We need to suppress such error message. The output of v4l2-sysfs-path -d is much more useful: Device pci:00/:00:14.4/:04:05.0: video1(video, dev 81:1) video17(video, dev 81:6) video25(video, dev 81:4) video33(video, dev 81:2) video49(video, dev 81:9) vbi1(vbi, dev 81:3) vbi17(vbi, dev 81:8) vbi9(vbi, dev 81:7) radio1(radio, dev 81:5) Here at least all devices of the PCI card are grouped together. While it would be nice to have the device address exported, it isn't enough: first of all you want a more abstract API when the app iterates over the hardware devices, secondly such an API would map muchmore nicely to the MC, and thirdly doing this in the library will allow us to put more intelligence into the code. The proposed API should work with MC also. Eventually, we'll need more stuff when MC parser is added there through. For example, if I'm not mistaken cx88 devices consist of multiple PCI devices. It's not enough to group them by PCI address. You can however add code to this library that will detect that it is a cx88 device and attempt to group the video/audio/dvb devices together. We'll need to add some intelligence at the sysfs parser to handle devices with internal PCI/USB bridges, like cx88. The Sirius USB camera I have here is also an interesting device: it has internally one USB hub, connected to several devices: - an UVC webcam; - one USB audio output device (AVC); - one USB external port; - one USB HID device, with 3 multimedia buttons (vol up/down and play). If I plug a V4L device at his USB port, the current code does the wrong thing [1]. [1] I never tested, but I suspect that plugging an extra camera or tv device on it won't work anyway, due to USB bandwidth requirements, so this may not be a real usecase, although I'd like to fix this issue later. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 30-05-2011 04:14, Hans Verkuil escreveu: On Sunday, May 29, 2011 16:55:38 Mauro Carvalho Chehab wrote: Em 29-05-2011 10:30, Hans de Goede escreveu: IMO, we should be reviewing this policy, for example, to name video output devices as video_out, and webcams as webcam, and let udev to create aliases for the old namespace. What categories of video devices do we have? - video (TV, HDMI et al) input - video output - sensor input (webcam-like) - mem2mem devices (input and/or output) - MPEG (compressed video) input - MPEG (compressed video) output - Weird: ivtv still captures audio over a video node, there may be others. pvrusb2 also does that. Both are abusing of the V4L2 API: they should be using alsa for audio output. I think that alsa provides support for mpeg-encoded audio. My understanding is that in practice the difference between webcam and video input isn't that important (since you could hook up a camera to a video input device I'm not even sure that you should make that difference). It is relevant for the users. For example, when you have for example a notebook with its camera, and a TV harware, users and applications may want to know. For example, a multimedia conference application will choose the webcam by default. But input, output, mem2mem is important. Yes. And so is compressed vs uncompressed. Not really. There are several devices that provides compressed streams, like most gspca hardware. Several of them allow you to select between a compressed or a not-compressed formats. What you're meaning by compressed is, in fact, input/outputs for the mpeg encoder itself. So, I'd say that we have 2 different types of nodes there: encoder and decoder. Creating video_out and video_m2m nodes doesn't seem unreasonable to me. I don't know how to signal compressed vs uncompressed, though. Currently this is done through ENUM_FMT so it doesn't lend itself to using a different video node name, even though in practice video device nodes do not switch between compressed and uncompressed. Just ivtv (and maybe cx18?) uses different devices for compressed stuff. All other drivers use VIDIOC*FMT for it. But that's the case today and may not be true tomorrow. The whole UVC H.264 mess that Laurent is looking into springs to mind. 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. WRT detection speed I agree we should avoid opening the nodes where possible, so I guess that also means we may want a second give me more detailed info call which an app can do an a per device (function) basis, or we could leave this to the apps themselves. I'm in favour of a more detailed info call. +1 Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi Mauro,
Thanks for the RFC! Some initial comments below. I'll hope to do some more
testing and reviewing in the coming week.
On Sunday, May 29, 2011 03:01:43 Mauro Carvalho Chehab wrote:
Em 28-05-2011 13:20, Mauro Carvalho Chehab escreveu:
Em 28-05-2011 12:24, Hans Verkuil escreveu:
But I would really like to see an RFC with a proposal of the API and how
it is to be used. Then after an agreement has been reached the library can
be modified accordingly and we can release it.
Ok, that's the RFC for the API. The code is already committed, on a separate
library at v4l-utils. So, feel free to test.
http://git.linuxtv.org/v4l-utils.gi
Just finished a version 2 of the library. I've addressed on it the two
comments from Hans de Goede: to allow calling the seek method for the
associated devices using an open file descriptor, and to allow listing
all video nodes. The library is at utils/libmedia_dev dir, at
http://git.linuxtv.org/v4l-utils.git. IMO, the proper step is to move it
to the libv4l, but it is better to wait to the release of the current
version. After that, I'll change xawtv3 to link against the new library.
Btw, it may be a good idea to also move the alsa thread code from xawtv3
(and tvtime) to v4l-utils.
-
1) Why such library is needed
==
Media devices can be very complex. It is not trivial how to detect what's the
other devices associated with a video node.
This API provides the capabilities of getting the associated devices with a
video node.
It is currently implemented at http://git.linuxtv.org/v4l-utils.git, at the
utils/libmedia_dev/. After validating it, it makes sense to move it to be
part of libv4l.
2) Provided functions
==
The API defines a macro with its current version. Currently, it is:
#define GET_MEDIA_DEVICES_VERSION 0x0104
Each device type that is known by the API is defined inside enum device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g. MEDIA_DVB_FRONTEND = 100
Ditto for SND. That makes it easier to insert new future device nodes.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Should we have IR (input) nodes as well? That would associate a IR input with
a particular card.
};
The first function discovers the media devices and stores the information
at an internal representation. Such representation should be opaque to
the userspace applications, as it can change from version to version.
2.1) Device discover and release functions
=
The device discover is done by calling:
void *discover_media_devices(void);
In order to release the opaque structure, a free method is provided:
void free_media_devices(void *opaque);
2.2) Functions to help printing the discovered devices
=
In order to allow printing the device type, a function is provided to
convert from enum device_type into string:
char *media_device_type(enum device_type type);
const char *?
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
This would be much more useful if a callback is provided.
2.3) Functions to get device associations
The API provides 3 methods to get the associated devices:
a) get_associated_device: returns the next device associated with another one
char *get_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
char *seek_device,
enum device_type seek_type);
const char *? Ditto elsewhere.
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
seek_device:name of the device with you want to get an association.
seek_type: type of the seek device. Using NONE produces the same
result of using NULL for the seek_device.
This function seeks inside the media_devices struct for the next device
that it is associated with a seek parameter.
It can be used to get an alsa device associated with a video device. If
the seek_device is NULL or seek_type is NONE, it
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Hans Verkuil hverk...@xs4all.nl 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.
On Sunday, May 29, 2011 03:01:43 Mauro Carvalho Chehab wrote:
Em 28-05-2011 13:20, Mauro Carvalho Chehab escreveu:
Em 28-05-2011 12:24, Hans Verkuil escreveu:
But I would really like to see an RFC with a proposal of the API
and how
it is to be used. Then after an agreement has been reached the
library can
be modified accordingly and we can release it.
Ok, that's the RFC for the API. The code is already committed, on a
separate
library at v4l-utils. So, feel free to test.
http://git.linuxtv.org/v4l-utils.gi
Just finished a version 2 of the library. I've addressed on it the
two
comments from Hans de Goede: to allow calling the seek method for the
associated devices using an open file descriptor, and to allow
listing
all video nodes. The library is at utils/libmedia_dev dir, at
http://git.linuxtv.org/v4l-utils.git. IMO, the proper step is to move
it
to the libv4l, but it is better to wait to the release of the current
version. After that, I'll change xawtv3 to link against the new
library.
Btw, it may be a good idea to also move the alsa thread code from
xawtv3
(and tvtime) to v4l-utils.
-
1) Why such library is needed
==
Media devices can be very complex. It is not trivial how to detect
what's the
other devices associated with a video node.
This API provides the capabilities of getting the associated devices
with a
video node.
It is currently implemented at http://git.linuxtv.org/v4l-utils.git,
at the
utils/libmedia_dev/. After validating it, it makes sense to move it
to be
part of libv4l.
2) Provided functions
==
The API defines a macro with its current version. Currently, it is:
#define GET_MEDIA_DEVICES_VERSION 0x0104
Each device type that is known by the API is defined inside enum
device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g.
MEDIA_DVB_FRONTEND = 100
Ditto for SND. That makes it easier to insert new future device nodes.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Should we have IR (input) nodes as well? That would associate a IR
input with
a particular card.
};
The first function discovers the media devices and stores the
information
at an internal representation. Such representation should be opaque
to
the userspace applications, as it can change from version to version.
2.1) Device discover and release functions
=
The device discover is done by calling:
void *discover_media_devices(void);
In order to release the opaque structure, a free method is provided:
void free_media_devices(void *opaque);
2.2) Functions to help printing the discovered devices
=
In order to allow printing the device type, a function is provided to
convert from enum device_type into string:
char *media_device_type(enum device_type type);
const char *?
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
This would be much more useful if a callback is provided.
2.3) Functions to get device associations
The API provides 3 methods to get the associated devices:
a) get_associated_device: returns the next device associated with
another one
char *get_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
char *seek_device,
enum device_type seek_type);
const char *? Ditto elsewhere.
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
seek_device:name of the device with you want to get an association.
seek_type: type of the seek device. Using NONE produces the same
result of using NULL for the seek_device.
This function seeks inside the media_devices struct for the next
device
that it is associated with a seek parameter.
It can be used to get an alsa device associated with a video device.
If
the seek_device is NULL or seek_type is
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
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. 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. This does need some more thought for more complex devices though ... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 29-05-2011 08:19, Hans Verkuil escreveu:
Each device type that is known by the API is defined inside enum device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
It doesn't make sense to add anything at the struct without having a code
for discovering it. This RFC were made based on a real, working code.
That's said, the devices I used to test didn't create any radio node. I'll add
it.
the current class parsers should be able to get it with just a trivial change.
With respect to V4L_SUBDEV, a separate patch will likely be needed for it.
No sure how this would appear at sysfs.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g. MEDIA_DVB_FRONTEND =
100
Ditto for SND. That makes it easier to insert new future device nodes.
Good point.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Should we have IR (input) nodes as well? That would associate a IR input with
a particular card.
From the implementation POV, IR's are virtual devices, so they're not bound
to an specific board at sysfs. So, if this will ever need, a different logic
will be required.
From the usecase POV, I don't see why such type of relationship should be
useful. The common usecase is that just one RC receiver/transmitter to be
used on a given environment. The IR commands should be able to control
everything.
For example, I have here one machine with 2 cards installed: one with 2 DVB-C
independent adapters and another with one analog/ISDB-T adapter. I want to
control all three devices with just one remote controller. Eventually, 2
rc devices will be shown, but just one will be connected to a sensor.
In this specific case, I don't use the RC remotes, but I prefer to have a
separate USB HID remote controller adapter for them.
There are some cases, however, where more than one remote controller may be
desired, like having one Linux system with several independent consoles,
each one with its own remote controller. On such scenario, what is needed
is to map each mouse/keyboard/IR/video adapter set to an specific Xorg
configuration, not necessarily matching the v4l devices order. If not
specified, X will just open all input devices and mix all of them.
In other words, for event/input devices, if someone needs to have more than
one IR, each directed to a different set of windows/applications, he will
need to manually configure what he needs. So, grouping RC with video apps
doesn't make sense.
};
The first function discovers the media devices and stores the information
at an internal representation. Such representation should be opaque to
the userspace applications, as it can change from version to version.
2.1) Device discover and release functions
=
The device discover is done by calling:
void *discover_media_devices(void);
In order to release the opaque structure, a free method is provided:
void free_media_devices(void *opaque);
2.2) Functions to help printing the discovered devices
=
In order to allow printing the device type, a function is provided to
convert from enum device_type into string:
char *media_device_type(enum device_type type);
const char *?
Ok.
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
This would be much more useful if a callback is provided.
I can't see any usecase for a callback. Can you explain it better?
2.3) Functions to get device associations
The API provides 3 methods to get the associated devices:
a) get_associated_device: returns the next device associated with another one
char *get_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
char *seek_device,
enum device_type seek_type);
const char *? Ditto elsewhere.
OK.
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
seek_device:name of the device with you want to get an association.
seek_type: type of the seek device. Using NONE produces the same
result of using NULL for the seek_device.
This function seeks inside the media_devices struct for the next device
that it is associated
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 29-05-2011 08:47, Andy Walls escreveu:
Hans Verkuil hverk...@xs4all.nl wrote:
Each device type that is known by the API is defined inside enum
device_type,
currently defined as:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
It might be better to start at a new offset here, e.g.
MEDIA_DVB_FRONTEND = 100
Ditto for SND. That makes it easier to insert new future device nodes.
MEDIA_DVB_DEMUX,
MEDIA_DVB_DVR,
MEDIA_DVB_NET,
MEDIA_DVB_CA,
MEDIA_SND_CARD,
MEDIA_SND_CAP,
MEDIA_SND_OUT,
MEDIA_SND_CONTROL,
MEDIA_SND_HW,
Framebuffer devices are missing from the list. Ivtv provides one at the
moment.
Please send us a patch adding it against v4l-utils. I'm not sure how fb devices
appear at sysfs.
Thanks,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi, On 05/29/2011 03:08 PM, Mauro Carvalho Chehab wrote: 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. Ok, so we may need to use a different mechanism. I'm trying to think from the pov of what the average app needs when it comes to media device discovery, and what it needs is a list of devices which have the capabilities it needs (like for example video input). As mentioned in this thread earlier it might be an idea to add an option to this new lib to filter the discovered devices. We could do that, but with a bitmask containing capabilities, the user of the lib can easily iterate over all found devices itself and discard unwanted ones itself. 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. WRT detection speed I agree we should avoid opening the nodes where possible, so I guess that also means we may want a second give me more detailed info call which an app can do an a per device (function) basis, or we could leave this to the apps themselves. WRT grouping together, I think that the grouping view should be the primary view / API, as that is what most apps will want to use ... 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 is very topology / association detection oriented, as said before I don't think that is what the average app wants / needs, for example tvtime/xawtv want: 1) Give me a list v4l2 input devices with a tuner 2) Give me the sound device to read sound from associated to v4l2 input device foo (the one the user just selected). I realize that this can be done with the current API too, I'm just saying that it might be better to give the enumeration of physical devices a more prominent role, as well as getting a user friendly name for the physical device. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 29-05-2011 09:11, Mauro Carvalho Chehab escreveu:
Em 29-05-2011 08:19, Hans Verkuil escreveu:
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
MEDIA_V4L_VIDEO = 0,
Can you add MEDIA_V4L_RADIO as well? And MEDIA_V4L_SUBDEV too.
It might be better to start at a new offset here, e.g. MEDIA_DVB_FRONTEND =
100
Ditto for SND. That makes it easier to insert new future device nodes.
Good point.
char *media_device_type(enum device_type type);
const char *?
Ok.
const char *? Ditto elsewhere.
OK.
I did some testing: vivi video nodes do not show up at all.
Hmm... vivi nodes are not linked to any physical hardware: they are virtual
devices:
$ tree /sys/class/video4linux/
/sys/class/video4linux/
└── video0 - ../../devices/virtual/video4linux/video0
The current implementation discards virtual devices, as there's no way to
associate
them with a physical device. I'll fix the code to allow it to show also
virtual devices.
The above comments were addressed. I added also an option at v4l2-sysfs-path[1]
to allow
showing all discovered info as-is. By default, it will show something close to
what a
V4L2 application would do.
I didn't care enough to add support for midi and midiC0D0 type of devices, as I
don't have
any here for testing, and they're doubtful to be used by a V4L2 application,
but it would
be good to latter add support for them (or to remove them from the list of
parsed devices),
just to avoid reporting a device as of the type unknown. Not sure if is there
any other
alsa device not parsed.
On normal mode, it outputs the device based on /dev/video? topology:
$ ./utils/v4l2-sysfs-path/v4l2-sysfs-path
Video device: video2
vbi: vbi0
sound card: hw:2
pcm capture: hw:2,0
mixer: hw:2
Video device: video1
sound card: hw:1
pcm output: hw:1,0
mixer: hw:1
Video device: video0
Alsa playback device(s): hw:0,0 hw:0,1
On device mode, it will show:
$ ./utils/v4l2-sysfs-path/v4l2-sysfs-path -d
Device pci:00/:00:1b.0:
hw:0(sound card, dev 0:0) hw:0,0(pcm capture, dev 116:6) hw:0,0(pcm
output, dev 116:5) hw:0,1(pcm output, dev 116:4) hw:0(mixer, dev 116:8)
hw:0,0(sound hardware, dev 116:7)
Device pci:00/:00:1d.7/usb1/1-7:
video2(video, dev 81:2) vbi0(vbi, dev 81:3) hw:2(sound card, dev 0:0)
hw:2,0(pcm capture, dev 116:11) hw:2(mixer, dev 116:12)
Device pci:00/:00:1d.7/usb1/1-8:
video1(video, dev 81:1) hw:1(sound card, dev 0:0) hw:1,0(pcm output,
dev 116:9) hw:1(mixer, dev 116:10)
Device virtual0:
video0(video, dev 81:0)
Device virtual1:
timer(sound timer, dev 116:2)
Device virtual2:
seq(sound sequencer, dev 116:3)
In order, the above devices are:
- HDA Intel integrated at the motherboard chipset.
- USB Sirius webcam, with integrated audio output;
- USB HVR 950 (em28xx based);
- Vivi (the device at virtual0).
[1] btw, we should rename it ;) Its name makes not much sense with the current
approach
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 29-05-2011 10:30, Hans de Goede escreveu:
Hi,
On 05/29/2011 03:08 PM, Mauro Carvalho Chehab wrote:
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.
Ok, so we may need to use a different mechanism. I'm trying to think from
the pov of what the average app needs when it comes to media device discovery,
and what it needs is a list of devices which have the capabilities it needs
(like for example video input). As mentioned in this thread earlier it might
be an idea to add an option to this new lib to filter the discovered
devices. We could do that, but with a bitmask containing capabilities, the
user of the lib can easily iterate over all found devices itself and
discard unwanted ones itself.
I think that one of the issues of the current device node name is that the
kernel just names all video devices as video???, no matter if such device
is a video output device, a video input device, an analog TV device or a
webcam.
IMO, we should be reviewing this policy, for example, to name video output
devices as video_out, and webcams as webcam, and let udev to create
aliases for the old namespace.
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.
WRT detection speed I agree we should avoid opening the nodes where possible,
so I guess that also means we may want a second give me more detailed info
call which an app can do an a per device (function) basis, or we could
leave this to the apps themselves.
I'm in favour of a more detailed info call.
WRT grouping together, I think that the grouping view should be the primary
view / API, as that is what most apps will want to use ...
In the case of tvtime/xawtv, the non-grouped devices may also be important, as
they
generally represent the default output device. Eventually, this information is
also provided by libalsa, but I'm not sure if libalsa behave well if a video
device with audio output is probed before the motherboard-provided one.
On one setup here, the hw:0 is generally the video board hardware.
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 is very topology / association detection oriented, as said before
I don't think that is what the average app wants / needs, for example
tvtime/xawtv
want:
1) Give me a list v4l2 input devices with a tuner
do {
vid = get_associated_device(md, vid, MEDIA_V4L_VIDEO, NULL, NONE);
if (!vid)
break;
printf(Video device: %s\n, vid);
} while (vid);
Of course, we may do something like:
#define get_video_devices(md, prev) get_associated_device(md, prev,
MEDIA_V4L_VIDEO, NULL, NONE)
2) Give me the sound device
