[ANNOUNCE] experimental alsa stream support at xawtv3

[ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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.

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Devin Heitmueller]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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);

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans Verkuil]

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
> 
> 

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans de Goede]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans de Goede]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Rémi Denis-Courmont]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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.

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Rémi Denis-Courmont]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Devin Heitmueller]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans Verkuil]

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
> 
> 

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans de Goede]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Hans Verkuil]

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
> 
> 

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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.

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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

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

[Mauro Carvalho Chehab]

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);

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

[Hans Verkuil]

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

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

[Andy Walls]

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 

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

[Mauro Carvalho Chehab]

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

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

[Hans de Goede]

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

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

[Mauro Carvalho Chehab]

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.

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

[Hans de Goede]

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

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

[Mauro Carvalho Chehab]

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

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

[Hans Verkuil]

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

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

[Mauro Carvalho Chehab]

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

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

[Mauro Carvalho Chehab]

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

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

[Mauro Carvalho Chehab]

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

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

[Hans Verkuil]

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

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

[Mauro Carvalho Chehab]

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

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

[Hans Verkuil]

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

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

[Mauro Carvalho Chehab]

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

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Mauro Carvalho Chehab]

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
> 

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Emil Meier]

--- On Tue, 24/5/11, Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

> From: Devin Heitmueller <dheitmueller@kernellabs.com>
> Subject: Re: [ANNOUNCE] experimental alsa stream support at xawtv3
> To: "Hans Verkuil" <hverkuil@xs4all.nl>
> Cc: "Mauro Carvalho Chehab" <mchehab@redhat.com>, "Linux Media Mailing List" <linux-media@vger.kernel.org>
> Date: Tuesday, 24 May, 2011, 16:57
> On Tue, May 24, 2011 at 2:50 AM, Hans
> 
> Oh, and how is it expected to handle informing the
> application about
> device contention between DVB and V4L?  Some devices
> share the tuner
> and therefore you cannot use both the V4L and DVB device at
> the same
> time.  Other products have two independent input paths
> on the same
> board, allowing both to be used simultaneously (the
> HVR-1600 is a
> popular example of this).  Sysfs isn't going to tell
> you this
> information, which is why in the MC API we explicitly added
> the notion
> of device groups (so the driver author can explicitly state
> the
> relationships).
> 
> Today MythTV users accomplish this by manually specifying
> "Input
> Groups".  I say that's what they do, but in reality
> they don't realize
> that they need to configure MythTV this way until they
> complain that
> MythTV recordings fail when trying to record programs on
> both inputs,
> at which point an advanced user points it out to
> them.  End users
> shouldn't have to understand the internal architecture of
> their
> capture card just to avoid weird crashy behavior (which is
> what often
> happens if you try to use both devices simultaneously since
> almost no
> hybrid drivers do proper locking).

Are there mechanisms for device-locking in the v4l api? With my 2 hybrid saa7134 cards I have observed exactly this issues in Mythtv and also in xawtv and kaffeine....
At the moment I disable one device via additional card definitions and modprobe-parameters, so that the other one is "alone" and only one app gets control over the tuner. 

But this driver (saa7134) seams not even lock the /dev/video0 correctly, as starting xawtv twice renders the card inoperable and forces rebooting to get the card working again...
 
Is there a good starting point to implement the locking?

> I am in favor of this finally getting some attention, but
> the reality
> is that sysfs isn't going to cut it.  It just doesn't
> expose enough
> information about the underlying hardware layout.
> 
> Devin
> 
> -- 
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Emil

Re: [ANNOUNCE] experimental alsa stream support at xawtv3

[Devin Heitmueller]

On Tue, May 24, 2011 at 1:26 PM, Emil Meier <emil276me@yahoo.com> wrote:
> Are there mechanisms for device-locking in the v4l api? With my 2 hybrid saa7134 cards I have observed exactly this issues in Mythtv and also in xawtv and kaffeine....
> At the moment I disable one device via additional card definitions and modprobe-parameters, so that the other one is "alone" and only one app gets control over the tuner.

There is currently no infrastructure for doing this in the core
framework.  It varies on based on the bridge.  For example, the
saa7164 bridge driver won't let you do it (by design it returns
-EBUSY), but I believe almost all of the others will.  And of course
with no locking the net result is completely unpredictable results as
you attempt to issue a tuning request on one side while the other side
is already in use.

Worth noting that at least in MythTV you can work around the issue in
userland by putting both the V4L and DVB device into the same input
group.  That prevents MythTV from attempting to use both devices at
the same time.

> But this driver (saa7134) seams not even lock the /dev/video0 correctly, as starting xawtv twice renders the card inoperable and forces rebooting to get the card working again...

Probably worth noting that it is actually legal to have multiple
callers open a V4L2 device.  The EBUSY condition only occurs when
initiating streaming.  This is why you can have an application like
mplayer playing the video while at the same time using a command line
tool to change the channel.

That said, if the card is rendered inoperable until reboot, then
you've hit some sort of bug.

> Is there a good starting point to implement the locking?

Not really:  there isn't really any locking framework today which
spans both DVB and V4L.

There are really two different aspects to this problem:

The first is applications being able to tell what DVB and V4L devices
are related so that they know that they cannot even attempt to use
them at the same time.  This is necessary for stuff like MythTV so
that it's scheduler can know a conflict exists ahead of time instead
of waiting until actually attempting to do the record.

The second aspect is making sure that you simply can never actually
use both devices at the same time.  This is really about reliability -
locking to ensure that two callers don't screw up the state of the
tuner.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com