I can't forward image because of not created /proc/fbX

# ./vcam-util -l
Available virtual V4L2 compatible devices:
1. vcamfb0(640,480,rgb24) -> /dev/video0
2. vcamfb1(640,480,rgb24) -> /dev/video1
3. vcamfb2(640,480,rgb24) -> /dev/video2

# ls -al /proc/fb*
-r--r--r-- 1 root root 0 Jul  4 06:01 /proc/fb

Current vcam still need to process rawdata by users to framebuffer, and only support vlc player for display. vcam should at least support ffmpeg and ffplay for streaming display.

To crash the driver is enough to use fbset on the framebuffer device to change the resolution:
fbset -xres 1920 -yres 1080 -fb /dev/fb1

What should happen instead:
if the ioctl used by fbset is unsupported, the driver should not crash, but return some error to the userspace.

I just followed the steps, with only one thing to notice: the command sudo ./vcam-util -l returned vcamfb3(640,480,rgb24) -> /dev/video3, but the actual device was /dev/video2

First, thank you for making vcam and thank you for listing similar projects. One of the joys of open source is seeing developers being friendly to each other out and not treating alternatives as "competitors".

Now, my request. I know you probably don't want to talk bad about anybody else's software, but it would be helpful if there was some sort of chart showing the similarities and differences between vcam, v4l2loopback, and akvcam.

In particular, I'm running into a limitation where v4l2loopback works fine in Firefox, but the Chromium browser doesn't want to open my virtual camera. There are various ugly workarounds that people mention, like chmod 000 /dev/video0, which don't even work for me.

What improvements does vcam offer? Does it play nice with whatever the heck Chromium is looking for in a video camera?

Thanks!

I wrote the test.c as below

#include <fcntl.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/ioctl.h>
#include <unistd.h>

static char fb_path[128] = "/dev/fb1";
static int fd;

void signal_exit_handler(int sig)
{
    close(fd);
    exit(0);
}

int main()
{
    signal(SIGINT, signal_exit_handler);
    fd = open(fb_path, O_RDWR);
    unsigned char rgb[3] = {10, 60, 128};
    while (1) {
        for (int i = 0; i < 480; i++) {
            for (int j = 0; j < 640; j++) {
                write(fd, rgb, sizeof(rgb));
            }
        }
        for (int i = 0; i < 3; i++) {
            rgb[i]++;
        }
    }
    return 0;
}

after compile I enter this command

./test # terminal 1
vlc v4l2:///dev/video2 # terminal 2

but video is still the original black and white gradient picture

There is a few problems in VIDIOC_G/TRY/S_FMT implementation. Some issue result in test fail on v4l2-compliance, others comes from that the implement is incompliant with document description, and nevertheless some questions from my own.

allow_scaling=1

1. allow_scaling=1 will lead to test failure on VIDIOC_G/TRY/S_FMT (710). The issue comes from the inconsistency, which the return format first acquire from G_FMT should match the later returning format from TRY_FMT.

createInvalidFmt(fmt, clip, type);
doioctl(node, VIDIOC_G_FMT, &fmt);
fmt_try = fmt;
ret = doioctl(node, VIDIOC_TRY_FMT, &fmt_try);
...
if (!matchFormats(fmt, fmt_try))
    result = fail("%s: TRY_FMT(G_FMT) != G_FMT\n",
            buftype2s(type).c_str());

2. While vcam device with parameter setting allow_scaling=1, TRY_FMT would force to change the ouputbuffer and vcamfb size to {1280, 720}, I am curious that is it intended?

/* find the nearest size from {vcam_sizes[n_avail - 1].width, vcam_sizes[n_avail - 1].height}
 * which is specify to {1280, 720}
 */
const struct v4l2_frmsize_discrete *sz = v4l2_find_nearest_size(
            vcam_sizes, n_avail, width, height, vcam_sizes[n_avail - 1].width,
            vcam_sizes[n_avail - 1].height);

3. If the behavior is intended, there will be two problem for the implementation:

• 3.1 According to the document, TRY_FMT should not change the driver state. The job should transfer to S_FMT to accomplish.

The VIDIOC_TRY_FMT ioctl is equivalent to VIDIOC_S_FMT with one exception: it does not change driver state. It can also be called at any time, never returning EBUSY. This function is provided to negotiate parameters, to learn about hardware limitations, without disabling I/O or possibly time consuming hardware preparations.

• 3.2 When allow_scaling=1, TRY_FMT will always return fmt with size={1280, 720}. Than test [710] will always fail if default size was not {1280, 720}.

allow_cropping=1

4. dev->crop_output_format is first assign in TRY_FMT. However in practice, application would first call G_FMT to query current format, than further call S_FMT to modify the desire format. The problem lead to test fail in (441) and also (710). The assignment should be happen before G_FMT were called. (In my opinion, it might be reasonable to assign while create_vcam_device).

Good practice is to query the current parameters first, and to modify only those parameters not suitable for the application.

vcamfb_update

5. This is a question from me only. I am not sure why it is necessary to update the vcamfb after TRY/S_FMT, while the device can handle different input and output buffer format in submit_copy_buffer
6. Finally, what is the difference between fb.c/vcamfb_update and control.c/control_iocontrol_modify_input_setting, in my opinion, the two function has similar purpose and might be a chance to combine together?

GitHub Actions can automate CI pipeline, and we shall use it to validate the following:

• vcam is buildable with certain Linux kernels.
• source files follow the consistent coding style.

vwifi is an example which deploys GitHub Actions. Check its .github/workflows/main.yaml for details.

Sparse is a semantic checker for C programs; it can be used to find a number of potential problems with kernel code. There are various warnings raised by Sparse.

Steps:

1. Make sure sparse installed in advance. See https://www.kernel.org/doc/html/latest/dev-tools/sparse.html
2. Run the command:

make -C /lib/modules/`uname -r`/build M=`pwd` modules C=1

Warnings:

control.c:47:5: warning: cast removes address space '__user' of expression
control.c:61:5: warning: cast removes address space '__user' of expression
fb.c:101:45: warning: cast removes address space '__user' of expression
fb.c:101:45: warning: incorrect type in argument 2 (different address spaces)
fb.c:101:45:    expected void const [noderef] __user *from
fb.c:101:45:    got void
fb.c:227:45: warning: cast removes address space '__user' of expression
fb.c:227:45: warning: incorrect type in argument 2 (different address spaces)
fb.c:227:45:    expected void const [noderef] __user *from
fb.c:227:45:    got void *