Trouble, trouble… framebuffer can not work normal in VoCore2.
I guess openwrt has some limit of the /dev/ node size.

My plan of driver is like this:

Kernel Side                    User/Client Side            Display
Framebuffer (memory)  ->read   vodisp agent app     ->     libusb 
                      <-write  other framebuffer app

For max compatible and speed, I use Simple Framebuffer driver in Linux kernel. Actually it just a free memory space used to store video data.

vodisp is a simple server read from frame buffer and send data by libusb to USB screen. And other application depends on frame buffer can directly write to frame buffer.

This should work, but get weird issue. When I write 1152000 bytes to framebuffer, I find Linux is dead, looks like internal deadlock.

This is really critical bug, even though USB display is still working, but can not compilable with framebuffer app， that is a great lose.

[embedyt]https://youtu.be/RpzJ3UnTP6c[/embedyt]

I grab some frames from the famous movie “Beauty and Beast”, now it is clearly show the screen can play video so smooothly.

But nothing is that smooth… I get a bad news from my screen provider, the screen has out of stock, all I can get is eight units…

I have to order new samples from another provider, but the screen is customized, so not sure when I can get the mass production…

Bug fixed. Now it is stable 🙂
Test frame rate again, it is around 20~20.5fps, emm, it does not reach my target 24fps, still have space to optimize.

I send two pictures to the screen in a loop and use my phone record 5 seconds(slow motion), count frame by frame, it is 102 frames.

[embedyt]https://youtu.be/6zqGlMJCh9g[/embedyt]

Next step, write Linux driver and use frame buffer driver.

PS: looks like it is so smoothly from blog 1 to 6, step by step… actually the develop process is so painful and hopeless… I spend over two months full time on this. I had the thought of giving up over thousands times…
I can not go this far without my family’s encouragement.
Finally, the result is so beautiful, can not believe I made this! crying like a baby. T-T

Still picture, 50% chance works.

Moving picture, shit always happens. It is really moving, but it should show static still image.

[embedyt] https://www.youtube.com/watch?v=H_8iSRbW08Q[/embedyt]

PS: I use phone camera recorded 240fps video, and use ffplay count every frame, true 25fps and true 24bit color.

Hopefully I can fix it today. Looks like there are some data corrupt or timing issue. :p

The three days I have made a great process.

Backlight PWM control is working now and the screen can reach at least 24fps. I checked send 144 frames time is 5.8s.

This is a simple code I do the test:
first create three random pictures, and then use libusb bulk mode send it to the screen. Totally 48 loops and every loops send three “true color” pictures. Also a video of the test is attached.

#define FRAMESIZE		((unsigned int)800 * 480 * 3)

...


    buf1 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf1[i] = (unsigned char)(rand() & 0xff);
    buf2 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf2[i] = (unsigned char)(rand() & 0xff);
    buf3 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf3[i] = (unsigned char)(rand() & 0xff);

    for(i = 0; i < 48; i++) {
        // send to out endpoint 2.
        code = libusb_bulk_transfer(handle, 0x02, buf1, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
        code = libusb_bulk_transfer(handle, 0x02, buf2, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
        code = libusb_bulk_transfer(handle, 0x02, buf3, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
    }

The screen is 80% done, I think I can fix rest bugs very soon 🙂

[embedyt]https://youtu.be/zA81GuyK6qY[/embedyt]

It works now but not the backlights.

I have to make the backlight to fixed level to avoid the process delay too much. I was planing to use LCD PWM to control its backlight brightness.

Currently the FPS is very low, around one frame per second, power consume is 200mA.

But this is just the first step. If I am lucky enough and the screen datasheet is showing real parameters, I should get a wonderful result in two or three days 😉

The feeling is very bad…

I find the problem of the back light. It is because I am using screen-chip PWM to control LED brightness. When I send command to the screen, it do not action at all, keep output 0 to the LED power control chip.

Looks like the problem is the screen chip accept my command but ignore the parameters. weird issue, I have worked on this over three days but no way out.

…Emm, maybe I need change another screen and try …