goatcorp
[Linux] Game launches, but crashes when going to 'system configuration' due to monitor duplication issue presenting 8 monitors to game
Hello,
This issue was not originally found by myself, but I did experience it myself yesterday.
Searching the discord, I found a workaround, and some mention that it can be fixed, but I have not seen anything tracking this bug officially, nor any indication that it is being worked on, so I figured I'd post it here.
Short version: Using dxvk and default settings appears to be doubling the amount of available monitors being sent to the game. The game cannot handle 8 being sent to it and crashes. Disabling dxvk and switching to vulkan renderer stops the monitor doubling and allows the game to properly see the correct number of monitors.
Longer Details: When you have 4 monitors (on a single video card in these 2 examples, don't know if that matters, but that was the case here), and are using default settings, the game crashes if you go to the 'system configuration' menu with a dx11 error. Example here:
Usagi on discord helped another user diagnose and workaround this issue back in August. First, they had them disconnect 1 monitor, to bring the total down to 3. This worked, but resulted in the 'system configuration' menu showing SIX monitors instead of 3, with each monitor duplicated:
Usagi then suggested that the user disable dxvk, and switch the renderer to Vulkan via a registry edit, supposing that when 4 monitors were attached, it was actually passing EIGHT total to the game, and the game could not handle that many, and crashed.
I followed this advice myself, and it worked for both the original user, and myself, showing only the correct number of monitors in the system configuration menu, and not crashing the game after disabling dxvk and switching to the vulkan renderer. Examples:
Usagi on discord then commented that this is potentially fixable (the doubling of the monitors being passed to the game) either via a plugin, or with xlcore modifications, but I have not seen any progress on this issue anywhere since then.
I can see how people with 1, 2 or 3 monitors would regard this as only a visual/UI bug, and since it does not cause crashes at those numbers, it is low priority. However, it has been shown that this is now a crash bug at higher monitor counts.
Vulkan works, but with graphical issues and stutter issues for me on this. I would prefer to use dxvk and all the default settings.
Edit: This bug appears to ONLY Manifest in the Flatpak version (so far). I will be testing additional versions myself as well and verify if it is, or is not, in other versions. Details will be added below as I test other options.
~~Request to merge https://github.com/goatcorp/XIVLauncher.Core/issues/266 and this issue, as it has been discovered that they are the same issue.~~
Not the same issue afterall, however @rankynbass is also experiencing the monitor duplication issue with the Flatpak only.
Please don't merge these. I only have 2 monitors and they each have their own GPU.
Additional rationale cross-posted:
I don't see any evidence of duplicate monitors in my case, I don't think there's sufficient evident to merge these (at least not based on the information available in the other report).
Most importantly my game isn't crashing for performance reasons, it crashes when it tries to illegally access memory it shouldn't.
Its very clearly attempting to map the same region in memory here: Mapped memory region 0x7fc9f4000000 - 0x7fc9f7ffffff that it shouldn't, throws up a dx11 error message box, does not exit w/ 139, waits for me the user to close the program while it keeps trying to map that region in memory, and then exits 0.
Posted from the other thread (#266), since they're apparently not the same issue:
I've tested this with a local install (rpm) an AppImage, and the flatpak. The monitor duplication issue is only happening for me on the flatpak. Nvidia GPU, multiple versions of wine and dxvk tested.
Edit: XLM with native steam is also safe. Only one monitor shown.
I can confirm the PPA Version also does not have this issue.
At this point, it looks like it's specifically with the Flatpak version. Which is annoying but good that it's easily workaround-able by using a different one.