On Tue, Jan 05, 2016 at 01:49:33PM +0100, Jan Niehusmann wrote: > Hi, > > On Thu, Sep 24, 2015 at 03:53:07PM -0700, Matt Roper wrote: > > Just pull the info out of the plane state structure rather than staging > > it in an additional structure. > > > > v2: Add 'visible' condition to sprites_scaled so that we don't limit the > > WM level when the sprite isn't enabled. (Ville) > > It looks like this patch - specifically the visible condition in > ilk_compute_cur_wm - causes screen flicker when moving the cursor from > one screen to another one in a multi-screen setup. > > My hardware is a Thinkpad x201s > (http://www.thinkwiki.org/wiki/Category:X201s) > 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02), > CPU is an i7-620LM. > > The screen flickering is the one the coursor is leaving. In most cases, > parts of the screen just blank for a very short moment. In some rare > cases, the screen even stays blanked until I move the cursor back to > that screen. No stability issues were observed, this seems to be a > purely cosmetic issue. > > I bisected the issue to 43d59eda1f69631c267e06ab6b94ed3c14f1f6d1. As I > knew the flickering was cursor-related, I tried the following minimal > patch, which actually fixed the symptom, when applied to 4.4-rc8: > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index f091ad1..1ef0c54 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -1791,7 +1791,7 @@ static uint32_t ilk_compute_cur_wm(const struct intel_crtc_state *cstate, > { > int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0; > > - if (!cstate->base.active || !pstate->visible) > + if (!cstate->base.active) > return 0; > > return ilk_wm_method2(ilk_pipe_pixel_rate(cstate), > > > I have no idea at all if this is actually fixing anything or if it's > just hiding the real bug. All I can say is that the flickering doesn't > occur any longer. > > Jan Hi Jan. I think the flicker you're seeing is caused by our current lack of two-stage watermark updates on platforms that use ILK-style watermarks. I have a patch series at http://patchwork.freedesktop.org/bundle/mattrope/atomic_wm_ilk/ that's supposed to address this, but it's still awaiting review at the moment so it isn't yet available upstream. Now that folks are coming back from holiday vacations and such, hopefully we'll get the review finished soon and be able to merge the patches. The change you propose above would cause us to calculate watermarks as if the cursor plane was on full-time (even when it's actually off because the cursor is on the other display), so your watermarks wouldn't need to change when you move your mouse to the other display and you wouldn't see a flicker at that point. If the review process for atomic WM carries on too long, we may want to consider merging a patch like yours as a short term workaround for the issue you're seeing. There would still be plenty of other ways to trigger flickering (changing cursor size, using sprite planes (e.g., via xvideo), etc., but at least a cursor getting enabled/disabled wouldn't cause a flicker. Thanks. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
