Re: [AD] Supporting a new platform/device

[Mark Watkin <devhead@xxxxxxxxxxxx>]

So there was a bit of back and forth between my OGA and my desktop 
(https://github.com/pmprog/allegro5/commits/master)

I've managed to "fix" my code errors, but I'm having trouble building.

odroid@goadvance:~/allegro5/build$ make -j2
[  6%] Built target copy_demo_data
[ 12%] Built target copy_skater_data
[ 13%] Linking C shared library lib/liballegro.so
[ 28%] Built target copy_example_data
[ 28%] Built target docs
/usr/bin/ld: CMakeFiles/allegro.dir/src/odroidgoadv/oga_system.c.o: in function `_al_register_system_interfaces':
/home/odroid/allegro5/src/odroidgoadv/oga_system.c:170: multiple definition of `_al_register_system_interfaces'; CMakeFiles/allegro.dir/src/unix/udrvlist.c.o:/home/odroid/allegro5/src/unix/udrvlist.c:46: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/allegro.dir/build.make:1076: lib/liballegro.so.5.2.7] Error 1
make[1]: *** [CMakeFiles/Makefile2:694: CMakeFiles/allegro.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
odroid@goadvance:~/allegro5/build$


I don't really know why I'm getting duplicate 
_al_register_system_interfaces, as far as I can tell, I'm copying the 
GP32Wiz one closely enough.

Any ideas?

 Cheers


Friday, June 26, 2020, 8:47:51 PM, you wrote:

MW> Hello SiegeLord,

MW>  Thanks for the reply.

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

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

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

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

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

MW>  Regards,
MW>    Mark


MW> 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