X11 Color Bafflement

rlsj · 08-07-2015, 11:52 AM

Using RPi-B2 with Raspbian Linux, modern 1920X1080 monitor

Writing a medium-sized project using X11 graphics. XSetForeground before XFillRectangle does not result in the expected color. In the color specification, 0x0rrggbb, only the blue (0x0ff) gets blue. Green (0x0ff00) gets bright yellow and red (0x0ff0000) gets black! I need to discuss this with someone who knows how it works. Can anyone recommend an IRC server and channel that welcomes X11 questions?

--rlsj

Keith Hedger · 08-08-2015, 06:30 AM

You can't use rgb values directley you must first allocate the colour, you can parse a string to get a value for the allocation see the man page for:
XParseColor
XAllocColor

Not at my machine at the moment so I cant give an example.

jpollard · 08-08-2015, 07:10 AM

It depends on the visual class of the display. If you have truecolor, then you should be able to use the RGB values.

Your errors appear to be caused by using a color (something like a 16 bit color) table rather than a direct color.

You should be able to get more information by using "xwininfo" and point at your application window as that should tell you what is being used (and I'm guessing, used by default).

One thing (my Pi2) I have noticed is that it may have some unanticipated memory limits - the size of the display may require more memory to be allocated to the gpu. And without that extra memory, the X server may be using allocated color tables where you have a more limited color range (it may be using a 16 bit color instead of 48 bit). I'm using an older monitor (1280x1024) so my visual class is TrueColor, with a 24 bit depth (the translation from 48 to 24 is internal to the server - and I've allocated 160MB to the gpu for video support).

I will also admit to an older X programming practice - it has been quite a while since I wrote code for X11, and that last project didn't need much in the way of color handling (only text - so mostly just forground/background colors used, and those came from the default table).

Keith Hedger · 08-08-2015, 09:08 AM

Quote:

Originally Posted by jpollard

It depends on the visual class of the display. If you have truecolor, then you should be able to use the RGB values ...

You are correct I have been so used o using XAllocColor that I didn't notice, of course using XAllocColor will work with a lesser deph as well, depends on what the OP wants, and from the looks of the original post he is not using truecolour as he is not getting the correct colours.

rlsj · 08-08-2015, 12:26 PM

jpollard wrote:
"If you have truecolor, then you should be able to use the RGB values... Your errors appear to be caused by using a color (something like a 16 bit color) table rather than a direct color."

I had already tumbled to that. What I wanted was a pale blue background for text, which rgb.txt says is 0x0add8e6. Purely by (lengthy) trial-and-error I discovered that 0x0deff in the third parameter of XSetForeground gives me what I want. Not that it is fully logical. eeff, for example, has a reddish tinge. And anything other than ff in the last byte results in a wholly different color. But I'll go with it, aware that my code may give different results on other hardware.

Keith Hedger wrote:
"You can't use rgb values directley ..."

Apparently true, but you can set colors with hex codes, even if unpredictable.

He recommended
"XParseColor
"XAllocColor"

Have you read the man pages for either function recently? Like most Linux man pages, they are written for those who only need to refresh their memories and are incomprehensible to anyone for whom hours of cross-reference are unavailable. As a typical example, the man page for XFillRectangle carefully fails to state whatever it is that fills the rectangle. At least I never found it in several rereadings and surmised it to be the foreground color after mistakenly assuming the background color.

I gather that the whole colormap complexity is there for legacy reasons. For truecolor hardware, which I obviously have, does no system configure statement exist that allows using it directly?

(This is why I wanted to discuss this subject in IRC.)

--rlsj

Keith Hedger · 08-08-2015, 01:58 PM

Here's some code snippets fopr you

Code:

struct colourStruct
{
	char		*name;
	long		pixel;
};

void LFSTK_windowClass::LFSTK_setColourName(int p,char* colour)
{
	XColor tc,sc;

	this->colourNames[p].name=strdup(colour);
	XAllocNamedColor(this->display,this->cm,colour,&sc,&tc);
	this->colourNames[p].pixel=sc.pixel;
}

void LFSTK_windowClass::LFSTK_clearWindow()
{
	XSetFillStyle(this->display,this->gc,FillSolid);
	XSetClipMask(this->display,this->gc,None);
	XSetForeground(this->display,this->gc,this->colourNames[NORMALCOLOUR].pixel);
	XFillRectangle(this->display,this->window,this->gc,0,0,this->w,this->h);
}

LFSTK_setColourName sets a colour structure from a colour string of the form "pink" or "#ff00ff", I save the colour string for later use, but you can discard it.
colourNames is just an array of colour structures, NORMALCOLOUR=0 etc,this->display,this->window etc should be self expanatory.
Note you use the colourNames.pixel value to set the forground in the LFSTK_clearWindow() function.

Have a look at this:
http://www.linuxquestions.org/questi...ect-4175542914
Which is the start of a full desktop just using Xlib/cairo etc withou all the bumpf and crud of stuff like gtk.
There is an underlying logic to xlib but as anyone who has used it will tell you the documentation really is AWFUL!

rlsj · 08-08-2015, 02:43 PM

Thank you, Keith Hedger, for the "code snippets." Do you really use so many displays, graphic contexts etc. that you need pointers to identify them?

May I repeat my last question: Does no system configure statement exist that can cause
XSetForeground(display,gc,0x0rrggbb) to give me that exact color -- without all the colormap and alloc statements?

You wrote,
"[This is the URL of] the start of a full desktop just using Xlib/cairo etc ..."

That's exactly how I'm coding my application, because GTK is impenetrable. But when you're reinventing the wheel you need to hurry.

--rlsj

jpollard · 08-08-2015, 02:56 PM

Based on the numbers you show for colors I'm betting you actually have only 16bit color. The RGB values are not 8 or 16 bit, but more in a bit pattern of 6,5,5. Usually this is done through a color table that has to be setup to provide a mapping between the entries used, and the resulting display.

And the colormap isn't there for legacy. It is there for equipment that has limited memory for images; and that happens more often than you may realize.

Yes, gpus may be able to generate 24 bit color... but that doesn't mean memory is available to use them directly. Instead, color tables get generated, and the image contains pixels that are then used to index into the table to get the final color for the given pixel.

It is possible you will have to allocate a color table, then fill it with the colors you want to use.

Some hints on the GPU limitations for the pi are at: http://raspberrypi.stackexchange.com...sus-gpu-memory

And that will also determine the restrictions the X server has for the display.

jpollard · 08-08-2015, 03:09 PM

Quote:

Originally Posted by rlsj

Thank you, Keith Hedger, for the "code snippets." Do you really use so many displays, graphic contexts etc. that you need pointers to identify them?

The pointers are there because the same information is shared. No need to create or copy them all over the place. Second, which context is being referenced... Guess what - that is determined by the address used (faster than trying to compare structures...)

Quote:

May I repeat my last question: Does no system configure statement exist that can cause
XSetForeground(display,gc,0x0rrggbb) to give me that exact color -- without all the colormap and alloc statements?

The answer is both yes and no. It all depends on the color class. If you have limited memory, then no you can't. If you have TrueColor, then yes you can.

Quote:

You wrote,
"[This is the URL of] the start of a full desktop just using Xlib/cairo etc ..."

That's exactly how I'm coding my application, because GTK is impenetrable. But when you're reinventing the wheel you need to hurry.

--rlsj

And "hurry" is not way to reinvent the wheel. GTK is there to provide an additional layer of flexibility, which in turn, provides speed to development - but, unfortunately, you have to know how to use the layer. Going directly Xlib is not fast. (been there done that. Even a basic tool kit took two months for a very small application, but the requirements were to not be dependent on any particular library - only assume the basic X library).

Some people like to use code generators to create the framework for their application. After that, they focus on the details of the application and not the framework.

rlsj · 08-08-2015, 03:11 PM

jpollard:

I have allocated the maximum RAM allowed by the /boot/config.txt file referenced in that URL (which is obsolete, BTW) to graphics: 256 MB out of 1 GB. Other apps show JPG and video files on this machine in HD full colors, so I'm guessing a configuration statement must exist that my default graphics support has not invoked. Can you suggest anywhere to explore?

--rlsj

rlsj · 08-08-2015, 03:20 PM

(Reply to jpollard's third post)

"The pointers are there because the same information is shared." So the answer to my question about the pointers is "yes."

" If you have TrueColor, then yes you can [force direct use of 0x0rrggbb]."

Glad to see it! How? Would it be better to ask that on an RPi forum?

Thanks for the assurance.

--rlsj

Keith Hedger · 08-08-2015, 05:20 PM

As above the display and window pointers are just copy's ( display is for instance only aquired once from the main qindow class and passed to all the other classes ) virtually all xlib calls need the display pointer so its a good idea to grab it at the start of your program and just pass it around, the majority of xlib call also take a window id which can also be a pixmap.

Gtk in its current form is becomming less and less flexible and gtk3 should really be renamed to gnome toolkit, i personnaly wont have it on my system.

All high level toolkits xforms, gtk, qt etc all have to comunicate with the low level xlib functions at some point wther they do it directly or via other intermediate libs like xcb, if you do nnot like/want all the bloat that goes with somthing like gtk then carry on learning xlib, contrary to what a few fanboys of certain distros wold like yiu to beleive xlib is in use and will continue to be in use on literlymillions of linux machines, so you are not wasting your time, and frankly sometimes the wheel needs reinventing becasue some idiot has decided that square wheels work best.

jpollard · 08-08-2015, 06:09 PM

Yeah... I kind of lean that way myself. I dislike gnome too.

rlsj · 08-08-2015, 09:12 PM

jpollard wrote, in answer to my question about getting direct color access,
"It all depends on the color class. If you have limited memory, then no you can't. If you have TrueColor, then yes you can."

But how?

Is 256 MB of graphic-dedicated RAM enough? I note that 1920*1080*4 only equals 8.3 MB. 256 MB is enough for 30 full screens of 32-bit color. Where can I find instruction on how to enable truecolor directly?

--rlsj

jpollard · 08-09-2015, 01:07 AM

Not sure. I think it will depend on the GPU.

In my case (the pi 2 is the only one I've actually played with) it provides TrueColor by default, but does not handle video (depends, some dvd iso images work, some don't - with only 160MB they seem to work), and since there are 4 processors, it can keep up (I have tried 256, but it doesn't perform any better than 160MB).

Normally, TrueColor is actually 24 bit color rather than 32.

It has been a long time, but I think the application has to query (using XDefaultVisual) to determine the visual being used...

What I don't know is if there are differences between the various gpu implementations that impose different limits on the X server. The pi2 allows for TrueColor. I don't know if the original pi does.

sorry I can't get more detailed. I would have to dig up the books and start making test programs again. The last time I worked in X I was still using imake/xmkmf and other build tools (which don't seem to be provided anymore), so the test programs I have don't compile at the moment. So I would have to port my primitive toolkit first.