| Re: [AD] Supporting a new platform/device |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Okay, so got it to compile finally, but basically, the majority
doesn't work.
I can run ex_monitorinfo and ex_nodisplay fine.
Most tests gave me the following error:
Thread 1 "ex_drawpixels" received signal SIGSEGV, Segmentation fault.
al_get_bitmap_flags (bitmap=bitmap@entry=0x0)
at /home/odroid/allegro5/src/bitmap.c:331
331 if (bitmap->parent)
(gdb)
Any ideas?
I also added a keyboard test to the bottom of ex_nodisplay
------------------------------------------------------------------------
ALLEGRO_KEYBOARD_STATE kstate;
al_install_keyboard();
al_get_keyboard_state(&kstate);
while(!al_key_down(&kstate, ALLEGRO_KEY_A))
{
if(al_key_down(&kstate, ALLEGRO_KEY_Z)) { printf("z"); }
if(al_key_down(&kstate, ALLEGRO_KEY_X)) { printf("x"); }
al_get_keyboard_state(&kstate);
}
------------------------------------------------------------------------
However, this didn't seem to register any of the keypresses on the
keyboard I'd attached to the USB port. Though whether this is
something to do with my Allegro build, or Linux picking up on the
keyboard, I'm not 100% on. The reference image OtherCrashOverride
provided doesn't seem to let me open a BASH shell, and he's
purposefully patched out keyboard support in his EmulationStation
build.
Now, there is a seperate OS image, based around developing on the OGA
with a Wayland desktop, so I might try compiling and running under
that to see if that makes a difference. But other than that, I don't
really know what to do about the keyboard either.
Cheers
Friday, July 3, 2020, 8:02:11 PM, you wrote:
MW> Thanks for taking a look.
MW> I've managed to get it past that now, had to set ALLEGRO_UNIX 0.
MW> Though found a tonne of other bits I needed to configure.
MW> I also get reports of no audio back-end now, and I had to disable the
MW> Primitives library, as that started going on about linking OGL
MW> (despite turning that option off).
MW> And finally,
MW> [ 62%] Linking C executable ex_dualies
MW> /usr/bin/ld: ../lib/liballegro.so.5.2.7: undefined reference to `_al_joystick_driver_list'
MW> collect2: error: ld returned 1 exit status
MW> make[2]: *** [examples/CMakeFiles/ex_filter.dir/build.make:92: examples/ex_filter] Error 1
MW> make[1]: *** [CMakeFiles/Makefile2:739:
MW> examples/CMakeFiles/ex_filter.dir/all] Error 2
MW> make[1]: *** Waiting for unfinished jobs....
MW> /usr/bin/ld: ../lib/liballegro.so.5.2.7: undefined reference to `_al_joystick_driver_list'
MW> collect2: error: ld returned 1 exit status
MW> make[2]: *** [examples/CMakeFiles/ex_dualies.dir/build.make:90: examples/ex_dualies] Error 1
MW> make[1]: *** [CMakeFiles/Makefile2:768:
MW> examples/CMakeFiles/ex_dualies.dir/all] Error 2
MW> make: *** [Makefile:130: all] Error 2
MW> odroid@goadvance:~/allegro5/build$
MW> I'm getting a joystick driver list failure. Not really sure about this
MW> one, but then I've not looked much into it yet
MW> Progress, but I don't think I'll get any more time tonight now.
MW> What I'll probably do, is once I have this building (if I ever get it
MW> to work), I'll rename my local repo, delete my fork and refork, then
MW> migrate all the changes into a nice single neat pull request...
MW> Cheers
MW> 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
>>>
>>>
>>>
>>>