Re: [AD] Supporting a new platform/device

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/