Bug 106935 - [CHV] Mouse cursor flicker on external display, rendering artifacts under cursor
Summary: [CHV] Mouse cursor flicker on external display, rendering artifacts under cursor
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: ReadyForDev
Depends on:
Reported: 2018-06-16 14:33 UTC by russianneuromancer
Modified: 2019-03-02 05:38 UTC (History)
3 users (show)

See Also:
i915 platform: BSW/CHT
i915 features: display/Other

debug dmesg with drm-tip kernel (1007.75 KB, text/plain)
2018-06-16 14:33 UTC, russianneuromancer
no flags Details
debug dmesg with drm-tip 2018-06-19 kernel (1.84 MB, text/plain)
2018-06-19 14:46 UTC, russianneuromancer
no flags Details

Description russianneuromancer 2018-06-16 14:33:37 UTC
Created attachment 140179 [details]
debug dmesg with drm-tip kernel


I find that mouse cursor is always flicker on external displays attachable to CherryTrail-based Dell 5855 tablet. 

modesettings DDX (Ubuntu Defaut) - cursor flicker frequently on all movement, artifacts under cursor, sometimes long tail (for example above terminal window with changing content, or above Nautilus that render loading animation) link to video is below
Intel DDX, DRI3 - same as with modesetting DDX.
Intel DDX, DRI2, HWCursor - cursor flicker when content below cursor is changes, but don't left tail
Intel DDX, DRI2, SWCursor - almost same as HWCursor, but seems like cursor flickering start not after boot or after web-browser, Nautilus or terminal launch, but few minutes later.

Video for DRI3 variant of this issue:
https://mega.nz/#!JNpBharA!giDibmmE9he9NkqR13pGncLrxCCZhoIY27K3cU7vRsY (please pay attention to the ending).

Attached dmesg debug from boot with Intel DDX, DRI3 (moving gnome-recorder above htop, then just moving cursor above htop, cursror left very long tail).

Dell 5855 tablet with Intel Atom x5-Z8500
Tested docking soltuions:
1. Dell Dock WD15
2. Dell S2718D display attached to tablet directly via USB-C
3. Belkin USB-C 3.1 Express Dock HD
No difference was found, cursor flicker with all three. However, there is no such issue if I attache Skylake and KabyLake-based laptops to listed docks.

Ubuntu Gnome 17.04-18.04 x86_64
Linux 4.11-4.17.1, drm-tip/2018-06-16 (02d8db1a894b0e646b2debd64ce24b8e99fd2ffd)
Mesa 1.17.0-18.0.0rc5
libdrm: 2.4.80-2.4.91
xserver-xorg-video-intel: 2.99.917+git20170309 - 2.99.917+git20171229
xserver-xorg-core: 1.19.3-1.19.6

As far I know this is not regressions, as I seen this issue at least 1.5-2 years ago, display support starting to work on this tablet (before there was just black screen).
Comment 1 Radosław Szwichtenberg 2018-06-19 08:00:40 UTC
Please send full dmesg (from boot to error) with drm.debug=0x1e

Try using https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e
Comment 2 russianneuromancer 2018-06-19 14:46:25 UTC
Created attachment 140230 [details]
debug dmesg with drm-tip 2018-06-19 kernel

> Try using https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e log_buf_len=4M?

Tried drm-tip/2018-06-19 (1ae7a58d270bad4b7051d3808b00cae86f624696) and issue is still reproducible, dmesg attached.
Comment 3 Lakshmi 2018-09-10 12:41:49 UTC
Radoslaw, any updates on this issue?
Comment 4 Leszek Lesner 2018-10-14 18:10:32 UTC
I can confirm this issue with an Intel HD400 running in a mini pc with attached HDMI monitor running Plasma 5.12.
Comment 5 Lakshmi 2018-10-15 06:01:22 UTC
Leszek, Can you elaborate the use case and issue itself?  
How often you see the issue?
Have you verified this issue with latest drm-tip? (https://cgit.freedesktop.org/drm-tip).
If problem exists with latest drm-tip, set kernel parameters drm.debug=0x1e log_buf_len=4M and reboot.
Try to reproduce the issue and attach the dmesg log. This way we see more information about the bug.
Comment 6 russianneuromancer 2018-10-15 12:49:23 UTC
Lakshmi, for me issue is still reproducible with latest drm-tip. You can find dmesg in Comment 2 - is anyone can look into this dmesg?
Comment 7 Jani Saarinen 2018-10-15 13:00:18 UTC
Hi, That dmesg is 3 months old. Question was about latest (today).
Comment 8 Ville Syrjala 2018-10-19 17:01:30 UTC
The problem happens because of that CHV bug where we can't show the cursor when it's straddling the left screen edge. At that point we switch to using the software cursor.

The flickering is pretty much unavoidable for the front buffer rendering cases. But with page flipping/tearfree it should be possible to implement a flicker free software cursor. Presumably no one has bothered since most hardware has a working hardware cursor.

The trails being left behind by the software cursor I think is some kind of damage tracking bug. It only seems to happen with tearfree here. Maybe it could happen with a page flipping compositor as well, not sure.

I sent a patch [1] that causes us to at least switch back to using the hardware cursor when then cursor is next updated. That tends to happen quite often so should mitigate some of the problem. You may still see some ugly cursor trails though. Fixing those could be a lot trickier.

[1] https://patchwork.freedesktop.org/series/51265/
Comment 9 russianneuromancer 2018-10-25 14:49:53 UTC
> That tends to happen quite often so should mitigate some of the problem. You may still see some ugly cursor trails though. Fixing those could be a lot trickier.

Now issue happen much less often. Thank you! What is current Status of this bugreport then? No new info needed as I understand?

Also, should I fill separate bugreport to modesetting DDX?
Comment 10 russianneuromancer 2019-01-14 07:40:11 UTC
Is there anything that keeping it from merging?
Comment 11 Chris Wilson 2019-03-01 18:27:47 UTC
commit 6afed33b2d673d88674f0c76efe500ae414e8e1b (upstream/master)
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Mar 1 11:26:07 2019 +0000

    sna: Switch back to hwcursor on the next cursor update
    Once we've switched to using the swcursor (possibly
    due to the cursor ioctl failing) we currently keep
    using the swcursor until the modeset.
    That's not particularly great as the swcursor has several
    issues. Apart from the (presumably expected) flicker,
    the cursor also tends to leave horrible trails behind
    around dri2/3 windows (happens with tearfree at least).
    To avoid some of that let's try to switch back to the hwcursor
    a bit sooner. We can do that neatly via the convenient swcursor
    block handler.
    v2 [ickle]: Apply the restoration after the screen update is complete.
    v3 [vsyrjala]: Push it back to restore_swcursor and remove the
    fullscreen redraw -- prevents terrible flickering in v2!
    References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 12 russianneuromancer 2019-03-02 05:38:48 UTC
Thank you! :)

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.