Re: [AD] Supporting a new platform/device

[Mark Watkin <devhead@xxxxxxxxxxxx>]

Thanks for taking a look.

I've managed to get it past that now, had to set ALLEGRO_UNIX 0. 
Though found a tonne of other bits I needed to configure.

I also get reports of no audio back-end now, and I had to disable the 
Primitives library, as that started going on about linking OGL 
(despite turning that option off).

And finally, 


[ 62%] Linking C executable ex_dualies
/usr/bin/ld: ../lib/liballegro.so.5.2.7: undefined reference to `_al_joystick_driver_list'
collect2: error: ld returned 1 exit status
make[2]: *** [examples/CMakeFiles/ex_filter.dir/build.make:92: examples/ex_filter] Error 1
make[1]: *** [CMakeFiles/Makefile2:739: examples/CMakeFiles/ex_filter.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/usr/bin/ld: ../lib/liballegro.so.5.2.7: undefined reference to `_al_joystick_driver_list'
collect2: error: ld returned 1 exit status
make[2]: *** [examples/CMakeFiles/ex_dualies.dir/build.make:90: examples/ex_dualies] Error 1
make[1]: *** [CMakeFiles/Makefile2:768: examples/CMakeFiles/ex_dualies.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
odroid@goadvance:~/allegro5/build$


I'm getting a joystick driver list failure. Not really sure about this 
one, but then I've not looked much into it yet

Progress, but I don't think I'll get any more time tonight now.

What I'll probably do, is once I have this building (if I ever get it 
to work), I'll rename my local repo, delete my fork and refork, then 
migrate all the changes into a nice single neat pull request...

Cheers


Thursday, July 2, 2020, 9:59:43 PM, you wrote:

S> CMake thinks that this is still a Unix system, so it includes the 
S> src/unix/udrvlist.c in the source list which has a 
S> _al_register_system_interfaces. I note that if you look in that file, it
S> turns out to handle both X11 and Raspberry Pi. It might be the case that
S> you want to add the OGA stuff there if you're planning on using the unix
S> functionality.

S> I took a look at the GP2Wiz stuff, but I don't understand how it avoids
S> this issue, it might just be broken.

S> I took a look at the rest of the code, it seems fine.

S> -SL

S> On 6/30/20 9:43 PM, Mark Watkin wrote:
>> 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
>> 
>> 
>> 
>>