I'm using a Raspbery Pi 2 as an X Window Server to replace some legacy devices. However the X window program only supports 256 colors and will throw an error if the color depth is set higher.

I've set the following in the config file:


When LXDE loads it looks a messed up, the icon text is not readable and the start menu is black and white.

Messed Up Color

When I open the run window the colors will look good again (well, as good as 256 colors can).


I've also tried using the frame_buffer_ignore_alpha = 1 but that didn't help.

I realize I might be one of the only people wanting to run my Pi in 8 bit color mode but does anyone have any ideas of things to try? I also tried creating an Xorg.conf file and set it to 8 bits there but then LXDE doesn't even load.

Running Xephyr in 8 bit mode works and the application loads but the color palette is all wrong. Is this possibly a limitation of the RPI2 hardware? I wouldn't be suprised if the GPU does not support 8 bit palettized output.

  • Does your screen revert to black & white when you close the run window? Also, it wouldn't hurt posting the output of fbset Commented Dec 8, 2015 at 21:11

2 Answers 2


You might want to try using Xnest or Xephyr. These are X servers that run nested within another server. So you can create a second X server as a window within your main desktop then connect your 'special' application to this nested server. Xephyr is the more modern version. Both xnest and xserver-xephyr exist in the Raspian apt repository along with xterm and twm for a real retro desktop. The following produces an 8 bit nested Xserver:

xinit $(which xterm) -- $(which Xephyr) :1 -screen 800x600x8 -br -reset -terminate

enter image description here

  • This looks promising, thank you! I will try shortly and report back.
    – Cam
    Commented Dec 13, 2015 at 1:47
  • That seems a great solution - I did play with Xephyr a while back and I'd forgotten about it - IIRC you may have to remember that the second server (sub-window) is a different screen (:1) not the default (:0) but its so vague in my mind I can't be certain of when that is the case...
    – SlySven
    Commented Dec 14, 2015 at 12:16
  • 1
    Yes, the nested server will be :1 but if you use the xinit line shown then the xterm has DISPLAY set correctly to ":1.0" and all X clients will connect to the nested X server. From another shell on your main desktop you would have to specify the nested server. ie: env DISPLAY=:1.0 x-client-application-name
    – patthoyts
    Commented Dec 14, 2015 at 12:23
  • Xephyr allowed me to run the application, it didn't complain about 256 colors anymore which is great. Unfortunately the color palette is all wrong, black is blue and another shade of blue is a strange green color etc. After much searching I couldn't find any other leads regarding the color issue, I'm beginning to think it's a limitation of the RPI2 (not supporting 8 bit palatalized color mode) but does anyone have any suggestions regarding this problem?
    – Cam
    Commented Jan 20, 2016 at 21:03

Are you sure you want to run your X-server in 8-bit mode? It uses a completely different way of setting colours to the modes with more bits (the colours for each of the 256 index values are arranged in a palette that has to be shared between ALL applications and if there isn't enough to go around the inactive applications will lose some of the colours they want to use to active ones so their colours will change randomly as the mouse is moved between windows.)

From the eLinux guide to config.txt settings we have:

framebuffer_width: console framebuffer width in pixels. Default is display width minus overscan.

framebuffer_height: console framebuffer height in pixels. Default is display height minus overscan.

framebuffer_depth: console framebuffer depth in bits per pixel. Default is 16. 8 bit is valid, but default RGB palette makes an unreadable screen. 24 bit looks better but has corruption issues as of 20120615. 32 bit has no corruption issues but needs framebuffer_ignore_alpha=1 and shows the wrong colors as of 20120615.

framebuffer_ignore_alpha: set to 1 to disable alpha channel. Helps with 32 bit.

One assumes that the issues with 24 and 32 bits have been fixed long ago! So, why is it necessary to run in 8 Bit mode when you can use a higher number of colours - I cannot think off-hand of any applications that DEMAND 8 bit colour but if you know otherwise please respond and I will try to enlarge/revise what I have put here...!

  • Thanks for the info, unfortunately it seems this particular application (circa mid 90s) does intact demand 256 colours. I still haven't found a solution that works but I haven't had much time, I'll try shortly and get back to you with some more info. On Windows Platforms we are able to run the application using OpenText/Hummingbird Exceed with the PsuedoColor setting. If found some references to that in the Xorg documentation but couldn't get it to work on Raspbian. I was also thinking of trying Ubuntu Snappy Core to see if I have any better luck with that.
    – Cam
    Commented Dec 13, 2015 at 1:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.