Frame Buffer FAQ

Last Updated: 8th May 1995

This document is written and maintained by David Tong, SunSoft CTE.
Copyright (C) 1994-95 David Tong and SunService UK.
Permission is given to distribute this document provided it is not modified in any way.

I maintain this FAQ purely for the fun of it, and because if I didn't it wouldn't get done.
If you've found it helpful, please let me know.

I am keen to receive any corrections, updates, suggestions, queries, etc.
I can be contacted by email as David.Tong@eng.sun.com or by post at
UMPK03-208, 2550 Garcia Ave, Mountain View, CA 94043
or contact my manager, Larry.Johnson@eng.sun.com.

Every effort is taken to maintain the accuracy of the information; your assistance is appreciated.
No responsibility is taken for any inaccuracies.

Click on the "?" logo to get back to here

0. What's the bottom line on 1280 x 1024 @ 76Hz on the SX?

1. How do I set the resolution of the primary frame buffer?

2. How do I set the resolution of a second frame buffer?

3. How do I find whether I have a GX, a GX+, a TGX or a TGX+?

4. What are the restrictions on multi-headed machines?

5. What resolutions do the various frame buffers support?

6. What is the default resolution for each frame buffer?

7. How do I change the console frame buffer?

8. Will Solaris 1.x run on a SS20SX?

9. How do I change the default depth or visual class in OpenWindows?

10. Why does the screen look paler or darker in 24 bit mode?

11. How can I display the same tool on multiple windows?

12. Can I replace the monitor with an LCD display?

13. What frame buffers are available from third parties?

0. What's the bottom line on 1280 x 1024 @ 76Hz on the SX?

I've made this question zero, because it's arguably TMFAQ I've ever seen. (Alongside "When do you leave?", but that's another story.)

As detailed elsewhere in this document, the SX does support 1280x1024@76 resolution, but it's tricky to get. This is due to a restriction in the SX's prom. Under 2.3 you had to set the resolution in the EEPROM using the command:

setenv output-device=screen:r1280x1024x76m

You could not use cg14config as the version supplied with 2.3 did not allow this resolution.

This was supposed to be fixed in 2.4 - early versions allowed both 1280x1024x76 and 1280x1024x76m, but only 1280x1024x76m actually works. Unfortunately, this was broken at some stage, and not spotted until later in the beta phase. Bug ID 1164703 was logged, but at a low priority (4), so it was not fixed in time for FCS. It has now been fixed for 2.5 - see Bug ID 1187375 - but at the moment (March 95) there is no patch available. In the meantime, you must continue to set the resolution in the EEPROM.

1. How do I set the resolution of the primary frame buffer?

First, verify that the resolution is supported - see Question 5.
The resolution is specified as rHORIZxVERTxFREQ - the r and x characters are significant.

To set the resolution, run the following command as root:

# eeprom output-device=screen:r1280x1024x76

then reboot. Alternatively, halt the machine and type

ok setenv output-device screen:r1280x1024x76
ok reset

Some frame buffers have their own configuration programs; for the ZX you should use leoconfig:

 /usr/kvm/leoconfig -m 1280_67

while for the SX you should use cg14config:

 /usr/kvm/cg14config -r 1280x1024@66

2. How do I set the resolution of a second frame buffer?

For the SX use the command cg14config. You should NOT reboot, as this will reset the resolution. To ensure that the resolution is set each time, place the command somewhere that it will be run each time you reboot (/etc/init.d) or start OpenWindows ($HOME/.xinitrc).

 /usr/kvm/cg14config -d /dev/fbs/cgfourteen1 -r 1280x1024@66

Be aware that the resolutions supported by cg14config differ between Solaris 2.3 and 2.4. For further details, see the SX section in Question 5.

Note to Solaris 2.3 users: There is a bug in the cgfourteen driver, ID 1119523. This is fixed in Solaris 2.4. For further information please contact your local SunService Hotline.

For other frame buffers, it is a little trickier. You have to set the resolution at boot time in the nvramrc. Here is a script that will set up the nvramrc so that it initialises the resolution to 1280x1024 @ 76Hz.

Note: This information is included in the TGX/TGX+ Hardware Installation Guide, 801-5399-10, pages B-10 and B-11. However the quote marks shown in the script in that document are not correct - the code here is correct.
Page B-10 of that document also gives the incantations for a few other resolutions besides the 1280x1024x76Hz variety. For the truly daring, page B-8 tells you what the numbers mean and implies how you might program in a custom resolution. (This is, of course, unsupported!)

#!/bin/sh

eeprom fcode-debug\?=true
eeprom nvramrc='probe-sbus
" /iommu/sbus/cgsix@3" select-dev
r1280x1024x76
" /iommu/sbus/cgsix@3" " set-resolution" execute-device-method drop
device-end
install-console
banner
'
eeprom use-nvramrc\?=true

The script presumes sun4m architecture; for sun4c change /iommu/sbus to /sbus
The other information you will need to run the script is which sbus slot the second frame buffer card resides in - ie the one that will be used as the second head. In this instance, it assumes a cgsix frame buffer in sbus slot 3.

The script has the disadvantage that it makes the second TGX the console frame buffer. You may not want this; for example if you have a SS20SX with an additional TGX, you may wish to set the resolution of the TGX while maintaining the SX as the console.

In which case, try this script instead. It should set the resolution of the TGX to 1280x1024@76 while maintaining the SX as the console.

NB: This is UNSUPPORTED and the originator denies all knowledge!

#!/bin/sh
eeprom fcode-debug\?=true
eeprom nvramrc='probe-all
install-console
banner
: vsetup " 135000000,81128,76,32,64,288,1280,2,8,32,1024,COLOR,0OFFSET" ;
vsetup 4
" /sbus/cgsix@2" " override" execute-device-method drop
'
eeprom use-nvramrc\?=true

3. How do I find whether I have a GX, a GX+, a TGX or a TGX+?

Run the following command:

 dmesg | grep cg

You should see messages similar to this:

cgsix0 at sbus0: SBus slot 2 0x0 SBus level 5 sparc ipl 9
cgsix0 is /iommu@f,e0000000/sbus@f,e0001000/cgsix@2,0
cgsix0: screen 1152x900, single buffered, 1M mappable, rev 11
cgsix1 at sbus0: SBus slot 1 0x0 SBus level 5 sparc ipl 9
cgsix1 is /iommu@f,e0000000/sbus@f,e0001000/cgsix@1,0
cgsix1: screen 1152x900, double buffered, 4M mappable, rev 6

If the rev number of the board is 11 or more then the board is a TGX/TGX+
If the rev number is 9 or less, then it is a GX/GX+
If you see the text single buffered, 1M mappable then it is a GX/TGX
if you see double buffered, 4M mappable then it is a GX+/TGX+

Thus, in the example above, cgsix0 is a TGX, while cgsix1 is a GX+

Note: On a SPARCstation LX with the optional VSIMM, one will actually see 2M mappable. This is equivalent to a TGX+.

4. What are the restrictions on multi-headed machines?

As far as software restrictions go, until OpenWindows V3.2 (Solaris 2.2) you were limited to a maximum of 4 heads by the xnews server. For 3.2 this limit was raised to 16, so now you are effectively limited by how many frame buffers the machine can physically support.

Some sources suggest that the operating system can only support 6 frame buffers; however this is still more than the number of SBUS slots available in most machines.

SparcStation 5

The SS5 will support 3 heads - (2 SBus cards + 1 Afx or 3 SBus cards)
You cannot have more than 1 S24 card in an SS5 system because the S24 card requires an AFX bus and the SS5 only has one AFX bus connector.

SparcStation 10

The SS10 can have 4 heads - (4 SBus cards)

SparcStation 20

The SS20 can have up to 5 heads, either 1 SX and 4 SBus cards (TGX/TGX+) or 2 SX and 3 SBus cards (TGX/TGX+)

There are capacitance loading issues with the SS20 SBus that causes some limitations on the number and configuration of SBus cards. You can use 1 or 2 TGX cards with any combination of any other SBus cards.

You can use 3 or 4 TGX cards, but if you have 3 you should leave the fourth SBus slot open. This is because some SBus cards with high capacitance rating may overload the SBus capacitance and cause problems.

For the SX, the first SX head simply requires a VSIMM. The second SX head requires a VSIMM and an extension card that takes the place of one SBus card.

However I have since received an email which states that a maximum of 2 TGX/TGX+ cards are supported in a SS20:

This rather suprised me, however inside the SS20 box is an 
engineering addendum that say's only a maximum of 2 TGX or
TGX+ cards can be installed in the system.
The text is not very clear, but it also intimates that if
two cards are fitted, nowt further else can be!

Also the July 1994 Config Handbook (the Purple, don't leave
home without one book), clearly states on page 52 that one
TGX or TGX+ is supported on the SS5 and only two TGX or TGX+
are supported on the SS20.

I will try and dig out the engineering addendum, but we did
check this with engineering and they confirmed the addendum.

SparcServer 1000

Up to 4 Frame Buffers are supported in a SS1000.

SparcServer 2000

Only one Frame Buffer is supported in the SS2000.

ZX and Turbo ZX

The ZX series cards impose their own set of restrictions on a machine. Because of the amount of power the ZX consumes, and consequently the heat that it produces, you can only have one ZX in a machine, which takes up two slots, though the remaining slots may be available for use by other SBUS cards, depending on cooling and power factors.

The Turbo ZX card uses more power and produces even more heat than the ZX. As a result, two fan cards are needed. This takes up a total of 4 slots. Additionally, on a Sparc 20, the side vents must be replaced to improve the cooling. This is detailed in the TurboZX Graphics Accelerator installation manual, part number 801-7829-10.

5. What resolutions do the various frame buffers support?

The following resolution values are all taken from the Field Engineer's Handbook, except where stated otherwise.

CG3 and GX

1152 x  900 @ 66Hz	1152 x  900 @ 76Hz

76Hz is only supported on later boards, where it is the default.

GXplus

1152 x  900 @ 66Hz	1152 x  900 @ 76Hz
1024 x  800 @ 85Hz
1280 x 1024 @ 67Hz Default

GS (CG12)

1152 x  900 @ 76Hz

GT

1280 x  1024 @ 67Hz	1280 x  1024 @ 76Hz Default

ZX (Leo)

 640 x  480 @ 60Hz
 770 x  575 @ 50Hz
 960 x  680 @108Hz	 960 x  680 @112Hz
1024 x  768 @ 60Hz	1024 x  768 @ 76Hz
1152 x  900 @ 66Hz	1152 x  900 @ 76Hz
1280 x 1024 @ 76Hz	1280 x 1024 @ 67Hz

Turbo GX

1024 x  768 @ 60Hz	1024 x  768 @ 70Hz	1024 x  768 @ 76Hz
1024 x  800 @ 74Hz	1024 x  800 @ 85Hz
1152 x  900 @ 66Hz	1152 x  900 @ 76Hz

Turbo GXplus

1024 x  768 @ 60Hz	1024 x  768 @ 70Hz	1024 x  768 @ 76Hz
1024 x  800 @ 74Hz	1024 x  800 @ 85Hz
1152 x  900 @ 66Hz	1152 x  900 @ 76Hz
1280 x 1024 @ 67Hz	1280 x 1024 @ 76Hz
1600 x 1280 @ 76Hz

SX (CG14)

There is an element of confusion as to what resolutions the SX supports. The cg14config manual page for Solaris 2.3 agrees with the FE Handbook, whereas the cg14config manual page for Solaris 2.4 differs.

1024 x  768 @ 60Hz	1024 x  768 @ 66Hz	1024 x  768 @ 70Hz
1024 x  800 @ 84Hz
1152 x  900 @ 66Hz	1152 x  900 @ 76Hz
1280 x 1024 @ 66Hz	1280 x 1024 @ 76Hz(1)
1600 x 1280 @ 66Hz
1920 x 1080 @ 72Hz

(1) Cgfourteen will support 1280x1024 @ 76Hz but the tricky part is in telling it how to do it. You have to set the resolution with the command

# /usr/sbin/eeprom output-device=screen:r1280x1024x76m

or ok setenv output-device=screen:r1280x1024x76m

and reboot. Note the m after the 76 - this is significant, and allegedly stands for mutant(!)

The man page under Solaris 2.4 reflects what values are supported in the cgfourteen driver. However it's still up to the prom to recognize them because the driver simply takes user's request and passes it to the prom to change the prom variable 'output-device'. Under 2.4 1024x800@84 was taken out and 1920x1080@72 added.

6. What is the default resolution for each frame buffer?

The default resolution depends on the attached monitor. The following table shows the resolution that will be selected for each detected sense code.

FRAMEBUFFER DEFAULT RESOLUTIONS BY SENSE CODE

December 6th 1994, David C. Kehlet

Code	TGXplus(1)	TGX(2)		GXplus		GX (LSC chip)
-------------------------------------------------------------------
7 	1152x900x66 	1152x900x66 	1152x900x66 	1152x900x66 	
6	1152x900x76	1152x900x76	1152x900x76	1152x900x76	
5	1024x768x60	1024x768x60	1152x900x66	1152x900x66
4	1152x900x76	1152x900x76	1280x1024x67	1152x900x76	
3	1152x900x66	1152x900x66	1152x900x66	1152x900x66	
2	1280x1024x76	1152x900x66     mutant(3)	mutant(3)
1	1600x1280x76	1152x900x66     mutant(4)	mutant(4)
0	1024x768x77	1024x768x77	1152x900x66	1152x900x66

(1) SSLX with the extra VRAM SIMM is the same as the TGXplus.

(2) SSLX is the same as the TGX. SS Voyager is the same as the TGX, except that code 7 is used to tell the system to use the internal LCD display.

(3) Sync timing matches 1280x1024x76, actual pixels displayed are less. Use is not recommended.

(4) Sync timing matches 1600x1280x76, actual pixels displayed are less. Use is not recommended.

Code	SX		ZX		S24		
------------------------------------------------------
7	1152x900x66	1152x900x66	1152x900x66	
6	1152x900x76	1152x900x76	1152x900x76
5	1024x768x60	1152x900x66	1024x768x70
4	1152x900x76	1280x1024x67	1152x900x76
3	1152x900x66	1152x900x66	1152x900x66
2	1280x1024x76(5)	1280x1024x76	1152x900x76
1	1600x1280x76(5)	1152x900x66	1152x900x66
0	1024x768x60	1024x768x76	1152x900x66

(5) The 4Mbyte VSIMM drops to 8 bits per pixel in these modes.

7. How do I change the console frame buffer?

The console is chosen from the set of devices whose device-type is "display". The first such device encountered during OpenBoot probing is chosen. SBus devices are probed in the order specified by the OpenBoot configuration parameter sbus-probe-list, and the conventional way to select one device over another as the console is to:

sbus-probe-list

However neither of these will work to choose an SBus device as the console device in an SX-equipped system because the MBus-based SX is probed before any SBus slots.

A solution is to explicitly specify the console device in NVRAM. You can leave the SX VSIMM in place and still select your device to be the system console by making a few definitions in NVRAM:

output-device

use-nvramrc?

true

Assume, for example, that there is a ZX in SBus slot 2 of a sun4m machine. First get into the OpenBoot monitor (L1-A), and

	ok  show-sbus

Look at the list of devices and make sure you really have a ZX (leo) in SBus Slot 2. This is not really needed if you know what you have already.

 
	ok  nvalias  zx-screen  /iommu/sbus/SUNW,leo@2,0
	ok  setenv  output-device  zx-screen
	ok  reset

After the reset, the console output will go the ZX in SBus slot 2. In this scenario, The nvalias OpenBoot command creates the devalias (for zx-screen in this case) and sets use-nvramrc? to true. The setenv command changes the console output device from the default "screen" to the explicitly-specified "zx-screen".

If you want to delete the devalias zx-screen and revert to the default console just type:

	ok  nvunalias zx-screen
	ok  set-default output-device

8. Will Solaris 1.x run on a SS20SX?

NO. The SX frame buffer is only supported under Solaris 2.3 or greater. There is no support for it in SunOs 4.x/Solaris 1.x
You can install 4.x on a 20SX, using the head as a console only, but you will not be able to start OpenWindows unless you add another frame buffer and use that instead (see earlier questions for details of how to do this).

9. How do I change the default depth or visual class in OpenWindows?

In the past, OpenWindows would always use 8 bit PseudoColor as the default visual, even when a 24 bit frame buffer is being used. However this rule is now changing. Starting with the S24, OpenWindows will default to 24 bit TrueColor. This rule is expected to continue as new graphics products are developed, however 8 bit PseudoColor will remain the default visual for the existing 24 bit frame buffers, such as the SX, ZX, GT and GS.

A 24-bit TrueColor default reduces colormap flashing. DeskSet and other applications that are really visual-independent then don't take up entries in the colormap. Thus those applications that do care have more available.

It is expected that most applications will be able to use 24-bit TrueColor. Fewer and fewer people should have to play colormap tricks such as 4/4 double buffering or wierd plane masking as screen update rates go up. Also, the data copy advantage of 8-bit pixels is going away with SX, S24 and future Frame Buffers.

You can alter the default depth or class by using the defdepth or defclass options to the server, thus:

	openwin -dev /dev/fb0 defdepth 24
	openwin -dev /dev/fb0 defclass TrueColor

Acceptable depths are 8 or 24; you cannot set a depth of 1. The nearest you can get to simulating a monochrome display is to select a greyscale visual (see below) and specifying the -2d flag to olwm.

Acceptable classes are: GrayScale StaticGray PseudoColor StaticColor DirectColor and TrueColor.

NB: 24 bit DirectColor visual is only supported on the S24 or ZX, and only under OpenWindows 3.4
Bug 1168007 has been logged, documenting colormap problems when this visual is used. As a workaround, use the option -whitepixel 1 thus:

	openwin -dev /dev/leo0 defclass TrueColor defdepth 24 -whitepixel 1

10. Why does the screen look paler or darker in 24 bit mode?

If the screen looks pale and washed out, or too dark, you need to alter the gamma correction level. For the SX the default is 2.2; for the ZX it is 2.22 Use the -g option to cg14config or leoconfig to find level that is acceptable for your monitor. Increasing the value will make the screen lighter; decreasing it will make it darker.

11. How can I display the same tool on multiple windows?

There are two options: the hardware solution and the software solution.

The hardware solution involves taking the signal from the frame buffer, amplifying it, then splitting it and sending it to multiple monitors. Amplification is necessary since the signal from the frame buffer is only designed to drive one monitor.

At least two software solutions are available: ShowMe, available from Sun, and XMX, a Public Domain product available from Brown University. These tools work by interposing a handler between the X client and server, and sending copies of the information to other remote screens.

Information on ShowMe is readily available from Sun.

XMX is available by FTP from a number of sites; use `Archie' to find the most convenient site, or try Brown University directly:

	wilma.cs.brown.edu:/pub:xmx.tar.Z

Note that this information may be out of date.

12. Can I replace the monitor with an LCD display?

LCD panels are a lot like CRTs, but have stricter timing. They usually require a digital interface; the analog outputs from Sun's frame buffers probably won't work.

In addition, many LCD displays are designed to be driven by PC frame buffers which use very different timings, and therefore cannot be used with any of SUN's products.

Both PC format and Digital frame buffers are available from third party vendors. See Question 13 for more information.

If you are interested in LCD technology here is excellent document written by Scott Bruck, SBRUCK@EM.DRL.MEI.CO.JP, of Matsushita's Liquid Crystal Display Development Center (sic).

13. What frame buffers are available from third parties?

NB: This is not an exhaustive list, and no recommendation is implied or should be inferred by the presence or absence of any vendor.

Integrix

1200 Lawrence Drive, Suite 150 Newbury Park, California 91230
Phone: 800 300-8288
Email: sales@integrix.com

Integrix sell Sbus cards along with a 9.4" 640x480 flat panel display which can be connected to a SPARC20. They also sell digital frame buffers which will drive Sharp and NEC flat panel displays.

Vigra

10052 Mesa Ridge Court, San Diego, California 92121
Phone: 619 597-7080

Vigra also sell SBus cards which will drive Sharp and NEC flat panels.

RasterOps

Phone:

RasterOps sell a 640x480 SBus frame buffer designed to connect to a standard PC monitor.

Edited and maintained by David.Tong@eng.sun.com SunSoft CTE - Solaris User Environment.