FS#49371 - [linux] 4.6.x i915 tearfree results in flicker and xf86-video-intel 1:2.99.917+651+g34f

Attached to Project: Arch Linux
Opened by Stefan de Konink (skinkie) - Tuesday, 17 May 2016, 07:07 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 02 October 2017, 23:14 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


After upgrading to:
testing/xf86-video-intel 1:2.99.917+651+g34f63f2-1
testing/linux 4.6-1

In combination with my existing Xorg option:

cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "TearFree" "true"

The screen starts to flicker after Xorg is started when moving the mouse. As Window Manager I am using XFCE. Additionally dmesg shows:

[ 853.479397] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
[ 853.479420] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
[ 884.983087] [drm:intel_psr_work [i915]] *ERROR* Timed out waiting for PSR Idle for re-enable

where the Time out line repeats.

Disabling TearFree solves removes the Flicker.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 02 October 2017, 23:14 GMT
Reason for closing:  Upstream
Additional comments about closing:  upstream has now disabled PSR by default because they don't want people to use it.
Comment by Ishbir Singh (Ishbir) - Thursday, 19 May 2016, 18:24 GMT
Do you have an Intel Skylake based GPU? If so, the issue exists on Linux 4.5 (with the default options though) as well.
Comment by Stefan de Konink (skinkie) - Thursday, 19 May 2016, 23:12 GMT
To be honest I have no clue if it is a Skylake or not. I am using it in a Toshiba Chromebook 2.

And without wanting to start any flamewars. To solve my issues with suspend, video and audio I gave GalliumOS a go. They currently are running on Linux 4.1 and everything just works. Stil wondering if an AUR package with their kernel should be on my todo list.
Comment by Alexander Pavel (SuperIce97) - Friday, 20 May 2016, 20:48 GMT
PSR is a power saving feature called "Panel Self Refresh". It was considered a bit buggy in previous kernel releases but was deemed stable enough to be enabled by default on Kernel 4.6 by the main Linux developers. I'm not sure what this should be filed under, kernel or xf86-video-intel bug. Tear-Free is not a default option, so this likely won't affect many people. Do you really need the tear-free option? I'm running an Broadwell based PC and never had issues with tearing, but then again I use Gnome, which is supposed to be tear free anyway (and now I've moved to Wayland, so same thing there).
I don't thing the kernel config should disable this feature as it can lead to massive power savings from the GPU of 29%-85% (Source: https://www.phoronix.com/scan.php?page=news_item&px=Intel-PSR-Default) and doesn't cause issues in the default configuration, but this bug should definitely be sent to Intel and be mentioned on the Arch Wiki.

If you continue having issues, I'm not 100% sure what could be done as I don't use XFCE, and Wayland isn't supported and can't be used as a fix. However, I found a couple of options online. On the Ubuntu forums, I saw this fix: Enable "Synchronize drawing to the vertical blank" in Settings Manager -> Window Manager Tweaks -> Compositor tab. You need the compton compositor for this. Another fix was using the compton compositor and adding "--vsync opengl" to the compton launch options. You could also use linux-lts, which uses kernel 4.4 and does not have PSR enabled.
Comment by Stefan de Konink (skinkie) - Friday, 20 May 2016, 21:26 GMT
Scrolling in Chrome looks very ugly without TearFree enabled. So yes, I would like that feature. In the GalliumOS wiki something is written as: "Compton as the compositor for tear free compositing
Performs better than enabling Tear Free in the Intel graphics driver with a compositor" I don't really see how that is related but Chromium and scrolling is very fluent. I think the vertical blanking is indeed what prevents Chrome from drawing to fast.
Comment by Alexander Pavel (SuperIce97) - Saturday, 21 May 2016, 03:31 GMT
Is the rest of your system tearing or just chromium? If it's just chromium, go to "chrome://flags" and enable "Override software rendering list". My chromium occasionally has tearing when the GPU process crashes, so maybe your chromium isn't using the GPU (and thus tearing like my system does when the chromium GPU process crashes). It's mostly stable on my 2 systems, one with Broadwell graphics and the other nVidia (the nVidia one is the one that has been having GPU process crashes recently; the Broadwell seems rock solid).
Comment by Tobias Powalowski (tpowa) - Thursday, 02 June 2016, 14:24 GMT
Please try 4.6.1-2 it adds a PSR patch.
Comment by vyacheslav (galdralag) - Friday, 10 June 2016, 08:10 GMT
I have same problem.
4.6.2 still has flickering.
Adding i915.enable_psr=0 to kernel command line solves problem.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 10 June 2016, 09:32 GMT
4.6.2 had this:
drm/i915/psr: Try to program link training times correctly

commit 03b7b5f983091bca17e9c163832fcde56971d7d1 upstream.

The default of 0 is 500us of link training, but that's not enough for
some platforms. Decoding this correctly means we're using 2.5ms of
link training on these platforms, which fixes flickering issues
associated with enabling PSR.

But if it didn’t helped for you, then you should report upstream.
Comment by vyacheslav (galdralag) - Saturday, 04 February 2017, 08:58 GMT
With kernel 4.9.6 at last flickering fixed for me
Comment by Giuseppe (G-G) - Sunday, 12 February 2017, 17:50 GMT
That's because after 4.9.3 they disabled psr by default:
which unfortunately means we don't get that feature.