8-bit pseudocolor visuals not available in Solaris 10 guests

[rasta]

There appears to be no way to get support for 8-bit pseudocolor (overlay) visuals in a 24-bit default setup for Solaris 10 guests. Such support is essential for older graphic applications. I need to run Xnest in 8-bit mode for an application, so I need support for both 24-bit and 8-bit visuals. Altering xorg.conf does not seem to help. I assume that this ticket is for an enhancement, not a defect, but as far as I am concerned, it is such a major limitation that it is a severe defect.

My guest is Solaris 10 u7 (32-bit) running on a 32-bit WinXP host with VT-x enabled. I have a NVIDIA Quadro FX 3500 vcard.

Here is my perennial output of xdpyinfo from terminals in my guest:

xdpyinfo

name of display: :0.0 version number: 11.0 vendor string: Sun Microsystems, Inc. vendor release number: 10300000 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats:

depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32

keycode range: minimum 8, maximum 255 focus: window 0x3000009, revert to PointerRoot number of extensions: 34

BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC SolarisIA TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XEVIE XFIXES XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo

default screen number: 0 number of screens: 1

screen #0:

dimensions: 1600x1200 pixels (423x317 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x44 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0x3a003f

KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask

number of visuals: 4 default visual id: 0x22 visual:

visual id: 0x22 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

visual:

visual id: 0x23 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

visual:

visual id: 0x24 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

visual:

visual id: 0x25 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

If there is a way to alter xorg.conf to get 8-bit visuals, or if you need further info, please let me know.

Thank you...

[rasta]

log of running Solaris guest (no 8-bit visuals avalable)

[Sander van Leeuwen]

Do you want to run X in 8 bit colour mode or a specific application only in an otherwise high colour mode X desktop?

In case of the former I suggest you try to switch to a VGA or VESA driver. If it's the latter, then it sounds like something X should handle internally.

[rasta]

Hi Sander,

Thank you for your reply. My case is the latter. The way I normally do things is to have X running in 24-bit, and then run Xnest locally in 8-bit pseudocolor mode for an application.

When you say that X should handle this internally, I assume you mean that I can somehow change xorg.conf to allow 8-bit pseudocolor (overlay?) mode in an 24-bit default visual environment? If so, I have no idea how to do that, and I have tried. My understanding was that doing that runs into trouble when interfacing with the limited capability of the display driver supplied with the Solaris guest additions, and that no real access to the actual host video card is possible from a guest.

Please let me know if any of the above assumptions are wrong. More importantly, if you know how I can get my guest (xorg?) to allow 8-bit overlay visuals, please let me know the specific ways to edit xorg.conf and/or other files to do so.

You also mentioned "switching to a VGA or VESA driver". I didn't know that was possible from a vbox guest. Would I do that through editing xorg.conf? Is there documentation somewhere about how to handle such things in a vbox Solaris (or other) guest running X?

I started a forum thread about this many moons ago:

​http://forums.virtualbox.org/viewtopic.php?f=20&t=8772&sid=a8e3bb15fb06dface414e9adc441e7ca

Thank you in advance!

[Sander van Leeuwen]

I assume X handles the colour conversion internally, but perhaps our display driver lacks some capability.

Switching to the builtin VESA driver and testing it there would be useful though. Don't ask me how to manually switch drivers though; I'm no X expert. :)

[rasta]

My understanding is that the issue lies with the lack of functionality for handling 8-bit pseudocolor visuals in the display driver supplied with the Solaris guest additions. Even older Sun display drivers for sparc machines (like those for XVR-500 video card), have 8-bit visual capability. I need to find out what it will take for the Vbox Solaris driver to support 8-bit, or if there is some other way to alter xorg.conf to get the support.

I have no idea how to switch the driver. In the xorg.conf supplied with 3.0.4, the driver is "vboxvideo." Here are the pertinent sections of xorg:

Section "Monitor"

Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model"

HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0

EndSection

Section "Device"

Identifier "Card0" Driver "vboxvideo" VendorName "Unknown Vendor" BoardName "Unknown Board" BusID "PCI:0:2:0"

EndSection

Section "Screen"

Identifier "Screen0" Device "Card0" Monitor "Monitor0"

EndSection

[rasta]

Answers I need:

1) Are the limitations in the vboxvideo driver supplied with the Solaris Guest Additions the cause of the lack of 8-bit pseudocolor visuals for a Solaris 10 guest?

2) If so, how much effort will it take for Sun to update the driver to enable 8-bit visuals, and, more importantly, have they any inclination to do so? I have to know, as if the problem is not fixed, I will have to largely abandon VirtualBox/Solaris 10.

3) If not, what are the other causes of the problem? Can I somehow edit xorg.conf to get 24- and 8-bit visuals? Changing default_depth to 16 using svccfg does not help the problem. vboxvideo driver appears to support 16- and 32-bit graphics.

Until the above questions are answered, I am dead in the water.

[Michael Thayer]

The problem may be that we don't support DirectColour visuals, which should provide colour palettes. Whether we can do that with a reasonable effort is another question though. If you know anything about how this works in an X.Org video driver, your feedback would be appreciated.

[rasta]

Thank you for your post. Unfortunately, I am not an expert on X, and thus cannot shed any light on how DirectColor works with xorg. I also do not know if lack of DirectColor support is the cause of the problem. What will it take to get you (Sun) to research the issue and enable 8-bit pseudocolor visuals for a Solaris 10 guest? I am willing to consider entering into a contract relationship with Sun if the price is reasonable.

[Michael Thayer]

Before starting discussing contracts and things (which I am not qualified to do), have you tried out the vesa driver in VBox to see if it fulfils your requirements? Just replace "vboxvideo" with "vesa" in xorg.conf, and change the graphics depth to eight bit.

[rasta]

Thank you for the tip, Michael! I'll try it out now.

[rasta]

I changed xorg.conf thus:

Section "Monitor"

Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model"

HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0

EndSection

Section "Device"

Identifier "Card0" Driver "vesa" VendorName "Unknown Vendor" BoardName "Unknown Board" BusID "PCI:0:2:0"

EndSection

Section "Screen"

Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 8 SubSection "Display" ViewPort 0 0

Depth 8 Modes "1600x1200_60.00"

EndSubSection

# SubSection "Display" # ViewPort 0 0 # Depth 16 # Modes "1600x1200_60.00" # EndSubSection # SubSection "Display" # ViewPort 0 0 # Depth 32 # Modes "1600x1200_60.00" # EndSubSection EndSection

And various permutations with different "Display" sebsections for different resolutions, all to no avail. Still only 24 planes of TrueColor are available (xdpyinfo output same as shown above except for screen resolution):

screen #0:

dimensions: 1280x1024 pixels (433x347 millimeters) resolution: 75x75 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32

With vesa, I am limited to 1280x1024 and smaller screens, and 86 Hz refresh, whereas with vboxvideo I could get the 1600x1200x60Hz that matches my monitor.

[rasta]

Here is the Xnest command I am used to running on sparc boxes using JDS desktop:

Xnest -pn -geometry 1600x1200 -depth 8 -class Pseudocolor -install :1 & twm -display :1 & xterm -display :1 -title "xterm -sb" -sb&

On the Vbox guest, the desired visual is not found "Fatal server error: Uable to find desird default visual."

[Michael Thayer]

Regarding the limited resolution, the "Custom VESA resolutions" feature described in the VirtualBox manual should help. Regarding the second issue, it may well just be an X.Org configuration issue - you might be best taking that to an X.Org/Linux-related forum or something to see what they have to say.

[Michael Thayer]

Err, sorry, make that X.Org/Solaris-related for your Solaris guest :)

[Michael Thayer]

Update: I tested the VESA driver 8-bit mode, and it does not seem to be properly supported by VirtualBox.

[rasta]

I agree about lack of vesa support in Vbox. Custom vesa resolutions are another issue that need not be discussed here.

At this point I do not think that there is a way to alter xorg.conf in a Solaris Vbox guest and get 8-bit visuals, either with the default vboxvideo driver or the vesa driver. I hope I am wrong, but I don't think so. I have searched the web and posted several times on Solaris forums, and found nothing. If Solaris x86 is loaded onto a box (non-virtual environment) having an NVIDIA card, xorg CAN be altered to get 8-bit visuals. The problem lies with the vboxvideo driver (and vesa). I went through all this with VMware and they choked/punted on the problem.

Therefore, the idea of building DirectColor support into the vboxvideo driver may be the only way to go.

[Michael Thayer]

Making our virtual graphics card handle 8 bit modes correctly with the VESA driver would be the easiest way of handling this, but I fear that this will probably never be a high enough priority for us to get round to. You might be able to find someone else willing/able to do the work though (e.g. by asking on the Qemu mailing lists or whatever they use). If they submitted a patch to us we would probably be able to integrate it into a future version.

[Frank Mehnert]

Custom VESA resolutions: Section 9.5 in the user manual.

[rasta]

About the custom resolutions, I tried the vboxmanage setextradata global gui/maxguestresolution 1600,1200 command, and it had no effect whatsoever on vesa resolution for the guest. At least the vboxvideo driver works well for resolutions. The vesa driver is nearly useless, as Mike suggested above.

[rasta]

See this Solaris x86 thread for helpful info:

​http://forums.sun.com/thread.jspa?messageID=10841564&tstart=0#10841564

The expert thought that Michael and I were "talking past each other".

[Michael Thayer]

Glad you were able to solve this. I think that using an external X server is a better solution that adding colour palette support (that is what I actually meant when I talked about direct colour above) to VirtualBox. Just to clear things up here, the problem is not one of the Guest driver, but rather one of the underlying emulated graphics card. The graphics card that the guest sees is emulated in software, and bears no connection to the physical card on the host. And in the case of VirtualBox, support for emulating colour palettes, which are needed for PseudoColour (and yes, for DirectColour) was never added, as these days hardly anyone actually needs it (I can't remember anyone other than you wanting it). While possible, adding this emulation would be a significant engineering time investment which doesn't really seem worth it for the limited audience (was just you, and now that you have found another solution it has probably dropped to zero again).

[rasta]

Yes, my impression from your earlier comments was that the problem lay in the vboxvideo and vesa cards emulated by Vbox. There was one other vbox user (woboyle) who also had interest in pseudocolor graphics for Solaris guests (see forum thread listed above). Really, the problem lay in the 10+-year-old graphical app that I need which was limited to 256 colors. That program needs to be upgraded to handle 24-bit environments, but that also would require a very substantial time commitment. Thanks for your help!