Unix port failing on sdl_display object creation

[androiddrew]

So I have attempted to build the unix port on two ubuntu machines. One is a 22.04 with an Nvidia GPU the other is a 24.04 Ubuntu machine with a simple dell with an onboard GPU.

I have added DEBUG to the micropython compile with:

diff --git a/builder/unix.py b/builder/unix.py
index ba0bc7d..669798f 100644
--- a/builder/unix.py
+++ b/builder/unix.py
@@ -245,6 +245,7 @@ def compile(*args):  # NOQA

     cmd_ = compile_cmd[:]
     cmd_.extend(list(args))
+    cmd_.insert(0, "DEBUG=1")

     return_code, _ = spawn(cmd_)
     if return_code != 0:

I am running on both machines

python3 make.py unix submodules clean mpy_cross DISPLAY=sdl_display INDEV=sdl_pointer

I copy the example program on https://github.com/lvgl-micropython/lvgl_micropython/blob/main/README.md?plain=1#L580-L628 to a test_unix_sdl.py file then run

toor@toor-jammy-jellifish:~/experiments/lvgl_micropython$ ./build/lvgl_micropy_unix ./test_unix_sdl.py
Segmentation fault (core dumped)

When I run the program with gdb

Reading symbols from ./build/lvgl_micropy_unix...
(gdb) break main
Breakpoint 1 at 0x1b1f48: file main.c, line 467.
(gdb) run ./test_unix_sdl.py 
Starting program: /home/toor/experiments/lvgl_micropython/build/lvgl_micropy_unix ./test_unix_sdl.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=2, argv=0x7fffffffdb58) at main.c:467
467 int main(int argc, char **argv) {
(gdb) c
Continuing.
[New Thread 0x7ffff1200640 (LWP 24564)]

Thread 1 "lvgl_micropy_un" received signal SIG34, Real-time event 34.
0x00007ffff7d18bcf in __GI___poll (fds=0x7fffffffd248, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) backtrace
#0  0x00007ffff7d18bcf in __GI___poll (fds=0x7fffffffd248, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff6f647e2 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ffff6f64eb1 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007ffff6f65ea6 in xcb_wait_for_reply64 () from /lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007ffff6fc831c in _XReply () from /lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff66c4921 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#6  0x00007ffff667382c in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#7  0x00007ffff4e088fe in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#8  0x00007ffff667144d in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#9  0x00007ffff4e5e564 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#10 0x00007ffff4e62d5e in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#11 0x00007ffff4e62ee6 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#12 0x00007ffff4e3858b in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#13 0x00007ffff4e48875 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#14 0x00007ffff666f7c7 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#15 0x00007ffff666feef in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#16 0x00007ffff7ffd040 in ?? () from /lib64/ld-linux-x86-64.so.2
#17 0x0000000000000000 in ?? ()

The above output was from my 22.04 ubuntu machine with an NVIDIA GPU.

I am getting this signal 34 event. I'm kind of at a loss where to take this. I manually typed in each line from test_unix_sdl.py and I believe it is happening on initializing the SDLDisplay.

display = sdl_display.SDLDisplay(
    data_bus=bus,
    display_width=_WIDTH,
    display_height=_HEIGHT,
    frame_buffer1=buf1,
    frame_buffer2=buf2,
    color_space=lv.COLOR_FORMAT.RGB888
)

[androiddrew]

Ok, this is interesting so I

sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p
sudo systemctl stop apport
ulimit -c unlimited
sudo sysctl -p

And reran the program, hitting the segmentation fault which gave me a core dump

gdb ./build/lvgl_micropy_unix /tmp/core-LVGL_MP_RENDERE.29778

And I see a different backtrace

(gdb) backtrace
#0  0x00005cf37db3a12d in gc_lock () at ../../py/gc.c:337
#1  0x00005cf37dbb8c51 in call_py_func_with_lock (cif=0x7f1ab9d021a8, ret=<optimized out>, args=0x7f1ab3bfee60, user_data=<optimized out>) at modffi.c:295
#2  0x00007f1aba8e77ec in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x00007f1aba8e8050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x00005cf37dcbcbd0 in BlitNtoNPixelAlpha ()
#6  0x00005cf37dcad056 in SDL_SoftBlit ()
#7  0x00005cf37dc21f04 in SDL_UpperBlit_REAL ()
#8  0x00005cf37dc0cc24 in SW_RunCommandQueue ()
#9  0x00005cf37dbf93cd in SDL_RenderPresent_REAL ()
#10 0x00005cf37da9c014 in flush_thread (self_in=0x7f1ab9c18300) at /home/toor/experiments/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#11 0x00005cf37dc15e3a in SDL_RunThread ()
#12 0x00005cf37dc6b6bd in RunThread ()
#13 0x00007f1aba694ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x00007f1aba726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) 

And it looks like garbage collection may be doing something here.

So I added

import gc
gc.disable()

But still see

#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337
337     MP_STATE_THREAD(gc_lock_depth)++;
[Current thread is 1 (Thread 0x722ef7200640 (LWP 30302))]
(gdb) backtrace
#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337
#1  0x00005cb61d57fc51 in call_py_func_with_lock (cif=0x722efd302268, ret=<optimized out>, args=0x722ef71fede0, user_data=<optimized out>) at modffi.c:295
#2  0x0000722efdf2f7ec in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x0000722efdf30050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x0000722efadff1bd in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#6  0x0000722efc78a11e in __glDispatchCheckMultithreaded () from /lib/x86_64-linux-gnu/libGLdispatch.so.0
#7  0x0000722efcec0e8c in ?? () from /lib/x86_64-linux-gnu/libGLX.so.0
#8  0x00005cb61d6c6c91 in X11_GL_MakeCurrent ()
#9  0x00005cb61d5f2ba8 in SDL_GL_MakeCurrent_REAL ()
#10 0x00005cb61d5c201a in GL_ActivateRenderer ()
#11 0x00005cb61d5c4de1 in GL_UpdateTexture ()
#12 0x00005cb61d5b7477 in SDL_UpdateTexture_REAL ()
#13 0x00005cb61d5eecd1 in SDL_UpdateWindowTexture ()
#14 0x00005cb61d5ef971 in SDL_UpdateWindowSurface_REAL ()
#15 0x00005cb61d5c042d in SDL_RenderPresent_REAL ()
#16 0x00005cb61d463014 in flush_thread (self_in=0x722efd218380) at /home/toor/experiments/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#17 0x00005cb61d5dce3a in SDL_RunThread ()
#18 0x00005cb61d6326bd in RunThread ()
#19 0x0000722efdc94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#20 0x0000722efdd26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

[kdschlosser]

wow DUH!!! (this is DUH about me not you)

OK so here is the skinny. MicroPython is exiting before the code gets the chance to fully run. When you run the file directly as you are there is no loop in the main thread to keep the program running. This is normally handled by the repl.

take your test script and place it into the same folder that the MicroPython binary is in. Then run the binary without adding the file name onto the end. MicroPython will run and you will get a REPL. then simply import the file. import test_unix_sdl and away you go....

[kdschlosser]

I have been trying to figure out why the backtrace is the way it is as it wasn't making any sense to me either.

[kdschlosser]

what I did to improve the performance is I created a thread that handles the flushing of the buffers to the screen. That is seen here

#17 0x00005cb61d5dce3a in SDL_RunThread ()

this line is a bit misleading...

#0  0x00005cb61d50112d in gc_lock () at ../../py/gc.c:337

line 337 is NOT gc_lock() look carefully. It says "in" gc_lock()

Here is gc_lock

void gc_lock(void) {
    // This does not need to be atomic or have the GC mutex because:
    // - each thread has its own gc_lock_depth so there are no races between threads;
    // - a hard interrupt will only change gc_lock_depth during its execution, and
    //   upon return will restore the value of gc_lock_depth.
    MP_STATE_THREAD(gc_lock_depth)++;                                                         <<<=== line 337
}

line 337 is actually a macro and that macro translates to...

mp_thread_get_state()->gc_lock_depth

The failure is happening not with the gc but is happening from mp_thread_get_state()

[androiddrew]

Ah, import test_unix_sdl still seg faults, but I assume that's because of what you are mentioning later with the mp_thread_get_state() call. I unfortunately have blown past what I know already on this one, I can recreate it on another machine so it's not specific to the nvidia glx stuff that I initially thought it was.

[kdschlosser]

OK that's the important part is it not being specific to the display driver..

when you do a debug run on it does it still seg fault at the same place?

[kdschlosser]

also have you tried increasing the heap to say 20mb, just for shits and giggles.. Ya never know...

[androiddrew]

OK that's the important part is it not being specific to the display driver..

when you do a debug run on it does it still seg fault at the same place?

No the core dump seems to show a different backtrace. The first gdb trace I provide is from a gdb run.

also have you tried increasing the heap to say 20mb, just for shits and giggles.. Ya never know...

Set heap size to 20MB. Still seg faults. but this is the core-dump backtrace

Reading symbols from ./build/lvgl_micropy_unix...

warning: Can't open file /memfd:/.nvidia_drv.XXXXXX (deleted) during file-backed mapping note processing
[New LWP 65653]
[New LWP 65657]

warning: Section `.reg-xstate/65653' in core file too small.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build/lvgl_micropy_unix ./test_unix_sdl.py'.
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Section `.reg-xstate/65653' in core file too small.
#0  0x0000761e5b97b686 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
[Current thread is 1 (Thread 0x761e5b972b80 (LWP 65653))]
(gdb) backtrace
#0  0x0000761e5b97b686 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#1  0x0000761e5b97c050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#2  <signal handler called>
#3  __GI___ioctl (fd=9, request=3223340586) at ../sysdeps/unix/sysv/linux/ioctl.c:36
#4  0x0000761e58d27140 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#5  0x0000761e58d2d84d in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#6  0x0000761e588603c0 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#7  0x0000761e58861452 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#8  0x0000761e58862ee6 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#9  0x0000761e5883858b in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#10 0x0000761e58848875 in ?? () from /lib/x86_64-linux-gnu/libnvidia-glcore.so.560.35.03
#11 0x0000761e5a12c7c7 in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#12 0x0000761e5a12ceef in ?? () from /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
#13 0x0000761e5bace040 in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x0000000000000000 in ?? ()

Back to Nvidia stuff

[androiddrew]

:sob: I created an Ubuntu VM on my macbook using VMWare....same seg fault.

[androiddrew]

Ok on the VM (Ubuntu 22.04) I get this issue

Thread 1 "lvgl_micropy_un" received signal SIG34, Real-time event 34.
Download failed: Invalid argument.  Continuing without source file build-llvm/tools/clang/stage2-bins/llvm/include/llvm/PassInfo.h.
~PassInfo () at llvm/include/llvm/PassInfo.h:30
warning: 30 llvm/include/llvm/PassInfo.h: No such file or directory
(gdb) quit
A debugging session is active.

Which seems so much more sparse than the other sessions...and wI have no clue why llvm is even needed

[kdschlosser]

The core dump file is truncated.. see here as to possible causes..

https://stackoverflow.com/questions/47047779/why-does-gdb-prompt-unexpected-size-of-section-reg-xstate-xxxxx-in-core-file

It's a gdb thing that needs to be corrected so we can see the proper dump output.

warning: Section `.reg-xstate/65653' in core file too small.

[kdschlosser]

I just cloned the repo, compiled it and ran it...

it's running and not crashing.

Did you guys installed the requirements?

sudo apt-get install build-essential libffi-dev pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev  libaudio-dev libjack-dev libsndio-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev fcitx-libs-dev libpipewire-0.3-dev libwayland-dev libdecor-0-dev

On top of those you also need to have a desktop GUI installed and running. There needs to be a framework in place that SDL is able to use to display the application window. It will not work from the native shell. You MUST launch the desktop and then open a shell once in the desktop the GUI has to be running.

[androiddrew]

• Yup I have all the dependencies installed as documented
• All desktop machines have a GUI and I'm running it in a desktop environment.

I see a flash of the window open, it's black but no slider widget is displayed then it seg faults. That occurs in all three of my machines two of which are new installs of 24.04 Ubuntu on both a Dell intel i7 machine and a VM fusion VM. The third one is a Ryzen + Nvidia desktop which is where we see all the desk

Are you running the same compilation command as I am? What OS are you using? What virtual machine software?

[androiddrew]

Got the VM to drop a core dump

sing host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build/lvgl_micropy_unix'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000058fa86825e5d in gc_lock () at ../../py/gc.c:337
337     MP_STATE_THREAD(gc_lock_depth)++;
[Current thread is 1 (Thread 0x769b25e006c0 (LWP 24963))]
(gdb) backtrace
#0  0x000058fa86825e5d in gc_lock () at ../../py/gc.c:337
#1  0x000058fa868a3fd1 in call_py_func_with_lock (cif=0x769b34702028, ret=<optimized out>, args=0x769b25dff560, user_data=<optimized out>)
    at modffi.c:295
#2  0x0000769b352ba641 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#3  0x0000769b352bad38 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#4  <signal handler called>
#5  0x000058fa869036bf in SDL_FillRect4SSE ()
#6  0x000058fa86903967 in SDL_FillRect_REAL ()
#7  0x000058fa868f5543 in SW_RunCommandQueue ()
#8  0x000058fa868e3e3d in SDL_RenderPresent_REAL ()
#9  0x000058fa8679cd19 in flush_thread (self_in=0x769b34618520) at /home/toor/workspace/lvgl_micropython/ext_mod/lcd_bus/sdl_bus/sdl_bus.c:233
#10 0x000058fa869007ea in SDL_RunThread ()
#11 0x000058fa8695b9ed in RunThread ()
#12 0x0000769b3509ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#13 0x0000769b35129c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

[mdlayher]

I gave the example a try on Ubuntu 22.04.4 with GNOME and Wayland and I don't get a segfault, but I do end up with an empty window with no UI elements:

[androiddrew]

I gave the example a try on Ubuntu 22.04.4 with GNOME and Wayland and I don't get a segfault, but I do end up with an empty window with no UI elements:

This is exactly what I see for 2 - 15 seconds before the program raises a seg fault for me.

[kdschlosser]

This is what I am running for a test script.. I have not checked it against the one that is in the readme file.

from micropython import const  # NOQA

_WIDTH = const(480)
_HEIGHT = const(320)

_BUFFER_SIZE = _WIDTH * _HEIGHT * 3
import lcd_bus  # NOQA

bus = lcd_bus.SDLBus(flags=0)

buf1 = bus.allocate_framebuffer(_BUFFER_SIZE, 0)
buf2 = bus.allocate_framebuffer(_BUFFER_SIZE, 0)

import lvgl as lv  # NOQA

import sdl_display  # NOQA

lv.init()

display = sdl_display.SDLDisplay(
    data_bus=bus,
    display_width=_WIDTH,
    display_height=_HEIGHT,
    frame_buffer1=buf1,
    frame_buffer2=buf2,
    color_space=lv.COLOR_FORMAT.RGB888
)

display.init()

import sdl_pointer

mouse = sdl_pointer.SDLPointer()

import task_handler
th = task_handler.TaskHandler()

scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x000000), 0)

slider = lv.slider(scrn)
slider.set_size(400, 25)
slider.center()

def on_value_changed(_):
    print('VALUE_CHANGED:', slider.get_value())

slider.add_event_cb(on_value_changed, lv.EVENT.VALUE_CHANGED, None)

I am running Windows 11 with WSL that has Ubuntu 22.04 installed on it....

The CI is only good for checking to see if it compiles properly not if it actually runs.

[kdschlosser]

This is what I am doing to compile it.

git clone https://github.com/lvgl-micropython/lvgl_micropython
cd lvgl_micropython
python3 make.py unix submodules myp_cross DISPLAY=sdl_display INDEV=sdl_pointer

[androiddrew]

Ok I have some progress to report.

I commented out the

#import task_handler
#th = task_handler.TaskHandler()

and at the end of your test script I am using.

import time
while True:
    lv.tick_inc(5)
    lv.timer_handler()
    time.sleep_ms(5)

Which hasn't seg faulted yet, and it has been running for a couple of minutes now. @kdschlosser your test script is "almost" what is in the README.md. No difference on our compile step.

So:

• task_handler.TaskHandler() might actually be the source of my seg faults
• The SDL display still is just a black screen. No clue where to go from here on that.
• The SDL pointer appears to work though because it's triggered the on_value_change callback.

I ran

for lib in build-essential libffi-dev pkg-config cmake ninja-build gnome-desktop-testing libasound2-dev libpulse-dev  libaudio-dev libjack-dev libsndio-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev libxss-dev libxkbcommon-dev libdrm-dev libgbm-dev libgl1-mesa-dev libgles2-mesa-dev libegl1-mesa-dev libdbus-1-dev libibus-1.0-dev libudev-dev fcitx-libs-dev libpipewire-0.3-dev libwayland-dev libdecor-0-dev; do 
    version=$(dpkg -s $lib 2>/dev/null | grep '^Version:' | awk '{print $2}')
    if [ -z "$version" ]; then
        version="Not installed"
    fi
    printf "%-30s %s\n" "$lib" "$version"
done

And these are the lib versions of the dependencies that I have installed at this time

build-essential                12.9ubuntu3
libffi-dev                     3.4.2-4
pkg-config                     0.29.2-1ubuntu3
cmake                          3.22.1-1ubuntu1.22.04.2
ninja-build                    1.10.1-1
gnome-desktop-testing          2021.1-2
libasound2-dev                 1.2.6.1-1ubuntu1
libpulse-dev                   1:15.99.1+dfsg1-1ubuntu2.2
libaudio-dev                   1.9.4-7build1
libjack-dev                    1:0.125.0-3build2
libsndio-dev                   1.8.1-1.1
libx11-dev                     2:1.7.5-1ubuntu0.3
libxext-dev                    2:1.3.4-1build1
libxrandr-dev                  2:1.5.2-1build1
libxcursor-dev                 1:1.2.0-2build4
libxfixes-dev                  1:6.0.0-1
libxi-dev                      2:1.8-1build1
libxss-dev                     1:1.2.3-1build2
libxkbcommon-dev               1.4.0-1
libdrm-dev                     2.4.113-2~ubuntu0.22.04.1
libgbm-dev                     23.2.1-1ubuntu3.1~22.04.2
libgl1-mesa-dev                23.2.1-1ubuntu3.1~22.04.2
libgles2-mesa-dev              23.2.1-1ubuntu3.1~22.04.2
libegl1-mesa-dev               23.2.1-1ubuntu3.1~22.04.2
libdbus-1-dev                  1.12.20-2ubuntu4.1
libibus-1.0-dev                1.5.26-4
libudev-dev                    249.11-0ubuntu3.12
fcitx-libs-dev                 1:4.2.9.8-5
libpipewire-0.3-dev            0.3.48-1ubuntu3
libwayland-dev                 1.20.0-1ubuntu0.1
libdecor-0-dev                 0.1.0-3build1

[kdschlosser]

ok try this...

replace this file lvgl_micropython/api_drivers/common_api_drivers/linux/lv_timer.py

with this one lv_timer.py.txt

you will need to remove the .txt extension

Then recompile it.

instead of using create_timer I created a thread that will handle the timers.

see if that works... I have not tested it, the idea is sound tho... we will see...

[androiddrew]

replace this file lvgl_micropython/api_drivers/common_api_drivers/frozen/other/task_handler.py

with this one lv_timer.py.txt

Are you sure you didn't mean to replace api_drivers/common_api_drivers/linux/lv_timer.py ?

[kdschlosser]

wow yeah your right.. don't know why I said to replace that one..

severe brain fart.

[androiddrew]

Ok, I did replace it...and my whole PC froze when I imported test_script.py. So I don't think that implementation works.

I really appreciate you looking at this. I have also been trying to get some other people trying to build this too. At present I think your VM is the only one I have seen that isn't just a black screen.

Seeing how at the moment I can manage the tick interface manually with this while loop I was instead focusing on the blank SDL display. I have SDL2 libs installed locally through apt and I got a working window running from another program

g++ 01_hello_SDL.cpp -w -lSDL2 -o 01_hello_SDL

I know we are statically building libSDL2.a and putting it in the ./lib/micropython/ports/unix/build/standard/SDL. I was trying to fiddle with some of the Cmake lines you had in unix.py but that didn't really do anything. I also don't know what I am doing here.

Is there a way we can just link the micropython to the sdl shared libs I have installed from apt?

Could you provide me all of the output from you own run of the make.py command? I'd like to compare it to what I am seeing on my end.

Should I be instead focusing on the lv_conf.h?

Last thing. When I run the micropython binary I get file SDLPointer_2 placed in the working directly after importing the test_script.py. I don't know if that is significant or not.

[androiddrew]

Btw I took the ./lib/micropython/ports/unix/build-standard/SDL copied it to my hello world SDL cpp project (Where I create a blue screen) and used it for the build. I can see with ldd that there is no longer any link to the libSDL2-2.0.so.0 on my system.

So I think this isn't an SDL compilation problem. I don't know where to go from here. Please advise!

[kdschlosser]

OK the reason why I am downloading SDL2 and compiling it is because of the versions that are available for a given Linux "flavor" and version. The problem is that the versions that are available on those package repos are not up to date. Not by a long shot.

what version of SDL2 is being installed from your package manager?

so this is what happens. These are the versions of SDL2 that are available for the different Ubuntu releases.

Ubuntu 20.04 (Focal Fossa): SDL2 2.0.10 Ubuntu 22.04 (Jammy Jellyfish): SDL2 2.0.20 Ubuntu 24.04(Nobel Numbat): SDL2 2.30.0

Version 2.30 is what is needed in order to run.

It is a HUGE amount of additional code to add to figure out the OS, and then figure out the package manager and query the package manager to collect what SDL2 version is being used to be able to determine if the version that is installed can be used or not. Because of all of the different package managers that exist across all of the different Linux flavors it becomes a monumental task to do that and to do it correctly without any problems.

SDL2 has a build system that is supposed to detect and set everything up so if it is not working then there is something that has to be missing.

write the build output to a file so I can inspect it and see what might be missing between mine and yours. Then we can get the missing pieces installed into your system and that should correct the issue. I will update the requirements once we know what is missing and when we get it working.

[kdschlosser]

to dump the output to a file run this as your build command..

python3 make.py unix mpy_cross submodules DISPLAY=sdl_display INDEV=sdl_pointer > build_output.txt

then attach that file to a post.

[kdschlosser]

it looks like you are running Ubuntu 22.04 which is not a high enough version to use the SDL2 that is available from the package manager.

[androiddrew]

Here is the output of the build command

lvgl_compile_out.txt

it looks like you are running Ubuntu 22.04 which is not a high enough version to use the SDL2 that is available from the package manager.

The package manager version of SDL isn't the problem though. I showed that I can use both the package lib and the static lib we build in this project to build a native cpp SDL binary that just creates a window and adds a background color. Also I have tried building this unix lvgl_micropython on both a Ubuntu 22.04 and an Ubuntu 24.04 both with the same results of a black screen.

[androiddrew]

Uh oh. I think something changed in https://github.com/lvgl-micropython/lvgl_micropython/commit/6d4b75d1e9f4d1c74c9f6f401a6f92928968f4b1. When I cloned fresh and used the same above test script I now get a Runtime error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test_script.py", line 42, in <module>
  File "sdl_pointer.py", line 15, in __init__
  File "pointer_framework.py", line 16, in __init__
  File "_indev_base.py", line 36, in __init__
RuntimeError: Display driver needs to initilized before indev driver

I added some print statements to check on the validation logic for that runtime error and I can see that

commit 058edd0c05d0d2301764c682ffc646e00d9b9159

displays = display_driver_framework.DisplayDriver.get_displays()
print("Driver Displays")
print(displays)

Output:

Driver Displays
[<SDLDisplay object at 7f4304819a80>]

But a build from commit ec536448fb0ea8bcbc7439d81b32dc39b601c7f7

Shows that the sdl display driver isn't being appended to DisplayDriver._displays

Driver Displays
[]

[kdschlosser]

ok the last problem you mentioned is fixed.

The unix port should also be fixed as well.

[kdschlosser]

All of the config settings for SDL2 were in alignment with mine.

The issue was because of writing the framebuffer data outside the main thread, Microsoft Windows does some magic to allot that to work but Linux, not so much.. So I moved the frame buffer being written to the main thread and that should solve the issue.

[androiddrew]

@kdschlosser I have some great news. This is very close to being resolved.

On commit e0b974e1b5e1d4967c86ed324892f9b486c50b86

I needed to modify:

diff --git a/api_drivers/common_api_drivers/display/sdl_display.py b/api_drivers/common_api_drivers/display/sdl_display.py
index 73bb140..9249297 100644
--- a/api_drivers/common_api_drivers/display/sdl_display.py
+++ b/api_drivers/common_api_drivers/display/sdl_display.py
@@ -100,7 +100,8 @@ class SDLDisplay(display_driver_framework.DisplayDriver):
             offset_y=offset_y,
             color_byte_order=display_driver_framework.BYTE_ORDER_RGB,
             color_space=color_space,
-            rgb565_byte_swap=False
+            rgb565_byte_swap=False,
+            _init_bus=False
         )

         self._data_bus = data_bus

and then manually push the SDLDisplay to display_driver_framework.DisplayDriver._displays.append(display) to get the example working.

Attached are my NOTES.md which has more details about what I was doing and the errors I encountered.
NOTES.md

test_lv.py.txt

[kdschlosser]

ok should be all fixed up now...

also. you no longer need to supply the submodules or the mpy_cross build commands. Those have been removed. If they need to be done then it will take care of doing what it needs to do. you also do not need to supply the clean command either. It will automatically clean the build prior to compiling. It will not remove SDL2 if it has already been compiled. using the clean command will remove SDL2

[kdschlosser]

good to know that it is almost all solved. Glad to have gotten the rendering portion all sorted, had to do some research to find out what could have been causing it.

[androiddrew]

@kdschlosser Just did a fresh build from commit 94109fb626f58d1067b7b1b708773e6a89b57420 with no intervention I could run the test script immediately. I'm going to close out this issue. Thanks for all the attention on this one.

[kdschlosser]

Thanks for reporting the problem and taking the time to work with me on solving the issue. makes it a lot easier to fix problems when the user knows how to debug and present information that is useful. Makes the process go a lot faster that's for sure. This was a tricky problem to deal with to be able to isolate where the actual problem was stemming from.

Just to let you know only one frame buffer is supported now because the buffer data has to be written from the main thread which is the same thread that LVGL is running in, no point to using double buffering if the main thread is not able to continue doing stuff while the buffer is being written. It will allow you to create the second buffer but it never gets sued for anything. So save the memory and don't make a second buffer because it will not get used. I left it that way for backwards compatibility. I am going to have it print out a message if the second buffer is used stating that it is not needed and doesn't get used at all.