Keyboard/Mouse unresponsive at launch (Apple M2, aarch64-linux) #941
Comments
|
Your startup log looks completely normal. The unknown event is likely As an aside, the only unexpected thing is that your implementation does not seem to support Back to the original problem, the only thing I can think of is SDL which provides windowing, events, and keyboard/mouse input handling. How did you install your SDL library and what version is it? We know the game compiles and runs fine on arm64, but is officially tested on this arch using macOS not linux. It would be cool to get this working if possible. |
Here's the result of I haven't had any issues with SDL on this system (whether the game is from Debian packages, or compiled). I'm assuming the SDL instance is probably fine, unless Doom 3 requires some bleeding edge version, or some kind of extension not provided in Debian packages. How can I get SDL to ignore the unknown event |
|
The SDL version seems fine (needs to be sdl2). Unknown events are ignored by default, so no worry there. Wayland might be an issue - I have never tried it personally, although others use it successfully. And if I understand it correctly, XWayland is an X compatibility layer on top of Wayland, so that could be something to look into. Some suggestions for now:
|
Ran some tests (took a while cuz I messed up or corrupted Anyways, I don't have any controllers plugged into the laptop (in fact I ran these tests with no USB devices or Bluetooth mice just in case). I'm gonna skip the loading files/Vulkan/OpenAL part straight to the tail of what the terminal reads, but I'll have the full logs available as files: Normal run
|
|
Thanks for testing so extensively. All of these combinations and logs show expected behaviour, but unfortunately don't give much of a clue regarding the underlying problem. If you are able to use a debugger, I would be interested in starting with basic keyboard input. The file in question is <your_RBDoom3BFG_install_dir>/neo/sys/sdl/sdl_events.cpp. In this file, look for Place a breakpoint on the indicated line above then start the game. After you see the game selector screen, simply hit "enter" (to select a game) and the breakpoint should be hit. What is the value of If you get nothing I guess you could go a level up and check for all SDL events by looking in the same file at: |
|
Did both the breakpoint for |
|
You can figure out which SDL path is being used by adding the following line to CMakeLists.txt: Note you can also set
|
|
I have some great news!!! Seems like I figured out the SDL issue, played around with cmake: if I add Perhaps the issue was that for Debian systems, it tries to look in Issue 1: SegfaultFinally able to use input in the game, I tested everything I could (doom 1 & 2 work ok it seems). In the main game for some reason I get a I understand this really doesn't say much, so if there is a more verbose mode I can launch the executable in, I'd be happy to do so to figure out exactly at what point it is crashing. I made sure that it is not an out-of-memory issue (which would surprise me in a 24 GB system). Perhaps it's something to do with the way I installed the game itself (which I redid like twenty times today) Issue 2: correct way of installing, copying, overriding base/I've tried messing around with gamefiles, I dont want to list every permutation here, but what is the correct way to install the game files for an If I simply use the GOG |
|
Good news re solving your SDL issue. Regarding issue 1: Can you run inside the debugger and provide the stack trace following your segfault. I'd like to know specifically where it fails. Regarding issue 2: The proper way to install for linux (all arches) is to follow the instructions at: https://github.com/RobertBeckebans/RBDOOM-3-BFG?tab=readme-ov-file#compile_linux. After copying the original base folder from Steam or GOG, you can apply 1.3 base over top and then 1.5.1 base over the top of that. Afterwards follow the instructions carefully and run One thing you have not mentioned so far regarding running on arm64 is getting the right binary for DXC. DXC is important since it is the SPIRV compiler for the game's GPU shaders and RBDoom3BFG will not run without it. I believe DXC is precompiled for x86_64, unless you are building it yourself. For macOS x86_64 and arm64 it comes precompiled with the Vulkan SDK. However, for linux the Vulkan SDK is only available for x86_64. How are you getting the correct DXC binary for linux on arm64 - are you compiling it yourself or installing it via your linux package manager (if available)? |
System
Vulkan (backstory)
Since the Asahi project recently added conformant Vulkan support, I decided to compile some Vulkan games. The system runs the
vkcubemodel as well as GZDoom and vkQuake perfectly, but I wanted something that actually has some nice visuals and thought of RBDOOM-3-BFG's move to Vulkan.How I installed Doom 3
Anyways, there's no aarch64-linux build of Vulkan SDK, so I first compiled Vulkan SDK, added the binaries to
$PATH, compiled RBDOOM-3-BFG, copied thebase/from the latest patched install ongog.com.The problem
Launching the executable opens a window, loads the screen where you select Doom 1, 3, or 2, plays the music, but I have no mouse cursor to move around nor does it respond to any keyboard input. Given this odd platform (aarch-64-linux) I have to compile most of my games. Thus far, I haven't had any issues with other 3D games utilizing SDL and Vulkan/OpenGL, so I think the system (Mesa, Vulkan, SDL) are functioning correctly. The
stdoutproduces some missing file errors, however not sure if that's causing the no input issue. I've tried the originalbase/from GOG, as well as applying the 1.3 or 1.5 patches from Moddb (one of them didn't launch the game at all, the other launched and same no input result).stdout
Here's the
stdout. I am determined to get this port working, so I am willing to do further tests and provide whatever info necessary.The text was updated successfully, but these errors were encountered: