Compatibility Report

Looks like a game bug, there's a use-after-free on a texture that can be observed even with wined3d:

0134:trace:d3d11:d3d_texture2d_create Created texture 00000000167BD4C0.
0134:trace:d3d11:d3d11_texture2d_QueryInterface iface 00000000167BD4C0, riid {6f15aaf2-d208-4e89-9ab4-489535d34f9c}, object 000000000011D730.
0134:trace:d3d11:d3d11_texture2d_AddRef 00000000167BD4C0 increasing refcount to 2.
0134:trace:d3d11:d3d11_texture2d_Release 00000000167BD4C0 decreasing refcount to 1.
0134:trace:d3d11:d3d11_texture2d_GetDesc iface 00000000167BD4C0, desc 000000000011D7F0.
0134:trace:d3d11:d3d11_device_context_CopyResource iface 0000000012EFB7E8, dst_resource 00000000167BD450, src_resource 00000000167BD4C0.
0134:trace:d3d11:d3d11_texture2d_GetType iface 00000000167BD4C0, resource_dimension 000000000011D63C.
0134:trace:d3d11:d3d11_texture2d_Release 00000000167BD4C0 decreasing refcount to 0.
# The next call crashes with DXVK
0134:trace:d3d11:d3d11_texture2d_QueryInterface iface 00000000167BD4C0, riid {037e866e-f56d-4357-a8af-9dabbe6e250e}, object 000000000011D718.

I have already refunded this game. Even if I enter the game, it will crash halfway through loading the game. I am also a Steam Deck

You can try using 9.0 beta, and in desktop mode, you can enter the game with 9.0

I believe it would also be a good idea to upvote this thread with the bug report:
https://community.lemansultimate.com/index.php?threads/proton-wine-dxvk-ctd-at-launch.1020/#post-5950

thanks!

Would be good if someone could post a complete log with wined3d enabled. IMO it will give some hints to the LMU devs where the affected texture is released/accessed related to the game's own log output.

Something like this command can be used:
PROTON_LOG=1 PROTON_USE_WINED3D=1 WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+d3d11 %command%

("-all" turns off all unrelated log messages)

This should launch the game normally. Just reach the game menus and exit to prevent the log from growing too large. No need to force the crash on track loading, as it may not be related to this bug.
(I would do this myself, but currently don't have the game.)

Would be good if someone could post a complete log with wined3d enabled. IMO it will give some hints to the LMU devs where the affected texture is released/accessed related to the game's own log output.

Did so, though I had to force exit the game since you still could hear music from the game being playedk even though the window did close. The log is still quite big, I compressed
it to make the size manageable.

steam-2399420.log.zip

In my case, the screen goes black and returns to the desktop. I leave you the log in case it is useful:

steam-2399420.log

Thanks @poljar and @leillo1975

I'll take a look and post in the LMU bug report thread.

This crash seems to have been fixed with build 14742905 released on the 20th of June 2024:

Build ID: 14742905
General

• Stability fixes to address crashes when loading into a race & loading a replay

The game still crashes if you attempt to start a race, but at least you can start the game now.

I have exactly the same problem, crashes on loading at 46% Tested with 9.0-2, Experimental and Proton-GE 8-25

I attached a compressed proton log file:
steam-2399420.zip

LMU still does not work in the latest patch released today. Here is the proton log:
steam-2399420.zip

Still crashes when trying to start a race. For me the video output goes completely black with the PROTON_USE_WINED3D=1 option.
P.S. Once I generated Proton logs where do I find them?

One user on the LMU forum have tried the latest version of the game on Win 10 with the DXVK binaries, and it crashes at the same place as proton (~47% while loading a race).

So it seems this new issue is related to DXVK again. IIRC with PROTON_USE_WINED3D the game was crashing at the same place from the beginning, so it might be the same bug now.

Maybe @doitsujin could look at it again. :slightly_smiling_face:

Hopefully we will soon be able to enjoy this game. Let's see if the devs can dedicate some time to it.

Staff member answered

It is the Direct2D lack of support in Linux/Proton as I understand it

https://community.lemansultimate.com/index.php?threads/proton-wine-dxvk-ctd-at-launch.1020/page-2#post-34413

In recent version we get crash at 47-48% load (Menu working just fine).

Proton log shows:

373840.811:0168:trace:d2d:d2d_factory_CreateDevice iface 00000000A26170D0, dxgi_device 00000001A70D7590, device 0000000143D922E8.
373840.811:0168:trace:d2d:d2d_factory_AddRef 00000000A26170D0 increasing refcount to 2.
373840.811:0168:trace:d2d:d2d_factory_create_device Create device 00000000A27471C0.
373840.811:0168:trace:d2d:d2d_device_CreateDeviceContext iface 00000000A27471C0, options 0, context 000000000011DFA8.
373840.811:0168:trace:d2d:d2d_device_GetFactory iface 00000000A27471C0, factory 0000000009A7FEA8.
373840.811:0168:trace:d2d:d2d_factory_AddRef 00000000A26170D0 increasing refcount to 3.
373840.811:0168:trace:d2d:d2d_device_AddRef 00000000A27471C0 increasing refcount to 2.
info:  DXVK: Using 32 compiler threads
373840.822:0168:fixme:dwrite:dwritefactory_CreateMonitorRenderingParams (0000000000000001): monitor setting ignored
373840.822:0168:trace:d2d:d2d_device_create_device_context Created device context 0000000009A7FE70.
373840.822:0168:trace:d2d:d2d_device_context_QueryInterface iface 0000000009A7FE70, iid {235a7496-8351-414c-bcd4-6672ab2d8e00}, out 0000000143D922F8.
373840.822:0168:trace:d2d:d2d_device_context_inner_QueryInterface iface 0000000009A7FE88, iid {235a7496-8351-414c-bcd4-6672ab2d8e00}, out 0000000143D922F8.
373840.822:0168:warn:d2d:d2d_device_context_inner_QueryInterface {235a7496-8351-414c-bcd4-6672ab2d8e00} not implemented, returning E_NOINTERFACE.
373840.822:0168:warn:seh:dispatch_exception backtrace: --- Exception 0xc0000005.

So we got 235a7496-8351-414c-bcd4-6672ab2d8e00, and it was implemented (at least the interface itself) in latest wine link

But this version is not in the GE or Steam Proton

Am i remotely right, and we just need to test latest wine?

Okay he gave me an idea and i was able to successfully launch the race after implementing some d2d calls in Wine.

Clearly not without issues (HUD is only partly present, without text and other stuff), but my devices were detected, FFB works perfectly, fps is good.

1. Game uses IID_ID2D1DeviceContext3. It's implemented only in latest bleeding edge Wine (i tried 10.0)
2. Game uses ID2D1SpriteBatch, which is not present in Wine (yet). I implemented all ID2D1SpriteBatch methods, including CreateSpriteBranch and DrawSpriteBranch, some of these are just stubs. That was just enough for launching the map/race. Probably for the whole HUD present i need to more carefully implement those / check logs for more not implemented functions.
3. Game uses CLSID_D2D1Tint effect, which is also not present in Wine. Added definition of it and it was just enough.

I will play with my implementation of these d2d calls a little more and later will create a patch to Wine for it. When i will be comfortable with sharing the code, i will do it.

But for now, i think, it's not a dxvk/game issue anymore.

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-2620474144

If you do this you'll be a hero!

@JacKeTUs you are legend!

Thank you @JacKeTUs for providing very useful information about the real cause for LMU not working via Proton. I value your time so I won't selfishly ask if you've made any progress, but I hope somebody can take your findings and implement what's needed from Direct2D in Wine. I tried looking at it myself but I'm probably not qualified to write any useful code. Despite that I will try to play around with it, at least I might be able to learn more about Wine.

@JacKeTUs did it.

He made it work.

Test videos

https://www.youtube.com/watch?v=hW4czWaF90I

https://youtu.be/218N_zR9yFI

Hello!
Yes, can confirm :)

I managed to implement/work around many of functions needed to show HUD. Also managed to find (and fix) some bugs in Wine implementation of some clipping functions. There is still some small bugs (some clipping is absent), but it doesn't break things completely.

Recorded gameplay (link already shared above)

I forked Proton-GE for easy building and worked in it. https://github.com/JacKeTUs/proton-ge-custom/tree/lmu-d2d1. If you want to try it out, please build it yourself, following README.md (recursive cloning, configure, make redist or make install), and don't forget to checkout lmu-d2d1 branch.

What was fixed/worked on:

• Implemented Sprite Batch. Implemented CreateSpriteBatch, AddSprites, SetSprites, GetSprites, DrawSpriteBatch. As for now it just substitutes with DrawBitmap for every sprite. Sprites are used in HUD backgrounds, radar, minimap markers.
• Implemented Layers. Implemented PushLayer, PopLayer. As for now it substitutes with creating offscreen bitmap, saving old target, and in PopLayer - restoring old target, drawing layer bitmap. Layers are used by game in everything, all HUD is composed in Layers.
• Found a bug in Wine, which does not resets/saves AxisAligned clip stack when target is changed. On Windows every new target = new axis aligned clip stack. On Wine - new target is old stack. I moved this stack into the bitmap and bug was fixed, allowing text in game to show up.
• Tint Effect is tricky. As far as i understand, all builtin effects are implemented by Microsoft with HLSL shaders for every one of it. For now every effect in Wine is just a stub, and does not have any examples of implementation. For now i hacked it like so: if in DrawImage we get an ID2D1Effect, we get it's input bitmap and draw it. This works for 'Tint' effect, but won't work on, say, effects without an input bitmap, or effects with multiple bitmaps. Game does not use any other effects. This 'hack' is absolutely not good for upstream Wine. I think i need help from somebody with understanding of ID2D1Effect/ID2D1EffectImpl and HLSL shaders to think how we can implement these builtin effects.

I will very appreciate if we find somebody who is more fluent in Direct2D to help with it :D

I will try to clean up the code/try to optimize some things, and after implementing all tests I'll send MR to the Wine team.

Here is a small cake recipe on how to build it, nothing should be run as root:

close steam.
install: git autoconf docker (autoconf will clear some errors when patching).

start docker, check status, add your user to docker group, login to the group, test a hello world:
systemctl start docker.service
systemctl status docker.service
usermod -aG docker username
newgrp docker
docker run hello-world

checkout:
git clone https://github.com/JacKeTUs/proton-ge-custom --branch lmu-d2d1 --recurse-submodules
cd proton-ge-custom

apply patches:
./patches/protonprep-valve-staging.sh &> patchlog.txt

mkdir build && cd build
../configure.sh --build-name=GE-Proton10-1-LMU
mkdir -p ~/.steam/root/compatibilitytools.d
make install

restart steam and it should be listed.

When running make install I'm getting this error:

rm obj-fonts/source-han/simsun.ttc.tmp
rm obj-fonts/LiberationMono-Regular.sfd obj-fonts/LiberationSerif-Regular.sfd obj-fonts/LiberationSans-Regular.sfd obj-fonts/LiberationMono-Bold.sfd obj-fonts/LiberationSans-Bold.sfd
make: *** [../Makefile.in:1538: all] Error 2

Perhaps rm is trying to delete a non-existent file and fails?

Tested the LMU Proton build, seems to work fine except that I had really bad performance, but that might be a system issue (GPU not clocking properly sometimes, general only about 60% of the windows fps). But could consistently load into the race without crashing.

Only thing that I saw at quick glance was that the speed limit overlay was white instead of green/red, but I'm guessing that's the tint effect? Rest of the UI looked fine (including radar). Definitely looked playable which is great.

On a side note my PXN CB1 button box works now thanks to the controller fix, nice.

Tested the LMU Proton build, seems to work fine except that I had really bad performance, but that might be a system issue (GPU not clocking properly sometimes, general only about 60% of the windows fps).

You can try to disable HUD from the game settings to see if it gives you performance boost. From other testing i heard no to little difference with Windows

Only thing that I saw at quick glance was that the speed limit overlay was white instead of green/red, but I'm guessing that's the tint effect?

Yes, exactly. I managed to hack tinting with 'main' pixel shader, so for some sprites (flags) it's working.

On a side not my PXN CB1 button box works now thanks to the controller fix, nice.

Glad it helped you! Lets hope Valve picks that up soon, as it would tremendously help with other games

When running make install I'm getting this error:

Are you by any chance running CachyOS? I was getting the same exact error on that distro, and only managed to compile Proton when I booted into a clean Arch install I had around.

I previously had trouble compiling drivers on Cachy and realized that it's due to the fact that it's kernel was compiled with Clang, not with GCC like most Linux kernels. When I adjusted these drivers and their makefiles to use clang instead of GCC, it usually worked flawlessly.

I'm not sure if that would be the same issue for Proton, but when trying to compile with clang I ran into some other errors and eventually booted into a distro with a regular kernel. So that might be something worth looking into if you're in fact running Cachy or any other distro with a non-GCC compiled kernel.

Are you by any chance running CachyOS? I was getting the same exact error on that distro, and only managed to compile Proton when I booted into a clean Arch install I had around.

I'm running CachyOS and the make install worked fine.

Are you by any chance running CachyOS? I was getting the same exact error on that distro, and only managed to compile Proton when I booted into a clean Arch install I had around.

Nope, I'm on Ubuntu 25.04.

I previously had trouble compiling drivers on Cachy and realized that it's due to the fact that it's kernel was compiled with Clang, not with GCC like most Linux kernels. When I adjusted these drivers and their makefiles to use clang instead of GCC, it usually worked flawlessly.

I'm not sure if that would be the same issue for Proton, but when trying to compile with clang I ran into some other errors and eventually booted into a distro with a regular kernel. So that might be something worth looking into if you're in fact running Cachy or any other distro with a non-GCC compiled kernel.

I'm not 100% sure if Ubuntu compiles their kernel with GCC but I believe so. Currently running the provided 6.14.0-15-generic kernel.

You can try to disable HUD from the game settings to see if it gives you performance boost. From other testing i heard no to little difference with Windows

tldr: opponent cars make GPU clock go down
(I also had some rare crashes, I think about 3 while starting probably 20+ races)

Launch options: gamemoderun gamescope -H 1440 -W 7680 --mangoapp -- %command%
So I was testing different graphic settings (mostly without restarting LMU), also disabled HUD and replays. But nothing really worked, I had <10fps on 7680x1440 Ultra. Except when turning "Opponent Detail" from ultra to low I got ~60fps instead of ~<10fps (other detail options ultra, everything below opponent detail on low, anisotropic x16).
Then while testing I realized when the cars drive out of range the GPU clock was slowly rising until all cars were gone an the clock reached 3200MHz+ with 100+ fps (on all low).
When the cars came back around the GPU clock dropped again to <1800MHz.
Starting a race alone also had 3200MHz GPU clock.

One time I started a race and the clock was 3200MHz with a couple GT3 cars on start, then I switched the overall settings from very low to medium, started a race and clock was ~2500MHz with it going up again after the opponent cars drove away. But I could not reproduce this.

Tried again today this time on 2560x1440, low graphic settings the clock would start at about 1800MHz and then rise when the cars were out of range (CPU bottleneck at some point after ~350fps).
Without launch options it's the same, starting with about 1800-2000MHz and up to 2500 in pits with no other cars around (CPU bottleneck).
Changing graphic options sometimes seems to affect things but overall it is always ~1800MHz at start until the cars drive away.

System:
5700X3D/9070XT/32GB Ram
linux 6.14.7.arch2-1
mesa 1:25.1.1-1
sway 1:1.10.1-2
wayland 1.23.1-2
wlroots 0.18.2-2
Proton 10 LMU build

OpenSuse same behaviour mesa 25.0.2 / linux 6.14.0 and after update

Another thing I was noticing was that race loading times are double for NTFS (~>3:30min vs ~1:30 EXT4), but I'm guessing it's one of those "that's why we don't use NTFS" things. (only graphic setting tests were on NTFS, rest with EXT4)

opponent cars make GPU clock go down

That's interesting, thank you. Disabling HUD/driver names didn't help at all? Did you spot the same behavior on Windows with the same settings (triple screen), or FPS more stable there? Can you try without triple screen?

Also, are you testing with AI opponents, or is it online race?

Just speculation, but can it be that gpl shader compilation is affecting it...
I'm interested if my d2d implementation can affect this. If without hud/driver names fps is still low when near opponent cars, that's not related to d2d... 😢

For me perfomance is like windows or better.
The one time I had issues when I was trying a custom resolution, seems wayland or wathever did not like it much, and indeed most of the time performance was lost when close to cars, especially online.

I have been playing online now days and it its flowless, but I had my dose of stuff to resolve, in the end the most important things are:

• no custom resolution and
• Set framerate limit on the game config file, with mangoHUD it seems problematic, with game file butter smooth, setting file is: ~/.steam/steam/steamapps/common/Le Mans Ultimate/UserData/player/Settings.JSON and setting name eg. "Max Framerate": 120.0,

Disabling HUD completely didn't change anything. Steam overlay neither.
Windows does not do this, no. [Edit] It may after a while
I also did test single screen only, no change.
Then I disabled the other monitors and had 3400MHz on start, but after restarting the game it was again only 1800MHz, restarted again with gamescope (the LMU window really doesn't like sway apparently) and still only 1800MHz. Kinda like I mentioned that it worked that one time but I don't know why.
OpenSuse testing was with Plasma and only single screen as well (with others active), no custom resolution, MangoHud or anything really.
Might try fresh reinstall when I get around to it (did make a fresh prefix at some point).

For me on Plasma for single 4k fullscreen, performance stays the same with/without HUD/driver names and near the opponent cars (on start, on full grid with ~26 of them), all on Ultra, tried with gamescope too, i get around ~70 fps avg. I tested only AI. May be my testing isn't perfect. Did you tried latest build with 10-3 merged?
5950x, 6900xt, 32gb, mesa 25.1.1

Honestly, can't tell what can cause such issues, if not d2d and driver names...

What I additionally do (an a 6900XT) is to run simple scripts to undervolt and set some fan speed before and after the game, maybe if you are on AMD somthing similar could help:

Have you tried with all the Steam launch options removed ?

simrig:/home/slemke # cat /usr/bin/scripts/undervolt-gamemode-before.sh 
#!/bin/bash
echo "vo -80" > /sys/class/drm/card1/device/pp_od_clk_voltage
echo "c" > /sys/class/drm/card1/device/pp_od_clk_voltage
echo 'high' > /sys/class/drm/card1/device/power_dpm_force_performance_level
echo "4" > /sys/class/drm/card1/device/pp_power_profile_mode
cpupower frequency-set -g performance

#fan:
echo "1" > /sys/class/drm/card1/device/hwmon/hwmon0/pwm1_enable 
echo "162" > /sys/class/drm/card1/device/hwmon/hwmon0/pwm1
simrig:/home/slemke # 

[Edit] So I just ran into the same issue (low fps+power) on Windows after a couple races / restarts. Restarting the game fixed it.

So first things first, mesa got an update today (1:25.1.1-1 -> 1:25.1.1-2) and it looks like the clock stays high but the power and fps are too low.
The GPU is indeed undervolted (9070XT@-50mV, 340W, 2650RAM via LACT, same in windows but +10% power, enough cooling too). Didn't have these settings in openSuse.
So the clock in Linux is 3400MHz with about 200W and <40fps, in windows it's 3200MHZ with 60fps+ and 340W+.
Launch options were (PROTON_ENABLE_WAYLAND=1) gamemoderun gamescope -H 1440 -W 7680 --mangoapp -- %command%
Graphic ultra preset with post effects/MSAA/FXAA but limited to 25 cars visible.

Only single screen with "gamemoderun gamescope -r 165 -H 1440 -W 2560 --mangoapp -- %command%" I just got the low clock problem again.
Tried to use only on screen but right now it refuses to start completely.

Before the mesa update I did a bunch of testing (mesa 1:25.1.1-1)
MultiView (triple screen cameras) does seem to amplify the problem but not the root cause. Got higher clocks / fps without and could reproduce it (starting with off and turning it on or vice versa).
Also some graphic settings seem to have an influence. Going from medium to ultra settings made the issue worse.

I also tried with a fresh user profile (7680x1440 no MultiView) and had normal clocks with decent'ish fps, but every time I quit out of the race and tried to start another one it got stuck loading at about 48%, which apparently is/was a known bug on windows. But this didn't happen in any of the other testing before.

Even with a fresh reinstall and starting without changing anything (2560x1440) I had the low clocks.
MangoHud/Steam overlay didn't seem to change things but found comments regarding Afterburner/RSS overlay on Windows.
Tested rFactor 2 (same engine) but no drops (at this point I used more games from the Humble Bundle to test stuff then to actually play them :D)

You seem to have more general issues not related to this HUD fixes.
AMDs usually trothles GPU clock down to use less energy, most of the time this also hits perfomance, make sure you have a good performance setting on: /sys/class/drm/card1/device/pp_power_profile_mode (the * indicates on what you are), for me I use number 4 - VR when I start game (via gamemode script)
echo "4" > /sys/class/drm/card1/device/pp_power_profile_mode

Not saying it will fix it for you, but if you have not tried worth a test. (adjust card1 to your card)

Yeah, general issue was my first guess since there is a longstanding issue with GPUs not clocking properly/not getting proper utilization which nobody seems to have a proper answer to (both Linux/Windows and AMD/Nvidia) and is super random.

For the power usage issue, since I ran into it (or similar) in Windows I'm guessing it is game-related, although it is weird that with Proton it is instant and with Windows only after a while.

I did try setting a power profile with LACT but retested manually and while it did change something once and it seemed to run fine, I could not reproduce it (kinda like the times were it just ran fine). I also have no other game with these issues (and just retested AMS2/ACC/ACE with the LMU branch).
Next big update is supposed to come 10.06., maybe there are performance fixes that have an impact even tho nobody else seems to have these issues (I found some Windows reports but without GPU data).

Tested LMU with Proton 10-1-LMU and Proton 10-3-LMU and noticed few things.

First one, when driving and hitting ESC to change some settings, and when quitting from this menu, menu not always disappears. The game unpauses, I can drive the car, but menu is still on the screen. To hide this menu, I need to press ESC to show menu, and one more time ESC to hide. And then menu will go for real.

Second. Graphics performance very strange. Using RTX 3080, and depending on settings/position in the track I have ~70-120fps, but in reality the image is very choppy, as if I had ~30fps or something like that.

Tested rFactor2, I have the same ~70-120fps, but graphics is smooth.

HUD ON/OFF have no difference.

Limit FPS via Settings.json - Seems limiting via Mangohud does not work properly.
The menu thing is also a windows problem, seems to be some CEF engine issue IMO.

Seems limiting via Mangohud does not work properly

Not using Mangohud. FPS counter displayed by NVIDIA driver.

I played with the settings and with the lowest graphics settings I get at least 90fps. The game is definitely playable, but the image is still not smooth.

In today's update game introduced new dependency: GameInput. It's not implemented in Wine at all.
Developers stated that game has mechanism for fallback to the dinput, but for this GameInput.dll should return anything but S_OK on the context creation, and without this dll game just crashes to desktop.

For now i compiled small dll with exactly this stub. Later I'll just add it to my Proton fork.
https://github.com/JacKeTUs/gameinput-notimpl
Just copy dll from the Releases to the game folder, and you'll be good to go

UPD: I put it in my Proton fork, if you update your repo and recompile, game should just work (tag GE-Proton10-4-LMU )

There is a regression for me - using CSL DD with https://github.com/gotzl/hid-fanatecff and lmu-d2d1 branch of Proton GE causes me to almost immediately crash to desktop with error report window. Turning the wheelbase off and turning the game on causes it to run fine untill I turn on the wheelbase again, the same crash occurs then.

Using regular GE-Proton or any other version causes the game to run fine until it crashes during loading.

@kropop, please, record the trace with PROTON_LOG=1 in game launch setting and send me the file after game crash.
Also, you already copied the GameInput.dll file, right?

I wonder if it relates to Fanatec SDK...

Also, can you check specifically vanilla Proton-GE 10.3? I didn't updated to 10.4 just yet, but i wonder if your issue is limited to this version

UPD:
@kropop, i updated my fork to the 10.4, can you check if this version will work for you, please?

@JacKeTUs I might have a similar/related problem and the games crashes when I connect or disconnect any usb-device. It is not a show-stopper for me I just take care to have everything plugged in before starting LMU. This happens on 10-1-LMU, 10-4-LMU and proton experimental.

I have the gameinput.dll in the correect directory

I am now observing the same issue, game just doesn't like hotplugging controllers. On Windows with skipping GameInput initialization everything ok. I'm looking into it now. It's unrelated to my fixes, as it's happening even on 'stock' Proton versions.

Crash on start is different though, and may be related to the Fanatec devices...

UPD: I found that crashes are due to unimplemented DirectInput::FindDevice.

UPD: @kropop, i updated my fork to the 10.4, can you check if this version will work for you, please?

It did not work either.

Here's the gist of my proton log:

https://gist.github.com/kropop/437e0316fdd85ffff9595d379c6443fe

Same result - game fires up, but if CSL DD is turned on before or after startup, the game will crash.

Same result - game fires up, but if CSL DD is turned on before or after startup, the game will crash.

As far as i can tell now, it's two different crashes. Game relies on unimplemented FindDevice to add device to the list if it was plugged in after game start, and it crashes if it sees two handles (hidraw and SDL/udev). Some can mitigate it by disabling hidraw entirely (PROTON_DISABLE_HIDRAW=1 %command%), but you will miss FanatecSDK features.

About 'crash at the start':
First and foremost - please repull lmu-d2d1 branch. I included some experimental stuff there earlier (by error), i wonder if it can influence crashes.
Second - are you using latest hid-fanatecff (0.2.0)? Is your hidraw device has all needed permissions?
Next - try to clear the game prefix entirely. I wonder if inclusion of multi-TLC patch broke the prefix for you. Remove any game launching options (PROTON_ENABLE_HIDRAW or SDL_JOYSTICK or anything). Also check out this: https://github.com/gotzl/hid-fanatecff?tab=readme-ov-file#game-hangscrashes-at-startup

Also, please try it with 'stock' GE-Proton 10.4 after all of that.

@JacKeTUs I think clearing the prefix solved it. I was already on latest hid-fanatecff release, I tried recompiling 10-4 then installing it again, it didn't work. Then I cleared the prefix completely and it started up fine.

It took an extremely long time to load for the first time (Interlagos), but it did go past 48% and I was able to drive. FFB works too, as do the Fanatec LEDs and screen. Side note - I have to use "Invert Force Feedback" option because otherwise FFB is really janky.

The menu is quite laggy, but in game performance seems okay. I'm gonna need to copy over my Windows settings for LMU to check.

Yay! So one more crash to solve, and it's about hotplugging...

I too had to invert FFB, didn't had to do it in any other game, and i didn't change FFB in this proton version...

For menu lags check out 'CEF mode' in SteamLibrary/steamapps/common/Le Mans Ultimate/UserData/player/Settings.JSON. For me "CEF Mode": 2 works best.

@JacKeTUs Thanks for your efforts, the game weren't even launch since last batch of game's update/hotfixs but the gameinput DLL fix that
Unfortunately i tried almost all versions of your custom GE-Proton but none of them works, the game still crash at 48% loading tracks like with official ones

Checking the trace log i found this error "Failed to allocate ID2D1SpriteBatch , Fatal", stnage as if i get it right your custom GE Proton should address that.

I tested with the 10.3 pre compiled on your github and clone+compile myself the master branch, neither works (of course i selected the right version in Steam), maybe i miss something

@BDave95
I didn't compile and publish built archive from d2d branch yet.
This error (Failed to allocate ID2D1SpriteBatch) is exactly what was missing in Proton, this means it's not implemented. It's fixed in my fork, branch lmu-d2d1

You need to compile it yourself, from lmu-d2d1 branch, please see https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-2891592728.

I'll soon probably publish built archive, but first gotta to find how to fix crash when plugging in devices while in game.

Also, when on latest commit, you don't need GameInput.dll anymore, it's included now in my Proton build.

UPD: Crash at device reconnection will be fixed in game in one of the next updates. I'll add translation of DIERR_DEVICENOTREG to the Wine too. Now, FormatMessage with this error code returns empty non-allocated string in Wine.

Hi everyone,

I managed to run LMU with @JacKeTUs's proton fork.
Is FFB working for you? I don't get any ffb with my g27
I had to use PROTON_DISABLE_HIDRAW=1 %command% to not crash at startup
What does this do exactly. Maybe it's because of that option?

Hi everyone,

I managed to run LMU with @JacKeTUs's proton fork. Is FFB working for you? I don't get any ffb with my g27 I had to use PROTON_DISABLE_HIDRAW=1 %command% to not crash at startup What does this do exactly. Maybe it's because of that option?

Hi!
FFB works for me with OpenFFBoard.

Did you tried cleaning up your prefix? Crash at startup is not normal...

Are you using new-lg4ff? Does FFB work in other games or fftest? Is the device recognized by game at all? Can you check if your wheel is recognized by xinput or dinput, via protontricks -c "wine control joy.cpl" 2399420"? Can you try to tick the box "Use Constant Force" in game Settings->Controls->Force Feedback, will it make the difference? Also, can you try to tick 'Invert FFB' too?

hidraw allows programs to communicate directly with the device, skip the middleman (SDL, udev). It can be useful if software communicates through some sort of SDK (like Fanatec or Thrustmaster), and allows for LEDs, for example. new-lg4ff kernel driver exposing FFB features through native Linux FFB API, and SDL/udev should work perfectly fine for you... Unless game itself doesn't have some sort of whitelist/blacklist...

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-2983388515

I tried again without the hidraw option and it worked. I guess it was a fluke last time
I'm not using new-lg4ff. I will look into it!
The constant force tweek actually made it work. Had to invert the ffb though. Thanks for helping!

the constant force tweek actually made it work. Had to invert the ffb though. Thanks for helping!

So, native logitech driver for G27 only exposes ConstantForce effect. Game engine uses Sinewave periodic force instead, with optional constant force switch
new-lg4ff adds support of the Sinewave, and this will fix your issue too

hi, for anyone need a working gameinput implementation could try my compatibility layer that translate gameinput to xinput api https://github.com/andrew-ld/gameinput2xinput/

to xinput api

Gamepads will be perfectly fine with it, but not steering wheels/pedals/shifters 😢
FFB is available only on DirectInput.

@JacKeTUs Thank you for pointing me the "recipe", just take some time to give it another try and it was my mistake, i followed blindly the instruction on your Github main page without checking what i was copy/pasting and it was a mistake as the instruction point on gloriouseggroll's github and not yours.
Now the track load without issue, once again thanks for the hard work on this

when will this be forked on the main GE-Proton ?

when will this be forked on the main GE-Proton ?

Missing stuff for now:

• Axis aligned clipping for Layers (fix of various clipping issues on HUD)
• Opacity brush calculation for Layers. Without these two i can't say Layers implementation is 100% complete. It's already 'good enough' for playing though.
• Implementation of Tint effect. Without it i can't say SpriteBatch implementation is complete (colors will be missed, and im just hacking around it for now) (speed gauge on race start is not colored, for example)
• Fix of latest crash when reconnecting device. Solution is known, i just need to add it.
• Explanation for Wine team for bug in Axis aligned clip and tests on all available surfaces.
• Tests for everything else. Without tests such complex MR would not (and should not) be accepted at all.

This all probably will be separate MR. First - add stub for Tint effect (so game won't crash), next - SpriteBatch (partially, without coloring), next - fix of bug with axis aligned clip preserving (so text would be visible), next - Layers.

I'd say we still have a long way to go. I'm not a full time Wine developer, so please be patient 🙏

We are grateful for everything you do @JacKeTUs, take as much time as you need, you've made it playable and that's already awesome. I need to do some more testing, I have a Fanatec CSL DD and when I checked your Proton build last time, the game ran very well, but my FFB was reeeeeally weird and wonky. I've seen something about having to turn on the option to invert FFB, I'll build the newest version of your lmu branch and check it out again during the weekend.

Seems limiting via Mangohud does not work properly

Not using Mangohud. FPS counter displayed by NVIDIA driver.

I played with the settings and with the lowest graphics settings I get at least 90fps. The game is definitely playable, but the image is still not smooth.

Did you ever figure this one out? I have the same issue. Fps reads as something like 160, but it feels very choppy.

I'm using mangohud and it works properly.

If your 'menu fps' is 'choppy', try to change CEF Mode in SteamLibrary/steamapps/common/Le Mans Ultimate/UserData/player/Settings.JSON. Developers said that you can try 0,1,2 and pick what works best for you. For me option '2' works best.

I'm not using gamescope/gamemode, and my game (in race) feels very smooth. FPS in Direct2D elements and in 3d is different (2d elements are kinda slower), but 3d for me - perfectly smooth. I don't know if it's due to my sub-optimal implementation of layers/batches, or game itself doesn't update 2d elements fast enough.

If your 'menu fps' is 'choppy', try to change CEF Mode in SteamLibrary/steamapps/common/Le Mans Ultimate/UserData/player/Settings.JSON. Developers said that you can try 0,1,2 and pick what works best for you. For me option '2' works best.

I'm not using gamescope/gamemode, and my game (in race) feels very smooth. FPS in Direct2D elements and in 3d is different (2d elements are kinda slower), but 3d for me - perfectly smooth. I don't know if it's due to my sub-optimal implementation of layers/batches, or game itself doesn't update 2d elements fast enough.

The menu is choppy, which is whatever, but it seemed to spill over onto the 3D. It was choppy during races. As for the 2D implementation, has anyone tried it on both Linux and Windows and would they be able to comment on a delta?

Tried it some laps yesterday evening and had a weird bug, i did several returns to stand a come back to the car to adjust the car's setup and on one occasion the ranking stayed on top of the screen, i had the car cockpit in transparency and could drive the car but obviously not very practical
After changing between timing screens everything came back to normal and it only happened once.
As this game is full of bugs i don't know if this one is related to the custom proton or to the game itself, and i haven't found anything relevant in logs, but i thought it worth reporting it

By the way on your git i saw 2 branches, d2d1 and d2d1-hid, can you explain quickly the difference for those of us not devs or USB hackers ;-)

@BDave95

ranking stayed on top of the screen

That's definitely some d2d stuff, when i'll fix some clipping issues it probably will be fixed.
Game is definitely full of bugs right now, and it has many crashes in different places (like, after quali, into a race) even on Windows... :(

-hid branch has some experimental stuff like implemented HidP_SetData and slight adjustment of Wine's generation of GUID's for devices. SetData helps with Simhub (if you launch simhub through this proton, it will be able to communicate with devices), and new generation for GUID's helps with game actually remembering settings for reconnected devices. Right now it's kinda global Wine issue, with many different joysticks - if you reconnect them in different order after rebooting, game will think that, say, pedals are steering wheel, and etc.

It's like very WIP, it kinda breaks 'unique serial numbers' feature in Wine, i managed to test it only on AC/AC Evo, and different bug struck me in LMU when device reconnects.
I'd recommend just sticking to the d2d1 now, and try out -hid only if you're feel like you want experiments :D

CEF mode seems to mostly fix the lag issue, last issue I seem to have is a crash on startup when using VR. If I find time, might try to debug it to see where it's failing.

Edit

It seems to be failing in VRUI.cpp when calling D3DX11CreateTextureFromMemory. Looking it up, this seems to be a deprecated function and I cannot find it in dxvk. I have no clue how dxvk handles depracated functions, if something is returning a null pointer, or what. Wouldn't know how to debug it either as I can't really get gdb to work and let me step through anything like some asm or something. I'll leave the logs if somebody has better knowledge of how to debug it.

trace_2025_06_22_15_58_47-14.txt

Proton log is too large to be added to the comment, if it's required I can figure out a way to send it.

Same case, works perfect using the fanatec drivers hid-fanatecff, only in case to use the steamvr show the same error.

@dmitsuki, @c0per0, does it happen with 'vanilla' Proton? Or for crash in VR to happen we need to load into a race?

Starting program with command-launcher service.

To run commands in the per-app container, use a command like:

/home/oleg/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/bin/steam-runtime-launch-client \
        --bus-name=:1.320 \
        -- \
        bash

In my case after init lmu, using hid branch, don't tray with lmu.

@dmitsuki

Did you ever figure this one out? I have the same issue. Fps reads as something like 160, but it feels very choppy.

Sorry for late answer, I was on vacation

What I did. Graphics settings on low. Car count bigger than default (I think 20). And for antialiasing I have x4

With no FPS limits, I have ~80-150fps, and video is choppy and magohood frame line looks like this:

But when I limiting frames to 90 or 85fps (settings.json, "Max Framerate"), I have smooth frames, and mangohud frames line is even and video is smooth.

after put this launch parameter to show log this is my log file in my case the game don't find steamvr, try half life alyx and work perfect, but this game is native.

steam-2399420.log

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-2993781417

Just to comment on this. The function D3DX11CreateTextureFromMemory is implemented when using ge-proton, see https://github.com/GloriousEggroll/proton-ge-custom/blob/d630fab1453cc33a7df244110712c9d5d076c12d/patches/protonprep-valve-staging.sh#L97

I tried to dig a bit further and got this stacktrace:

Thread 109 "CrBrowserMain" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 344]
0x0000000140340cb2 in Le Mans Ultimate STEAM_GOLD_DX11 64bit!GetPluginVersion () from /opt/steam/steamapps/common/Le Mans Ultimate/Le Mans Ultimate.exe
(gdb) bt
#0  0x0000000140340cb2 in Le Mans Ultimate STEAM_GOLD_DX11 64bit!GetPluginVersion () from /opt/steam/steamapps/common/Le Mans Ultimate/Le Mans Ultimate.exe
#1  0x00000001409c9062 in tm_sdk_installer_unregister_changes () from /opt/steam/steamapps/common/Le Mans Ultimate/Le Mans Ultimate.exe
#2  0x0000000000119b60 in ?? ()
#3  0x00000001409c8cba in tm_sdk_installer_unregister_changes () from /opt/steam/steamapps/common/Le Mans Ultimate/Le Mans Ultimate.exe
#4  0x000000014270c030 in ?? ()
#5  0x0000000000119a10 in ?? ()
#6  0x000000000233beb0 in ?? ()
#7  0x0000000000000000 in ?? ()

This crash appears to be in the CrBrowserMain process, which likely is the process rendering the VRUI.
But not sure if this goes into the right direction... I'm puzzled why tm_* functions appear here, I don't have a thrustmaster device ...

@gotzl, hello!
I had similar error when device was plugging in. Basically, game is trying to call FormatMessageA, and in Wine it returns an empty string for some error codes. Try to set breakpoint specifically to FormatMessage implementation (dlls/kernelbase/locale.c), or just try to read trace using WINEDEBUG="+nls"

It was fixed by game itself, but i think there is multiple such instances in their code, and they didn't fix all of them

hello, I have a pretty important HUD performance issue. I recently upgraded my PC(yesterday) to an I5-14400 and an RTS 4060 Ti. normally, i should be alright with high settings, but I'm actually not. when I load a race weekend with the AI, the HUD on the track makes the FPS dip down as low as 15 FPS. most of the time it's at 30-47. but when I hide the HUD, it's extremely fluid, no choppiness, FPS around 47 and 60(I did limit the FPS in the Settings.JSON and changed the CEF), but as soon as I make the HUD reappear, the FPS drop hard(especially on the Full HUD)

EDIT: turns out it was because I was using rFactor 2's Data Acquisition plugin. after pulling the DAMPlugin.dll out of the plugin folder, the HUD is smooth

EDIT 2: never mind, even without that DLL, the HUD stutters. both with AI and online. hiding the HUD makes it instantly better, but that's not optimal

EDIT 3: after verifying and redownloading LMU's files, doing some more tests, building the most recent Proton LMU fix and setting the CEF to CPU (on 2), I can say that the issue seems resolved. fingers crossed

~Seems 1.0 broke it again, tried it with ge 10-10(which includes some LMU fixes), 10.1 & experimental bleeding-edge, all have the same result: main menu works, but CTD when loading into a session.~

Building from @JacKeTUs repo fixed it for me

@tristandruyen, ge10-10, 10.1, bleeding edge don't have d2d fixes, you still need to build my branch

@JacKeTUs Thx a lot for the info! ~I'm now struggling with the build, couldn't get it to build locally and am currently trying to get the gh action running. Could you upload a release .tar.gz like with some of your older fixes ?~

nvm, got it to build, works mostly fine on screen, can confirm the same VR issues already mentioned above.

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-3092382252

Anyone else had similar issues?
I followed the same steps, which led to everything working with good performance, but since the last update the game I get 15 fps with the hud on in online games. Offline games do not seem to be affected.

I recently changed some of my hardware, I run an R9 7900 and an RX 9070 XT. I use CachyOS. The game 100% feels less smooth on Linux, but it was a lot more of an issue on my old GPU that often struggled even on Windows.
Now I get 200+ fps but I do have to limit my framerate in settings, like others above, because otherwise the frametimes fluctuate a lot between 5 and 25ms which is very bad. When limited to 200 fps, it's between 5 and 10ms, and I can get it more stable if I limit it at my refresh rate which is 165. At that point the game is perfectly stable and playable... but still feels as if it isn't as smooth as it should be. But I can make that sacrifice to finally ditch Windows, and hopefully the support will catch up in the future.

@andiritt I tried testing it with the HUD on and off and on my system it makes absolutely no difference, so perhaps that is an issue on nvidia GPUs only?

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-3193900280

Have you tried this setting in ~/.steam/steam/steamapps/common/Le Mans Ultimate/UserData/player/Setttings.JSON that did help om my system (also CachyOS and AMD-gpu)

"CEF Mode": 2,

@andiritt

but since the last update the game I get 15 fps with the hud on in online games

I had ~8 online races, and I had no issues with HUD. That was single class race GT3 or GTE
NVidia RTX 3080

I can't build JacKeTUs's GE Proton LMU branch anymore. Patches are not being applied, and the patchlog.txt is not created.

Furthermore, when trying to build I get the following error:

:: Configuring with build name: GE-Proton10-1-LMU
:: Trying to find usable container engine.
:: Trying docker.
+ docker run --rm ghcr.io/open-wine-components/umu-sdk@sha256:3506ccda91f7a7dcc4f2b2b6f60355798a59d5ee16401b5e204cacb1d90f9381
!! The container cannot access files. Are you using SELinux?
!! Please read README.md and check your docker setup works.

Docker works, as I can do hello-world from Docker.

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-3216711438

Try to use "sudo" on the command. E.g. "sudo docker run"

@kropop Alternatively, you can just use the precompiled build posted before by @tristandruyen
https://github.com/tristandruyen/proton-ge-custom/releases/tag/GE-Proton10-4-LMU-fixbuild

Builds of JacKeTUs' latest version using GE-Proton10-17 w/ experimental HID detection fixes available here: https://github.com/srounce/proton-ge-custom/releases/tag/GE-Proton10-17-lmu-d2d1-hid-20250930-011859

@JacKeTUs published another update to his fork, bringing it up to date with GE-Proton10-25. This time you can just download it from his repo's releases:

https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton10-25-LMU-hid_fixes

And i included some of fixes to guidinstance generation, which should help with game remembering mappings, and FindDevice, which helped with game joysticks hotplugging.
For now, nothing new from d2d1 side of things

steam-2399420.log
I'm still getting the crash at 48% load when getting into a race but can't figure out why.
I'm using endeavouros on an 9070xt with the JacKTus fork.
Don't know if someone can point me to the right direction or if I need to give more details in order to figure it out

@Respuit
From your logs i don't see you using my build

Proton: 1768397262 experimental-bleeding-edge-10.0-294596-20260114-p6ce376-wa21b86f-dc10c75-vf6b48c

Double check if you set my build in compatibility settings :)

@JacKeTUs oh yea sorry I changed it to test my bad. Here is the log with the the hid fixes build.

steam-2399420.log

Installing the game on the main drive fixed it for me. Can confirm that VR does not work with the error
5.52s VRUI.cpp 391: D3DX11CreateTextureFromMemory( &device, vrCursorFile->mMemFile.get(), vrCursorFile->mMemFileSize, nullptr, nullptr, reinterpret_cast<ID3D11Resource**>(mCursorTexture.GetPP()), nullptr ) 5.52s VRUI.cpp 391: FATAL!!!
as mentioned before by others.

Is the vr error something that could be done on our side or the only solution possible is from the game developers?

After some investigation I was able to figure out why D3DX11CreateTextureFromMemory fails.
The data passed is a 32x32 windows cursor file (initial bytes 00:00:02:00:01:00:20:20) which wine's d3dx_image_init does not handle.
I'm not an expert in wine so I don't know where an implementation is missing etc.

@mdias I got as far as identifying that when I was investigating over the Christmas period. However your comment nudged me again and I picked it up and started poking at it again and eventually found that it seemed to failing to handle CUR with DIB inside. So, I rather lazily vibecoded a clunky fix of doing the bitmap parsing in-situ just to explore the idea and it works! I was able to get to the main menu, start a singleplayer session and drive. So it seems like it's working well. Performance seemed pretty decent (5070ti), framerate was pinned at the refresh of my HMD, and I was able to do a lap of Bahrain comfortably.

@srounce could you throw your branch up on GitHub?

On Fri, Feb 20, 2026, 10:53 AM Samuel Rounce @.***>
wrote:

srounce left a comment (ValveSoftware/Proton#7512)
https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-3936544442

@mdiasI got as far as identifying that when I was investigating over the
Christmas period. However your comment nudged me again and I picked it up
and started poking at it again and eventually found that it seemed to
failing to handle CUR with DIB inside. So, I rather lazily vibecoded a
clunky fix of doing the bitmap parsing in-situ just to explore the idea and
it works! I was able to get to the main menu, start a singleplayer session
and drive. Performance seemed pretty decent (5070ti), framerate was pinned
at the refresh of my HMD was able to do a lap of Bahrain comfortably.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-3936544442,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANPX5RFFG3HWQMLBF7DAED4M5J3HAVCNFSM6AAAAABDR46B5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZWGU2DINBUGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

I also have a fix locally using the WIC codepath (d3dx_initialize_image_from_wic) for the cursor loading. But then I noticed that I was doing the fix on top of vanilla wine 11.2 source and decided to try the same fix on top of proton's wine bleeding-edge branch and it crashes when calling WICCreateImagingFactory_Proxy before it runs any code inside of WICCreateImagingFactory_Proxy itself, so I'm not quiet sure what's happening here...

A summary of the fix:

1. change dlls/windowscodecs/icoformat.c to not reject cursor format (cursor and icon formats are extremely similar); just a single line of code change
2. change dlls/d3dx9_36/d3dx_helpers.c/h to use WIC loading for cursor and icon files
   • add D3DX_IMAGE_FILE_FORMAT_ICO entry to enum d3dx_image_file_format
   • add it to wic_container_guid_from_d3dx_file_format handling, returning GUID_ContainerFormatIco for this format
   • add format signature to file_format_signatures
   • in d3dx_image_init add the case for D3DX_IMAGE_FILE_FORMAT_ICO to call d3dx_initialize_image_from_wic

I'm not sure I'll have time or be able to implement a fix on top of proton's wine, but if I do I'll share. In the mean time if you guys manage to fix it, please share too :)

Here's my hacky workaround commit which I managed to run with in VR: https://github.com/srounce/wine/commit/e6bfab1ca95e000dfea6ed13be33bf585c1ecba7

Here's my implementation of @mdias's summary above: https://github.com/srounce/wine/commit/a4951787dca982cd4b65aed74dd6117f9108270e

I'm compiling the @mdias fix atop @JacKeTUs' proton branch at the moment and once I've got it working, I'll publish a prebuilt GE-Proton release sometime tomorrow. If I can't get it to work I'll publish a release with my hacky fix instead.

Here's my hacky workaround commit which I managed to run with in VR: srounce/wine@e6bfab1

Here's my implementation of @mdias's summary above: srounce/wine@a495178

I'm compiling the @mdias fix atop @JacKeTUs' proton branch at the moment and once I've got it working, I'll publish a prebuilt GE-Proton release sometime tomorrow. If I can't get it to work I'll publish a release with my hacky fix instead.

Can't seem to get VR to work but not sure if I'm doing something wrong when building. I'll test when you release a published build.

@dmitsuki I uploaded a locally built copy here: https://github.com/srounce/proton-ge-custom/releases/tag/lmu-d2d1-hid-vr-fix-e6bfab1. If you wait a bit there is currently a build of the same commit building in CI if you prefer that, it should be finished within the hour. In any case you will need to set WINEDLLOVERRIDES="d3dx11_43=b" in the launch options to use the modified d3dx11_43.dll

Hi there!

Hoping someone can help me.

Using -
Fedora 43
Plasma wayland - Latest versions
Mesa - Latest versiosn
HID-FanatecFFB - Latest version

System Specs -
Ryzen 7 7800X3D
RX 7800XT
32GB DDR5
Fanatec CSL DD

Le Mans Ultimate - installed to Nvme SSD
Using this version of proton - GE-Proton10-25 with D2D1 and hid fixes

Issue I'm having is the game stutters like crazy, doesn't matter what track or if AI is on or off, or online or offline.

I'll be driving around, video will microstutter, causing my FFB to cut out for as long as the stutter last.

I've tried every Stutter fix I can find online.

• CEF = 2
• Fullscreen, borderless window, window, gamescope
• Vsync on, off, software, video
• FXAA on, off
• Opponent Detail to lowest
• AI drivers to lowest
• Capping FPS in game (though I only have 2 options, 60fps or 165 fps), Capping in the settings file to 120
• Adaptive sync on and off
• Turning all the settings down to lowest
• Monitoring CPU/GPU which sit at like 40-50% utilization, clock speeds are stable on both CPU and GPU.
• Resizable bar is enabled.

Does any one know anything that would cause microstutters and how to fix it?

The frame time graph does look super jagged too so probably contributing, played 4 hours of ACC last night and not a single hiccough, wondering what's wrong with LMU on my system.

Thanks!

Regarding the VR cursor loading issue, I've investigated a lot more and made a wine repo with the fixes here: https://github.com/mdias/wine/tree/cursor-load-fix (based on top of JacKeTUs's d2d1-hid branch.

After some more debugging I saw 2 different behaviors depending on whether the builtin d3dx11_43.dll was used, or the native one.

The builtin d3dx11_43 doesn't recognize icon/cursor files at all, and fails there immediately. It's file pattern recognition strategy is also very limited and doesn't let us properly differentiate between a cursor file and old TGA file formats, although for LMU it doesn't seem to cause any issues.

The native d3dx11_43 doesn't do pattern recognition by itself and instead uses windowscodecs (builtin!) pattern matching functionality. This functionality is also fairly limited (although a bit better than what builtin d3dx11_43 does) but also not flexible enough to distinguish Cursor vs TGA and once again doesn't have any pattern matching for cursor at all.

The changes in my branch add more advanced pattern matching to windowscodecs where we can more thoroughly validate Cursor vs TGA and therefore just the windowscodecs changes when used with native d3dx11_43 will now work.
I also added functionality to d3dx11_43 builtin to be able to load icon files, but not cursor files as the pattern matching available there is insuficient and would probably make some other games not work.

Game crashes on start after update v1.3 applied.

Until the last update, game worked with GE-Proton10-25-LMU-hid_fixes and I could race an online event.

Don't know if this is related to the game, proton or EAC, but right now, crashes every time I try to run it.

Game crashes on start after update v1.3 applied.

Until the last update, game worked with GE-Proton10-25-LMU-hid_fixes and I could race an online event.

Don't know if this is related to the game, proton or EAC, but right now, crashes every time I try to run it.

https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton10-34-LMU-hid_fixes

@alexbrrsclnt, check new release (http://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton10-34-LMU-hid_fixes) please.

Something in between GE versions 32 - 33 "fixed" game initialization. I just reapplied patches on top of GE10-34, and it works

@alexbrrsclnt, check new release (http://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton10-34-LMU-hid_fixes) please.

Something in between GE versions 32 - 33 "fixed" game initialization. I just reapplied patches on top of GE10-34, and it works

Yeah, just see the new version, applied and tested and game works! Thanks a lot man!

Hi I have updated my VR fix fork here:
https://github.com/srounce/proton-ge-custom/releases/tag/GE-Proton10-34-LMU-hid_fixes-vr

It's basically @JacKeTUs fork with the same fix as before applied to the Wine version.

Hi all,
I have almost the exact same issue as @azlekayn , however this has started again for me with v1.3. On the previous version, using GE-Proton10-25-LMU-hid_fixes , there was effectively no microstutter when using basic hud with all elements other than radar turned off, in CEF mode 2. In versions before v1.2, the game was utterly unplayable due to constant stuttering.

Since v1.3, the stuttering has returned and I have been unable to fix it with any fixes I could find, including all listed above, however I am aware some will only apply to the previous versions due to the new UI framework. It will occur in online servers, however only in race servers. On the practice servers I haven't had it happen. However as soon as I join the event, the stuttering starts and will continue for every session. I thought this could be to do with the other player models, however with lowest render setting and the lowest opponent car number, it makes no difference. It even happens during qualifying, when no other cars are being rendered. GPU and CPU load is around 50%-60% with clocks all sitting at normal speeds.

Has anyone else experienced this with v1.3, and has anyone ever been able to fix it?
It's particularly annoying as I bought RaceControlPro+ the day before v1.3 released so i've effectively wasted that money if it isn't fixable.

System:
EndeavourOS/Arch
KDE Plasma 6 on Wayland
Moza R5

Ryzen 7 7700X
NVidia RTX 3080 (running latest nvidia-open-dkms drivers)
32GB DDR5

Steam launch options: DXVK_HUD=fps,frametimes,gpuload gamemoderun %command%

This is the frame time graph, the spikes will happen pretty consistently every few seconds.

Thanks in advance for any advice.

Replying to https://github.com/ValveSoftware/Proton/issues/7512#issuecomment-4180946678

Hi there!

So havn't had a chance to log into V1.3 ( life is super busy atm), but I got rid of most my stuttering by disabling telemetry.

Only similarities I can see between our systems is amount of ram and CPU, maybe it's something to do with 7th gen Ryzen?

I have a 7800x3d

Maybe try a nuclear reset, as in, rename .steam and .local/share/Steam
(this once resolved it for me IIRC for raceRoom) - if it works you can recover you stuff from the renamed folders.

Anyone getting a blackscreen at startup after the new update V1.3.2.0 ?
I have removed the caches, recreated proton prefix but it's only getting to render a black screen with a mouse cursor

Can play without issues here, 2D aswell as VR. Because of VR I am using the fork by srounce, so maybe that also fixes your issue.

Works if you run in a separate terminal, before the game:
socat TCP4-LISTEN:6397,fork TCP6:[::1]:6397

Issue seems to be rest server listens on IPv6, coherent, to draw the interface, only connects on IPv4. The command bridges IPv4 <> IPpv6. If it doesnt work make sure to disable firewall or at least open 6397

It looks like somehow game tries to listen on localhost, and if this name is not present in /etc/hosts, it doesn't bind to it, therefore doesn't launch... Later game tries to connect to 127.0.0.1:6397.

If i add 127.0.0.1 localhost to my /etc/hosts, game launches

first - commented 127.0.0.1 localhost line, game black screens

second - 127.0.0.1 localhost present in /etc/hosts, game launches.

UPD: apparently, if localhost resolves to multiple IPs (if ipv6 and ipv4 loopbacks are present) game somehow binds to only one of them. That's why socat fix works only for some... For me on Arch there was no bind at all.

UPD: Game launches if in /etc/hosts there is just one 127.0.0.1 localhost loopback record, without ipv6

Another even better solution:
"WebUI bind": "127.0.0.1",

grep "WebUI bind" .steam/steam/steamapps/common/Le\ Mans\ Ultimate/UserData/player/Settings.JSON 
    "WebUI bind": "127.0.0.1",

So can we expect JacketUS's proton changes to be implemented into official Valve proton or are we out of luck. My report got merged with this one, although I don't think it was relevant to this massive post but oh well. This gives me the impression that there really isn't an interest in making LMU playable with official Proton versions.

@BluesAdam this is on me, sorry, i didn't had time yet to properly finish this patch and tests and send it to the upstream.

@BluesAdam this is on me, sorry, i didn't had time yet to properly finish this patch and tests and send it to the upstream.

I'm waiting with patience, no worries. This is the one thorn for simracers on Linux. Once this is sorted out it will be a big relief for everyone. Thanks for the hardwork and take your time. Hopefully it won't take too long :)

This gives me the impression that there really isn't an interest in making LMU playable with official Proton versions.

I'm rather baffled who you're expecting the "interest" to be from? S397 aren't that interested in doing it because it seems that as part of their port efforts they are overhauling the parts of the UI which use the missing corners of Direct2d that Jacketus has implemented, and so his fixes won't be required in upcoming releases of the game.

Anyone here able to race after the 1.4 update ? I am able to start and rive in a race weekend but I can not join an online practice or a race.

@domdo452 Same issue here, cannot join online sessions. Starting to gather Logs and traces now.
Initial testing points to missing bcrypt implementation in Proton.

--- Proton / Wine version ---
======================
Proton: 1785137693 experimental-11.0-20260724c
SteamGameId: 2399420
Command: ['/home/phil/.local/share/Steam/steamapps/common/Le Mans Ultimate/start_protected_game.exe']
Options: {'forcelgadd', 'gamedrive'}
depot: 4.0.20260608.242786

--- All bcrypt fixme/warn/err lines ---
4058:32598.126:0184:0188:fixme:bcrypt:BCryptCreateHash ignoring object buffer
5987:32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported
5988:32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported
5989:32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported

--- Causal chain at 'Join': NetWorker spawns -> bcrypt derive fails -> retry loop ---
32637.967:0184:03b8:warn:threadname:NtSetInformationThread Thread renamed to L"LMU-HTTPWorker id952"
32638.968:0184:03bc:warn:threadname:NtSetInformationThread Thread renamed to L"LMU-HTTPWorker id956"
32639.160:0184:03c0:warn:threadname:NtSetInformationThread Thread renamed to L"NetWorker"
32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported
32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported
32639.210:0184:03c0:fixme:bcrypt:derive_key_hash buffer type 1 not supported
32639.969:0184:03c4:warn:threadname:NtSetInformationThread Thread renamed to L"LMU-HTTPWorker id964"
32640.969:0184:03c8:warn:threadname:NtSetInformationThread Thread renamed to L"LMU-HTTPWorker id968"

--- Endless retry storm (join never completes) ---
LMU-HTTPWorker threads spawned this session = 370
  first:   L"LMU-HTTPWorker id728"
  last :   L"LMU-HTTPWorker id996"

Well that was a quick find.

Issue

LMU's multiplayer join does an ECDH-P256 key exchange and derives the session key with BCryptDeriveKey(KDF=BCRYPT_KDF_HASH, …) passing a KDF_SECRET_PREPEND buffer. Wine's derive_key_hash ignored KDF_SECRET_PREPEND/KDF_SECRET_APPEND entirely (it hashed only the shared secret), so the derived key was wrong → the join handshake never validated → infinite spinner.
Reproduced identically on GE-Proton10 and Proton Experimental; triggered by today's LMU update.

The fix

A 1-function patch in dlls/bcrypt/bcrypt_main.c that makes BCRYPT_KDF_HASH honor the prepend/append buffers and compute the
spec-correct Hash(prepend || shared_secret || append).

0001-bcrypt-Support-KDF_SECRET_PREPEND-APPEND-in-BCRYPT_KDF_HASH.patch

@BluesAdam You can also just use this prebuilt release.
https://github.com/schlegp/proton-ge-custom/releases/tag/bcryptfix-v1

@BluesAdam You can also just use this prebuilt release. https://github.com/schlegp/proton-ge-custom/releases/tag/bcryptfix-v1

Thanks a lot. Giving it a try right now.

EDIT: Works like a charm. Thank you!

@schlegp At this moment the release build keeps crashing on startup (at LMu startup so just after the 'securing game'-screen for me.I also tried to replace the bcrypt.dll files from the fix-build to the 10-34-release by hand and the files size of the bcrypt.dll's are very different. I do know that your patch should not lose about 40kb in filesize so I think that it's kinda weird. Could it be some kind of compiler-settings that are different in someway?

I am on CachyOS if that is useful.

@schlegp At this moment the release build keeps crashing on startup (at LMu startup so just after the 'securing game'-screen for me.I also tried to replace the bcrypt.dll files from the fix-build to the 10-34-release by hand and the files size of the bcrypt.dll's are very different. I do know that your patch should not lose about 40kb in filesize so I think that it's kinda weird. Could it be some kind of compiler-settings that are different in someway?

I am on CachyOS if that is useful.

Did you download the VR version by any chance (or vice-versa)?

Just finished a gold race at Laguna Seca, I can confirm the non VR version of proton from @schlegp https://github.com/schlegp/proton-ge-custom/releases/tag/bcryptfix-v1 worked for an online race. Now that I've finished a race, I went to check my profile and that page is showing No Race History. I've relaunched LMU and checked again, but no luck. Is anyone else experiencing this?

UPDATE: Race History was working today in game, so I'm gonna chalk this up to a server issue yesterday.

I released new built version with cherry-picked commits from @srounce and @schlegp
https://github.com/JacKeTUs/proton-ge-custom/releases/tag/GE-Proton10-34-LMU-hid_fixes-vr-bcrypt

@schlegp, big thanks for investigation and the fix! Are you planning to send this patch to upstream Wine?

@JacKeTUs I am planning on upstreaming it, just have to check out the proper way of doing it. Do I just open a MR? Or do I have to create an Issue for it first?
Also it needs Tests aswell, so will have to write those today.

@domdo452 Hmm.. You could try JacKeTUs build, maybe I have packaged it incorrectly. We would need some logs of the crash to be able to help here. You can launch the game with "PROTON_LOG=1 %command%" to get a log in your home directory.

@domdo452 are you trying to run in VR or not?

@schlegp https://gitlab.winehq.org/wine/wine/-/wikis/Developer-FAQ#can-i-contribute-code-generated-by-a-large-language-model-llm-tool

@srounce Well, then that code will not be upstreamed, hopefully someone else with the skills to do it without LLM can do it.

[@srounce] are you trying to run in VR or not?

I am (trying to) running the non-vr version

@domdo452 Hmm.. You could try JacKeTUs build, maybe I have packaged it incorrectly. We would need some logs of the crash to be able to help here. You can launch the game with "PROTON_LOG=1 %command%" to get a log in your home directory.

I have managed to get it working with the JackeTUs build

I'll make a bcrypt test and patch for upstream.