xwininfo/xdpyinfo seems to confirm the red and blue channels are reversed for GLX windows:
visual:
visual id: 0xb4
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
versus non-GLX windows:
visual:
visual id: 0x28
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
However the problem is not as simple as changing a pixel format. Xmir is running in rooted mode, so we only get to choose one visual for the whole display at start-up. So we need to find a way to force GLX to use the correct visual, or to force XComposite to mix the colours correctly. Because it's really out of Mir's control...
xwininfo/xdpyinfo seems to confirm the red and blue channels are reversed for GLX windows:
visual:
visual id: 0xb4
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
versus non-GLX windows:
visual:
visual id: 0x28
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
However the problem is not as simple as changing a pixel format. Xmir is running in rooted mode, so we only get to choose one visual for the whole display at start-up. So we need to find a way to force GLX to use the correct visual, or to force XComposite to mix the colours correctly. Because it's really out of Mir's control...