drivers: display: sdl: Ensure draw is performed from init thread

[faxe1008]

Add a thread to the SDL display driver to ensure that init and renderer calls are performed from the same thread.

Fixes #71410.

Ping @Finomnis @PetervdPerk-NXP

[VynDragon]

Tested functionaility, works. Looks like it makes sense and i see no issue with code.

[aescolar]

Thank you very much @faxe1008

[aescolar]

Honest question: Given that it seems this sdl_thread is a thread meant only to call the bottom , how do you expect this to happen?
(same comment for sdl_display_blanking_*)

[faxe1008]

Very good question. Currently the handling of input events happens in another thread:
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/native/common/sdl/sdl_events.c#L20

So when adding logging to see where write, SDL event handling and input callback are invoked I get this:

sdl_display_write  THREAD ID: 0x61cb80
sdl_handle_events  THREAD ID: 0x510980
sdl_input_callback THREAD ID: 0x510980

I feel like this needs to also happen within the sdl thread that I am adding here, since there is also manipulation of the renderer going on within sdl_handle_window_event (https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/native/common/sdl/sdl_events_bottom.c#L16) . Eventually this means that sdl_input_callback callback will happen in the same thread as sdl_display_write if one selects CONFIG_INPUT_MODE_SYNCHRONOUS. Currently since the msgq can only hold one item this would be an issue, I think. Maybe @Finomnis can chime in here since this concern was originally raised by him.

[PetervdPerk-NXP]

Running my code with both SDL_DISPLAY_USE_HARDWARE_ACCELERATOR=n and SDL_DISPLAY_USE_HARDWARE_ACCELERATOR=y gives me this checkerboard.

The code seems to be running and accepting inputs based on looking on the console output.

Addressed

[aescolar]

Yeah the mutex needs to protect that as well.

@faxe1008 I look forward to that last change, so I approve :)

[Finomnis]

I'd put the default priority way lower, I'd almost argue I'd put it to the lowest priority possible. Otherwise low priority threads calling draw functions would cause a priority inversion.

Is there a way to use priority inheritance to bump this priority dynamically when higher priority threads are waiting for this?

I know mutexes can do priority inheritance, right? Is there a way to achieve the same with the semaphore?

[aescolar]

@Finomnis note this is only for native_sim, where you are not constrained like in an embedded device.
But more importantly note that this thread would only get unblocked if the thread that wants to draw has just been scheduled. So even though this thread has high priority, it is only running as a result of that requesting thread running.
=> A high priority for it seems sensible in my eyes.

[Finomnis]

Ok :)

[faxe1008]

Changed the default priority to NUM_PREEMPT_PRIORITIES.

[pdgendt]

@faxe1008 note for the future: do not add Fixes #.... to the commit message body as per the guidelines.