GNOME Bugzilla – Bug 786677
Red and blue channels are inverted for some windows
Last modified: 2017-08-28 23:41:47 UTC
Red and blue channels are inverted when using some applications like Epiphany, Totem or Cheese. It only happens using Wayland, not with Xorg. When using Totem or Cheese, only the video gets the wrong colors. With Epiphany, the whole window (including the gtk+ decorations), only after visiting some (almost all) websites. I met this problem yesterday. I'm usually testing versions as soon as they're available, so the bug probably appeared in 3.25.90 or 3.25.91. I've tried to reinstall some 3.25.90 packages (mutter, gnome-shell and more), the bug didn't disappear. I'm not even sure that the bug is in mutter. It really looks related to bug 779234.
It definitely is in Mutter. It only happens when you use new Mesa which uses zwp_linux_dmabuf_v1. Patch incoming.
Created attachment 358305 [details] [review] wayland-dma-buf: Fix 32bpp channel order inversion Apparently my understanding of Cogl pixel formats, or at least their use, was somewhat shaky. Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping when creating dmabufs from clients, fixing inverted channel ordering seen from GL clients, e.g. gold highlights in gtk4-demo when using the GSK GL backend when they should be blue.
It's perfect. Thanks a lot for the really quick fix, you made my day!
Created attachment 358310 [details] [review] wayland-dma-buf: Fix 32bpp channel order inversion Apparently my understanding of Cogl pixel formats, or at least their use, was somewhat shaky. Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping when creating dmabufs from clients, fixing inverted channel ordering seen from GL clients, e.g. gold highlights in gtk4-demo when using the GSK GL backend when they should be blue.
Michel Dänzer pointed out that I was mapping ARGB to RGBA rather than ARGB. Fixing that has no effect at all on the end result, which seems odd. Fixed anyway.
(In reply to Guillaume Ayoub from comment #3) > It's perfect. Thanks a lot for the really quick fix, you made my day! No problem; sorry for breaking it in the first place!
Review of attachment 358310 [details] [review]: Works in my testing. The SoB can be removed as unused in GNOME projects.
Weirdly, the SoB isn't present in my local commit message, only when uploaded by git-bz ... ?!
You did a "git bz attach" for another commit SHA?
'git bz attach 786677 HEAD^..' Just checked my reflog and none of the commits ever have SoB in them at any point.
Ah hm, maybe format.signoff=true in my global configuration then.
Review of attachment 358310 [details] [review]: So my understanding is that DRM_FORMAT_* is that both ARGB in the cogl and drm format ends up as A:R:G:B in memory.. at least on little endian systems. The cogl one would be A:R:G:B on big endian as well, but what about drm? Anyway, this is more correct than what is now for most people, so looks good. SoB is indeed unneeded however.
(In reply to Jonas Ådahl from comment #12) > Review of attachment 358310 [details] [review] [review]: > > So my understanding is that DRM_FORMAT_* is that both ARGB in the cogl and > drm format ends up as A:R:G:B in memory.. at least on little endian systems. > The cogl one would be A:R:G:B on big endian as well, but what about drm? > Anyway, this is more correct than what is now for most people, so looks good. The last time we looked at DRM formats on big-endian, we concluded the only way it was possibly working is that there were an even number of channel inversions through composition and display, so it all roughly held together. The general consensus was that big-endian should keep the same A:R:G:B representation as little-endian in byte order, but no-one really wanted to do it because then someone might ask them to go fix all of big-endian. > SoB is indeed unneeded however. Will attach a new one then, but it's trial and error as to whether or not it works, so hopefully I don't spam it too hard.
Created attachment 358315 [details] [review] wayland-dma-buf: Fix 32bpp channel order inversion Apparently my understanding of Cogl pixel formats, or at least their use, was somewhat shaky. Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping when creating dmabufs from clients, fixing inverted channel ordering seen from GL clients, e.g. gold highlights in gtk4-demo when using the GSK GL backend when they should be blue.
The patch is now in master. Thanks! Attachment 358315 [details] pushed as 06d0989 - wayland-dma-buf: Fix 32bpp channel order inversion
*** Bug 786786 has been marked as a duplicate of this bug. ***