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)
xserver-xorg-video-intel: 2.99.917+git20170309 - 2.99.917+git20171229
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).
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
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.
Radoslaw, any updates on this issue?
I can confirm this issue with an Intel HD400 running in a mini pc with attached HDMI monitor running Plasma 5.12.
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.
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?
Hi, That dmesg is 3 months old. Question was about latest (today).
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  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.
> 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?
Is there anything that keeping it from merging?
commit 6afed33b2d673d88674f0c76efe500ae414e8e1b (upstream/master)
Author: Ville Syrjälä <email@example.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
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!
Signed-off-by: Ville Syrjälä <firstname.lastname@example.org>
Signed-off-by: Chris Wilson <email@example.com>
Thank you! :)