[Bug 49667] New: user32-rawinput-mouse: can't use other programs normally while running Elite Dangerous
https://bugs.winehq.org/show_bug.cgi?id=49667 Bug ID: 49667 Summary: user32-rawinput-mouse: can't use other programs normally while running Elite Dangerous Product: Wine-staging Version: 5.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kolAflash(a)kolahilft.de CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- This is mouse bug is analogous to this keyboard bug: https://bugs.winehq.org/show_bug.cgi?id=48419 When user32-rawinput-mouse is being used, it's problematic to click onto other X11 windows while a "Elite Dangerous" is running. In detail: 1. configure "virtual desktop" mode via winecfg 2. Start EliteDangerous in Wine 3. Open a view inside EliteDangerous where every mouseclick (independent of cursor position) will have an effect (e.g. cockpit mode -> mouse-1 fires weapon) 4. switch to another X11 window (e.g. Firefox) 5. click onto something When clicking in Firefox, the click also get send into the game. So e.g. the primary weapon gets fired in the game. Alternatively, the cursor can also positioned over an ingame button (e.g. in the main menu). Then get another window into foreground without moving the mouse (e.g. alt-tab) and then click. This will trigger the ingame button over which the cursor lasted before switching windows. Workaround: ./patches/patchinstall.sh DESTDIR=../wine-5.14 --all -W user32-rawinput-mouse -W user32-rawinput-mouse-experimental -W user32-rawinput-hid (user32-rawinput-mouse-experimental and user32-rawinput-hid depend on user32-rawinput-mouse) For more details, please see: https://bugs.winehq.org/show_bug.cgi?id=48419#c5 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #1 from kolAflash <kolAflash(a)kolahilft.de> --- This is still broken in Wine-Staging-6.9 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |o.dierick(a)piezo-forte.be Ever confirmed|0 |1 --- Comment #2 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Since a game update of World of Warships to 12.2, it doesn't start with upstream Wine, but starts with Staging (bug 46263). While doing test for this unrelated bug, I experienced the present issue. The application receive and reacts to mouse events (movement, clicks) even when the window is not focused. I bisected wine-staging to find the cause of this behaviour and it is in 'user32-rawinput-mouse'. Compiling plain Wine with this patchset triggers the behaviour. The patchset seems to send events from the desktop. I think the patchset needs to enable/disable sending the raw info from the desktop when the application gets/looses focus. I'm also using a fullscreen virutal desktop to play the game in. I didn't test the application without a virtual desktop. The issue can be seen in the gnome shell desktop switching preview. When I hit the shortcut key, the application is reduced in the preview with other windows. If I click anywhere, the application reacts as if I clicked in its window as if it was fullscreen. If in a match, the preview follows the mouse movement even if the window is not focused, and clicking fire the weapon, while the application is in the background or even on another desktop, which result in random shots fired and the inability to do some other task while using the application. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #3 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- ...present in wine-staging 8.0-rc5 to 8.5. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|user32-rawinput-mouse: |user32-rawinput-mouse: |can't use other programs |Application receive mouse |normally while running |events although not |Elite Dangerous |focused; hinders | |multi-tasking. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|user32-rawinput-mouse: |user32-rawinput-mouse: |Application receive mouse |Application receives mouse |events although not |events although not |focused; hinders |focused; hinders |multi-tasking. |multi-tasking. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #4 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, This issue is specifically caused by 0008-winex11.drv-Listen-to-RawMotion-and-RawButton-events. Removing that single patch fixes the issue, but then introduces another issue: When clicking a button, the mouse jumps by a large offset. Removing the patchset user32-rawinput-mouse-experimental fixes that second issue. Instead of removing the patches, I tried to detect when wine doesn't have the focus window and disable sending rawinput events in that case. My limited knowledge and understanding of the rawinput and winex11.drv code was not enough to achieve that. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 TOM <l12436(a)yahoo.com.tw> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l12436(a)yahoo.com.tw --- Comment #5 from TOM <l12436(a)yahoo.com.tw> --- after some debug, I found something funny. is_virtual_desktop() is always return 0 event if I run the game with explorer /desktop=test,1366x768 It seems that it could not get the flag DF_WINE_CREATE_DESKTOP -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #6 from TOM <l12436(a)yahoo.com.tw> --- (In reply to TOM from comment #5)
after some debug, I found something funny. is_virtual_desktop() is always return 0 event if I run the game with explorer /desktop=test,1366x768 It seems that it could not get the flag DF_WINE_CREATE_DESKTOP
maybe I was wrong, I call in incorrect location. sorry for bothering. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #7 from TOM <l12436(a)yahoo.com.tw> --- I also trying to solve this, but that are no function for me to distinguish whether the screen is focus or not, and is virtual desktop is opened or not. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #8 from kolAflash <kolAflash(a)kolahilft.de> --- (In reply to Olivier F. R. Dierick from comment #4)
Hello,
This issue is specifically caused by 0008-winex11.drv-Listen-to-RawMotion-and-RawButton-events. Removing that single patch fixes the issue, but then introduces another issue: When clicking a button, the mouse jumps by a large offset. Removing the patchset user32-rawinput-mouse-experimental fixes that second issue.
Between wine-staging-9.2 and wine-staging-9.3 the user32-rawinput-mouse-experimental patchset was disabled by default (--all). https://gitlab.winehq.org/wine/wine-staging/-/commit/ff18b9b26e636ff5a626257... And between wine-staging-9.3 and wine-staging-9.4.1 these where removed completely: user32-rawinput-mouse-experimental/ user32-rawinput-mouse/0008-winex11.drv-Listen-to-RawMotion-and-RawButton-events https://gitlab.winehq.org/wine/wine-staging/-/commit/aa8b27c396f926212689d18... https://gitlab.winehq.org/wine/wine-staging/-/commit/aa8b27c396f926212689d18... So the ticket can probably be marked as resolved. I'll try to take time to test this in the next days. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=49667 --- Comment #9 from kolAflash <kolAflash@kolahilft.de> --- (In reply to kolAflash from comment #8)
[...] So the ticket can probably be marked as resolved. I'll try to take time to test this in the next days.
Unfortunately not. The problem is still existing in Wine-Staging-11.0-rc5. I overlooked that the relevant patch just got moved here and user32-rawinput-mouse (not the old "-experimental") is still enabled by default. https://gitlab.winehq.org/wine/wine-staging/-/blob/aa8b27c396f926212689d18da... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla