Re: [AD] Supporting a new platform/device

[SiegeLord <siegelordex@xxxxxxxxx>]

Hi Mark,

Let me answer your questions in-line.

On 6/24/20 5:40 AM, Mark Watkin wrote:
> Hello all,
>
>    I put a thread up on allegro.cc, but it's locked, so I thought I'd
>    reask here.
>
>    I want to get an Allegro build running on the Odroid Go Advance.
>    (https://www.hardkernel.com/shop/odroid-go-advance-black-edition-clear-white/)
>
>    It's a Linux machine, but the reference image doesn't have X11; and
>    the display uses KMS/DRM. I don't really understand all the
>    different driver components in Linux, but OtherCrashOverride has a
>    library for access the Go Advance hardware, and his "RetroRun2"
>    shows usage of EGL and GLES2
>    https://github.com/OtherCrashOverride/libgo2
>    https://github.com/OtherCrashOverride/retrorun-go2/blob/master/src/video.cpp
>
>
>    I created a "Toolchain-odroidgoadv.cmake" in the cmake directory,
>    but, building on the OGA just uses the regular linux toolchain (the
>    compilation only fails due to missing GL header files).
>
>    So is creating a new Toolchain file the right way to add support to
>    the device?

Generally you only need a toolchain file if you need to use a custom 
C/C++ compiler. Honestly, I think we use it too often. I'd use SDL 
driver as a good, minimal, example, which only requires setting 
ALLEGRO_SDL to `true` via `cmake -DALLEGRO_SDL=1` which then triggers 
everything.

>    I also then created a folder /src/odroidgoadv, and dropped in there
>    a file called ogajoy.c, which contains my inital joystick code
>    (based on the /src/sdl/sdl_joystick.c file), and I'll create
>    "ogadisplay.c" for the display and "ogasystem.c" for configuring the
>    system VTable, and just copy the majority from the linux base, but redirect
>    joystick and graphics to my new functions.
>
>    Again, is this the right way of doing it? And if so, what causes the
>    selection of the ALLEGRO_SYSTEM_INTERFACE?

The way the system driver registration works is that in system.c: 
https://github.com/liballeg/allegro5/blob/326fb49a6b979e43aa434f42925093d9b6e9b83d/src/system.c#L252 
we call _al_register_system_interfaces. This function is defined on each 
platform:

$ git grep 'void _al_register_system_interfaces' src 

src/android/android_system.c:void _al_register_system_interfaces(void)
src/gp2xwiz/wiz_system.c:void _al_register_system_interfaces(void)
src/iphone/iphone_system.c:void _al_register_system_interfaces(void)
src/macosx/system.m:void _al_register_system_interfaces()
src/sdl/sdl_system.c:void _al_register_system_interfaces(void)
src/unix/udrvlist.c:void _al_register_system_interfaces(void)
src/win/wsystem.c:void _al_register_system_interfaces()

The CMakeLists.txt makes sure that only one of those files is actually 
included in the library. For example, for SDL we have:

if(ALLEGRO_SDL)
    list(APPEND LIBRARY_SOURCES ${ALLEGRO_SRC_SDL_FILES})
    list(APPEND PLATFORM_LIBS ${SDL2_LIBRARY} m)
    include_directories(${SDL2_INCLUDE_DIR})
endif(ALLEGRO_SDL)

Where ALLEGRO_SRC_SDL_FILES is defined in cmake/FileList.cmake.

So, in summary, to create a new driver you at the minimum need to do the 
following:

1. Create a file which defines `_al_register_system_interfaces`.

2. In cmake/FileList.cmake a variable that mentiones that file.

3. In CMakeLists.txt add an option to select your driver. Make sure to 
turn off other platforms as necessary if your option is selected.

4. Add the variable from step (2) to the list of platform sources.

Now, it's interesting that you mention KMS and DRM. I'm actually trying 
to add a RPI4 KMS + DRM driver, so perhaps there's something that can be 
shared in these two backends. My code is sadly not yet ready however.

-SL