I have a different issue with this game and was told to post it here.

EDIT : Thanks to @JacobSvenningsen I also upgraded Mesa to 25.1.2 and the issue seems to have disappeared !

System Information

OS : Debian Trixie (13)
CPU : AMD Ryzen 7 9800X3D
GPU : AMD RX 7800 XT
Mesa version : 25.0.5 [Issue fixed with 25.1.2]
Kernel version : 6.12.27
Proton version : Tested with 9.0.4, Experimental and Hotfix
Game version : 1.3.2 (Latest)
No mods used
Steam Runtime System Information

Description

I purchased the game around the end of April and enjoyed it bug-free for around a week, then I did a system update and since then, every time I load the game, a single PAK file will fail to load entirely. In game this means missing textures and models (showing as white blobs), and occasionally crashes during loading if it hits a critical file.

In the logs, this shows as a plethora of lines with "[ERROR] ReadFile returned 1". But the truly bizarre part of the bug ? Every time the game is launched, the affected PAK file changes, meaning a whole new set of corrupted textures. And of course the previously affected PAK file miraculously works again so it's not a matter of corrupted files.

Affected files (for now)

data\characters.pak
data\hlod_prefab.pak
data\ipl_characters-part2.pak
data\ipl_characters-part3.pak
data\ipl_objects-part0.pak
data\ipl_objects-part1.pak
data\ipl_objects-part3.pak
data\ipl_objects-part4.pak

Reproduction

Start a new game or load a save

Things I tried

• System updates
• Validating game files (including deleting all PAK files to force re-download)
• Purging shader cache

Examples

Launch No 1 (Notice the missing texture on the guard)

Game log

Launch No 2 (Notice the missing texture for the road, buildings and vegetation in the center)

Game log

Additional files

Proton log
DPKG log of the related update

Managed to resolve it.
Went ahead and followed some bad practice and installed the mesa packages from Kisak PPA, bringing Mesa to 25.1.2
Currently it's working using that version of Mesa and using Proton 10.0-1 (beta).

Original post:

I have a different issue which prevents the game from working altogether.

System Information

OS : Debian Sid
CPU : AMD Ryzen 9 7900X3D
GPU : AMD RX 7800 XT
Mesa version : Initially 25.0.5-2. Then upgraded to 25.1.0-1
Kernel version : Initially 6.12.30-1. Then tried upgrading to 6.15.1
Proton version : Tested with 9.0.4, 10.0-1 (beta), Experimental, Hotfix and even Glorious Eggroll 10-4
Game version : 1.3.2 (Latest)
System diagnostics

Description

Back in February and March, I played the game extensively with no real issue, but trying to run the game again yesterday, I'm greeted with one of three outcomes:

• The splashscreen shows up and nothing more happens
• A black screen pops up. Alt-tabbing reveals the splashscreen is still present
• Intro logos are being displayed and as soon as the EULA, DLC screen information, or the main menu is reached, it freezes.

When the last outcome occurs, the music is still playing and the cursor can be moved. Pressing one of the buttons, plays a sound which could indicate that the button was actually pressed.
It feels driver related, and it might not be Proton specific. Scouring the internet, it seems Windows users are reporting similar issues, which sometimes are reported to be fixed by a reboot, removing the game's shader cache or a driver update. Deleting the game's shader cache can lead to the last outcome (freeze at main menu) to become more likely, but doesn't resolve anything.

Tried upgrading mesa, the kernel, tried different proton version and reinstalling the game to another drive.

Additional files

Log when the main menu is reached
vulkaninfo
kcd.log
kcd_launcher.log

Managed to resolve it. Went ahead and followed some bad practice and installed the mesa packages from Kisak PPA, bringing Mesa to 25.1.2 Currently it's working using that version of Mesa and using Proton 10.0-1 (beta).

Holy crap you just fixed my issue too ! Looks like it is a problem with Mesa 25.0 then.

the bluetooth Xbox controller is not seen by the game

Same here on Arch Linux with Proton 10.0-3. Steam input is disabled.
Connected Gulikit ES Pro controller (Xbox controller) via Bluetooth or USB cable does not work in game, seems related to the last patch, according to this thread

A workaround for now is launching the game with:

SteamDeck=1 %command%

My Dualsense controller works OK, both via Bluetooth or USB cable.

Indeed, the controller doesn't work on Linux, and Warhorse will likely not address it, as it's unsupported platform, so all hope in Proton.

Considering the growth of steamos and the new steam machine I'd think they would put some resources into supporting linux.

I can use ge proton 9-27 with SteamDeck=1 %command% but using proton 9 for whatever reason causes laggyness that I don't see in proton 10 with kb/mouse.

i see there is more xbox issues. As a sidenote, i'm using both of them with an usb cable.

steam-1771300.log

https://gist.github.com/sorenfrey-blip/4bd474fde75ed1b51c94302c7bdd1d20

Updating gfx driver worked

Controller workaround, works for my Handheld with Nobara, should work on other devices too.
https://github.com/SprtnDio/kcd2controllerfix_linux_handheld

I'm experiencing the same freeze symptom. Game runs fine for ~10-60 minutes, then the image freezes while audio continues playing. No Xid errors in kernel logs, no OOM, no compositor crash.

System

• Framework Laptop 16, AMD Ryzen AI 9 HX 370, NVIDIA RTX 5070 Laptop GPU (8 GB VRAM)
• NVIDIA 580.126.18 (open), kernel 6.18.7-76061807-generic
• Pop!_OS 24.04 LTS (COSMIC, Wayland)
• Proton Experimental (10.1000-200) and Proton 10.0-4 — both affected
• Game settings: Ultra, 2560x1600, DLSS upscaling, vsync on

GPU monitoring data during freeze

I ran nvidia-smi polling every 5 seconds. The freeze pattern is clear:

timestamp,                  memory.used, temperature.gpu, utilization.gpu
2026/04/06 15:26:49.567,    6296 MiB,    51,              51 %    ← normal gameplay
2026/04/06 15:26:54.591,    6296 MiB,    59,             100 %    ← freeze starts here
2026/04/06 15:27:04.637,    6296 MiB,    63,             100 %
2026/04/06 15:27:34.774,    6296 MiB,    66,             100 %    ← peak temp
2026/04/06 15:28:14.941,    6296 MiB,    47,             100 %    ← temp dropping
2026/04/06 15:29:55.312,    6296 MiB,    42,             100 %    ← still 100% but cold

Key observations:

• GPU jumps from ~50% to 100% utilization at the moment of freeze
• VRAM stays constant at 6296 MiB (not hitting the 8 GB limit)
• Temperature drops from 66°C to 42°C while utilization stays at 100% — the GPU reports busy but isn't actually computing (silent hang)
• No Xid errors in dmesg or journalctl
• kernel.split_lock_mitigate=0 did not help

This looks like a silent GPU hang in the Vulkan presentation/submit path — the GPU is stuck in a loop reporting 100% but doing no real work.

Compatibility Report

• Name of the game with compatibility issues: Kingdom Come Deliverance 2
• Steam AppID of the game: 1771300

System Information

• GPU: RTX 3070
• Video driver version: nvidia-open 595.58.03
• Kernel version: 6.19.14-arch1-1
• Link to full system information report as Gist: https://gist.github.com/Oreo412/bfeb18d8a3959ba0a89bfd8103595b9f
• Proton version: I've tried 9.0-4, 10.0-4, experimental, hotfix and GE

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

Symptoms

When starting the game, it will most likely crash sometime between starting and about a minute into the game. If I can get past about a minute of actually being loaded into a save, it'll work perfectly fine for however long I play it. I've played the game for hours without any issue once I've gotten past that initial chance of it crashing. I often have to restart my PC many times though to be able to get past that initial chance.

Reproduction

Every time I start the game, there's a chance that it crashes

KCD2 controller bug — root cause found (Microsoft GameInput service fails under Proton/Wine)

This is a follow-up on the long-running controller thread. I found what appears to be the actual root cause of why no Xbox/compatible controller works in KCD2 1.5.6 under Proton, and it explains why the SteamDeck=1 / physical-DualSense workarounds behave as they do.

Summary

KCD2 (1.5.6, here the GOG build via a Steam non-Steam shortcut / Heroic, same .exe) uses the Microsoft GameInput API through its WhGdk.dll. Microsoft's GameInput redistributable is explicitly "Wine-aware" (v2.0+), and the real runtime does load under Proton when the redistributable is installed into the game's active prefix. However, its companion GameInputRedistService.exe starts and then immediately exits because it depends on Windows components Wine/Proton does not provide. Because the service cannot stay running, GameInput enumerates zero devices, and the game permanently reports:

Input device added: 4, controller type: 3, is connected: 0, name: 'xinput0'
Input device added: 4, controller type: 4, is connected: 0, name: 'scepad0'

No controller (real or uinput/uhid-emulated; Xbox, DualSense, Steam Deck presentation, or Steam Input) can be enumerated through this path.

Evidence (from WINEDEBUG=+hid,+rawinput,+dinput,+ginput,+gameinput, attached log)

The controller itself enumerates correctly at Wine's HID/SDL level (here an emulated DualSense 054c:0ce6 emitting valid 64-byte HID input reports to /dev/hidraw9):

hid:hidraw_device_create ... /dev/hidraw9, desc {vid 054c, pid 0ce6 ...}
hid:bus_main_thread creating hidraw device 054c:0ce6 with usages 0001:0005
hid:sdl_add_device controller id 0 ... desc {vid 054c, pid 0ce6 ... is_gamepad 1}

With the real GameInput redist installed and gameinput.dll overridden to native, the Wine stub message (fixme:ginput:GameInputCreate ... stub!) disappears and GameInputRedistService.exe starts:

PE ... Deferred gameinputredistservice
00000064 (D) C:\Program Files\Microsoft GameInput\x64\GameInputRedistService.exe

But the service then exits. Its dependencies fail:

fixme:combase:RoGetActivationFactory (L"WindowsUdk.Services.OneSettings.OneSettingsManager", {1ea95298-8257-597f-ac75-a3052e439cab}, ...): semi-stub
err:combase:RoGetActivationFactory Failed to find library for L"WindowsUdk.Services.OneSettings.OneSettingsManager"
err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\winebth": c0000142
fixme:service:scmdatabase_autostart_services Auto-start service L"winebth" failed to start: 1114

Result: GameInputRedistService cannot stay running, so the GameInput runtime enumerates no devices and the game never marks a pad connected.

Why the workarounds behave the way they do

• Physical DualSense works / Xbox doesn't (seen across this thread): the game has a separate Sony path (scepad0) that reads the DualSense via HID directly; Xbox controllers have no such alternate path and are fully dependent on the GameInput service. So a real DualSense bypasses the broken service, but no Xbox controller can.
• SteamDeck=1 does not make the game enumerate a controller — it only toggles a UI/input-layout flag. It does not fix the GameInput service.

Suggested fix direction

1. Provide a Wine stub/implementation for WindowsUdk.Services.OneSettings.OneSettingsManager (or make the GameInput service tolerate its absence rather than exiting).
2. Fix winebth (Bluetooth HID host driver) so it loads and reports HID devices.
3. Alternatively, implement Wine's own GameInputCreate to enumerate HID/SDL gamepads directly, bypassing the native service requirement.

Note on the prefix

The GOG game here actually runs in a nested prefix (compatdata/2798862691/pfx/pfx/, the inner pfx), not the outer pfx. DLL overrides and the GameInput redist must be placed in the inner prefix for them to take effect. This is easy to miss and may affect other reports.

Attached: steam-2798862691.log.gz (full WINEDEBUG=+hid,+rawinput,+dinput,+ginput,+gameinput trace, gzipped).

Full WINEDEBUG=+hid,+rawinput,+dinput,+ginput,+gameinput trace from the root-cause run (gzipped, base64-encoded):

https://gist.github.com/KarolisGl/ccd99e7a8932d03661f909e7984310d3

Decode with:

curl -L <gist-raw-url> | base64 -d > steam-2798862691.log.gz && gunzip steam-2798862691.log.gz

Follow-up: verified working fix (DualSense emulation + enabling hidraw)

Following my earlier post on the GameInput service: I now have a verified working fix on KCD2 1.5.6 (GOG build via Steam non-Steam shortcut / Heroic). Input works in-game. It does not require fixing the GameInput service — it routes input through the game's separate Sony (scepad0) path instead.

What works

Two parts are required together:

1. Present an Xbox controller as a native DualSense using InputPlumber's ds5 UHID target. This creates a real Sony Interactive Entertainment DualSense Wireless Controller (054c:0ce6) + /dev/hidraw node with valid 64-byte HID reports.

2. Enable hidraw in the prefix — Proton ships DisableHidraw=1 (SDL-only) by default, which hides Sony devices from Wine's native hidraw path. Set it to 0:

   • $PREFIX/pfx/system.reg, key [System\\ControlSet001\\Services\\winebus]
   • "DisableHidraw"=dword:00000000

With both, kcd.log changes from scepad0 ... connected: 0 to:

CScePad::SetControllerType(), m_ControllerType: DualSense

and the pad connects and works in-game.

Why this matches the thread's observations

• A physical DualSense works because the game reads Sony pads via HID (scepad0); hidraw is exactly that path. The emulated DualSense satisfies the same path.
• Xbox controllers fail because the game has no working Sony path for them and the Xbox/GameInput path is broken — this fix sidesteps both by turning the Xbox into a DualSense.

Notes / caveats

• PS button prompts appear in-game (the game detects a real DualSense identity). controls_force_xbox_layout=1 in attributes.xml does not override this — KCD2 has full native DualSense support and uses PS prompts whenever it detects the Sony device. There is no config that shows Xbox prompts while a DualSense identity is connected.
• InputPlumber's ds5 UHID target binds to a real udev-backed controller. A pure uinput virtual source is not bound by the udev dev_node matcher.
• Full step-by-step (including running InputPlumber as a normal user via an isolated D-Bus session): see https://github.com/SprtnDio/kcd2controllerfix_linux_handheld for the profile approach + the DisableHidraw=0 registry change above.

Hope this saves someone the multi-week rabbit hole.