* [ANNOUNCE] experimental alsa stream support at xawtv3 @ 2011-05-23 20:17 Mauro Carvalho Chehab 2011-05-23 20:19 ` Devin Heitmueller 2011-05-24 6:50 ` Hans Verkuil 0 siblings, 2 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-23 20:17 UTC (permalink / raw) To: Linux Media Mailing List; +Cc: Devin Heitmueller 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. 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-23 20:17 [ANNOUNCE] experimental alsa stream support at xawtv3 Mauro Carvalho Chehab @ 2011-05-23 20:19 ` Devin Heitmueller 2011-05-23 20:30 ` Mauro Carvalho Chehab 2011-05-23 20:32 ` Mauro Carvalho Chehab 2011-05-24 6:50 ` Hans Verkuil 1 sibling, 2 replies; 39+ messages in thread From: Devin Heitmueller @ 2011-05-23 20:19 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab <mchehab@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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-23 20:19 ` Devin Heitmueller @ 2011-05-23 20:30 ` Mauro Carvalho Chehab 2011-05-23 20:32 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-23 20:30 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Linux Media Mailing List Em 23-05-2011 17:19, Devin Heitmueller escreveu: > On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab > <mchehab@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 <dheitmueller@kernellabs.com> - * + * * Derived from the alsa-driver test tool latency.c: * Copyright (c) by Jaroslav Kysela <perex@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", sched_param.sched_priority); -} - -snd_pcm_sframes_t readbuf(snd_pcm_t *handle, char *buf, long len, - size_t *frames, size_t *max) +static snd_pcm_sframes_t readbuf(snd_pcm_t *handle, char *buf, long len, + size_t *frames, size_t *max) { snd_pcm_sframes_t r; @@ -306,8 +298,8 @@ snd_pcm_sframes_t readbuf(snd_pcm_t *handle, char *buf, long len, return r; } -snd_pcm_sframes_t writebuf(snd_pcm_t *handle, char *buf, long len, - size_t *frames) +static snd_pcm_sframes_t writebuf(snd_pcm_t *handle, char *buf, long len, + size_t *frames) { snd_pcm_sframes_t r; @@ -352,7 +344,7 @@ int startup_capture(snd_pcm_t *phandle, snd_pcm_t *chandle, return 0; } -int tvtime_alsa_stream(const char *pdevice, const char *cdevice) +static int alsa_stream(const char *pdevice, const char *cdevice) { snd_pcm_t *phandle, *chandle; char *buffer; @@ -370,20 +362,20 @@ int tvtime_alsa_stream(const char *pdevice, const char *cdevice) } // setscheduler(); - + printf("Playback device is %s\n", pdevice); printf("Capture device is %s\n", cdevice); /* Open the devices */ if ((err = snd_pcm_open(&phandle, pdevice, SND_PCM_STREAM_PLAYBACK, SND_PCM_NONBLOCK)) < 0) { - printf("Cannot open ALSA Playback device %s: %s\n", pdevice, + printf("Cannot open ALSA Playback device %s: %s\n", pdevice, snd_strerror(err)); return 0; } if ((err = snd_pcm_open(&chandle, cdevice, SND_PCM_STREAM_CAPTURE, SND_PCM_NONBLOCK)) < 0) { - printf("Cannot open ALSA Capture device %s: %s\n", + printf("Cannot open ALSA Capture device %s: %s\n", cdevice, snd_strerror(err)); return 0; } @@ -406,10 +398,11 @@ int tvtime_alsa_stream(const char *pdevice, const char *cdevice) return 1; } - startup_capture(phandle, chandle, format, buffer, negotiated.latency, + alsa_is_running = 1; + startup_capture(phandle, chandle, format, buffer, negotiated.latency, negotiated.channels); - while (1) { + while (!stop_alsa) { in_max = 0; /* use poll to wait for next event */ @@ -452,6 +445,8 @@ int tvtime_alsa_stream(const char *pdevice, const char *cdevice) snd_pcm_close(phandle); snd_pcm_close(chandle); + + alsa_is_running = 0; return 0; } @@ -460,13 +455,22 @@ struct input_params { const char *cdevice; }; -void *tvtime_alsa_thread_entry(void *whatever) +static void *alsa_thread_entry(void *whatever) { struct input_params *inputs = (struct input_params *) whatever; - tvtime_alsa_stream(inputs->pdevice, inputs->cdevice); + + printf("Starting copying alsa stream from %s to %s\n", inputs->cdevice, inputs->pdevice); + alsa_stream(inputs->pdevice, inputs->cdevice); + printf("Alsa stream stopped\n"); + + return whatever; } -int tvtime_alsa_thread_startup(const char *pdevice, const char *cdevice) +/************************************************************************* + Public functions + *************************************************************************/ + +int alsa_thread_startup(const char *pdevice, const char *cdevice) { int ret; pthread_t thread; @@ -486,17 +490,27 @@ int tvtime_alsa_thread_startup(const char *pdevice, const char *cdevice) inputs->pdevice = strdup(pdevice); inputs->cdevice = strdup(cdevice); + if (alsa_is_running) { + stop_alsa = 1; + while ((volatile int)alsa_is_running) + usleep(10); + } + + stop_alsa = 0; + ret = pthread_create(&thread, NULL, - &tvtime_alsa_thread_entry, (void *) inputs); + &alsa_thread_entry, (void *) inputs); return ret; } -#ifdef TVTIME_ALSA_DEBUGGING -/* This allows the alsa_stream.c to be a standalone binary for debugging */ - int main(int argc, char *argv[]) +void alsa_thread_stop(void) { - char *pdevice = "hw:0,0"; - char *cdevice = "hw:1,0"; - tvtime_alsa_stream(pdevice, cdevice); + stop_alsa = 1; } + +int alsa_thread_is_running(void) +{ + return alsa_is_running; +} + #endif diff --git a/common/alsa_stream.h b/common/alsa_stream.h index 8572c8b..b8d468c 100644 --- a/alsa_stream.h +++ b/alsa_stream.h @@ -1 +1,3 @@ -int tvtime_alsa_thread_startup(char *pdevice, char *cdevice); +int alsa_thread_startup(const char *pdevice, const char *cdevice); +void alsa_thread_stop(void); +int alsa_thread_is_running(void); ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-23 20:19 ` Devin Heitmueller 2011-05-23 20:30 ` Mauro Carvalho Chehab @ 2011-05-23 20:32 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-23 20:32 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Linux Media Mailing List Em 23-05-2011 17:19, Devin Heitmueller escreveu: > On Mon, May 23, 2011 at 4:17 PM, Mauro Carvalho Chehab > <mchehab@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 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-23 20:17 [ANNOUNCE] experimental alsa stream support at xawtv3 Mauro Carvalho Chehab 2011-05-23 20:19 ` Devin Heitmueller @ 2011-05-24 6:50 ` Hans Verkuil 2011-05-24 7:21 ` Hans de Goede ` (2 more replies) 1 sibling, 3 replies; 39+ messages in thread From: Hans Verkuil @ 2011-05-24 6:50 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List, Devin Heitmueller 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 6:50 ` Hans Verkuil @ 2011-05-24 7:21 ` Hans de Goede 2011-05-24 14:09 ` Mauro Carvalho Chehab 2011-05-24 14:15 ` Mauro Carvalho Chehab 2011-05-24 14:57 ` Devin Heitmueller 2 siblings, 1 reply; 39+ messages in thread From: Hans de Goede @ 2011-05-24 7:21 UTC (permalink / raw) To: Hans Verkuil Cc: Mauro Carvalho Chehab, Linux Media Mailing List, Devin Heitmueller 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 majordomo@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 7:21 ` Hans de Goede @ 2011-05-24 14:09 ` Mauro Carvalho Chehab 2011-05-24 15:55 ` Hans de Goede 2011-05-28 12:55 ` Rémi Denis-Courmont 0 siblings, 2 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-24 14:09 UTC (permalink / raw) To: Hans de Goede; +Cc: Hans Verkuil, Linux Media Mailing List, Devin Heitmueller 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 14:09 ` Mauro Carvalho Chehab @ 2011-05-24 15:55 ` Hans de Goede 2011-05-28 12:44 ` Mauro Carvalho Chehab 2011-05-28 12:55 ` Rémi Denis-Courmont 1 sibling, 1 reply; 39+ messages in thread From: Hans de Goede @ 2011-05-24 15:55 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Hans Verkuil, Linux Media Mailing List, Devin Heitmueller 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 15:55 ` Hans de Goede @ 2011-05-28 12:44 ` Mauro Carvalho Chehab 2011-05-28 13:01 ` Rémi Denis-Courmont 2011-05-28 14:10 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 12:44 UTC (permalink / raw) To: Hans de Goede; +Cc: Hans Verkuil, Linux Media Mailing List, Devin Heitmueller 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-0000: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); 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"); >> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 12:44 ` Mauro Carvalho Chehab @ 2011-05-28 13:01 ` Rémi Denis-Courmont 2011-05-28 14:41 ` Mauro Carvalho Chehab 2011-05-28 14:10 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 39+ messages in thread From: Rémi Denis-Courmont @ 2011-05-28 13:01 UTC (permalink / raw) To: Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 13:01 ` Rémi Denis-Courmont @ 2011-05-28 14:41 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 14:41 UTC (permalink / raw) To: Rémi Denis-Courmont; +Cc: Linux Media Mailing List 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 12:44 ` Mauro Carvalho Chehab 2011-05-28 13:01 ` Rémi Denis-Courmont @ 2011-05-28 14:10 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 14:10 UTC (permalink / raw) To: Hans de Goede; +Cc: Hans Verkuil, Linux Media Mailing List, Devin Heitmueller 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 14:09 ` Mauro Carvalho Chehab 2011-05-24 15:55 ` Hans de Goede @ 2011-05-28 12:55 ` Rémi Denis-Courmont 2011-05-28 14:39 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 39+ messages in thread From: Rémi Denis-Courmont @ 2011-05-28 12:55 UTC (permalink / raw) To: Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 12:55 ` Rémi Denis-Courmont @ 2011-05-28 14:39 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 14:39 UTC (permalink / raw) To: Rémi Denis-Courmont; +Cc: Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 6:50 ` Hans Verkuil 2011-05-24 7:21 ` Hans de Goede @ 2011-05-24 14:15 ` Mauro Carvalho Chehab 2011-05-24 14:57 ` Devin Heitmueller 2 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-24 14:15 UTC (permalink / raw) To: Hans Verkuil; +Cc: Linux Media Mailing List, Devin Heitmueller 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 6:50 ` Hans Verkuil 2011-05-24 7:21 ` Hans de Goede 2011-05-24 14:15 ` Mauro Carvalho Chehab @ 2011-05-24 14:57 ` Devin Heitmueller 2011-05-26 6:53 ` Hans Verkuil 2011-05-28 12:00 ` Mauro Carvalho Chehab 2 siblings, 2 replies; 39+ messages in thread From: Devin Heitmueller @ 2011-05-24 14:57 UTC (permalink / raw) To: Hans Verkuil; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil <hverkuil@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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 14:57 ` Devin Heitmueller @ 2011-05-26 6:53 ` Hans Verkuil 2011-05-28 12:17 ` Mauro Carvalho Chehab 2011-05-28 12:00 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 39+ messages in thread From: Hans Verkuil @ 2011-05-26 6:53 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List On Tuesday, May 24, 2011 16:57:22 Devin Heitmueller wrote: > On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil <hverkuil@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 > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-26 6:53 ` Hans Verkuil @ 2011-05-28 12:17 ` Mauro Carvalho Chehab 2011-05-28 12:26 ` Hans de Goede 2011-05-28 15:24 ` Hans Verkuil 0 siblings, 2 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 12:17 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List 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 <hverkuil@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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 12:17 ` Mauro Carvalho Chehab @ 2011-05-28 12:26 ` Hans de Goede 2011-05-28 15:24 ` Hans Verkuil 1 sibling, 0 replies; 39+ messages in thread From: Hans de Goede @ 2011-05-28 12:26 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Hans Verkuil, Devin Heitmueller, Linux Media Mailing List 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 Verkuil<hverkuil@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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 12:17 ` Mauro Carvalho Chehab 2011-05-28 12:26 ` Hans de Goede @ 2011-05-28 15:24 ` Hans Verkuil 2011-05-28 16:04 ` Mauro Carvalho Chehab 2011-05-28 16:20 ` Mauro Carvalho Chehab 1 sibling, 2 replies; 39+ messages in thread From: Hans Verkuil @ 2011-05-28 15:24 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Devin Heitmueller, Linux Media Mailing List 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 <hverkuil@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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 15:24 ` Hans Verkuil @ 2011-05-28 16:04 ` Mauro Carvalho Chehab 2011-05-28 16:20 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 16:04 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List 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 <hverkuil@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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 15:24 ` Hans Verkuil 2011-05-28 16:04 ` Mauro Carvalho Chehab @ 2011-05-28 16:20 ` Mauro Carvalho Chehab 2011-05-29 1:01 ` [RFCv2] Add a library to retrieve associated media devices - was: " Mauro Carvalho Chehab 1 sibling, 1 reply; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 16:20 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-28 16:20 ` Mauro Carvalho Chehab @ 2011-05-29 1:01 ` Mauro Carvalho Chehab 2011-05-29 11:19 ` Hans Verkuil 0 siblings, 1 reply; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 1:01 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 the device where the association will be made 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 an open file descriptor 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. 3) Examples with typical usecases ============================== a) Just displaying all media devices: void *md = discover_media_devices(); display_media_devices(md); free_media_devices(md); The devices will be shown at the order they appear at the computer buses. b) For video0, prints the associated alsa capture device(s): void *md = discover_media_devices(); char *devname = NULL, video0 = "/dev/video0"; do { devname = get_associated_device(md, devname, MEDIA_SND_CAP, video0, MEDIA_V4L_VIDEO); if (devname) printf("Alsa capture: %s\n", devname); } while (devname); free_media_devices(md); Note: the video0 string can be declarated as "/dev/video0" or as just "video0", as the search functions will discard any patch on it. c) Get the alsa capture device associated with an opened file descriptor: int fd = open("/dev/video0", O_RDWR); ... void *md = discover_media_devices(); vid = fget_associated_device(md, NULL, MEDIA_SND_CAP, fd, MEDIA_V4L_VIDEO); printf("\n\nAlsa device = %s\n", vid); close(fd); free_media_devices(md); d) Get the mainboard alsa playback devices: char *devname = NULL; void *md = discover_media_devices(); do { devname = get_not_associated_device(md, devname, MEDIA_SND_OUT, MEDIA_V4L_VIDEO); if (devname) printf("Alsa playback: %s\n", devname); } while (devname); free_media_devices(md); e) Get all video devices: md = discover_media_devices(); char *vid = NULL; do { vid = get_associated_device(md, vid, MEDIA_V4L_VIDEO, NULL, NONE); if (!vid) break; printf("Video device: %s\n", vid); } while (vid); free_media_devices(md); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 1:01 ` [RFCv2] Add a library to retrieve associated media devices - was: " Mauro Carvalho Chehab @ 2011-05-29 11:19 ` Hans Verkuil 2011-05-29 11:47 ` Andy Walls ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Hans Verkuil @ 2011-05-29 11:19 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 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 the device where the association will > be made > 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 an open file descriptor > > 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. > > 3) Examples with typical usecases > ============================== > > a) Just displaying all media devices: > > void *md = discover_media_devices(); > display_media_devices(md); > free_media_devices(md); > > The devices will be shown at the order they appear at the computer buses. > > b) For video0, prints the associated alsa capture device(s): > > void *md = discover_media_devices(); > char *devname = NULL, video0 = "/dev/video0"; > do { > devname = get_associated_device(md, devname, MEDIA_SND_CAP, > video0, MEDIA_V4L_VIDEO); > if (devname) > printf("Alsa capture: %s\n", devname); > } while (devname); > free_media_devices(md); > > Note: the video0 string can be declarated as "/dev/video0" or as just "video0", > as the search functions will discard any patch on it. > > c) Get the alsa capture device associated with an opened file descriptor: > > int fd = open("/dev/video0", O_RDWR); > ... > void *md = discover_media_devices(); > vid = fget_associated_device(md, NULL, MEDIA_SND_CAP, fd, > MEDIA_V4L_VIDEO); > printf("\n\nAlsa device = %s\n", vid); > close(fd); > free_media_devices(md); > > d) Get the mainboard alsa playback devices: > > char *devname = NULL; > void *md = discover_media_devices(); > do { > devname = get_not_associated_device(md, devname, MEDIA_SND_OUT, > MEDIA_V4L_VIDEO); > if (devname) > printf("Alsa playback: %s\n", devname); > } while (devname); > free_media_devices(md); > > e) Get all video devices: > > md = discover_media_devices(); > > char *vid = NULL; > do { > vid = get_associated_device(md, vid, MEDIA_V4L_VIDEO, > NULL, NONE); > if (!vid) > break; > printf("Video device: %s\n", vid); > } while (vid); > free_media_devices(md); > I did some testing: vivi video nodes do not show up at all. And since there is no concept of 'media hardware' in this API the handling of devices with multiple video nodes (e.g. ivtv) is very poor. One thing that we wanted to do with the MC is to select default nodes for complex hardware. This gives applications a hint as to what is the default video node to use for standard capture/output. This concept can be used here as well. Perhaps we should introduce a 'V4L2_CAP_DEFAULT' capabity that drivers can set? I think this library would also be more useful if it can filter devices: e.g. filter on capture devices or output devices. Actually, I can't immediately think of other useful filters than capture vs output. We also need some way to tell apps that certain devices are mutually exclusive. Even if we cannot tell the app that through sysfs at the moment, this information will become available in the future through the MC, so we should prepare the API for this. Did anyone test what happens when the user renames device nodes using udev rules? I haven't had the chance to test that yet. Regards, Hans ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 11:19 ` Hans Verkuil @ 2011-05-29 11:47 ` Andy Walls 2011-05-29 12:58 ` Mauro Carvalho Chehab 2011-05-29 11:54 ` Hans de Goede 2011-05-29 12:11 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 39+ messages in thread From: Andy Walls @ 2011-05-29 11:47 UTC (permalink / raw) To: Hans Verkuil, Mauro Carvalho Chehab Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede Hans Verkuil <hverkuil@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 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 the device where the association >will >> be made >> 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 an open file >descriptor >> >> 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. > >> >> 3) Examples with typical usecases >> ============================== >> >> a) Just displaying all media devices: >> >> void *md = discover_media_devices(); >> display_media_devices(md); >> free_media_devices(md); >> >> The devices will be shown at the order they appear at the computer >buses. >> >> b) For video0, prints the associated alsa capture device(s): >> >> void *md = discover_media_devices(); >> char *devname = NULL, video0 = "/dev/video0"; >> do { >> devname = get_associated_device(md, devname, MEDIA_SND_CAP, >> video0, MEDIA_V4L_VIDEO); >> if (devname) >> printf("Alsa capture: %s\n", devname); >> } while (devname); >> free_media_devices(md); >> >> Note: the video0 string can be declarated as "/dev/video0" or as just >"video0", >> as the search functions will discard any patch on it. >> >> c) Get the alsa capture device associated with an opened file >descriptor: >> >> int fd = open("/dev/video0", O_RDWR); >> ... >> void *md = discover_media_devices(); >> vid = fget_associated_device(md, NULL, MEDIA_SND_CAP, fd, >> MEDIA_V4L_VIDEO); >> printf("\n\nAlsa device = %s\n", vid); >> close(fd); >> free_media_devices(md); >> >> d) Get the mainboard alsa playback devices: >> >> char *devname = NULL; >> void *md = discover_media_devices(); >> do { >> devname = get_not_associated_device(md, devname, MEDIA_SND_OUT, >> MEDIA_V4L_VIDEO); >> if (devname) >> printf("Alsa playback: %s\n", devname); >> } while (devname); >> free_media_devices(md); >> >> e) Get all video devices: >> >> md = discover_media_devices(); >> >> char *vid = NULL; >> do { >> vid = get_associated_device(md, vid, MEDIA_V4L_VIDEO, >> NULL, NONE); >> if (!vid) >> break; >> printf("Video device: %s\n", vid); >> } while (vid); >> free_media_devices(md); >> > >I did some testing: vivi video nodes do not show up at all. And since >there is >no concept of 'media hardware' in this API the handling of devices with >multiple >video nodes (e.g. ivtv) is very poor. One thing that we wanted to do >with the MC >is to select default nodes for complex hardware. This gives >applications a hint >as to what is the default video node to use for standard >capture/output. This >concept can be used here as well. Perhaps we should introduce a >'V4L2_CAP_DEFAULT' >capabity that drivers can set? > >I think this library would also be more useful if it can filter >devices: e.g. >filter on capture devices or output devices. Actually, I can't >immediately think >of other useful filters than capture vs output. > >We also need some way to tell apps that certain devices are mutually >exclusive. >Even if we cannot tell the app that through sysfs at the moment, this >information >will become available in the future through the MC, so we should >prepare the API >for this. > >Did anyone test what happens when the user renames device nodes using >udev rules? >I haven't had the chance to test that yet. > >Regards, > > Hans >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" >in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html Framebuffer devices are missing from the list. Ivtv provides one at the moment. -Andy ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 11:47 ` Andy Walls @ 2011-05-29 12:58 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 12:58 UTC (permalink / raw) To: Andy Walls Cc: Hans Verkuil, Devin Heitmueller, Linux Media Mailing List, Hans De Goede Em 29-05-2011 08:47, Andy Walls escreveu: > Hans Verkuil <hverkuil@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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 11:19 ` Hans Verkuil 2011-05-29 11:47 ` Andy Walls @ 2011-05-29 11:54 ` Hans de Goede 2011-05-29 13:08 ` Mauro Carvalho Chehab 2011-05-29 12:11 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 39+ messages in thread From: Hans de Goede @ 2011-05-29 11:54 UTC (permalink / raw) To: Hans Verkuil Cc: Mauro Carvalho Chehab, Devin Heitmueller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 11:54 ` Hans de Goede @ 2011-05-29 13:08 ` Mauro Carvalho Chehab 2011-05-29 13:30 ` Hans de Goede 0 siblings, 1 reply; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 13:08 UTC (permalink / raw) To: Hans de Goede; +Cc: Hans Verkuil, Devin Heitmueller, Linux Media Mailing List 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 13:08 ` Mauro Carvalho Chehab @ 2011-05-29 13:30 ` Hans de Goede 2011-05-29 14:55 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 39+ messages in thread From: Hans de Goede @ 2011-05-29 13:30 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Hans Verkuil, Devin Heitmueller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 13:30 ` Hans de Goede @ 2011-05-29 14:55 ` Mauro Carvalho Chehab 2011-05-30 7:14 ` Hans Verkuil 0 siblings, 1 reply; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 14:55 UTC (permalink / raw) To: Hans de Goede; +Cc: Hans Verkuil, Devin Heitmueller, Linux Media Mailing List 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 to read sound from associated to > v4l2 input device foo (the one the user just selected). const char *alsa = fget_associated_device(md, NULL, MEDIA_SND_CAP, fd, MEDIA_V4L_VIDEO); An alias for it can also be provided. > 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. Yeah, getting a friendly name would be nice. It should be noticed that udev does it already on RHEL6/Fedora 15 (newer versions of udev?): $ tree /dev/v4l/ /dev/video* /dev/v4l/ ├── by-id │ └── usb-Vimicro_Corp._Sirius_USB2.0_Camera-video-index0 -> ../../video1 └── by-path └── pci-0000:00:1d.7-usb-0:8.2:1.0-video-index0 -> ../../video1 /dev/video0 [error opening dir] /dev/video1 [error opening dir] /dev/video2 [error opening dir] (weird: it didn't catch the names for vivi and for hvr-950). More research about it is needed, but, at least on some cases, it can be done without needing to open the device node. > > Regards, > > Hans > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 14:55 ` Mauro Carvalho Chehab @ 2011-05-30 7:14 ` Hans Verkuil 2011-05-30 13:15 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 39+ messages in thread From: Hans Verkuil @ 2011-05-30 7:14 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Hans de Goede, Devin Heitmueller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-30 7:14 ` Hans Verkuil @ 2011-05-30 13:15 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-30 13:15 UTC (permalink / raw) To: Hans Verkuil; +Cc: Hans de Goede, Devin Heitmueller, Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 11:19 ` Hans Verkuil 2011-05-29 11:47 ` Andy Walls 2011-05-29 11:54 ` Hans de Goede @ 2011-05-29 12:11 ` Mauro Carvalho Chehab 2011-05-29 14:39 ` Mauro Carvalho Chehab ` (2 more replies) 2 siblings, 3 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 12:11 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 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 the device where the association will >> be made >> 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 an open file descriptor >> >> 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. The v4l2-sysfs-patch util does that, using those API calls [1] http://git.linuxtv.org/v4l-utils.git?a=blob;f=utils/v4l2-sysfs-path/v4l2-sysfs-path.c;h=7579612bdcd888d49e78772ed7ff8c5e410b7687;hb=HEAD > > 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. It may make sense to have a function that will open each device, do a VIDIOC_QUERYCTL and export an enrich list of devices based on what's returned there. >> >> 3) Examples with typical usecases >> ============================== >> >> a) Just displaying all media devices: >> >> void *md = discover_media_devices(); >> display_media_devices(md); >> free_media_devices(md); >> >> The devices will be shown at the order they appear at the computer buses. >> >> b) For video0, prints the associated alsa capture device(s): >> >> void *md = discover_media_devices(); >> char *devname = NULL, video0 = "/dev/video0"; >> do { >> devname = get_associated_device(md, devname, MEDIA_SND_CAP, >> video0, MEDIA_V4L_VIDEO); >> if (devname) >> printf("Alsa capture: %s\n", devname); >> } while (devname); >> free_media_devices(md); >> >> Note: the video0 string can be declarated as "/dev/video0" or as just "video0", >> as the search functions will discard any patch on it. >> >> c) Get the alsa capture device associated with an opened file descriptor: >> >> int fd = open("/dev/video0", O_RDWR); >> ... >> void *md = discover_media_devices(); >> vid = fget_associated_device(md, NULL, MEDIA_SND_CAP, fd, >> MEDIA_V4L_VIDEO); >> printf("\n\nAlsa device = %s\n", vid); >> close(fd); >> free_media_devices(md); >> >> d) Get the mainboard alsa playback devices: >> >> char *devname = NULL; >> void *md = discover_media_devices(); >> do { >> devname = get_not_associated_device(md, devname, MEDIA_SND_OUT, >> MEDIA_V4L_VIDEO); >> if (devname) >> printf("Alsa playback: %s\n", devname); >> } while (devname); >> free_media_devices(md); >> >> e) Get all video devices: >> >> md = discover_media_devices(); >> >> char *vid = NULL; >> do { >> vid = get_associated_device(md, vid, MEDIA_V4L_VIDEO, >> NULL, NONE); >> if (!vid) >> break; >> printf("Video device: %s\n", vid); >> } while (vid); >> free_media_devices(md); >> > > 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. > And since there is > no concept of 'media hardware' in this API the handling of devices with multiple > video nodes (e.g. ivtv) is very poor. As I said before, with just one line of code, grouping multiple video nodes into different groups will work with sysfs. All it needs to know is the group name, passed via uevent interface. > One thing that we wanted to do with the MC > is to select default nodes for complex hardware. This gives applications a hint > as to what is the default video node to use for standard capture/output. This > concept can be used here as well. Perhaps we should introduce a 'V4L2_CAP_DEFAULT' > capabity that drivers can set? We may add one uevent for that too. > I think this library would also be more useful if it can filter devices: e.g. > filter on capture devices or output devices. Actually, I can't immediately think > of other useful filters than capture vs output. Yes, that makes sense: just like with SND devices, the library may classify the outputs and inputs with different types. > We also need some way to tell apps that certain devices are mutually exclusive. > Even if we cannot tell the app that through sysfs at the moment, this information > will become available in the future through the MC, so we should prepare the API > for this. Makes sense. Please propose a way for it. We may use group info for that, but in a few cases (like video/vbi), having two devices grouped don't mean that they're mutually exclusive. > Did anyone test what happens when the user renames device nodes using udev rules? > I haven't had the chance to test that yet. We'll probably need to do some glue with udev or dbus. Not sure if it announces it somehow. Cheers, Mauro ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 12:11 ` Mauro Carvalho Chehab @ 2011-05-29 14:39 ` Mauro Carvalho Chehab 2011-05-30 6:34 ` Hans Verkuil 2011-05-30 6:54 ` Hans Verkuil 2 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-29 14:39 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 pci0000:00/0000: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 pci0000:00/0000: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 pci0000:00/0000: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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 12:11 ` Mauro Carvalho Chehab 2011-05-29 14:39 ` Mauro Carvalho Chehab @ 2011-05-30 6:34 ` Hans Verkuil 2011-05-30 11:37 ` Mauro Carvalho Chehab 2011-05-30 6:54 ` Hans Verkuil 2 siblings, 1 reply; 39+ messages in thread From: Hans Verkuil @ 2011-05-30 6:34 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-30 6:34 ` Hans Verkuil @ 2011-05-30 11:37 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-30 11:37 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-29 12:11 ` Mauro Carvalho Chehab 2011-05-29 14:39 ` Mauro Carvalho Chehab 2011-05-30 6:34 ` Hans Verkuil @ 2011-05-30 6:54 ` Hans Verkuil 2011-05-30 13:03 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 39+ messages in thread From: Hans Verkuil @ 2011-05-30 6:54 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 > >> 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 the device where the association will > >> be made > >> 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 an open file descriptor > >> > >> 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. > > The v4l2-sysfs-patch util does that, using those API calls [1] > http://git.linuxtv.org/v4l-utils.git?a=blob;f=utils/v4l2-sysfs-path/v4l2-sysfs-path.c;h=7579612bdcd888d49e78772ed7ff8c5e410b7687;hb=HEAD > > > > > 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. (BTW: note the initial 'No such file or dir' error at the top: it's perfectly fine not to have any dvb devices) The output of v4l2-sysfs-path -d is much more useful: Device pci0000:00/0000:00:14.4/0000: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. 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. Regards, Hans ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [RFCv2] Add a library to retrieve associated media devices - was: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-30 6:54 ` Hans Verkuil @ 2011-05-30 13:03 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-30 13:03 UTC (permalink / raw) To: Hans Verkuil; +Cc: Devin Heitmueller, Linux Media Mailing List, Hans De Goede 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 pci0000:00/0000:00:14.4/0000: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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [ANNOUNCE] experimental alsa stream support at xawtv3 2011-05-24 14:57 ` Devin Heitmueller 2011-05-26 6:53 ` Hans Verkuil @ 2011-05-28 12:00 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 39+ messages in thread From: Mauro Carvalho Chehab @ 2011-05-28 12:00 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Hans Verkuil, Linux Media Mailing List Em 24-05-2011 11:57, Devin Heitmueller escreveu: > On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil <hverkuil@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 > ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2011-05-30 13:15 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-23 20:17 [ANNOUNCE] experimental alsa stream support at xawtv3 Mauro Carvalho Chehab 2011-05-23 20:19 ` Devin Heitmueller 2011-05-23 20:30 ` Mauro Carvalho Chehab 2011-05-23 20:32 ` Mauro Carvalho Chehab 2011-05-24 6:50 ` Hans Verkuil 2011-05-24 7:21 ` Hans de Goede 2011-05-24 14:09 ` Mauro Carvalho Chehab 2011-05-24 15:55 ` Hans de Goede 2011-05-28 12:44 ` Mauro Carvalho Chehab 2011-05-28 13:01 ` Rémi Denis-Courmont 2011-05-28 14:41 ` Mauro Carvalho Chehab 2011-05-28 14:10 ` Mauro Carvalho Chehab 2011-05-28 12:55 ` Rémi Denis-Courmont 2011-05-28 14:39 ` Mauro Carvalho Chehab 2011-05-24 14:15 ` Mauro Carvalho Chehab 2011-05-24 14:57 ` Devin Heitmueller 2011-05-26 6:53 ` Hans Verkuil 2011-05-28 12:17 ` Mauro Carvalho Chehab 2011-05-28 12:26 ` Hans de Goede 2011-05-28 15:24 ` Hans Verkuil 2011-05-28 16:04 ` Mauro Carvalho Chehab 2011-05-28 16:20 ` Mauro Carvalho Chehab 2011-05-29 1:01 ` [RFCv2] Add a library to retrieve associated media devices - was: " Mauro Carvalho Chehab 2011-05-29 11:19 ` Hans Verkuil 2011-05-29 11:47 ` Andy Walls 2011-05-29 12:58 ` Mauro Carvalho Chehab 2011-05-29 11:54 ` Hans de Goede 2011-05-29 13:08 ` Mauro Carvalho Chehab 2011-05-29 13:30 ` Hans de Goede 2011-05-29 14:55 ` Mauro Carvalho Chehab 2011-05-30 7:14 ` Hans Verkuil 2011-05-30 13:15 ` Mauro Carvalho Chehab 2011-05-29 12:11 ` Mauro Carvalho Chehab 2011-05-29 14:39 ` Mauro Carvalho Chehab 2011-05-30 6:34 ` Hans Verkuil 2011-05-30 11:37 ` Mauro Carvalho Chehab 2011-05-30 6:54 ` Hans Verkuil 2011-05-30 13:03 ` Mauro Carvalho Chehab 2011-05-28 12:00 ` Mauro Carvalho Chehab
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.