Basically, it appears that my x-server (according to xdpyinfo) is providing the wrong color data for the "truecolor" mode. The full xdpyinfo log is here(http://pastebin.com/bmtfzTQA) if you want to take a look. Let's look at two different visuals:
24 bit:
Code: Select all
visual:
visual id: 0x21
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 11 bits
Code: Select all
if (XMatchVisualInfo(
x11_state.display,
x11_state.screen_num,
24, TrueColor,
&x11_state.visual_info) == 0) {
fprintf(stderr, "Warning found strange 24-bit TrueColor visual:\n");
fprintf(stderr, " Graphics may not draw correctly\n");
}
if (x11_state.visual_info.bits_per_rgb != 8) {
fprintf(stderr, "Warning found strange 24-bit TrueColor visual: \n");
fprintf(stderr,
" bit per color = %d, rmask = %lX, gmask = %lX, bmask = %lX\n",
x11_state.visual_info.bits_per_rgb,
x11_state.visual_info.red_mask,
x11_state.visual_info.green_mask,
x11_state.visual_info.blue_mask
);
fprintf(stderr, " Graphics may not draw correctly\n");
}
Code: Select all
Warning found strange 24-bit TrueColor visual:
bit per color = 11, rmask = FF0000, gmask = FF00, bmask = FF
Graphics may not draw correctly
32 bit:
Code: Select all
visual:
visual id: 0xf0
class: TrueColor
depth: 32 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
I've running Debian 8 stable, fully updated, with the Nvidia 375.26 driver from backports on a 550ti (I play video games that require the newer drivers). I could roll back to the "stable" 340 drivers and check if the problem still persists, but I find that unlikely since the "easygl" program worked fine last week (and the drivers were not updated since then).
Is there anything I can do here? The biggest question I have now is why X incorrectly thinks that my 24-bit truecolor visual has 11 bits per color. Is there a way to override this?
Thanks!