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
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 11:57, Devin Heitmueller escreveu: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I share Hans' concern on this. This is an API that seems pretty immature, and I worry that it's adoption will cause lots of problems as people expect it to work with a wide variety of tuners. Well, it is better than the current assumption made by tvtime that the video capture board will always be using hw:1, and the standard output being using hw:0. For example, how does the sysfs approach handle PCI boards that have multiple video and audio devices? The sysfs layout will effectively be: PCI DEVICE - video0 - video1 - alsa hw:1,0 - alsa hw:1,1 The approach taken in this library will probably help with the simple cases such as a USB tuner that only has a single video device, audio device, and VBI device. But it's going to fall flat on its face when it comes to devices that have multiple capture sources (since sysfs will represent this as a tree with all the nodes on the same level). Indeed, the current implementation is very simple. However, sysfs already provides a standard way for doing more complex device identification like that. The proper way is to export such information via uevent nodes. All we need to do is to add something like: VIDEO=video0 to the other devices that share the same resources associated with video0 node. This is done by simply add something like this: add_uevent_var(env, VIDEO=video%d, vdev-num); to the alsa and dvb part of the driver. Devices that provide just one video and one alsa driver doesn't need to use it, so, in cases like audio provided via snd-usb-audio is already covered. More complex devices like the above will have the alsa module implemented internally. So, it should be easy to add the associated video node at the uevent information for that board. Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). For the media controller to be used by things like that, other subsystems need to start using it, like alsa and dvb. It is still a long road for this to happen, and the actual usecase for it is due to the SoC designs. The sysfs approach, on the other hand, is simple, more effective and faster to implement. It also provides everything it is needed. Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). MythTV setup is very complex. Even if you want do do a simple task like just watching an analog or digital TV, you need to do a large amount of non-trivial configuration steps. This is not API's fault. I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. Devin -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 26-05-2011 03:53, Hans Verkuil escreveu: On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I wanted to do a review of this library, but Devin did it for me in his comments below. I completely agree with his comments. Once I have all the control framework stuff that is in my queue done, then I want to go through as many drivers as I can and bring them all up to the latest V4L2 standards (using v4l2-compliance to verify correctness). It is my intention to create some helper functions to implement a MC node for these simple legacy drivers. Eventually all V4L drivers should have a MC node. Converting all devices to use MC won't help, as the alsa device is implemented on some cases by independent drivers (snd-usb-alsa). As I said before, forcing all drivers to implement MC is silly. They just don't need it. Let's focus the MC stuff where it really belongs: SoC designs and very complex devices, were you should need to know and to change the internal routes and V4L2 API is not enough for it. Writing a library like the one proposed here would then be much easier and it would function as a front-end for the MC. The design of the library methods should be independent of MC or sysfs. That's what I did: the methods there provide the basic information about the media devices without exporting sysfs struct to it. Once we have the library stable, it can be extended to also implement device discovery via MC (or even using both). Yet, MC is an optional feature, and still not ready to handle inter-subsystem dependencies. As there isn't even a single patch adding MC API for sound or dvb, it is clear that it will take at least 2 development kernel cycles (e. g. about 6 months) for this to start happening. In other words, you're arguing against using what's currently provided by the Kernel, on a standard way, in favour of something that will take at least 6 months having the basic API added for the other subsystems to be able to report their device trees, plus the time to port all drivers to use it. This doesn't sound like a good plan to me. Once having MC completed, an optional extension to the library may allow its usage also for MC device info methods, where available at the driver(s). The last few months I wasn't able to really spend the time on V4L that I wanted, but that is changing for the better. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi, On 05/28/2011 02:17 PM, Mauro Carvalho Chehab wrote: Em 26-05-2011 03:53, Hans Verkuil escreveu: On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuilhverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I wanted to do a review of this library, but Devin did it for me in his comments below. I completely agree with his comments. Once I have all the control framework stuff that is in my queue done, then I want to go through as many drivers as I can and bring them all up to the latest V4L2 standards (using v4l2-compliance to verify correctness). It is my intention to create some helper functions to implement a MC node for these simple legacy drivers. Eventually all V4L drivers should have a MC node. Converting all devices to use MC won't help, as the alsa device is implemented on some cases by independent drivers (snd-usb-alsa). As I said before, forcing all drivers to implement MC is silly. They just don't need it. Let's focus the MC stuff where it really belongs: SoC designs and very complex devices, were you should need to know and to change the internal routes and V4L2 API is not enough for it. Writing a library like the one proposed here would then be much easier and it would function as a front-end for the MC. The design of the library methods should be independent of MC or sysfs. That's what I did: the methods there provide the basic information about the media devices without exporting sysfs struct to it. Once we have the library stable, it can be extended to also implement device discovery via MC (or even using both). Yet, MC is an optional feature, and still not ready to handle inter-subsystem dependencies. As there isn't even a single patch adding MC API for sound or dvb, it is clear that it will take at least 2 development kernel cycles (e. g. about 6 months) for this to start happening. In other words, you're arguing against using what's currently provided by the Kernel, on a standard way, in favour of something that will take at least 6 months having the basic API added for the other subsystems to be able to report their device trees, plus the time to port all drivers to use it. This doesn't sound like a good plan to me. Once having MC completed, an optional extension to the library may allow its usage also for MC device info methods, where available at the driver(s). I've to side with Mauro here, I agree that the important thing is having a userspace library which can be used by other userspace apps to find out which sound / vbi device belongs to a video node. This libraries API should not export knowledge about how this information is gathered. For now if can use sysfs to make things at least work with simple devices (and in the future still use sysfs when running on older kernels). Once we actually have a better kernel userspace API for this, and devices which implement this API, we could make the library try that first, and fall back to using sysfs when that new API is not available. I said before I hope to release a new v4l-utils soon. After that I want to start working towards a first 0.9.0 devel release, which will contain the v4l plugin patches done by Nokia, and could very well also contain some API for this. Therefor I would like to focus on defining a sane API for discovering video nodes, and associated nodes. As said before I'm not completely sold on the current API of Mauro's mini lib, but to be honest I've not really studied either the current API or the problem it solves too closely. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 12:55, Hans de Goede escreveu:
Hi,
On 05/24/2011 04:09 PM, Mauro Carvalho Chehab wrote:
Em 24-05-2011 04:21, Hans de Goede escreveu:
Hi,
My I suggest that we instead just copy over the single get_media_devices.c
file to xawtv, and not install the not so much a lib lib ?
If we do that, then all other places where the association between an alsa
device
and a video4linux node is needed will need to copy it, and we'll have a fork.
Also, we'll keep needing it at v4l-utils, as it is now needed by the new
version
of v4l2-sysfs-path tool.
Btw, this lib were created due to a request from the vlc maintainer that
something
like that would be needed. After finishing it, I decided to add it at xawtv
in order
to have an example about how to use it.
I'm not saying that this is not useful to have, I'm just worried about
exporting the API before it has had any chance to stabilize, and about
also throwing in the other random libv4l2util bits.
Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I
consider it unpolite to revert other peoples commits, so I would prefer for
you
to revert the install libv4l2util.a patch yourself. But if you don't (or
don't
get around to doing it before I do the release), I will revert it, as this
clearly needs more discussion before making it into an official release
tarbal (we can always re-introduce the patch after the release).
I'm not a big fan or exporting the rest of stuff at libv4l2util.a either
Glad we agree on that :)
but I
think that at least the get_media_devices stuff should be exported somewhere,
Agreed.
maybe as part of libv4l.
That would be a logical place to put it, otoh currently libv4l mostly mimics
the
raw /dev/video# node API, so adding this API is not a logical fit there ...
It may make more sense to have something in libv4l2 like:
enum libv4l2_associated_device_types {
libv4l2_alsa_input,
libv4l2_alsa_output,
libv4l2_vbi
};
While, on a large amount of the usecases the above will work, the association
is not that
simple, as it may have more than one device associated for each type, but I
liked the basic
idea.
In fact, I was thinking on implementing something like the above for the media
devices structure, but I opted to use a simple sorted device list, as the code
will be simpler, clearer to read and without the need of implementing complex
allocation schemes.
int libv4l2_get_associated_devive(int fd, enum
libv4l2_associated_device_types type, ...);
Where fd is the fd of an open /dev/video node, and ... is a param through
which the device gets returned (I guess a char * to a buffer of MAX_PATH
length where the device name gets stored, this could
be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc.
Using the fd will be more complex, as we'll loose the device node (is there a
glibc way to get the device path from the fd?). Well, we may associate the fd
descriptor with the device node internally at libv4l.
Note that an API for enumerating available /dev/video nodes would also
be a welcome addition to libv4l2.
This comes with a bonus from the sysfs enum approach. Of course if the udev
rules are not doing weird things like creating video devices under /dev/v4l
(that happens on some distros).
Yet, it makes sense to add a method there that will seek for the device nodes
and return /dev/video0 or /dev/v4l/video0 depending on how the distro is
using it.
Some distros even use both. For example, at Fedora 15 and RHEL6, this is
currently:
/dev/v4l/
├── by-id
│ └── usb-2040_WinTV_USB2_0002819348-video-index0 - ../../video0
└── by-path
└── pci-:00:1d.7-usb-0:7:1.0-video-index0 - ../../video0
/dev/video0
On RHEL5, it is just:
/dev/video0
The last time I used Mandriva (3 years ago), they used to have it at just
/dev/v4l/video0. Not sure what they're doing currently. I think that
Ubuntu/Debian just use /dev/video0.
Anyways I think we're are currently
doing this the wrong way up. We should first discuss what such an API
should look like and then implement it. Hopefully we can re-use a lot
of the existing code when we do this, but I think it is better
to first design the API and then write code to the API, the current
API at least to me feels somewhat like an API written around existing
code rather then the other way around.
No, was just the opposite: the API were designed to fulfil the needs by
the alsa streaming methods implemented by Devin at tvtime:
int alsa_thread_startup(const char *pdevice, const char *cdevice);
The two arguments are the alsa playback device and the alsa capture device.
the API were designed around that, to do something like:
struct some_opaque_struct *opaque = discover_media_devices();
alsa_playback = alsa_playback(opaque);
alsa_capture = alsa_capture(opaque);
alsa_thread_startup(alsa_playback, alsa_capture);
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Le mardi 24 mai 2011 17:09:45 Mauro Carvalho Chehab, vous avez écrit : If we do that, then all other places where the association between an alsa device and a video4linux node is needed will need to copy it, and we'll have a fork. Also, we'll keep needing it at v4l-utils, as it is now needed by the new version of v4l2-sysfs-path tool. Btw, this lib were created due to a request from the vlc maintainer that something like that would be needed. After finishing it, I decided to add it at xawtv in order to have an example about how to use it. Hmm errm, I said VLC would need to be able to match a V4L2 device to an ALSA input (where applicable). Currently, V4L2 devices are enumerated with (lib)udev though. I am not very clear how v4l2-utils fits there (and oh, ALSA is a bitch for udev-hotplugging but I'm getting side tracked). I guess I misunderstood that /dev/media would logically group related devices. Now I guess it is _solely_ intended to plug DSPs together à la OpenMAX IL. Sorry about that. Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). I'm not a big fan or exporting the rest of stuff at libv4l2util.a either, but I think that at least the get_media_devices stuff should be exported somewhere, maybe as part of libv4l. Should it be exposed as a udev device attribute instead then? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Le samedi 28 mai 2011 15:44:52 Mauro Carvalho Chehab, vous avez écrit : int libv4l2_get_associated_devive(int fd, enum libv4l2_associated_device_types type, ...); Where fd is the fd of an open /dev/video node, and ... is a param through which the device gets returned (I guess a char * to a buffer of MAX_PATH length where the device name gets stored, this could be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc. Using the fd will be more complex, as we'll loose the device node (is there a glibc way to get the device path from the fd?). Well, we may associate the fd descriptor with the device node internally at libv4l. Not really. fstat() can tell you fd is a character device, and provide the major and minor though. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 28-05-2011 09:44, Mauro Carvalho Chehab escreveu: Anyways I think we're are currently doing this the wrong way up. We should first discuss what such an API should look like and then implement it. Hopefully we can re-use a lot of the existing code when we do this, but I think it is better to first design the API and then write code to the API, the current API at least to me feels somewhat like an API written around existing code rather then the other way around. No, was just the opposite: the API were designed to fulfil the needs by the alsa streaming methods implemented by Devin at tvtime: int alsa_thread_startup(const char *pdevice, const char *cdevice); The two arguments are the alsa playback device and the alsa capture device. the API were designed around that, to do something like: struct some_opaque_struct *opaque = discover_media_devices(); alsa_playback = alsa_playback(opaque); alsa_capture = alsa_capture(opaque); alsa_thread_startup(alsa_playback, alsa_capture); free_media_devices(opaque); PS.: I'm not using the real names/arguments at the above, to keep the example simpler and clearer. The actual code is not that different from the above: struct media_devices *md; unsigned int size = 0; char *alsa_cap, *alsa_out, *p; char *video_dev = /dev/video0; md = discover_media_devices(size); p = strrchr(video_dev, '/'); alsa_cap = get_first_alsa_cap_device(md, size, p + 1); alsa_out = get_first_no_video_out_device(md, size); if (alsa_cap alsa_out) alsa_handler(alsa_out, alsa_cap); free_media_devices(md, size); ... fd = open(video_dev, rw); I decided to re-organize the way the API will handle the devices, in order to make clearer that the internal struct should be opaque to the applications using the library [1]. [1] http://git.linuxtv.org/v4l-utils.git?a=commitdiff;h=435f4ba896f76d92a800a2089e06618d8c3d93f0 Now, the functions will just return a void pointer that is used as a parameter for the other functions. So, the typical usecase is, currently: void *md; char *alsa_playback, *alsa_capture, *p; md = discover_media_devices(); if (!md) return; alsa_capture = get_first_alsa_cap_device(md, video_dev); alsa_playback = get_first_no_video_out_device(md); if (alsa_capture alsa_playback) alsa_handler(alsa_playback, alsa_capture); free_media_devices(md); I'll be working on improving the API, in order to read the uevent information from the media nodes (were device major/minor info are stored) and to associate a device with its file descriptor. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 28-05-2011 09:55, Rémi Denis-Courmont escreveu: Le mardi 24 mai 2011 17:09:45 Mauro Carvalho Chehab, vous avez écrit : If we do that, then all other places where the association between an alsa device and a video4linux node is needed will need to copy it, and we'll have a fork. Also, we'll keep needing it at v4l-utils, as it is now needed by the new version of v4l2-sysfs-path tool. Btw, this lib were created due to a request from the vlc maintainer that something like that would be needed. After finishing it, I decided to add it at xawtv in order to have an example about how to use it. Hmm errm, I said VLC would need to be able to match a V4L2 device to an ALSA input (where applicable). Currently, V4L2 devices are enumerated with (lib)udev though. I am not very clear how v4l2-utils fits there (and oh, ALSA is a bitch for udev-hotplugging but I'm getting side tracked). Once you have a V4L2 device, it will use something similar to (lib)udev to get the associated alsa device for that video input. I guess I misunderstood that /dev/media would logically group related devices. Now I guess it is _solely_ intended to plug DSPs together à la OpenMAX IL. Sorry about that. Although people is thinking and discussing about using it also on other subsystems, it is currently limited to video4linux only. As you said, the current focus is to plug DSPs. Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). I'm not a big fan or exporting the rest of stuff at libv4l2util.a either, but I think that at least the get_media_devices stuff should be exported somewhere, maybe as part of libv4l. Should it be exposed as a udev device attribute instead then? An udev attribute can be added to allow such association on devices where both audio and video are handled by a driver at /drivers/media (I'm actually thinking on using udev uevent instead, as there's nothing that you can control with it). This won't cover 100% of the cases, as some devices just provide a standard Usb Audio Class for audio. So, the standard driver (snd-usb-audio) will handle the audio part without knowing anything about the video part of the device. The current library will handle such case by detecting that both audio and video nodes belong to the same physical device. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 28-05-2011 10:01, Rémi Denis-Courmont escreveu: Le samedi 28 mai 2011 15:44:52 Mauro Carvalho Chehab, vous avez écrit : int libv4l2_get_associated_devive(int fd, enum libv4l2_associated_device_types type, ...); Where fd is the fd of an open /dev/video node, and ... is a param through which the device gets returned (I guess a char * to a buffer of MAX_PATH length where the device name gets stored, this could be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc. Using the fd will be more complex, as we'll loose the device node (is there a glibc way to get the device path from the fd?). Well, we may associate the fd descriptor with the device node internally at libv4l. Not really. fstat() can tell you fd is a character device, and provide the major and minor though. Yeah, major/minor should be enough to associate it with the device info. The library will need to read the uevent information also, to get the device major/minor, but this should work properly. I'll write a method for the library to allow using the file descriptor instead of the file name. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
On Saturday, May 28, 2011 14:17:25 Mauro Carvalho Chehab wrote: Em 26-05-2011 03:53, Hans Verkuil escreveu: On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I wanted to do a review of this library, but Devin did it for me in his comments below. I completely agree with his comments. Once I have all the control framework stuff that is in my queue done, then I want to go through as many drivers as I can and bring them all up to the latest V4L2 standards (using v4l2-compliance to verify correctness). It is my intention to create some helper functions to implement a MC node for these simple legacy drivers. Eventually all V4L drivers should have a MC node. Converting all devices to use MC won't help, as the alsa device is implemented on some cases by independent drivers (snd-usb-alsa). As I said before, forcing all drivers to implement MC is silly. They just don't need it. Let's focus the MC stuff where it really belongs: SoC designs and very complex devices, were you should need to know and to change the internal routes and V4L2 API is not enough for it. In general I hate inconsistent behavior between drivers (frankly, it's always been a significant problem within V4L in particular). So I don't think it is silly at all to roll out the MC with the V4L subsystem. Writing a library like the one proposed here would then be much easier and it would function as a front-end for the MC. The design of the library methods should be independent of MC or sysfs. That's what I did: the methods there provide the basic information about the media devices without exporting sysfs struct to it. Once we have the library stable, it can be extended to also implement device discovery via MC (or even using both). Good. Yet, MC is an optional feature, and still not ready to handle inter-subsystem dependencies. As there isn't even a single patch adding MC API for sound or dvb, it is clear that it will take at least 2 development kernel cycles (e. g. about 6 months) for this to start happening. In other words, you're arguing against using what's currently provided by the Kernel, on a standard way, in favour of something that will take at least 6 months having the basic API added for the other subsystems to be able to report their device trees, plus the time to port all drivers to use it. This doesn't sound like a good plan to me. I agree with that. 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. We want the same thing, but this needs a proper design review if we want to have applications use this effectively and if it is to be extended to use the MC. Regards, Hans Once having MC completed, an optional extension to the library may allow its usage also for MC device info methods, where available at the driver(s). The last few months I wasn't able to really spend the time on V4L that I wanted, but that is changing for the better. 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 -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 28-05-2011 12:24, Hans Verkuil escreveu: On Saturday, May 28, 2011 14:17:25 Mauro Carvalho Chehab wrote: Em 26-05-2011 03:53, Hans Verkuil escreveu: On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I wanted to do a review of this library, but Devin did it for me in his comments below. I completely agree with his comments. Once I have all the control framework stuff that is in my queue done, then I want to go through as many drivers as I can and bring them all up to the latest V4L2 standards (using v4l2-compliance to verify correctness). It is my intention to create some helper functions to implement a MC node for these simple legacy drivers. Eventually all V4L drivers should have a MC node. Converting all devices to use MC won't help, as the alsa device is implemented on some cases by independent drivers (snd-usb-alsa). As I said before, forcing all drivers to implement MC is silly. They just don't need it. Let's focus the MC stuff where it really belongs: SoC designs and very complex devices, were you should need to know and to change the internal routes and V4L2 API is not enough for it. In general I hate inconsistent behavior between drivers (frankly, it's always been a significant problem within V4L in particular). So I don't think it is silly at all to roll out the MC with the V4L subsystem. Adding support for an unneeded API just to provide a consistent behaviour is silly. This is the same as requiring that all V4L devices to add support for the DVB API even if they don't need it. Writing a library like the one proposed here would then be much easier and it would function as a front-end for the MC. The design of the library methods should be independent of MC or sysfs. That's what I did: the methods there provide the basic information about the media devices without exporting sysfs struct to it. Once we have the library stable, it can be extended to also implement device discovery via MC (or even using both). Good. Yet, MC is an optional feature, and still not ready to handle inter-subsystem dependencies. As there isn't even a single patch adding MC API for sound or dvb, it is clear that it will take at least 2 development kernel cycles (e. g. about 6 months) for this to start happening. In other words, you're arguing against using what's currently provided by the Kernel, on a standard way, in favour of something that will take at least 6 months having the basic API added for the other subsystems to be able to report their device trees, plus the time to port all drivers to use it. This doesn't sound like a good plan to me. I agree with that. 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. We want the same thing, but this needs a proper design review if we want to have applications use this effectively and if it is to be extended to use the MC. The time to propose an RFC is about the same time as writing some patches. Having some code is better, as it allow people to test it and review in the form of patches improving it. As I'm doing it on my spare time, I'll take the faster approach. Feel free to contribute. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
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.
1) Media enumberation library
==
/**
* enum device_type - Enumerates the type for each device
*
* The device_type is used to sort the media devices array.
* So, the order is relevant. The first device should be
* V4L_VIDEO.
*/
enum device_type {
UNKNOWN = 65535,
NONE= 65534,
V4L_VIDEO = 0,
V4L_VBI,
DVB_FRONTEND,
DVB_DEMUX,
DVB_DVR,
DVB_NET,
DVB_CA,
/* TODO: Add dvb full-featured nodes */
SND_CARD,
SND_CAP,
SND_OUT,
SND_CONTROL,
SND_HW,
};
/**
* discover_media_devices() - Returns a list of the media devices
* @md_size:Returns the size of the media devices found
*
* This function reads the /sys/class nodes for V4L, DVB and sound,
* and returns an opaque desciptor that keeps a list of the devices.
* The fields on this list is opaque, as they can be changed on newer
* releases of this library. So, all access to it should be done via
* a function provided by the API. The devices are ordered by device,
* type and node. At return, md_size is updated.
*/
void *discover_media_devices(void);
/**
* free_media_devices() - Frees the media devices array
*
* @opaque: media devices opaque descriptor
*
* As discover_media_devices() dynamically allocate space for the
* strings, feeing the list requires also to free those data. So,
* the safest and recommended way is to call this function.
*/
void free_media_devices(void *opaque);
/**
* display_media_devices() - prints a list of media devices
*
* @opaque: media devices opaque descriptor
*/
void display_media_devices(void *opaque);
/**
* get_not_associated_device() - Return the next device not associated with
* an specific device type.
*
* @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.
*/
char *get_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
char *seek_device,
enum device_type seek_type);
/**
* get_associated_device() - Return the next device associated with another one
*
* @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 will just search for
* devices of the desired_type.
*/
char *get_not_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
enum device_type not_desired_type);
2) Example showing the typical usecase
===
#include ../libmedia_dev/get_media_devices.h
#include stdio.h
int main(void)
{
void *md;
char *alsa;
md = discover_media_devices();
display_media_devices(md);
alsa = get_associated_device(md, NULL, SND_CAP, video0, V4L_VIDEO);
if (alsa)
printf(Alsa device associated with video0 capture: %s\n,
alsa);
alsa = get_not_associated_device(md, NULL, SND_OUT, V4L_VIDEO);
if (alsa)
printf(Alsa output device: %s\n, alsa);
free_media_devices(md);
return 0;
}
3) Planned improvements
a) To create a new functions similar to get_associated_device, that uses an
opened
file descriptor for device association;
b) provide a method to return /dev names for applications.
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
[RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
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,
MEDIA_V4L_VBI,
MEDIA_DVB_FRONTEND,
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,
};
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);
All discovered devices can be displayed by calling:
void display_media_devices(void *opaque);
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);
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 will just search for
devices of the desired_type.
b) fget_associated_device: returns the next device associated with another one
char *fget_associated_device(void *opaque,
char *last_seek,
enum device_type desired_type,
int fd_seek_device,
enum device_type seek_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
fd_seek_device: file handler for
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I wanted to do a review of this library, but Devin did it for me in his comments below. I completely agree with his comments. Once I have all the control framework stuff that is in my queue done, then I want to go through as many drivers as I can and bring them all up to the latest V4L2 standards (using v4l2-compliance to verify correctness). It is my intention to create some helper functions to implement a MC node for these simple legacy drivers. Eventually all V4L drivers should have a MC node. Writing a library like the one proposed here would then be much easier and it would function as a front-end for the MC. The last few months I wasn't able to really spend the time on V4L that I wanted, but that is changing for the better. Regards, Hans I share Hans' concern on this. This is an API that seems pretty immature, and I worry that it's adoption will cause lots of problems as people expect it to work with a wide variety of tuners. For example, how does the sysfs approach handle PCI boards that have multiple video and audio devices? The sysfs layout will effectively be: PCI DEVICE - video0 - video1 - alsa hw:1,0 - alsa hw:1,1 The approach taken in this library will probably help with the simple cases such as a USB tuner that only has a single video device, audio device, and VBI device. But it's going to fall flat on its face when it comes to devices that have multiple capture sources (since sysfs will represent this as a tree with all the nodes on the same level). Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. Devin -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. Regards, Hans I've basically added there the code that Devin wrote for tvtime, with a few small fixes and with the audio device auto-detection. With this patch, xawtv will now get the alsa device associated with a video device node (if any), and start streaming from it, on a separate thread. As the code is the same as the one at tvtime, it should work at the same devices that are supported there. I tested it only on two em28xx devices: - HVR-950; - WinTV USB-2. It worked with HVR-950, but it didn't work with WinTV USB-2. It seems that snd-usb-audio do something different to set the framerate, that the alsa-stream code doesn't recognize. While I didn't test, I think it probably won't work with saa7134, as the code seems to hardcode the frame rate to 48 kHz, but saa7134 supports only 32 kHz. It would be good to add an option to disable this behavior and to allow manually select the alsa out device, so please send us patches ;) Anyway, patches fixing it and more tests are welcome. The git repositories for xawtv3 and v4l-utils is at: http://git.linuxtv.org/xawtv3.git http://git.linuxtv.org/v4l-utils.git 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 -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi, On 05/24/2011 08:50 AM, Hans Verkuil wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. My I suggest that we instead just copy over the single get_media_devices.c file to xawtv, and not install the not so much a lib lib ? Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). Regards, Hans *) To get a number of libv4l changes which I did recently out there. Once you install it on systems it becomes much harder to change. Regards, Hans I've basically added there the code that Devin wrote for tvtime, with a few small fixes and with the audio device auto-detection. With this patch, xawtv will now get the alsa device associated with a video device node (if any), and start streaming from it, on a separate thread. As the code is the same as the one at tvtime, it should work at the same devices that are supported there. I tested it only on two em28xx devices: - HVR-950; - WinTV USB-2. It worked with HVR-950, but it didn't work with WinTV USB-2. It seems that snd-usb-audio do something different to set the framerate, that the alsa-stream code doesn't recognize. While I didn't test, I think it probably won't work with saa7134, as the code seems to hardcode the frame rate to 48 kHz, but saa7134 supports only 32 kHz. It would be good to add an option to disable this behavior and to allow manually select the alsa out device, so please send us patches ;) Anyway, patches fixing it and more tests are welcome. The git repositories for xawtv3 and v4l-utils is at: http://git.linuxtv.org/xawtv3.git http://git.linuxtv.org/v4l-utils.git 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 -- 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 -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 04:21, Hans de Goede escreveu: Hi, My I suggest that we instead just copy over the single get_media_devices.c file to xawtv, and not install the not so much a lib lib ? If we do that, then all other places where the association between an alsa device and a video4linux node is needed will need to copy it, and we'll have a fork. Also, we'll keep needing it at v4l-utils, as it is now needed by the new version of v4l2-sysfs-path tool. Btw, this lib were created due to a request from the vlc maintainer that something like that would be needed. After finishing it, I decided to add it at xawtv in order to have an example about how to use it. Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). I'm not a big fan or exporting the rest of stuff at libv4l2util.a either, but I think that at least the get_media_devices stuff should be exported somewhere, maybe as part of libv4l. Anyway, as you're releasing today a new v4l-utils, I agree that it is too early to add such library, as it is still experimental. I'm not considering make any new xawtv release those days, so I'm OK to postpone it. I'll commit a few patches commenting the install procedure for now, re-adding it after the release, for those that want to experiment it with xawtv with the new support. 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 03:50, Hans Verkuil escreveu: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. With respect to the other stuff inside libv4l2util, they are there for a long time, and not much has changed since them. Yet, I'm not a big fan of exporting them, as they may not be useful to other applications. With respect to the new API I've added, there are not much to change at the get_media_devices stuff. It has just 5 methods: one to retrieve info, one to free data, one to display all info (used by v4l2-sysfs-path tool), and two for getting the alsa devices. Of course, new functions can always be added, and the structs might need more fields. I've added a proper documentation for it. I also added a macro with a version number for the library. This will help userspace apps that would use it to check for the version number. That's said, I'm moving the get_media_devices into a new library, to avoid mixing it with other stuff. As I said, I'm OK to postpone the install to happen for the -next version of v4l2-utils, so I've commented for now the install scripts for it. Once you install it on systems it becomes much harder to change. Regards, Hans 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: [ANNOUNCE] experimental alsa stream support at xawtv3
On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I share Hans' concern on this. This is an API that seems pretty immature, and I worry that it's adoption will cause lots of problems as people expect it to work with a wide variety of tuners. For example, how does the sysfs approach handle PCI boards that have multiple video and audio devices? The sysfs layout will effectively be: PCI DEVICE - video0 - video1 - alsa hw:1,0 - alsa hw:1,1 The approach taken in this library will probably help with the simple cases such as a USB tuner that only has a single video device, audio device, and VBI device. But it's going to fall flat on its face when it comes to devices that have multiple capture sources (since sysfs will represent this as a tree with all the nodes on the same level). Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi,
On 05/24/2011 04:09 PM, Mauro Carvalho Chehab wrote:
Em 24-05-2011 04:21, Hans de Goede escreveu:
Hi,
My I suggest that we instead just copy over the single get_media_devices.c
file to xawtv, and not install the not so much a lib lib ?
If we do that, then all other places where the association between an alsa
device
and a video4linux node is needed will need to copy it, and we'll have a fork.
Also, we'll keep needing it at v4l-utils, as it is now needed by the new version
of v4l2-sysfs-path tool.
Btw, this lib were created due to a request from the vlc maintainer that
something
like that would be needed. After finishing it, I decided to add it at xawtv in
order
to have an example about how to use it.
I'm not saying that this is not useful to have, I'm just worried about
exporting the API before it has had any chance to stabilize, and about
also throwing in the other random libv4l2util bits.
Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I
consider it unpolite to revert other peoples commits, so I would prefer for you
to revert the install libv4l2util.a patch yourself. But if you don't (or don't
get around to doing it before I do the release), I will revert it, as this
clearly needs more discussion before making it into an official release
tarbal (we can always re-introduce the patch after the release).
I'm not a big fan or exporting the rest of stuff at libv4l2util.a either
Glad we agree on that :)
but I
think that at least the get_media_devices stuff should be exported somewhere,
Agreed.
maybe as part of libv4l.
That would be a logical place to put it, otoh currently libv4l mostly mimics the
raw /dev/video# node API, so adding this API is not a logical fit there ...
It may make more sense to have something in libv4l2 like:
enum libv4l2_associated_device_types {
libv4l2_alsa_input,
libv4l2_alsa_output,
libv4l2_vbi
};
int libv4l2_get_associated_devive(int fd, enum libv4l2_associated_device_types
type, ...);
Where fd is the fd of an open /dev/video node, and ... is a param through
which the device gets returned (I guess a char * to a buffer of MAX_PATH
length where the device name gets stored, this could
be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc.
Note that an API for enumerating available /dev/video nodes would also
be a welcome addition to libv4l2. Anyways I think we're are currently
doing this the wrong way up. We should first discuss what such an API
should look like and then implement it. Hopefully we can re-use a lot
of the existing code when we do this, but I think it is better
to first design the API and then write code to the API, the current
API at least to me feels somewhat like an API written around existing
code rather then the other way around.
Anyway, as you're releasing today a new v4l-utils, I agree that it is too early
to add such library, as it is still experimental. I'm not considering make any
new xawtv release those days, so I'm OK to postpone it.
I'll commit a few patches commenting the install procedure for now, re-adding it
after the release, for those that want to experiment it with xawtv with the new
support.
Thanks!
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: [ANNOUNCE] experimental alsa stream support at xawtv3
--- On Tue, 24/5/11, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 To: Hans Verkuil hverk...@xs4all.nl Cc: Mauro Carvalho Chehab mche...@redhat.com, Linux Media Mailing List linux-media@vger.kernel.org Date: Tuesday, 24 May, 2011, 16:57 On Tue, May 24, 2011 at 2:50 AM, Hans Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). Are there mechanisms for device-locking in the v4l api? With my 2 hybrid saa7134 cards I have observed exactly this issues in Mythtv and also in xawtv and kaffeine At the moment I disable one device via additional card definitions and modprobe-parameters, so that the other one is alone and only one app gets control over the tuner. But this driver (saa7134) seams not even lock the /dev/video0 correctly, as starting xawtv twice renders the card inoperable and forces rebooting to get the card working again... Is there a good starting point to implement the locking? I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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 Emil -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. I've basically added there the code that Devin wrote for tvtime, with a few small fixes and with the audio device auto-detection. If any of these fixes you made apply to the code in general, I will be happy to merge them into our tvtime tree. Let me know. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 23-05-2011 17:19, Devin Heitmueller escreveu:
On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils)
during the weekend, I decided to add alsa support also on xawtv3, basically
to provide a real usecase example. Of course, for it to work, it needs the
very latest v4l2-utils version from the git tree.
I've basically added there the code that Devin wrote for tvtime, with a few
small fixes and with the audio device auto-detection.
If any of these fixes you made apply to the code in general, I will be
happy to merge them into our tvtime tree. Let me know.
They are small. As I changed the non-public stuff to static, some warnings
happened. I also added some logic there to avoid re-starting the thread when
it is active, to allow stopping a stream and to check if the stream is running.
The enclosed patch contains the diff from your version. As I'm using it at
xawtv,
I've removed tvtime_ prefix from the calls, so you'll probably need to fix it,
or
to change the function call inside tvtime.
--- a/alsa_stream.c
+++ b/alsa_stream.c
@@ -2,7 +2,7 @@
* tvtime ALSA device support
*
* Copyright (c) by Devin Heitmueller dheitmuel...@kernellabs.com
- *
+ *
* Derived from the alsa-driver test tool latency.c:
*Copyright (c) by Jaroslav Kysela pe...@perex.cz
*
@@ -23,6 +23,10 @@
*
*/
+#include config.h
+
+#ifdef HAVE_ALSA_ASOUNDLIB_H
+
#include stdio.h
#include stdlib.h
#include string.h
@@ -33,6 +37,11 @@
#include alsa/asoundlib.h
#include sys/time.h
#include math.h
+#include alsa_stream.h
+
+/* Private vars to control alsa thread status */
+static int alsa_is_running = 0;
+static int stop_alsa = 0;
snd_output_t *output = NULL;
@@ -43,12 +52,12 @@ struct final_params {
int channels;
};
-int setparams_stream(snd_pcm_t *handle,
-snd_pcm_hw_params_t *params,
-snd_pcm_format_t format,
-int channels,
-int rate,
-const char *id)
+static int setparams_stream(snd_pcm_t *handle,
+ snd_pcm_hw_params_t *params,
+ snd_pcm_format_t format,
+ int channels,
+ int rate,
+ const char *id)
{
int err;
unsigned int rrate;
@@ -66,14 +75,14 @@ int setparams_stream(snd_pcm_t *handle,
err = snd_pcm_hw_params_set_access(handle, params,
SND_PCM_ACCESS_RW_INTERLEAVED);
if (err 0) {
- printf(Access type not available for %s: %s\n, id,
+ printf(Access type not available for %s: %s\n, id,
snd_strerror(err));
return err;
}
err = snd_pcm_hw_params_set_format(handle, params, format);
if (err 0) {
- printf(Sample format not available for %s: %s\n, id,
+ printf(Sample format not available for %s: %s\n, id,
snd_strerror(err));
return err;
}
@@ -129,10 +138,10 @@ int setparams_bufsize(snd_pcm_t *handle,
return 0;
}
-int setparams_set(snd_pcm_t *handle,
- snd_pcm_hw_params_t *params,
- snd_pcm_sw_params_t *swparams,
- const char *id)
+static int setparams_set(snd_pcm_t *handle,
+snd_pcm_hw_params_t *params,
+snd_pcm_sw_params_t *swparams,
+const char *id)
{
int err;
@@ -181,7 +190,7 @@ int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
snd_pcm_format_t format,
snd_pcm_sw_params_t *p_swparams, *c_swparams;
snd_pcm_uframes_t p_size, c_size, p_psize, c_psize;
unsigned int p_time, c_time;
-
+
snd_pcm_hw_params_alloca(p_params);
snd_pcm_hw_params_alloca(c_params);
snd_pcm_hw_params_alloca(pt_params);
@@ -258,7 +267,7 @@ int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
snd_pcm_format_t format,
printf(final config\n);
snd_pcm_dump_setup(phandle, output);
snd_pcm_dump_setup(chandle, output);
-printf(Parameters are %iHz, %s, %i channels\n, rate,
+printf(Parameters are %iHz, %s, %i channels\n, rate,
snd_pcm_format_name(format), channels);
fflush(stdout);
#endif
@@ -270,25 +279,8 @@ int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
snd_pcm_format_t format,
return 0;
}
-void setscheduler(void)
-{
-struct sched_param sched_param;
-
-if (sched_getparam(0, sched_param) 0) {
- printf(Scheduler getparam failed...\n);
- return;
-}
-sched_param.sched_priority = sched_get_priority_max(SCHED_RR);
-if (!sched_setscheduler(0, SCHED_RR, sched_param)) {
- printf(Scheduler set to Round Robin with priority %i...\n,
sched_param.sched_priority);
- fflush(stdout);
- return;
-}
-printf(!!!Scheduler set to Round Robin with priority %i FAILED!!!\n,
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 23-05-2011 17:19, Devin Heitmueller escreveu:
On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils)
during the weekend, I decided to add alsa support also on xawtv3, basically
to provide a real usecase example. Of course, for it to work, it needs the
very latest v4l2-utils version from the git tree.
I've basically added there the code that Devin wrote for tvtime, with a few
small fixes and with the audio device auto-detection.
If any of these fixes you made apply to the code in general, I will be
happy to merge them into our tvtime tree. Let me know.
The code bellow will probably be more useful for you. It basically adds alsa
device autodetection. The patch is against xawtv source code, but the code
there is generic enough to be added on tvtime.
Have fun!
Mauro
diff --git a/x11/xt.c b/x11/xt.c
index 81658a0..7cf7281 100644
--- a/x11/xt.c
+++ b/x11/xt.c
@@ -22,7 +22,9 @@
#include netinet/in.h
#include netdb.h
#include pthread.h
-
+#ifdef HAVE_LIBV42LUTIL
+# include get_media_devices.h
+#endif
#if defined(__linux__)
# include sys/ioctl.h
#include linux/types.h
@@ -58,6 +60,7 @@
#include blit.h
#include parseconfig.h
#include event.h
+#include alsa_stream.h
/* jwz */
#include remote.h
@@ -1377,6 +1380,11 @@ grabber_init()
{
struct ng_video_fmt screen;
void *base = NULL;
+#if defined(HAVE_V4L2UTIL) defined(HAVE_ALSA)
+struct media_devices *md;
+unsigned int size = 0;
+char *alsa_cap, *alsa_out, *p;
+#endif
memset(screen,0,sizeof(screen));
#ifdef HAVE_LIBXXF86DGA
@@ -1417,6 +1425,22 @@ grabber_init()
}
f_drv = drv-capabilities(h_drv);
add_attrs(drv-list_attrs(h_drv));
+
+#if defined(HAVE_V4L2UTIL) defined(HAVE_ALSA)
+/* Start audio capture thread */
+md = discover_media_devices(size);
+p = strrchr(args.device, '/');
+if (!p)
+ p = args.device;
+alsa_cap = get_first_alsa_cap_device(md, size, p + 1);
+alsa_out = get_first_no_video_out_device(md, size);
+
+printf(Alsa devices: cap: %s (%s), out: %s\n, alsa_cap, args.device,
alsa_out);
+
+if (alsa_cap alsa_out)
+alsa_thread_startup(alsa_out, alsa_cap);
+free_media_devices(md, size);
+#endif
}
void
--
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
