Mouse events not forwarded to some applications (Wine, Firefox, etc.)

[uunniiblog]

Describe the bug
Instead of using proton to run a game, if you run it from wine mouse controls over the game do not work properly.

To Reproduce
Steps to reproduce the behavior:

1. Use wine to open a game
2. Mouseover buttons in the game
3. Can't click the buttons or even click to fast forward intro screens, etc

Expected behavior
Should work like with proton.

Screenshots
Attach a small video. First I run the game with a proton-ge runner, mouseover the main menu buttons and check that it works ok. Second I run the same game with a wine prefix (wine 11-2) and try to mouseover the same menu but doesn't work. Also can't click anything in the game

output_upscale.mp4

Environment (please complete the following information):

• Upscaler version: 0.2.6
• OS: EndeavourOS
• Windowing System: Wayland
• Desktop Environment / Window Manager: KDE 6.6.3
• GPU: AMD 9070 XT
• GPU Driver version: Mesa 26.0.2-1
• Additional system info (optional): Using wine 11-2 wow64, also tested with normal wine 10.14 same outcome. Proton-ge 10.24 works fine

Debugging logs:

Attach log running the game through wine and trying to mouseover and click around for a few seconds.

log.txt

Additional context
Keyboard controls seem to work fine, at least altf4 opens up the close game prompt.
I also have tried enabling DXVK in the wine prefix just in case it's something vulkan/wined3d related, but doesn't seem to change anything.

[baronsmv]

Hi, @uunniiblog. Thank you for the detailed report, video and logs.

The issue you're experiencing is quite interesting. The log confirms the overlay successfully listened and forwarded mouse move and clicks to the Wine window:

2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Mapped: (598,1468) -> content (554,1468) -> target (146,400)
2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Forwarding MouseMove to (146,400) with state 0
2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Sent event: MotionNotify(window = 121634823, root = 858, same_screen = 1, root_x = 598, root_y = 1468, time = 0, detail = 0, state = 0, event_x = 146, event_y = 400, child = 0, type = 6, sequence_number = 0)
2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Mapped: (598,1468) -> content (554,1468) -> target (146,400)
2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Forwarding ButtonPress: button 1 at (146,400)
2026-03-21 01:22:28,550 - upscaler.overlay - DEBUG - Sent event: ButtonPress(window = 121634823, root = 858, same_screen = 1, root_x = 598, root_y = 1468, time = 0, detail = 1, state = 0, event_x = 146, event_y = 400, child = 0, type = 4, sequence_number = 0)

I suspect it may be a compatibility problem between Wine and X11 events. Though, I can't seem to find much information about this, just posts like this one: When wine is going to work properly with Wayland without X11?

A couple of things came to mind though:

• Do this also happen under pure X11?
• What happens if you run wine with this variable? WINEDLLOVERRIDES="winemenubuilder.exe=d x11

Other than that, I have no idea how we can solve this problem.

[uunniiblog]

Hi, I think you meant WINEDLLOVERRIDES="winemenubuilder.exe=d" to disable winemenubuilder? In any case I have tried both ways but no luck. I do not have X11 installed right now but I will see if I can install it later or use a VM, or maybe someone else can report it the same issue happens with X11 and wine. Thanks!

[CelicaS]

@baronsmv When running under Wine, the mouse cursor experiences an offset; the magnitude of this offset is dependent on the program's initial position.

2026-03-21.17-51-53.mp4

log.txt

[baronsmv]

Thank you both @uunniiblog and @CelicaS for your feedback.

Yes, I've tested it in my own setup with Wine 11.0, and I can confirm this as well. It seems to behave like this:

• Under X11, any mouse event passes through the overlay. It's not an offset, it's ignoring the overlay entirely and clicking through it, to the original coordinates of the target window. That's particularly weird.
• Under Wayland, all mouse events are seemingly blocked.

All logs confirm that the upscaler in every case:

1. Gets the correct target window resolution.
2. Maps to the corresponding coordinates according to that resolution.
3. Forward the mouse event to the target window.

So, the mouse mapping calculation and forwarding seem to be working as intended.

I noticed a related error: Scaling rect has zero size, cannot map, but that's at the very beginning, before the first frame completed; after that, the rect is non-zero as confirmed by the log.

I don't think it's a window handle issue either. I've already tested comparing IDs with xwininfo and xdotool and tried manually targeting the window's parents, without any change. I've also tried mapping with XTest, but that doesn't help either.

This problem seems to be complex and likely involves low‑level X11/Wine specifics.

We'll keep this issue open and mark it as help_wanted in case there are any contributors who have experience with input under Wine.

[baronsmv]

Update from #8 (mouse wheel issue)

The wheel problem appears to share the same root cause with this issue: the target window may not have the necessary event mask for synthetic XSendEvent input.

Interestingly, using xdotool directly with windowactivate --sync works for sending events to these windows. However, integrating that XTEST logic inside the upscaler hasn’t succeeded.

We're keeping this issue open as a tracking point for the broader input problem affecting Wine and some applications. Any insights on how to enable synthetic events for these apps —or on a reliable forwarding method— are welcome.

[baronsmv]

Update

I’ve been investigating this problem further and noticed an interesting pattern in GE-Proton: events are only forwarded correctly when using GE‑Proton 10.x. When using older Proton versions (even the immediately previous GE-Proton9-27), the issue persists.

If we can pinpoint the change (possibly a specific patch introduced in GE-Proton10-1), we might be able to replicate it in the Wine runtime. I'll investigate its changelog.

This is definitely a tricky one!

[uunniiblog]

From what I can test it doesn't come from proton-ge, but from proton directly. if you check between normal proton 9 and proton 10 directly it's also the same behaviour.

https://github.com/ValveSoftware/Proton/wiki/Changelog#100-1
Thats the changelog but I don't see anything clear (I did test Added support for game mods that load via custom dinput8.dll. since it was a dll override but doesn't solve it)

I don't have the knowledge of how wine or x11 inputs work sadly, but comparing the class between proton 9 and 10 maybe you can see something?

https://github.com/ValveSoftware/wine/blob/proton_9.0/dlls/winex11.drv/mouse.c

This code

case XI_Motion:
case XI_ButtonPress:
case XI_ButtonRelease:
    return X11DRV_XIDeviceEvent( event->data );

It is gone in proton 10: https://github.com/ValveSoftware/wine/blob/proton_10.0/dlls/winex11.drv/mouse.c

Although checking current wine code that code is also gone so maybe it doesn't have anything to do.

I also see some changes in X11DRV_XInput2_Enable for the steam overlay, maybe could be related to the behaviour we see too

[baronsmv]

Thank you for sharing your findings, @uunniiblog. I looked into the changes between Proton 9, Proton 10 and Wine 11, and here’s what I found:

• In Proton 9 event.c there is a line that skipped synthetic events on foreign windows (it's even commented):

  /* ignore synthetic events on foreign windows */
  if (event->send_event && !data->whole_window) goto done;

  This is not present in Wine 11.0 though, so it’s not the cause.

• In mouse.c of Proton 10.0, there are many changes related to raw input:

  • NtUserSendHardwareInput is called with the SEND_HWMSG_NO_RAW flag instead of 0, which could affect how synthetic events are processed (differently to hardware ones?). I'm not really sure.
  • It introduces a new X11DRV_RawButtonEvent function.
  • The function map_raw_event_coords now takes a BOOL send_raw argument.

I tried applying some of the mouse.c changes from Proton 10 to Wine 11 and compiling it with them, but it didn't solve the problem.

Proton 10.0 also has some workarounds for Mutter, gamescope, and the Steam overlay, specifically around mapping and virtual rects like the ones the upscaler use, and a different focus handling, but I don't think that's it neither.

Since there are multiple changes and workarounds, I'm suspecting this is not an issue that can be solved with a single change or workaround in the source code of Wine.

I’ll keep digging and update when I have more concrete findings.