FS#46976 - [xf86-video-intel] Video distortions/noise when viewing in fullscreen mode

Attached to Project: Arch Linux
Opened by Felix (daphee) - Thursday, 05 November 2015, 14:03 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 18 February 2017, 21:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
Video distortions/noise when viewing in fullscreen mode.

Additional info:
Tested with multiple players Flash/bomi/VLC.
Seems not to happen with the HTML5 player.
(Just watched a few minutes on YouTube though - happened instantly when I turned off HTML5)

Happens regardless of wether hardware acceleration is turned off or on in VLC/bomi

Not having these issues with version 1:2.99.917+381+g5772556-1.
Were introduced in version 1:2.99.917+472+gf0fd4d5-1 and persist in -1:2.99.917+478+gdf72bc5-2.

Made a video with my phone, couldn't catch it with a screencast.
Download it here [1] (15 MB)

Steps to reproduce:
Watch a video in fullscreen with Flash/bomi/VLC/(...) - not HTML5.
E.g. this [2] did it in the first few seconds for me.

[1]: https://dl.dropboxusercontent.com/u/8474830/VID_20151105_140324.mp4
[2]: https://www.youtube.com/watch?v=J4LI_EqnJq8&user=collegehumor
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 18 February 2017, 21:43 GMT
Reason for closing:  No response
Additional comments about closing:  None of the affected users reported this upstream.
Comment by Doug Newgard (Scimmia) - Thursday, 05 November 2015, 16:16 GMT
Does it do this with both UXA and SNA?
Comment by Felix (daphee) - Thursday, 05 November 2015, 16:39 GMT
I watched a few short videos. Seems like it does it only with SNA not with UXA.
Comment by Andreas Radke (AndyRTR) - Sunday, 20 December 2015, 08:05 GMT
Please test latest driver and mesa version in testing repo.
Comment by Felix (daphee) - Sunday, 20 December 2015, 13:43 GMT
I did a -Syu without the testing repo and then only installed testing/xf86-video-intel testing/mesa.

I am using SNA because there is screen tearing with UXA.

The version of the driver installed now is 1:2.99.917+519+g8229390-1 and the version of mesa installed is 11.1.0-1

The issue persists unfortunately.
Do I have to enable the testing repo system-wide to properly test wether the issue is still there?
I would prefer to not to.
Comment by U (Gusar) - Sunday, 20 December 2015, 21:13 GMT
> Do I have to enable the testing repo system-wide to properly test wether the issue is still there?

The only package that matters is xf86-video-intel, other packages, regardless of the repo they're in, don't change anything (I'm using mesa-git). A few weeks ago I said in a forum thread that I will attempt a git bisect of the driver to find out where exactly between 381+g5772556 and 472+gf0fd4d5 the issue started, but well, real life(tm) got in the way. Someone should do a bisect though and then make a report upstream that mentions the offending commit.
Comment by Felix (daphee) - Wednesday, 27 January 2016, 11:32 GMT
I enabled DRI 3 which solved the issue.
Still using SNA and the newest version of the package from extra.
Comment by Stefan Flanderijn (hosnor101) - Tuesday, 22 March 2016, 12:54 GMT
I can confirm that enabling DRI3 resolves the weird glitches. It only happened after the most recent update (march 19th) and it appeared when I watched a video on full screen on a second monitor.
Comment by Andreas Radke (AndyRTR) - Friday, 01 April 2016, 16:48 GMT
@daphee: is the initial bug fixed for you with the latest updates?
Comment by Felix (daphee) - Monday, 04 April 2016, 19:58 GMT
Am back to DRI2 as there were other glitches/bugs with DRI3.

After watching a few minutes of video in different players it seems that indeed the bug is fixed.
Comment by Felix (daphee) - Monday, 04 April 2016, 20:59 GMT
Okay, so it seems the issue isn't gone. If I have more time I need to try to test as much programs, rendering... backends/whatever as possible.
All video players I tried still seem fine but when I turned hardware acceleration in Chromium back on and played a game running in the <canvas> on full screen
the same artifacts as in my original report appeared.
Comment by Andreas Radke (AndyRTR) - Thursday, 28 July 2016, 08:35 GMT
Intel driver package has seen many updates since then. Any news on this?

You may also want to test the new pkg in testing repo. DRI3 is now the default, you can fallback to DRI2 with a xorf.conf snippet
Comment by Felix (daphee) - Thursday, 28 July 2016, 22:42 GMT
I had the package uninstalled, falling back to the modesetting driver. Just reinstalled the package from testing. Will report back in a few days.
Comment by U (Gusar) - Friday, 29 July 2016, 20:29 GMT
Still happening. DRI 2 or 3 doesn't make a difference. But I actually did a bisect sometime last month, I was just too lazy to report it anywhere. It's commit 74c1e45, reverting it makes fullscreen video work fine. Now someone less lazy than me :) should report this upstream.
Comment by Andreas Radke (AndyRTR) - Saturday, 27 August 2016, 12:06 GMT
Someone affected please report this upstream. I'll soon close this one.
Comment by Felix (daphee) - Sunday, 04 September 2016, 10:55 GMT
Sorry. After I responded last time I reinstalled the driver but had a different issue which made it unusable for me so I went back to the modesetting driver.
(some windows didn't redraw properly. A text editor which just shows changes every few seconds is extremely annoying)
This is my main machine and currently I don't have time for more elaborate testing.
Comment by U (Gusar) - Monday, 05 September 2016, 17:55 GMT
Windows not updating isn't the fault of xf86-video-intel, the problem is buggy framebuffer compression. Disable that by loading the i915 kernel module with enable_fbc=0
Comment by Felix (daphee) - Sunday, 11 September 2016, 07:36 GMT
Thanks, but unfortunately enable_fbc=0 didn't help

Loading...