You can create C source files with functions and expose them to the GUI editor using the ESD_FUNCTION macro. (You can search the library sources for examples of this.)

RP2040 APIs can be used directly as in any regular RP2040 project. You can hide any code that accesses hardware from the GUI editor by putting it inside #ifndef ESD_SIMULATION guards, so you don't get compile errors in the simulation. (There's no simulation for hardware APIs currently, although as an alternative you could also provide your own implementation or validation stubs of hardware APIs inside a #ifdef ESD_SIMULATION guard, for debugging purposes.)

Below is an example of what does NOT work:

You're missing `BITMAP_HANDLE` before the `VERTEX2F` call. The display list is a state machine, so the draw depends on the state that's set. The handle is used to point to one of 32 bitmap states, which persist across frames. And don't forget `DISPLAY` at the end to end the display list, as it may contain garbage.

Also, you may be missing `BITMAP_SIZE_H` and `BITMAP_LAYOUT_H` calls, their previous state may contain garbage as well.

I recommend using the `EVE_CoDl_` convenience calls from HAL, such as `EVE_CoDl_bitmapLayout`, instead of App_WrCoCmd_Buffer etc, as they simplify compatibility and reduce mistakes. (e.g. `EVE_CoDl_vertex2f_4` includes logic to automatically switch vertex format if your coordinates are out of range, and `EVE_CoDl_vertexFormat` deduplicates redundant state change calls.)

Alternatively, instead of using the Esd_Loop function, reimplement this behaviour into your RTOS event loop.

Whenever you get an interrupt from EVE, push an event in your RTOS event loop, check if the current loop state is IDLE and the frame swap is done, and if so call Esd_Update and Esd_Render.

Instead of Esd_WaitSwap, you'll need a new function to check the swap (EVE_Cmd_rp(phost) == EVE_Cmd_wp(phost)) and also check EVE_CMD_FAULT(rp),
refer to EVE_Cmd_waitFlush and Esd_WaitSwap to see how the fault state is resolved correctly - it affects some internal state.
After cmd is swapped or reset, check if EVE_Hal_rd8(phost, REG_DLSWAP) == 0 --- this is just to catch any unexpected behaviour.

In this case Idle will only get called deep in the call stack while the command buffer is full (this should resolve quickly), so from there you can just pump any pending events in your RTOS event loop.

@Kaetemi, thanks for your answer,
Yes, the Idle function callback of the application could be used
for some cases, BUT it is called somewhat  'unpredictable' or multiple times.
  (see Esd_Loop()  =>  Esd_Update() : Idle at least once every frame)
Thanks!

For all the Idle calls that are done during the WaitSwap step, LoopState will be set to ESD_LOOPSTATE_IDLE.
Any other Idle calls that may be done deep in the call stack may have update or render loop state set instead.

As far as the multiple calls, it seems okay to just check in the Idle call if the low power state was already enabled to deduplicate.
Maybe a single IdleEnd call after each batch of Idle calls may be useful to restore back to full speed, though...

Do you have any reference device with power management and a reference RTOS to see how this can be integrated in practice?

* In contradiction to the EVE concept of a co-processor for offloading host MCU from graphics drawing,
   the ESD generated source has an endless, fulltime burner loop for repeated Updates/Render (about each 5-20ms), even if the HMI didn't change!!??
   What is the rational behind this?
   Any chance for changing (in near future) to an event-driven (dirty-state => refresh) model?

It's a simple loop that's familiar to Arduino users. It's also common in games. EVE has a bit of a background in both of those.
It makes things easy to understand for new developers who are already familiar with that style.
For animations it's also convenient.

Having it only run the loop when necessary is feasible, but it'll need more care from developers to flag when a refresh is needed.

     - RTOS unfriendly.
     - this is energy-unfriendly if battery powered.

That said, when the ESD Core library is waiting for something it'll spin on the Idle function callback of the application.
You might be able to take advantage of that call to enter a low power mode when ESD Core is doing nothing, and just go back into full speed based on some interrupt.

It'll spin on Idle in two situations:

• When in-between frames, and waiting for the display list to swap. This is called from the main loop directly
• Whenever writing to the coprocessor, and the coprocessor space is full. This is can be called very deep in the call stack

If you want to integrate with an RTOS event loop, then you can just use that event loop, and call the inner loop function once whenever EVE signals a frame swap (and disable the display list swap wait).
Ideally you'll also want to enter into your event loop from that second Idle situation. Mask out any events that would affect the ESD library while it's waiting. Exit the event loop whenever EVE sets some interrupt.

Do you have any reference device with power management and a reference RTOS to see how this can be integrated?

     - what about the touch-input tags repeatedly getting swapped out+in?

Not sure what you mean by this?

* There is a well hidden document BRT_AN_073 for porting ESD source to STM32L4.

That port has not been actively maintained and tested, as far as I know, so not sure what its state is.

3) Same as PushButton, but you'll need to hack Esd_TouchTag to force allocate a specific TAG in s_TagHandlers. (Make a copy of Esd_TouchTag_Start, but with // Allocate tag replaced to just pick the TAG that you need.) The TAG of each key is simply the ASCII code of the character. Then you'll either need an instance of Esd_TouchTag for each key in the CMD_KEYS, or extend it to support a whole range of tags in a single instance instead of just a single Tag. (At // Tag set if (s_TagDown == context->Tag), compare with a range instead, and set context->Tag to s_TagDown whenever the range is matched there.)

You can create your display list as your originally planned, then swap it, and create a second duplicate of it. Then you can just edit the vertices as you planned, but then swap between the two copies of your display list each time.

Does the currently produced emulator executable accept command line arguments to allow passing the Flash package name and if so please would it be possible to share the syntax required?

The emulator executable is simply your own application, with your main function.

You can handle arguments as any normal C program, and replace the interactive initialization with a programmatic initialization.