Tainted Grail: Fall of Avalon
I'll attempt to fix it create a pull request.
However, I won't be able to test it on systems using "charge_*" files.
Elevated to a general enhancement upstream:
I looked quite a bit. I don't see anything wrong in implementing energy_ based query (and maybe a bit better handling of the case when something goes wrong when reading required values) and probably going to do that. However, I don't see neither periodic fps drops at game start, nor any change in rate of GetSystemPowerStatus() calls the game does if I fill some sensible values instead of zeroes with missing fields.
Could you please elaborate a bit if possible:
- how exactly do you reproduce and observe the stated issue (periodic fps drop);
- what exact change in game behaviour do you see WRT the frequency of GetSystemPowerStatus calls when the values are filled in?
So far (after some brief check) I see the game calling GetSystemPowerStatus once per ~16ms regardless of whether values are filled in or not, which is probably not insanely lot. While, again, supporting energy-based reporting makes sense regardless, I am not convinced so far that doing something like throttling /sys read frequency here with a cache worth it.
Hi gofman,
Thank you for the reply.
I've patched the energy query and will submit it upstream, it's useful either way.
About the bug. Unfortunatly I still haven't been able to test whether the patch solves my problem. I'll do that this weekend and get back to you should the problem persist.
@Tomas-Mendes-ai Did you find a solution to this? I am hitting this ~1Hz frame drop problem as well. I tried only accessing the energy_ files, but that didn't solve the issue. Making fill_battery_state() do basically nothing (i.e., always set AcOnLine true) solves the issue, but that won't work for programs that really need the battery/AC state.
Hi @wlentz
I have a merge request open upstream to patch fill_battery_state().
No luck on my side fixing the problem.
If you have the time, do you think you could build from source using this branch?
I'd like to know if that fixes it for you and whether my patch is insufficient or we are having the same symptom for two distinct problems.
Thanks.
Hmm. Im getting
Unhandled exception: unimplemented function coremessaging.dll.DllGetActivationFactory called in 64-bit code (0x006fffffc0d107).
The game used to work, but i havent tried for few weeks.
Tested with: proton-experimental, 9.0-4 and GE 10-10
All have the same problem.
Full log, taken with GE proton but can upload the official one also if needed.
steam-1466060.log
log with proton experimental:
@xpander69 how is that related to this issue?
@xpander69 how is that related to this issue?
what issue? its a different issue. i cant open another issue because every game has 1 issue per game policy here.
Coming here after a long journey... Have the same 1Hz spikes.
I might know a few things about programming - but im new to linux... So i just hope this'll be fixed or improved soon.
Good luck.
I have charge_* files present only, but still have this 1hz stutter.
for testing, I mounted a temp empty filesystem over this sudo mount -t tmpfs none /sys/class/power_supply/BAT1 and the lag is gone.
I've been having the same stutter, also have charge_* files only. Masking the power supply path with sudo mount --bind /path/to/empty/dir /sys/class/power_supply/BAT1 fixes it. sudo umount /sys/class/power_supply/BAT1 to undo.
Still experiencing this same issue with Tainted Grail, using a Legion Pro 5 with an RTX 4060 running Bazzite, and using Proton 10-3, Experimental, or GE's 10-26.
Forgive my lack of know-how, but my /sys/class/power_supply only contains "BAT0" (containing both charge_ and energy_ files), so eo-uk's temporary solution doesn't seem to work.
I've been having the same stutter, also have charge_* files only. Masking the power supply path with
sudo mount --bind /path/to/empty/dir /sys/class/power_supply/BAT1fixes it.sudo umount /sys/class/power_supply/BAT1to undo.
This worked for me! 4070 laptop, 8845hs cpu, nobara.
Great work!
Still happening, seems to be an issue mainly in Legion laptops as all the reports I'm seeing are from those (and I'm also using a Lenovo Legion 5). Using the mount battery command fixes it but the laptop will pester me that there's no battery charge until I restart. (and if anyone's coming from the future - you can just replace BAT1 with BAT0 if you only have that one).
The fix has been waiting for a response for almost a year now ( https://gitlab.winehq.org/wine/wine/-/merge_requests/8460 ), it would be great if someone can ping a Wine maintainer and let them know people still need the fix.
Seriously...we keep getting patches - no one bothers to look into this issue???
No other game has this problem. They all run without a hitch.
Please for all that is holy look into this, and fix it...
Ditto, this is still a problem. I have an MSI Katana A15 so it's not limited to Legion laptops. The fix above (mount battery commands) still works.
Can confirm this is a problem with HP Victus Laptops to
I have mad a mod that fixes this issue because I wanted to play the game higher then 15 fps. I now get 60+ fps https://www.nexusmods.com/taintedgrailthefallofavalon/mods/243?published=1
I have mad a mod that fixes this issue because I wanted to play the game higher then 15 fps. I now get 60+ fps https://www.nexusmods.com/taintedgrailthefallofavalon/mods/243?published=1
Devs - could you please just integrate what this hero is doing on his free time to finally fix this issue? :D
Edit: Jesus Christ this works perfectly...
I have mad a mod that fixes this issue because I wanted to play the game higher then 15 fps. I now get 60+ fps https://www.nexusmods.com/taintedgrailthefallofavalon/mods/243?published=1
Devs - could you please just integrate what this hero is doing on his free time to finally fix this issue? :D
Edit: Jesus Christ this works perfectly...
what was you getting in fps before and after. Also if you have any problems in game please tell me so i can see if i can fix it. This includes lag promblems, etc. I might be able to work on a fix for those to. Also please endore and vote so other people on nexus can see the mod. I am trying to hopfully get more people who have this battery issue to know about this mod so they can play the game.
Proton versions
proton experimentalx1 2025-08proton 9.0-4fx1 2025-06
Upstream links
- show_bug.cgi?id=58401x1 2025-06
- show_bug.cgi?id=58397x1 2025-06
DLLs
coremessaging.dllx1 2025-08
Compatibility Report
System Information
I confirm:
steam-10551920230311919616.log
Upstream
I traced the issue upstream to WineHQ and added it in Bugzilla. Mirroring it here for visibility:
Observed Symptoms:
Frametime spikes from ~5ms to ~100ms occurring at ~1Hz intervals.
GPU frame dispatch (via DXVK) is delayed due to thread blocking in Wine’s battery status polling logic.
Performance Analysis (logs.txt):
strace shows constant, repeated attempts to read nonexistent files in /sys/class/power_supply/BAT1/
perf stat reveals ~8,270 openat() syscalls in 10 second window (on game title screen).
perf record/report shows significant thread time consumed inside NtPowerInformation-related logic in ntdll.
Root Cause:
In dlls/ntdll/unix/system.c, the function fill_battery_state() (Linux version) hardcodes the use of attributes: "charge_now" "charge_full" and "current_now".
These attributes are not universally present in /sys/class/power_supply/. On some systems, particularly those using energy-based reporting (µWh), the ABI-compliant alternatives are: "energy_now", "energy_full" and "power_now".
Since Wine looks only for the "charge_*" files and fails to return expected information, the game loops the query constantly which results in openat() being used in a tight polling loop - blocking threads and causing intermittent CPU stalls that propagate to the GPU rendering pipeline.
Solution 1:
Solution 2:
I gather solution 1 has a more consistent impact across different systems, while solution 2 is more lightweight on systems with "charge_*" and heavier on others.
Further reading:
Note:
Attribute "scope", while implemented in the kernel, is undocumented in the power_supply_class docs. Will later check if the rest of the documentation is up to date and raise the appropriate issue upstream. Until then, do not assume it correctly reflects the kernel implementation.
Out-of-scope commentary:
While Wine's behavior of querying /sys/class/power_supply/ on every NtPowerInformation() call correctly emulates the Windows API semantics, it has unintended performance implications on Linux. This is due to the fact that retrieving battery information from sysfs involves real filesystem I/O, including frequent failed lookups on systems that expose energy_* instead of charge_* attributes.
Therefore, applications may call NtPowerInformation() without prioritizing caching or proper fallback logic as they expect the operation to have a lower-cost then it does on Linux - causing significant and unnecessary performance degradation.
Will raise this for an enchancement in the proper channels.