Created attachment 140179 [details] debug dmesg with drm-tip kernel Hello! 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). Hardware: 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. Software: 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).
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 log_buf_len=4M?
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 [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/
> 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ä <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>
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.