Bug 104461 - [regression][bisected] Moving mouse in some games under wine causes mouse flicker and low performance
Summary: [regression][bisected] Moving mouse in some games under wine causes mouse fli...
Status: CLOSED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Ville Syrjala
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2018-01-02 17:21 UTC by Igor Kotrasiński
Modified: 2018-03-02 15:13 UTC (History)
1 user (show)

See Also:
i915 platform: BDW
i915 features: display/watermark

Attachments
lshw output (21.00 KB, text/plain)
2018-01-02 17:21 UTC, Igor Kotrasiński 		no flags Details
kernel config used for bisecting (115.36 KB, text/plain)
2018-01-02 17:22 UTC, Igor Kotrasiński 		no flags Details
dmesg with drm.debug=0x1e and drm-tip kernel (15.71 KB, application/x-xz)
2018-01-03 21:57 UTC, Igor Kotrasiński 		no flags Details
View All

Description Igor Kotrasiński 2018-01-02 17:21:01 UTC 
Created attachment 136500 [details]
lshw output

After a kernel upgrade to 4.12, moving the mouse in some games under wine (namely Mount & Blade Warband and Supreme Commander) causes the mouse cursor to flicker and video performance to drop considerably (the screen remains frozen while the mouse is moving), as well as cause some CPU load. Bisecting led to a commit a5509abda48e:


commit a5509abda48ecfc133fac6268e83fc1a93dba039 (refs/bisect/bad)
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Feb 17 17:01:59 2017 +0200

    drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW


Steps to reproduce:
    1. Install wine (tested with wine staging 2.19)
    2. Install one of mentioned games (I only tested retail versions, but Mount & Blade Warband demo might exhibit similar issues)
    3. Move the mouse around after the game loads

Expected results:
    Mouse moves without flickers or performance issues.

Actual results:
    Mouse flickers, CPU load is increased. The screen is frozen until the mouse stops moving.

Additional information:
    My laptop has an optimus setup with an integrated Intel and discrete Nvidia card. During tests I did not load the nvidia or the bbswitch driver and tested with the integrated card only.
Comment 1 Igor Kotrasiński 2018-01-02 17:22:18 UTC 
Created attachment 136501 [details]
kernel config used for bisecting
Comment 2 Elizabeth 2018-01-03 21:20:46 UTC 
Hello Igor, could you try this branch https://cgit.freedesktop.org/drm-tip and attach dmesg with debug info, drm.debug=0x1e on grub? Thank you.

Ville, could you give a quick look at this? Thank you.
Comment 3 Igor Kotrasiński 2018-01-03 21:56:50 UTC 
I tried the drm-tip kernel, the issue is still there although less pronounced (still heavy cursor flicker, but freezing turned into stuttering).
Comment 4 Igor Kotrasiński 2018-01-03 21:57:35 UTC 
Created attachment 136534 [details]
dmesg with drm.debug=0x1e and drm-tip kernel
Comment 5 Ville Syrjala 2018-01-31 19:11:52 UTC 
Looks like a bug/feature of the game (or maybe wine) that it actually keeps turning the cursor off and on all the time. That causes us to drop off the unthrottled cursor fastpath. No idea why the game/wine does that. Can't imagine anyone wants to look at a randomly flickering cursor for length of time.

The following hack in wine will eliminate the problem, but it would also leave a stale cursor on screen if the game actually wants to turn the cursor off:

diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c
index 186899fb16..9aaa9a18f9 100644
--- a/dlls/winex11.drv/mouse.c
+++ b/dlls/winex11.drv/mouse.c
@@ -223,6 +223,8 @@ void set_window_cursor( Window window, HCURSOR handle )
         XUnlockDisplay( gdi_display );
     }
 
+    if (!handle)
+      return;
     XDefineCursor( gdi_display, window, cursor );
     /* make the change take effect immediately */
     XFlush( gdi_display );

While making all cursor updates unthrottled would be possible from the hardware point of view, it'd be a lot of work to shoehorn that into the current driver architecture. So I'm going declare this as "not our bug" and move on ;)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.