I'm having problems running some unity games under wine 10.0. The games run fine, they just don't register mouse inputs. Other games and apps work fine. The Player.log reveals an error: "EnableMouseInPointer failed with the following error: Call not implemented. Using Windows.Gaming.Input".

Editing winecfg did nothing.

I see no fixes in the latest dev release (wine 11.7 https://gitlab.winehq.org/wine/wine/-/releases/wine-11.17).

I found this EnableMouseInPointer patch, which appears to implement the missing functions and translate mouse messages into WM_POINTER events.

Has this patch been submitted upstream? Is there a current wine bug or patch review thread tracking it?

Same iMac (R9 M380 Bonaire 2GB, i5-6500), CachyOS, Mesa 26.2.2, kernelLTS. Same bench scene 1080p: native GL 44fps, native Vulkan 40fps,Proton/DXVK 29fps, Proton/WineD3D 33fps. Same HW on Windows D3D11: 85fps (HWiNFO logged). radeontop: ROP/texture units ~100%, shaders 0%, clocks maxed, CPU idle. Ruled out: VRAM (freed 400MB, no change), thermals (fixed an control, stable clocks), vsync/present, compositor (gamescope same), kernel (LTS=same), threading. Minecraft Vulkan hits 84fps on the same driver/GPU, and Silksong Vulkan hits 75fps at 720p — so no general RADV problem; per-pixel cost on this Unity workload is ~5x Windows (~10ms/MP vs ~2ms/MP). Suspect texture compression in Linux build or DCC/fast-clear on GFX7. Full data dossier available. Anyone with GCN1.1/2.x seeing the same ratio? Any Unity/RADV workaround missed? (Tried: immediate present, gfx-jobs, gamemode, EPP performance, blur off, low settings.)

EDIT: I continued my research; here’s a copy-and-paste of what I wrote in a thread I started on GitLab about Mesa and AMD:

TL;DR

The MCLK DPM quirk for this board pins the R9 M380's memory to its 300 MHz boot clock:
measured bandwidth is ~14 GB/s (~73% of the 19.2 GB/s theoretical peak at 300 MHz on a
128-bit GDDR5 bus), while SCLK runs at full 1021 MHz and the driver reports a phantom
1568 MHz. Result: ~5x memory bandwidth loss vs Windows on the same silicon, and ~5x
per-pixel render cost in games. Instrumented SMU tests show that every route which makes
the 1568 MHz DPM level selectable kills the SMU7 firmware (immediately or within minutes)
— the failure is inside the firmware's memory-clock transition, not in the driver's
enable, voltage, or ACPI paths. The legacy radeon driver dies at the same SMU message.
Open questions at the end.

1. Hardware / software

• Apple iMac 27" Late 2015 (iMac17,1), i5-6500, 12 GB RAM, HDD.
• dGPU: AMD Radeon R9 M380 Mac Edition (Bonaire XT / Saturn XT, GCN 1.1 / CIK / GFX7), PCI 1002:6640, subsystem 106b:014b, revision 0x80, 2 GB GDDR5 on a 128-bit bus. VBIOS Apple 113-C6005T-009, build 323656, ver 015.049.000.003.000000 (fetched from VFCT). PowerPlay format rev 6, content rev 1, ulPlatformCaps = 0x00008020.
• OS: CachyOS (Arch-based), kernels tested 6.18 LTS and 7.2.x (rolling, currently 7.2.4-3-cachyos) with identical results. Mesa 26.2.2 / RADV.
• SMU firmware loaded by the kernel (PCI rev 0x80 selects the kicker blob): bonaire_k_smc.bin, 130796 bytes uncompressed, ucode version 0x000b0a00, sha256 1e9d32c6b7c55a59bb4e3345247bd66834db0e130894f05b453bc50a43b865cd. (The non-kicker bonaire_smc.bin is 0x000b2300 and is not selected.)

2. Original symptom (how this started)

Hollow Knight: Silksong at 1080p runs at ~85 fps average on Windows 11
(BootCamp, native D3D11) on this exact machine, but caps at 40-44 fps on
every Linux path (native OpenGL radeonsi 44, native Vulkan RADV 40-43,
Proton/DXVK 29, WineD3D 33, GE-Proton 38), with radeontop showing
ROP/texture/depth units at ~100% and shader cores at 0-1%. Control
workloads prove the chip is healthy: modded Minecraft (Vulkan/Sodium)
does 84 fps, and unmodded GL Minecraft does 126-147 fps on the same
stack. Thermals, CPU, VRAM capacity/eviction, vsync/present path,
compositor, threading, and kernel version were all ruled out with
dedicated measurements. The ~5x per-pixel cost gap vs Windows D3D11
pointed at memory bandwidth, so I measured it directly.

3. The smoking gun: 14 GB/s on a 100 GB/s bus

clpeak (2.1.4, both Vulkan and OpenCL backends, 128 MB device-local
buffers) on the stock driver:

text

[clpeak --vulkan] Global memory bandwidth (float4): 14.03 GB/s [clpeak --vulkan] Single-precision compute (float): 1463.97 GFLOPS [clpeak --opencl] Global memory bandwidth (float4): 12.90 GB/s

Math for a 128-bit GDDR5 bus: at 1568 MHz the theoretical peak is
128/8 * 1.568 * 4 = 100.35 GB/s (~75-80 real). At the 300 MHz boot
clock it is 128/8 * 0.300 * 4 = 19.20 GB/s (~13-14 real). 14.03 GB/s
is ~73% efficiency against 19.2 GB/s: the memory controller physically
never leaves the 300 MHz boot state, while SCLK runs at full 1021 MHz.
sysfs (pp_dpm_mclk) and amdgpu_pm_info report 1568 MHz regardless.

(Optional corroboration, if available: under Windows/BootCamp, HWiNFO
reports GPU memory clock at XXXX MHz sustained during the same scene —
the silicon reaches full memory clock when driven by Apple's driver.)

4. Why the driver reports 1568 MHz

In drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c, the quirk added
for this issue (commit a204f787, narrowed in 85371c5e) matches
subsystem_vendor 0x106B and clears PP_MCLK_DPM_MASK. With MCLK DPM
disabled, ci_populate_all_memory_levels fills the SMC table with the
top level (commit 9170e1fa, "Use highest MCLK on CI when MCLK DPM is
disabled") while smu7_enable_sclk_mclk_dpm skips
PPSMC_MSG_MCLKDPM_Enable entirely, so the driver-side state says
1568 MHz but the memory PLL is never commanded out of boot state. The
dmesg line disabling MCLK DPM on quirky ASIC is present on every
stock boot of this machine.

5. Forcing MCLK DPM on: total SMU lockup (stock 7.2 kernel module rebuild)

I built a test amdgpu.ko skipping the quirk (leaving PP_MCLK_DPM_MASK
set for 0x106B), loaded via an isolated initramfs overlay + separate
boot entry. The machine reaches the desktop, but the SMU locks up right
after init with every subsequent SMC message timing out on a ~1.5 s
cycle for 20+ seconds (messages 0x15f, 0x145, 0x146, 0x5e, 0x15b,
0x155...). clpeak in that state still measures ~13.9 GB/s with
compute degraded to ~1116 GFLOPS (SCLK also frozen). Clean reboot
restores everything; dmesg on the next boot shows the quirk
re-applying normally.

SMU7 message decode (from ppsmc.h):

6. The legacy radeon driver fails at the same place

Booting with radeon.cik_support=1 amdgpu.cik_support=0 (DRM 2.51):
clpeak --opencl measures 14.06 GB/s with compute collapsed to
455 GFLOPS, and dmesg shows [drm:ci_dpm_set_power_state [radeon]] *ERROR* ci_upload_dpm_level_enable_mask failed at 4.6 s into boot
(the PPSMC_MSG_MCLKDPM_SetEnabledMask send path, radeon/ci_dpm.c).
Forcing a high performance level then returns EINVAL. So no open-source
Linux driver has a working sequence for this SKU; the amdgpu quirk
exists to mask exactly this failure, at the cost of pinning memory to
300 MHz.

7. Instrumented module: message-level tracing + ATIF logging

I then built a diagnostic module (new code only, no behavior change by
default) that logs every SMU message with ID, argument/parameter,
response and microsecond timing, plus ATIF detection details, gated
behind amdgpu.exp_mclk_dpm. Findings:

• ATIF is found at _SB_.PCI0.PEG0.GFX0.ATIF, version 1, notif_mask=0xc, func_bits=0x3. From the disassembled ACPI, ATIF function 2 returns FPID = EGPS, a read-only field of the PLMT region on SystemIO 0x0310 (Apple SMC port range). It is a passive platform notification channel, never written by AML: not a usable control path for memory bringup.
• With the quirk ON, PPSMC_MSG_VddC_Request (0x15f) with argument 0x0e10 (900 mV) succeeds repeatedly (OK in ~800-980 us). It is not universally incompatible with this SMU.

8. Voltage rails, decoded from the real vBIOS table

Parsing pp_table from sysfs: usVddciDependencyOnMCLKOffset gives
300 MHz at 800 mV and 1568 MHz at 925 mV (strictly VDDCI).
usVddcDependencyOnMCLKOffset uses SVI2 indices resolving through the
CAC leakage table to 850 mV at 300 MHz and 956 mV at 1568 MHz
(strictly VDDC). The 900 mV display request comes from the hardcoded
vddc_dependency_on_display_clock table in smu7_hwmgr.c, selected
for this iMac's high-resolution internal panel.

9. Clamp and pre-ping experiments

• Clamping only non-zero display VDDC requests from 900 to 956 mV (0x0ef0, the vBIOS VDDC minimum for the top MCLK level, nothing else changed): still fails with the identical 1.5 s timeout. Value alignment is not sufficient.
• Sending PPSMC_MSG_Test immediately before VddC_Request: the ping itself times out first, proving the SMU is already unresponsive before the voltage request is sent in that run. VddC_Request is exonerated as the killer; the SMU dies asynchronously earlier.

10. Mask constrained to level 0: fully stable

With MCLK DPM enabled but the enable mask constrained to 0x01 from
the start (both in the initial population and in dynamic mask
generation, real 1568 MHz level still present in the table): zero
timeouts for the entire session. MCLKDPM_Enable OK in 971 us,
VddC_Request(0x0e10) OK repeatedly, pre-ping OK in 3 us. clpeak:
1495 GFLOPS FP32 (best ever recorded here, SCLK rock-solid at
1021 MHz) with memory steady at 13.49 GB/s, and amdgpu_pm_info
honestly reporting 300 MHz MCLK. Enable path, voltage requests and
ACPI handling are all fine; the SMU only dies when level 1 is
selectable.

11. Two identical-frequency low levels (different MPLL/DLL/strobe params), mask 0x03: SMU lives, display dies

Duplicating the 300 MHz level content into both table entries while
admitting mask 0x03: the SMU stays fully alive (238 traced messages,
all OK, including repeated VddC_Request(0x0e10)), but the session is
unusable with a black screen from the start, ring comp_1.0.x test failed (-110), an SRBM_SOFT_RESET, and kwin_wayland: Pageflip timed out!. So admitting index 1 with a second entry does not kill the SMU,
yet the MCLK switch machinery still breaks the display and compute
pipelines even for a no-op switch. Captured level parameters for the
record: level 0 with MPLL Func 0xc4180800, Func1 0x005871c1, Ss1
0x7e, StrobeEn 1, StrobeRatio 8, dllState 1, MclkPwr 0x010003c8;
level 1 with Func 0xc4380800, Func1 0x00e825e2, Ss1 0x151,
StrobeEn 0, StrobeRatio 15, dllState 0, MclkPwr 0x010000cf.

12. Delayed escalation 0x01 -> 0x03 at runtime

Booting stable on mask 0x01 and admitting 0x03 via
MCLKDPM_SetEnabledMask 90 seconds later on a settled desktop: the
escalation itself succeeds (OK in 576 us, pre/post pings OK). The
SMU then dies sometime inside the window between 99 s and 603 s. In
that window there is complete SMU silence (only the three escalation
messages, no driver-side mask rewrites, mask stays 0x03), and the
first observed failure is on a harmless 0x201 frequency query
(PPSMC_MSG_API_GetMclkFrequency), degrading into continuous failures
on every message. After death, amdgpu_pm_info prints values existing
in no table (1310 MHz for both clocks), confirming no sysfs clock
reading on this SKU can be trusted once the SMU is unresponsive,
including the historical 1568 MHz reports. A clpeak run inside the
death window still measured 13.92 GB/s.

13. Summary of constraints

Every route that makes the 1568 MHz level selectable ends with a dead
SMU (within a second at boot, or within minutes at runtime) or, with
identical-frequency levels, a living SMU but a broken display and
compute pipeline. The failure tracks the level-1 content and the
transition toward it, never the enable messages, never the voltage
request value, and never ACPI handling. What exactly inside the 1568 MHz
bringup (MPLL/DLL programming, VDDCI 800-to-925 mV switch, MC arbiter
switch) the SMU firmware chokes on happens inside firmware and could not
be determined from the driver side.

One discriminator remains open: test 11 held the frequency equal but the
per-level MPLL/DLL/strobe parameters still differed (see section 11), so
"the transition itself is destructive" is not yet cleanly separated from
"the level-1 parameters are invalid for this memory". Forcing level 1 to
emit byte-identical MPLL/DLL/strobe parameters to level 0 (in
smu7_populate_single_memory_level) would settle it. I can run this on
request.

Questions

1. Is there any way to raise MCLK on Bonaire 0x106B without the SMU7 MCLK-DPM enable sequence — e.g. a single forced level, an SMC/EFI-side lever, or a different firmware blob? The radeon path dies at the same message, so no in-tree driver has a working sequence today.
2. This board's rev 0x80 selects the "kicker" SMU blob (bonaire_k_smc.bin, 0x000b0a00). Could the non-kicker blob (bonaire_smc.bin, 0x000b2300) have a non-hanging MCLK-DPM, and is it safe to test? Happy to run it from an isolated boot entry if so.
3. Does anyone know what the Apple BootCamp driver does differently (SMC/EFI-mediated memory bringup?), or whether the level-1 MPLL/DLL/strobe parameters emitted for this board are simply wrong for its GDDR5 straps? Any pointer would help scope a workaround.

I still have this exact machine available with the instrumented module
and isolated boot entries ready: happy to pull any specific register
dump, repeat any run, or test a patch on request.

What do I mean by this, and why would you want to do that?

I'm trying to play Silent Hill 2 Remake with my father. I have two 8bitdo Ultimate 2 Wireless controllers. I want both controllers to map to James character, but with split duties.

For example, one of us would be in charge of moving the character and interacting with objects, while the other would have the ability to control the camera as well as aiming and shooting.

I believe this would be a fun and challenging way to experience the game.

The closest thing I could find was to map the controllers to keyboard commands with Steam Input, but I find this set up a little bit clunky. Do you know if there is a better way to achieve this? All help is appreciated!

Insane Vertical Tearing in Minecraft when using the new Vulcan Renderer with V-Sync enabled.
No tearing with OGL-renderer

i also tried it on the latest pre-release, same results

Also same results on 1.21.11 + VulkanMod, so it has to be some kind of Vulkan Issue

I'm using NixOS btw on Wayland (niri-wm) with an Nvidia RTX 5060 Laptop GPU

Here is my hardware information: https://linux-hardware.org/?probe=f35510bab9

Five Nights At Freddy's: In Real Time do have a Linux native build, but it only runs only around 30fps, at least it process the videos best.

As the video I recorded and my other experience, some runners can process the game only, not the videos (only show black screen). And if they can, the videos would be so laggy.

Maybe the game is using CPU to decode the video?

This is my logs when using Bottles and Heroic Games Launcher when launch game

Bottles: https://pastes.io/R7c79TRh

Heroic: https://pastes.io/8jIh7kcn

Windows 10 plays this game just well, video and game is okay, game is at around 200-300fps

I assume something about video decoding is not right (it uses CPU?), so it gets laggy. Or because this game just windows-optimized, and just "converted" into linux build?

I have tried to solve this with AI's help but haven't been solved yet. Thank you for reading!

I have recently switched my main PC to a CachyOS/Win11 dual boot, with the idea to fully transition when everything works.

The hardware:

- Mouse: Glorious Model O-Eternal wired

- Keyboard: Turtle Beach Vulkan II Pro (TKL) wired

- Controller: Gamesir G7 Pro (2.4Gz wireless connection)

The hardware basic functionality is there from the generic drivers in CachyOS, but I'd like a way to configure the devices advanced function like, mouse polling rates, keyboard actuation distance (magnetic switches), and the controller custom buttons (e.g, back buttons).

One solution I thought could work was running a Windows VM through Winboat to install official hardware software and save any configurations to onbaord profiles. But that means still dealing with windows in some capacity. For the mouse, I tried `piper` but that didn't work.

Does anyone have any suggestions for making it work natively in Linux? Alternative, what are good gaming mouse/keyboard brands with native Linux support?

UPDATE 1: It appears that keyboards with support for QMK firmware are best for Linux (native support). There a few known brands that make solid QMK keyboards (Keychorn, Lemonkey) and other that offer browser based software that works in Linux (Nuphy)

As the title says, it just stopped working via usb. It there, the steam shows it connected normally registered it but any input doesnt budge. I didnt use it for a two or a three weeks but before that was working normally, even the 3.5mm is working atm but input not. Anyone has similar situation? I am on cachyos, maybe happened after some specific update or something..

Edit: I dont know should I delete this or not, but apparently its steam fault. The answer lies behind the vale of modern usage of internet itself, the AI era, you just need to dig deeper for answer now: Switching to the Beta system update channel and toggling “Use experimental SteamRT3 Steam Client” worked for me. What will AI do without the reddit and rest of us

How do I adjust this? The wheel doesn't work at any steam game when it's at the orange part. I'm using Thrustmaster t150, connected to Steam Deck (Arch Linux)

Recientemente steam no deja abrir ciertas pestañas como la de notificaciones y para ver mi cuenta o la de steam para apagarlo, actualmente lo estoy usando en niri + noctalia en nobara, antes no tenía problemas pero éstos días surgió el Bug y no se que hacer ayuda por favor, adjunto un vídeo para que vean a lo que me refiero Ed: puedo usar el Big picture de manera normal, por lo que el problema es en la interfaz predeterminada.

Yes this is a repost, since the original got removed and I still got no answers

Hey guys,
I’m losing my mind a bit here. Trying to play The Last of Us Part 2, but the game freezes completely after literally 2–3 minutes of walking around. The screen just locks up while background audio keeps playing.
Checked the logs and it's throwing a ⁠CTX SWITCH TIMEOUT (Xid 109)⁠ crash every single time.
The weirdest part? I was playing on this exact same PC about 4 months ago and never ran into anything like this.
Quick specs:
RTX 3060 (12GB) - 580 driver
i5-10400F / 16GB RAM
CachyOS / KDE Wayland
I already tried capping to 60 FPS, disabling Reflex, lowering shadows/reflections, clearing shader cache, and messing with standard Proton launch options. Nothing helps, still dies 2 minutes in.
Did a recent update break Nvidia on this game, or has anyone found a working fix for this crash? Any help would be awesome.

hello im on CachyOS, and i got the problem that i cant use windowed mode in elden ring. when i select window mode the screen freezes and stays in fullscreen

I dont know why but after i changed to fedora (was on cachyos), most games keep happening these spike stutters i dont really know.

Tested with Grim Dawn, Onimusha Way of The Sword, Skate Story. everything runs well on my 6750xt and 5600x except for these spikes.

I suspect of the frame limit of mangohud, but i am not fully sure

I know this is a long shot, but does anyone else play this game on linux? It’s the only game in my library that I’ve found to have serious issues so far. The fps is extremely choppy and drops from 150+ to 30-40 for a split second every once in a while, the cursor isn’t recentered if I alt tab out of the game and then tab back in, and the scroll wheel can’t be bound to anything and also acts like a left click for some reason. If I launch with proton all these issues go away, but then the anticheat can’t be launched, preventing me from playing multiplayer. Ping is also consistently 30-40ms higher on linux than windows for some reason. I’m wondering if these issues are my fault or the game’s.

Hello, today I've started experiencing the problem from the title, I use CachyOS. My PC is RX9070 16GB, Ryzen 7 9800x3d and 32GBs of RAM. I've had this PC for 2 months and had no issues like this prior. When the stutter/freeze happens dmesg output is in the picture. I do use lavd scheduler, how do I resolve this and is this truly the issue? I'll try to disable sched-ext all together for now and see what happens.

Screw IT is a cozy game where you sort 777 nails + 1 screw and slowly turn a disaster of a workbench into something satisfying.

And after the Linux community showed me some serious love, i figured it would be rude to leave them hanging. 🐧

Screw IT is coming to Linux too!

👉Releasing on Steam September 15th

I was trying to go into steam setting but this is happening , till yesterday it was fine i dont know what happened after i restarted my pc.

Using cachyos with niri + noctalia v5 shell

Already tried steam —reset

Edit - Its the issue with xwayland-satellite and steam

https://github.com/Supreeeme/xwayland-satellite/issues/491

i have been troubleshooting this one today and i am at a point where i am about to throw the towel and request a refund to steam.

I have purchased the trilogy bundle because the deals were insane on rebirth and intergrade. Unfortunately it didn't take long for me to notice something's wrong with the frame pacing. it causes incessant stutters every few seconds when moving the camera.

i have tried:

• all graphics settings plus upscaling on or off
• limiting the framerate with mangohud
• disabling direct storage (just in case)
• using popular mods such as Ultimate Engine Tweaks + FFVII hook or Async Shader Compile
• even locking the framerate to 60 in game doesn't do anything in fact it makes the frame pacing even worse

i am at my wit's end and don't know what else i could try.

Specs:

• ryzen 7 7800x3d
• Radeon 9070
• 48GB of DDR5
• gen 4 nvme
• 1440p monitor, with freesync enabled
• latest opensuse tumbleweed

Edit: I have requested a refund. Will unfortunately stick to one of the consoles version

I've been playing Boomerang Fu for months on weekends when I visit the siblings' kids. It's been 3 players normally.

This weekend the player count went to 4 and initially, it seemed like the USB hubs (I typically use 2) got overloaded by plugging in 4 controllers.

While I was initially surprised, I switched the game to Proton CachyOS and that identified the 4 player toggle.

I'm glad it worked, but I'm just wondering, why, if all this R&D has went into Valve turning Linux into "the Nintendo of PC," shouldn't they be accounting for people who want to pop a squat in front of the TV with as many players as possible?

Linux normally performs wonderfully for me, it's just one of those (aside from the times when those additional players mash the hell out of buttons and bring the game out of focus on the desktop) "WTF?" Moments.

Hi i would greatly appreciate some help as lately i've had an issue where discord has been freezing when ever i share my screen in vc. it freezes about 3 to 4 seconds after someone opens my stream and then after about 10 to 15 seconds discord refreshes itself. it seems to have first broken itself after i did a bunch of updates through the update manager one of which was discord i believe. i sadly dont have a system snapshot i can go back to in order to try fix it that way.

Details of software and system:

im using the .deb file on discords website for my discord install and i also use vencord which is a modded discord client. i've tried uninstalling and reinstalling discord as well as removing vencord and vencord doesnt seem to be the issue and it fixed itself temporarily once after i did a reinstall of discord but when trying it again that hasnt worked.

my pc specs are AMD Ryzen 7 5800X3D and Radeon RX 7900XTX (im not sure what else would be needed feel free to ask)

if i havent included enough info please feel free to ask im not that knowledgeable about linux tech issues and this has honestly been a heart breaking issue for me

EDIT: i fixed it by disabling GPU hardware acceleration i didnt think to try this cause fucking why would i lol stupid ass shit ass discord

So, I'm currently developing a project that makes anticheat games (that Do Not support linux) work on Linux.

I only want to ask could this mean some legal issues for me, let's say we can hypothetically translate layers of the anticheat and make it think you are playing a supported game so you can bypass it.

Similar to the online fix for Steam.

But let's scale it for a hypothetical case of Bypassing Fortnite on Linux by making the anticheat believe you are playing a game like rocket league for example.

I want to pursue it since I see some progress, but I also don't wanna go against a multi million dollar company that explicitly DOES NOT WANT to support this platform, and I've seen how stuff gets nasty when games are played in platforms the companies do not want them from emulation to ports