Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#61731 - [chromium] VAAPI with r600 - distorted colors

Attached to Project: Arch Linux
Opened by Mantas Mikulėnas (grawity) - Tuesday, 12 February 2019, 17:56 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 15 February 2019, 14:28 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After the VAAPI-enabling patch was applied, Chromium shows distorted colors for H.264 videos:

https://i.imgur.com/S2ZadGV.png

This old laptop has an ATI Radeon HD 6370M, which uses 'r600' from libva-mesa-driver.

This issue does not occur in `mpv --vo=vaapi --hwdec=vaapi`.

As a workaround, I remove /usr/lib/dri/r600_drv_video.so to force software decoding.

local/chromium 72.0.3626.96-3
local/mesa 18.3.3-2
local/libva-mesa-driver 18.3.3-2
local/libva 2.4.0-1
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Friday, 15 February 2019, 14:28 GMT
Reason for closing:  Not a bug
Additional comments about closing:  allow_rgb10_configs was enabled for all applications in ~/.drirc, overriding the configuration shipped with Chromium.
Comment by Mantas Mikulėnas (grawity) - Wednesday, 13 February 2019, 06:30 GMT
I will check whether I have a stale ~/.drirc when I get back home.
Comment by Christopher Snowhill (kode54) - Thursday, 14 February 2019, 01:36 GMT
This is because Chromium's VAAPI patch, much like Totem when using VAAPI, is not aware of what to do when the driver presents 10 bit per channel color surfaces. Radeon has been doing this for maybe a year or two now.

You can look into setting allow_rgb10_configs to false either for Chromium, or globally, in either your personal .drirc, or the system drirc.
Comment by Evangelos Foutras (foutrelis) - Thursday, 14 February 2019, 02:59 GMT
@kode54: /usr/share/drirc.d/10-chromium.conf already does that and it fixes this exact issue on my desktop which has an r600g card (Radeon HD 6870) like OP.

@grawity: Do check if you have a drirc override somewhere.
Comment by Mantas Mikulėnas (grawity) - Thursday, 14 February 2019, 04:49 GMT
Yes, looks like I had a .drirc from earlier, in order to apply custom fixes to another program. I guess it needs to explicitly include /usr/share/drirc?
Comment by Christopher Snowhill (kode54) - Thursday, 14 February 2019, 06:44 GMT
Yes, I also had no /etc/drirc, so at some point I created one that simply overrides that one thing. I wasn’t even aware of /usr/share/drirc.d, much less how to include it by default.
Comment by Evangelos Foutras (foutrelis) - Thursday, 14 February 2019, 14:03 GMT
Mesa seems to load configuration files in this order:

- /usr/share/drirc.d/*
- /etc/drirc
- $HOME/.drirc

The existence of /etc/drirc and $HOME/.drirc does not prevent /usr/share/drirc.d/10-chromium.conf from being read. Unless I set "allow_rgb10_configs" to "true" in e.g. $HOME/.drirc, I get the correct behavior in Chromium.

If your custom drirc does not set the above variable at all but you still get pink videos in Chromium, post your drirc so I can try to reproduce.
Comment by Mantas Mikulėnas (grawity) - Friday, 15 February 2019, 13:36 GMT
Ok, it seems that my ~/.drirc was based on a full copy of an older /etc/drirc, which contained an <application name="Default"><option name="allow_rgb10_configs" value="true"/></> which apparently overrides the new option in /usr/share/drirc.

(Previously "full copy and edit" used to be the only way to add a custom application profile without losing the system default ones. And it seems that's still the case today...)

Loading...