| Summary: | [CHV] Mouse cursor flicker on external display, rendering artifacts under cursor | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | russianneuromancer | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | high | CC: | intel-gfx-bugs, lakshminarayana.vudum, radoslaw.szwichtenberg | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | ReadyForDev | ||||||||
| i915 platform: | BSW/CHT | i915 features: | display/Other | ||||||
| Attachments: |
|
||||||||
|
Description
russianneuromancer
2018-06-16 14:33:37 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 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.