Re: [AD] Supporting a new platform/device

[Mark Watkin <devhead@xxxxxxxxxxxx>]

Hello SiegeLord,

 Thanks for the reply.

 I've made an incomplete commit here: https://github.com/pmprog/allegro5/commit/b0908beb1f5ecb9cbb5c40ed7678d7758c5c859b

 I don't suppose you wouldn't mind just giving it a quick glance over
 to make sure I'm heading in the right direction. I ended up looking
 at a mix of the SDL and Wiz configuration, because aside from the
 toolchain, the Wiz is more akin to the OGA.

 So I think I'm on the right lines, but didn't want to waste all too
 much time for you to turn around and say "Nar, you didn't wanna do
 that" to quote Harry Enfield.

 As I mentioned, I don't really understand Linux drivers, or the
 display systems, however, the libgo2 library I linked does wrap that.
 I was just going to use that, but if it turns out that we could share
 some codebase, then yes, that would be better. Maybe the libgo2
 KMS/DRM wrapper might help you with some of your KMS/DRM code?

 I guess one of my other problems, is I can't even test what I have
 written, because of the lack of the video driver aspect. I hope the
 joystick code is okay. I checked how to use libgo2 in a test project,
 and use the same style as the wiz for threaded state comparison.

 Regards,
   Mark


Thursday, June 25, 2020, 8:00:57 AM, you wrote:

S> Hi Mark,

S> Let me answer your questions in-line.

S> 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?

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

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

S> $ git grep 'void _al_register_system_interfaces' src 

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

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

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

S> Where ALLEGRO_SRC_SDL_FILES is defined in cmake/FileList.cmake.

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

S> 1. Create a file which defines `_al_register_system_interfaces`.

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

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

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

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

S> -SL