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

OK, littlevgl is working pretty well. 🙂
We should disable tab animate, that is really laggy.

I find many good library.

Actually directFB is an good choose but currently it can not compile at all.

First is the one from China, named GuiLite, it has everything I need and its code is really simple, performance is good.

Second is littlevgl, very good interface and light weight.

Third is uGFX, also light weight but not totally free, for test and study it is free.

4th, μGUI, it is too light weight for VoCore2 🙂

I like C better than C++, so I’d like to choose one from littlevgl & uGFX if no better find.

Now the screen is working, I need to find a good UI library for this screen.
Currently candidates are:

1. Qt embed.
2. SDL2.
3. miniGUI.

Qt embed consume a lot of memory and disk space, normally one application will take 10MB.
SDL2 is not designed for embed device UI.
miniGUI is a good project, but I did not use it before, might be hard to combine.

My display is true color and vocore2 has 128MB memory and cpu speed is good, can show beautiful user interface than the 51/ARM based single chip microcomputer. So maybe my best choice is Qt.

…but I am not sure if Qt is light enough to run on this, try first.

Qt has nice support to compile it 🙂
http://doc.qt.io/qt-5/embedded-linux.html#configuring-a-specific-device

Qt is based on DirectFB, looks like directFB.org is abandoned, source code still valid at github.

Maybe I can directly use directdb?

[embedyt] https://www.youtube.com/watch?v=3PT_6n-tnek[/embedyt]

mirror part of the display for windows, macos, linux.

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 😉