Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

X server providing wrong color data (xdpyinfo)

Need help with peripherals or devices?
Post Reply
Message
Author
spsx272
Posts: 8
Joined: 2017-02-21 03:00

X server providing wrong color data (xdpyinfo)

#1 Post by spsx272 »

This may be a more technical problem than the usual here, but I'm baffled by this at the moment and want some advice before I roll back my drivers (although this does not seem to be driver-related).

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
This is incorrect... 24-bit color does not have 11 bits per color. On several other machines (one Debian and one Ubuntu), running xdpyinfo reveals the "significant bits in color specification" to be 8, as it's supposed to for 24-bit color. I figured this out because I was running a bespoke software program called "easygl" (for a university course) with the following code that threw up an error.

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");
    }
This code printed to the terminal

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
Basically, when X is asked for 24-bit truecolor, it returns the (wrong) fact that there's 11 bits per color. Anyways, here's the 32-bit visual.

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
This is correct, as 32-bit color has 8 bits per color plus an 8-bit alpha channel.

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! :D

spsx272
Posts: 8
Joined: 2017-02-21 03:00

Re: X server providing wrong color data (xdpyinfo)

#2 Post by spsx272 »

I rolled back to the "stable" 340 driver and xdpyinfo now shows the correct info (8 bit color map for 24-bit Truecolor). Unfortunately, my games don't work anymore... but I guess school comes first :lol: . If anyone has any info on why this is happening in the first place or any alternative fixes I'd like to hear it.

Post Reply