Hi again,

I noticed the signaling problem was related to a wrong "pusher" pid assignement in the vloopback driver. That is true at least for Ubuntu Linux kernel 2.6.31-20-generic.

In the vloopback_open function PID was being found by:
     loops[nr]->pid = find_pid_ns(current->pid,0);
I'm not completely aware of what ns (namespace) for PIDs ought to be. It is said to allow for movement of processes through hosts. I don't know to which extent this is also true for multi-cores.

Either way, the assumption of namespace 0 doesn't hold for 2.6.31. Maybe in 2.6.30 namespace 0 was interpreted as search for the real namespace. But in 2.6.31 the helper struct pid * find_vpid(int nr) can be used instead. So now it looks like this:
     loops[nr]->pid = find_vpid(current->pid);

With that change the signal really arrived on my userspace program and I'm ready to continue :-).

I also changed the debug message of vloopback_open about which pid called the function to output the stored pid instead:
        if (debug > LOG_NODEBUG)
            info("Stored pid %d", pid_vnr(loops[nr]->pid));

Best regards,

On Thu, Apr 15, 2010 at 6:00 PM, Raul Fajardo <rfajardo@gmail.com> wrote:
Hello everyone,

I've been perfeclty using the vloopback module in one-copy mode, using a straightforward user-space driver for the Logitech, Inc. QuickCam Notebook Pro.

The user-space driver configures the camera and loads the data from the USB to the vloopback pipe. On the other side camstream is able to output the video to me.

Now I was wondering if I could complete the driver with all necessary controls of brightness and so on, which are requested over ioctls. To do so I was intending to activate the zero-copy mode instead of the one-copy one and process the ioctls myself.

On the API I've seen the initialization would be simply based on a mmap call to the vloopback device. After that the "pusher" should receive the signal SIGIO whenever an ioctl has to be served so the "pusher" takes care of it.

I wanted to test that, so I initialized the vloopback in zero-copy mode accordingly (open+mmap) and added a signal handler for the SIGIO signal to my program, which prints out something when it is run. In order to pass ioctls to vloopback module I used the same camstream software.

What happens is that the camstream software blocks when I go to "File->Open viewer..." and my "userspace-driver" does not print out anything. Outcome of the test reported below.

So I wanted to ask if my assumptions are right about the zero-copy mode usage of vloopback? Is the zero-copy mode maybe deprecated and no longer supported? Or am I doing something wrong?

Thank you in advance,
Raul Fajardo

Test outcome follows:

I changed the vloopback debug mode to verbose:
static unsigned int debug = LOG_VERBOSE;
recompiled and reloaded the module.

dmesg shows the following by the described test:
Run my program on /dev/video0
[188100.986549] [vloopback_open] : Video loopback 0
[188100.986554] [vloopback_open] : Current pid 27048
[188100.986561] [vloopback_mmap] : Video loopback 0
On camstream go to "File->Open viewer..."
[188111.376989] [vloopback_open] : Video loopback 0
[188111.377214] [vloopback_open] : Video loopback 0
[188111.377222] [vloopback_ioctl] : Video loopback 0 cmd 2151446017   Camstream blocks here...
[188177.527576] [vloopback_release] : Video loopback 0  Force quit camstream

Signal handling as follows:

    struct sigaction pwc_sig_handler;
    struct sigaction standard_sig_handler;

    pwc_sig_handler.sa_flags = 0;
    pwc_sig_handler.sa_handler = &sig_handler;

    sigaction(SIGINT, &pwc_sig_handler, &standard_sig_handler);
    sigaction(SIGTERM, &pwc_sig_handler, &standard_sig_handler);
    sigaction(SIGIO, &pwc_sig_handler, &standard_sig_handler);

void sig_handler(int sig)
    printf("Aborting operation...\n");
    op_abort = 1;
    if ( sig == SIGIO )
        printf("Trying to access the device IOCTL\n");
        if ( video_dev != NULL )
            printf("Trying to access the device IOCTL\n");