Frame Buffer FAQ

If the PROM Information indicates or greater then the board is capable of supporting 1600x1200x75.

However the current version of the ffbconfig utility does not recognise this as a valid resolution;

 
# ffbconfig -res 1600x1200x75
ffbconfig: Invalid value for -res option: 1600x1200x75

Note: In 1600x1200 mode the Creator 3D will only operate in single buffered mode.

What's the bottom line on 1280 x 1024 on the SX?

1280x1024x76

setenv output-device=screen:r1280x1024x76m

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. This was fixed for 2.5 - see Bug ID 1187375. For earlier releases you must set the resolution in the EEPROM.

24 bits at 1280x1024

Well, the main problem is that we need to provide 8 bit and 24 bit windows side by side. The most reasonable way of doing this is to have control plane(s) that identify a pixel as being 8 or 24 bits. This means you need at least 25 bits per pixel. Now 1280 x 1024 x 25 is exactly 4Mb, which leaves no space at all for any other overhead, such as lookup tables.

How do I start OpenWindows in a dual-headed configuration?

The component that controls the screen is the X server, Xsun. This is started automatically when you invoke openwin. Openwin will pass flags and options down to Xsun to tell it how to configure the displays. The flags needed are detailed in the Xsun manual page.

Take as an example a machine which has two GX's installed. Looking in /dev you should see the following:

• /dev/fb is a symbolic link to the frame buffer entry in the dev ices directory: /devices/sbus@1,f8000000/cgsix@1,0:cgsix0.
• /dev/fb0 and /dev/fb1 are links to entries in the directory /dev/fbs, in this case /dev/fbs/cgsix0 and < CODE>/dev/fbs/cgsix1.

    openwin -dev /dev/fb0 -dev /dev/fb1

    openwin -dev /dev/fb0 -dev /dev/fb1 left
    openwin -dev /dev/fb1 -dev /dev/fb0

The keyword tells the server where to position the current display relative to the previous one, so any keyword placed after the first device is ignored. If no keyword is given, the default is right. Thus the command:

    openwin -dev /dev/fb0 top -dev /dev/fb1

    openwin -dev /dev/fb0 -dev /dev/fb1 bottom

How do I change the default configuration for CDE?

The easiest way to configure your system is to use fbconf, the Frame Buffer configuration utility available for download from this site. This requires Java; if you don't have it then you may need to do it manually.

You will need to be root to execute these commands.

# mkdir -p /etc/dt/config
# cp /usr/dt/config/Xconfig /etc/dt/config/Xconfig
# cp /usr/dt/config/Xservers /etc/dt/config/Xservers

Dtlogin.servers:               Xservers

Dtlogin.servers:	/etc/dt/config/Xservers

:0	Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner

 0   Local local_uid@console root /usr/openwin/bin/Xsun -dev /dev/fbs/ffb1 defdepth 24 defclass TrueColor right -dev /dev/fbs/ffb0 defdepth 8 defclass PseudoColor left 

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

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

# eeprom output-device=screen:r1280x1024x76

ok setenv output-device screen:r1280x1024x76
ok reset

 /usr/kvm/leoconfig -m 1280_67 

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

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

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

Note to Solaris 2.3 users: Because of Bug 1119523 you need a patched version of both the cgfourteen driver and the cg14config program. The driver is available as part of patch 101318 (the kernel jumbo patch) but at the time of writing the modified cg14config doesn't seem to be available as part of any patch. The bug is fixed in Solaris 2.4

I have copies of the binaries available. Note that this is NOT AN OFFICIAL PATCH! To download, select the Load to local disk option, then click here for cg14config, cgfourteen and a script written by Antoine Garric to automatically set the resolution at boot time.

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 script is modified from one in Sun document No: 802-5011-10 Platform Notes: SMCC Frame Buffers, available in the Answerbook volume Solaris 2.5 on Sun Hardware - search for the string "TurboGXplus Frame Buffer". To download a PostScript copy of the document (1.75M) click here.

#!/bin/sh
# Configure the entries for "cgsix@0" and "cgsix@1"
# to refer to each of your frame buffers.

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

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 SS20/SX or Ultra Creator with an additional TGX+, you may wish to set the resolution of the TGX+ while maintaining the SX or FFB as the console.

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

#!/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

Here is the appropriate voodoo for several supported resolutions. Note also that this will only work for the TGX or TGX+.

1024 x  768 at 60 Hz   64125000,48286,60,16,128,160,1024,2,6,29,768,COLOR
1024 x  768 at 70 Hz   74250000,56593,70,16,136,136,1024,2,6,32,768,COLOR
1024 x  768 at 77 Hz   84375000,62040,77,32,128,176,1024,2,4,31,768,COLOR
1152 x  900 at 66 Hz   94500000,61845,66,40,128,208,1152,2,4,31,900,COLOR
1152 x  900 at 76 Hz   108000000,71808,76,32,128,192,1152,2,4,31,900,COLOR,0OFFSET
1280 x 1024 at 67 Hz   117000000,71691,67,16,112,224,1280,2,8,33,1024,COLOR,0OFFSET
1280 x 1024 at 76 Hz   135000000,81128,76,32,64,288,1280,2,8,32,1024,COLOR,0OFFSET
1600 x 1280 at 76 Hz   216000000,101890,76,24,216,280,1600,2,8,50,1280,COLOR,0OFFSET

117000000       Pixel frequency or dot clock    (in Hz)
71691           Horizontal frequency            (in Hz)
67              Vertical frequency              (in Hz)
16              Horizontal Front Porch          (in pixels)
112             Horizontal Sync Width           (in pixels)
224             Horizontal Back Porch           (in pixels )
1280            Horizontal Displayed pixels     (in pixels)
2               Vertical Front Porch            (in lines)
8               Vertical Sync Width             (in lines)
33              Vertical Back Porch             (in lines)
1024            Vertical Displayed lines        (in lines)
COLOR           Color monitor flag
0OFFSET         No sync pedestal flag

So, given that I can control all the parameters, can I program the TGX/TGX+ with an arbitrary resolution?

108.0   # pixel clock in MHz
48      # horiz front porch in pixels
112     # horiz sync width in pixels
248     # horiz back porch in pixels
1280    # horizontal visible in pixels
1576    # horiz sync width during vertical sync in pixels
1       # vertical front porch in lines
3       # vertical sync in lines
38      # vertical back porch in lines
1024    # vertical visible in lines

Horiz freq = 1/(Horiz Time)
           = (Pixel Clock) / (Horizontal pixel count)
           = (Pixel Clock) / (Pixels + both porches + sync width)
           = 108.0MHz / (1280 + 48 + 112 + 248)
           = 63.98KHz

How do I find what frame buffers I have available?

cgthree Boring old unaccelerated cgthree. May also be a symlink to a more sophisticated device that is masquerading as a cgthree for backward compatibility.
cgsix GX family. See below.
cgtwelve GS. Older 24 bit frame buffer
cgfourteen SX. Newer, on-board 24 bit frame buffer
There are others, such as the cgeight, but they are by and large obsolete.

The exceptions to this rule are:
bwtwo the old monochrome buffer. Found in Sun3s, SLC, ELC, IPC and also available as an SBus card.
leo the ZX or Turbo ZX 24 bit accelerated 3D graphics card. It's not possible to tell the ZX and Turbo ZX apart from software.
gt and gt0 the GT - Graphics Tower. Very old, slow 3D graphics pipeline.
tcx Can refer to the S24 24 bit frame buffer which runs on a SS5 or the 8 bit frame buffer on a SS4.

Another option is to use fbinfo, the Frame Buffer Info script. This uses the prtconf program to interrogate the system configuration. It displays information about all the frame buffers that the system knows about.

A third option is to interrogate the frame buffer using IOCTL calls.
WARNING! This is not recommended for several reasons:

• Any application that needs to know what kind of framebuffer it is running on is very likely broken, or will break in the future when new framebuffers come out.
• Not all ioctls defined in fbio.h are implemented for all sun framebuffers. Programs which call these should act as gracefully as possible when they fail.

How do I work out if I have a GX, GX+, TGX or TGX+?

 dmesg | grep cg

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

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+.

What are the restrictions on multi-headed machines?

I've recently heard from Rich Pedano who has configured a system using a SparcStation 20 with six TGX+ boards. This was accomplished using an SBus expansion unit. He was even able to get 8 heads running successfully. He reported that the system worked fine with all heads configured at 1152x900, but not at 1280x1024. The system used XbigX to manage the screen as a single unit.

(For SUN internal users, Rich has published some information on his web page.)

The latest news (Feb 98) is that SMCC are planning to support up to 8 (eight) Elite 3D (AFB) frame buffers in the Ex000 series.

SparcStation 5

SparcStation 10

SparcStation 20

According to Ken Won the limitation is due to "capacitance loading issues". Some (un-named) SBus cards have a high capacitance rating, which - in conjunction with 3 TGX/TGX+ cards - can overload the bus. 4 TGX/TGX+ cards should not cause a problem, but if 3 are used the 4th slot should be left vacant.

As far as I am aware there are no other limits on the number of heads that are supported beyond the number of SBus slots. Thus supported 5 headed configurations are obtained by using additional SX and GX frame buffers (up to 2 TGX/TGX+ with up to 2 SX and up to 4 GX) For the SX, the first SX head simply requires a 4Mb or 8Mb VSIMM. The second SX head requires a VSIMM and an auxiliary video board, 501-2488 that takes the place of one SBus card.

Ultra 1 and 2

Ultra 5

Ultra 5 and 10

TechSource contacted me to confirm that they support multi-headed configurations on the Ultra 5 and 10 using their Raptor GFX cards.

Ultra 30 and 60

Ultra 150

Ultra 450

Only the Elite 3D m6 is supported in the Ultra 450 - you can have up to two of them. The FFB series is NOT supported.

High End Servers

Up to 4 Frame Buffers are supported in a SS1000 or Ex000. Only one Frame Buffer is supported in the SS2000. The Starfire E10K doesn't support any - it's all done via the SSP.

These configurations have been tested and are supported by Sun. It would be possible to create configurations with more frame buffers and there is no obvious reason why these configurations would not work. In fact, given the success reported with the SBus expander box (above) I would be very surprised indeed if it did not work. I would be grateful for any feedback from customers who have tried this.

ZX and Turbo ZX

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.

Can I drag a window from one screen to another?

A third-party product called X/bigX is available from X/software. It combines multiple screens to form a larger display area.

There is also a free product called Xmove, which lets you move windows from one display to another, but not drag them. Xmove is available from ftp.cs.columbia.edu.

What resolutions do the various frame buffers support?

FFB (AKA Creator)

The values will vary according to the card and driver in use. To set the resolution, run the ffbconfig program and restart OpenWindows or CDE. You do not need to reboot.

In November 1998 Sun announced an update to the Creator and Creator3D series 3 with a new PROM. This new prom added several resolutions including 1600x1200x75Hz (for Creator3D) which now fully supports all resolutions available on the Sun 21" display.

Resolution       	Refresh Rate   
-----------      	------------   
New Creator3D Series 3 resolutions with New Prom -06 (as of Nov 98)
1600 x 1200		75Hz (VESA)  (Single Buffered)

New Creator & Creator3D Series 3 resolutions with New Prom -06 (as of 
Nov 98)
1280 x 1024		60Hz, 75Hz, 85Hz (VESA)
1024 x 768		60Hz, 75Hz (VESA)
800 x 600		75Hz (VESA)
640 x 480		60Hz (VESA)

(Creator3D Series 3 only - in Single Buffered Mode)
1920 x 1200		70Hz
1920 x 1080		72Hz		
1600 x 1280		76Hz
1600 x 1000		66Hz, 76Hz
1440 x 900  		76Hz		

(Creator3D or Creator Series 3)						
1280 x 1024		67Hz, 76Hz					
1152 x 900		66Hz, 76Hz	
1024 x 768		60Hz, 63Hz, 70Hz, 77Hz	
1024 x 800		84Hz, 72Hz, 60Hz, 56Hz	
960 x 680		112Hz Stereo, 108Hz Stereo		
768 x 575		50Hz PAL		
640 x 480		60Hz, NTSC		

PGX

It supports a very wide range of resolutions and can only be configured using the utility m64config, not using the boot NVRAM. Obviously having this software-configurable in this way means that support for resolutions can be added (or removed) very easily. At the last count, m64config reported the following supported resolutions:

 640 x  480 @ 60   640 x  480 @ 67   640 x  480 @ 72   640 x  480 @ 75      
 720 x  400 @ 70   720 x  400 @ 88      
 800 x  600 @ 56   800 x  600 @ 60   800 x  600 @ 72   800 x  600 @ 75      
 832 x  624 @ 75      
1024 x  768 @ 87  1024 x  768 @ 60  1024 x  768 @ 70  1024 x  768 @ 75     
1152 x  870 @ 75     
1152 x  900 @ 66  1152 x  900 @ 76     
1280 x  800 @ 76     
1280 x 1024 @ 60  1280 x 1024 @ 67  1280 x 1024 @ 75  1280 x 1024 @ 76
1440 x  900 @ 76     
1600 x 1280 @ 76    
1600 x 1000 @ 66  1600 x 1000 @ 76    
1920 x 1080 @ 72  
1920 x 1200 @ 70    

Stereo:            960 x  680 @112   960 x  680 @108    
Interlaced:        640 x  480 @ 60   
				   768 x  575 @ 50     

PGX24

Resolution       Sync format      Color Depth
-----------      -----------      ----------
640x480x60       separate         8 or 24
800x600x75       separate         8 or 24
1024x768x60      separate         8 or 24
1024x768x70      separate         8 or 24
1024x768x75      separate         8 or 24
1024x768x77      composite        8 or 24
1024x800x84      composite        8 or 24
1152x900x66      composite        8 or 24
1152x900x76      composite        8 or 24
1280x800x76      composite        8
1280x1024x60     separate         8
1280x1024x67     composite        8
1280x1024x76     composite        8
1280x1024x75     separate         8
1280x1024x85     separate         8

These are supported resolutions. For ways to customise other resolutions see the note in Question 2.

Turbo GX

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

Turbo GXplus

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

CG3

1024 x  768 @ 77
1152 x  900 @ 66	1152 x  900 @ 76

Furthermore there is another CG3 board, 501-2691 which only supports 1024x768 @ 77Hz - it does not support 1152x900. This board is only supported in the SparcStation 5.

The on-board frame buffer in the SparcClassic is also a CG3. It supports all the resolutions listed above.

GX

1022 x 1000 @ 76			IPX only
1024 x  800 @ 85			IPX only
1024 x  768 @ 77			LX only
1152 x  900 @ 66  1152 x  900 @ 76
1280 x 1024 @ 67  1280 x 1024 @ 76	LX with 1Mb VSIMM only
1600 x 1280 @ 76			LX with 1Mb VSIMM only

The on-board frame buffers in the IPX and LX are also GX. Each supports additional resolutions, as noted above.

GXplus

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

GS (CG12)

1152 x  900 @ 76

GT

1280 x  1024 @ 67	1280 x  1024 @ 76 Default

ZX (Leo)

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

TCX

The supported resolutions for the SS4 are:

1024 x  768 @ 66  1024 x  768 @ 76
1152 x  900 @ 66  1152 x  900 @ 76
1280 x 1024 @ 66  1280 x 1024 @ 76

For 1152x 900@66 use 1152x900x94
For 1152x 900@76 use 1152x900x108
For 1280x1024@66 use 1280x1024x117
For 1280x1024@76 use 1280x1024x135

S24

SX (CG14)

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

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

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

or

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

(2) 1024x768, 1024x800, 1600x1280 and 1920x1080 are available but are unsupported. There is conflicting documentation on the subject. Although some of these are listed in the FE Handbook as supported there are a number of documents which state that they are not. One customer has reported that he was running an 8Mb SX clone at 1600x1280@66HZ on a Hitachi Accuvue UX6821, and in 24 bit mode he noticed pixels "flickering" or "shimmering" when using some of the CDE backgrounds or viewing certain images.

(3) The cg14config 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, for reasons unknown. Any information would be appreciated.

Voyager

The colour display has a resolution of 1024x768 and is manufactured by Sharp.

What is the default resolution for each frame buffer?

NB: See below for how the FFB2/2+ and PGX determine their default resolution.

FRAMEBUFFER DEFAULT RESOLUTIONS BY SENSE CODE

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

(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

(13w3 pin 7).

Code	Creator	and Creator3D
-----------------------------
7	1152x900x66
6	1152x900x76
5	1024x768x60
4	1280x1024 (6)
3	1152x900x66
2	1280x1024x76
1	1152x900x66
0	1024x768x77

How do I change the console frame buffer?

SBus devices

• install the preferred device in a lower-numbered SBus slot, or
  
• redefine the value of the sbus-probe-list variable.

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:

• make a devalias for the intended device
  
• set the output-device configuration parameter to refer to that devalias
  
• set the use-nvramrc? configuration parameter to true

	ok  show-sbus

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

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

UPA and PCI Devices

For UPA devices they will be at the top level, eg /SUNWffb@1d,0 or /SUNWafb@1e,0. For PCI devices you'll need to cd through the device tree.

Will 4.1.3 run on a SS20/SX or SS4/TCX?

SS20/SX

SS4/TCX

SS5/S24

Theoretically you might be able to get it to behave as a cg8 instead of a cgthree, which would provide 24 bit visuals, but this has never been tested and obviously is unsupportable.

There is a known bug in the cg3 emulation. Apparently a real cg3 also emulates a cg4 for the benefit of old statically-linked software. Although the TCX and S24 emulate a cg3, they do not emulate a cg3 emulating a cg4.

The standard MIT X11R5 and R6 do not have support for the TCX or S24 frame buffers. As a workaround, I am told that you can create a symbolic link from /dev/cgthree0 to /dev/tcx0 but this is of course unsupported. Note that Solaris 2.6 is based on X11R6, and does have support.

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

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 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
There is a bug logged, reference number 1168007 which highlights colormap problems when this visual is used. In brief, areas that should be white appear black, notably the background of shelltool and cmdtool windows. As a workaround, use the option -whitepixel 1 thus:

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

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

For some versions of the Creator/Creator 3D you may find that the default 24 bit TrueColor visual is gamma corrected. If you want the uncorrected visual you may need to explicitly select the visual by its ID - some applications (for example the image viewer XV) allow you to specify the visual on the command line, thus:

% xv -visual 0x3e

How can I display the same tool on multiple windows?

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

A ReadMe for XMX V1.0 is available.

Can I replace the monitor with an LCD display?

These days cheaper LCD displays are becoming common and Sun's FFB, AFB and PGX product lines are becoming increasingly "PC Compatible" by supporting VESA standard timings and both composite and seperate sync. Bottom line: it depends a lot on the age of your hardware. Try it and see. If you need to connect an older LCD display to an older system you may need to purchase additional third-party hardware. Which leads us neatly to:

What special purpose products 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.

Quantum 3D (formerly Southland Media Systems)

Integrix

Integrix sell various SBus cards including the S20 series that will display at 640x480 at 60 or 72Hz. They have a 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.

VisiCom

In Europe: Worting House, Basingstoke, Hants, RG23 8PY UK
Tel: +44 1256 330030
Fax: +44 1256 816978
Vigra and RasterFlex are both now owned by VisiCom. The RasterFlex and Vigra product line names have been retained. The RasterOps product was not acquired by VisiCom and is no longer available.

PixelVision

PixelVision produce LCD displays capable of up to 1280x1024 @ 76Hz, that can be driven from Sun's frame buffers.

RDI Computer Corp

RDI produce a 12" 1024x768 LCD monitor which can be driven by Sun's frame buffers.

Tech Source Inc.

TechSource manufacture a number of Sparc compatible graphics cards.
The Raptor GFX range are SunReady 8 or 24 bit PCI cards for the Ultra range, with resolutions up to 1920x1200.
The STARS 2K range are PCI cards that provide 2048 x 2048 resolution (check http://www.sun.com/pci/pci.cards.ihv.html for the latest information on whether this product has been verified by Sun)
The GXTRA range are 8 bit SBus cards providing 2D acceleration and 8 bit overlays.

ViewSonic

ViewSonic say they have tested some of their monitors, model numbers 21PS, 17PS and 20G with the TGX+ at 1600x1280 resolution. They believe that models PT810 and PT770 should also work. A SW1152 adaptor is needed, costing $15.

Ultra Spec Cables

Ultra Spec manufacture a range of cables, including monitor cables and PC to 13W3 adaptors.

Photon

Mirage

Software Integrators Inc.

Photon, Mirage and Software Integrators all manufacturers graphics cards which allow Sun and other fixed-frequency workstation monitors to run on a PC.

Parallax

You need a hack to run the framebuffer on solaris 2.6 (docmented on the web site) and I've heard the same hack works on solaris 7. (32 bit)

(Thanks to Bob Larson for this update)

Extron

RGB

StereoGraphics

For the FFB2/2+ the cable+emitter is StereoGraphics part number ESUN. For just the cable to hook FFB2/2+ to your existing emitter this is StereoGraphics part number 69967. The glasses are part number CE2.

Incidentally, StereoGraphics made prototypes of lower cost glasses that have a wire that connects to the framebuffer (no cordless IR transmission). It is unclear if this ever made it into production.

Dome Imaging Systems

Why does the Xsun server appear to be so large?

The "ps" command shows the Xsun server process to be very large on some systems, particularly those using the Creator 3D. Users may think that they are seeing performance degradation, and consider the problem a bug. In most cases there is NOT a problem.

What is happening is that ps is showing the sum of the mapped parts of the process's address space, and this does not have to correspond to either real memory, or to allocated swap space. That is what ps does - it tells you about a particular process.

Access to many devices is often memory-mapped into the address space of a process. This is a common technique, and means that applications need not know the details of the device, instead they just do what they consider to be regular memory writes.

A process has a virtual address space, and cannot write into "real" memory at all - instead the kernel intercepts all such requests and handles them together with the MMU. This phenonmenon is not new, nor specific to framebuffers. The cgsix, the mouse, the keyboard, are all mapped in the same way, but the amount of address space mapped for these devices is smaller and so is less noticeable.

For a better idea of what is happening, find the PID of the Xsun process and run the command /usr/proc/bin/pmap [PID] > /tmp/pmap. (It's important to redirect the output to a file or you could lock up your system in a deadly embrace.) View the file created and you will see something like this:

00010000    616K read/exec         /usr/openwin/bin/Xsun
000B8000     32K read/write/exec   /usr/openwin/bin/Xsun
000C0000  15656K read/write/exec     [ heap ]

Further down you may find a line like this:

F6800000 114704K read/write

NB: If you run your server in 24 bit mode then it WILL use more swap than in 8 bit mode. In such circumstances you may see unavoidable paging until you add more memory to compensate for your increased demands.

Can I use a Sun monitor with my PC?

SunExpress have such an adaptor, part number 530-2357-01. This has been tested with the following monitors in both DOS and Windows modes:

• 365-1335 New Multisync 20" Premium monitor
• 365-1338 New Multisync 17" Premium monitor
• 365-1343 New Multisync 17" Entry Level monitor

Ultra's catalog states that the 1396 is for use with three monitors; these are part numbers 365-1286, 365-1316 and 365-1324. These are all Sony monitors with the remote control, however this style of monitor also carries several other part numbers, such as 365-1330 and 365-1167; Ultra have not claimed to support these monitors.

These monitors support Windows hi-res drivers only. They do not work in DOS mode which is something like 640x480@60Hz. (According to Ben Myers this is actually the very old CGA mode 3, defined as 80 characters wide x 25 lines high, with vertical scan not too well defined. But most graphics cards, VGA and beyond, use 60Hz.) The monitors will not sync so low. The editor has tried using a 365-1324 in 1024x768 and 1280x1024 mode with a S3 chipset PCI video card without success, but has heard positive reports from other users.

One user reported that it was possible to use a 17" Sony GDM17E10 monitor; he used a standard 13W3 to HD15 cable with a small piece of wire inserted into the HD15 to short pins 13 and 14 - this provided the necessary sync signals. If you wish to use any other Sun monitor with a PC there are third party PCI/ISA card available. These work with windows but require drivers for DOS (that ship with them). Consult your favourite WWW search engine or check Photon, Mirage or Software Integrators in the 3rd party vendors list.

For an introduction to the issues of using fixed frequency monitors on PCs, consult the sci.electronics.repair FAQ maintained by Samuel M. Goldwasser.

What frame buffers are/are not supported in the Ultra machines?

Frame Buffers Not Supported in Ultra Series Systems:
GS, GT, GT2 (sbus adaptor card), GX, GX+, ZX2 (TZX)

8 bit frame buffers

24 bit frame buffers

As of October 1996, the ZX frame buffer will be supported in Ultra 1 and Ultra 2 machines. This is primarily intended to allow customers who are upgrading from older sun4m machines to keep the ZX; it is highly unlikely that new Ultra systems will be sold with ZXs.

The ZX is not a low cost alternative to the Creator; on the contrary, ZX is a much more expensive graphics option than the Creator graphics and has less than half the Creator graphics 3D performance and none of its image processing and video playback capabilities. Customers should be encouraged to upgrade to Creator graphics if at all possible.

In order to install the ZX in an Ultra 1 system you will need the ZX Ultra 1 Kit part #595-4072. This includes a flexible power cable that goes from the bottom SBus connector on the ZX to the lower SBus slot in the Ultra 1. There is also a ferrite cable clamp that needs to be placed at the end of cables plugging into the stereo port in order to pass FCC Class B certification.

(The ZX kit is not required in Ultra 2 systems as Ultra 2 has side by side SBus slots and passes FCC Class B without the ferrite connector.)

Note that the Turbo ZX will not be supported in either Ultra 1 or Ultra 2 systems, since it requires additional power and cooling.

Why are 24 bit Frame Buffers so expensive compared to a PC?

How do I change the resolution on the SparcStation 4?

As noted above, the timing parameters are different for the TCX. Here's an example of how to set the resolution to 1152x900 on the entry level monitor. Halt the machine and type:

    ok> setenv output-device screen:r1152x900x94
    ok> setenv fcode-debug? true
    ok> reset

#!/bin/sh
#
#
#
/usr/sbin/eeprom nvramrc='devalias hightcx /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@2,800000:r1280x1024x135
probe-sbus
" /iommu/sbus/cgsix@0" select-dev
r1280x1024x76
" /iommu/sbus/cgsix@0" " set-resolution" execute-device-method drop
device-end
install-console
banner
'
/usr/sbin/eeprom output-device=hightcx

How can I tell whether I have the 4Mb or 8Mb SX VSIMM installed?

The easy way is to take the lid off - if the VSIMM has chips on both sides then it's 8Mb, if the chips are on one side only it's 4Mb.

However if you can't take the lid off you have more of a problem. dmesg, sxconfig and cg14config don't tell you anything useful about the VSIMM. The only way to get this information is to analyse the output from prtconf, thus:

% prtconf -vp
. . .
            reg:  00000002.00000000.00010000.00000004.00000000.00400000
            device_type:  'display'
            name:  'cgfourteen'
. . .

What is different about the "new" TGX and TGX+?

The "old" TGX had the part number 501-2325; the new one has the part number 501-2922. The only difference between them is that the packaging of the ASIC has changed from Ceramic PGA to Plastic BGA. There is no logic or performance change and it uses the same PROM which reports the old part and chip rev numbers.

Similarly, the old TGX+ had part number 501-2253, while the new one has part number 501-2955. Once again, only the packaging of the chips - in this case both the ASIC and the RAMDAC - has changed.

The only way to tell the difference is to visually inspect the boards. The new style has a smaller sleeker green and black package; the older style is the obvious purple-brown ceramic square.

These changes provide a significant cost reduction without impacting quality.

What set of resolutions do the FFB series support?

Can the FFB1 be used with the 24" HDTV monitor?

What resolutions does the FFB2/2+ support with the 24" HDTV monitor?

	1920 x 1200 single-buffered
	1600 x 1000 single-buffered
	1440 x  900 single-buffered
	1280 x  800 single-buffered or double-buffered

The two display buffers can be combined to give 10Mb to use as a single display buffer. However the Z buffer memory cannot be combined in this way, which is why you can't have double buffering at higher resolutions.

Be aware that the 24" monitor uses the same sense code as the regular 20"/21" monitors. (Sense codes use just 3 bits, and there are no unused combinations left.) Consequently the system may be unable to determine whether a specified resolution is supported by the monitor. If you are unsure as to whether the resolution you need is supported, use the "try" parameter to ffbconfig.

More information on this subject is available on the Sun Internal Only FAQ.

What set of visuals does the FFB support?

It also supports a complex set of 8 and 24 bit overlays/underlays, and both linear and nonlinear gamma correction. More information is needed.

I'm confused by all these Creator boards. What's the story, Morning Glory?

The Series 2 has a 50% performance speedup and supports 1920x1200 in single buffer mode, YCC->BGR conversion and OpenGL depth cueing.

The Series 3 has programmable gamma correction, has multiple hardware colormaps and management software and has hardware stencil support.

Graphics part number and system support matrix.

There are two speeds of Creator 3D Series 1. Which one do I need?

Can I run two different window managers together on a dual headed machine?

Yes, it is possible to run a different window manager on each display. The most common combination is to have CDE and OpenWindows side-by-side, thus achieving the best of both worlds. To do this, you must first set the resource Dtwm*multiScreen to False in your .Xdefaults file. You then add the following line to the file $HOME/.dt/sessions/sessionetc

	/usr/openwin/bin/olwm -single -display :0.1 &

There is a drawback to this; attempting to change some of the properties using the Style Manager can cause the server to die.

How can I capture the video output from a frame buffer?

If your TV/VCR has a SCART connector (common enough in Europe, but very rare in North America) then it is fairly easy to make a cable to accomplish this. There is a web page at http://www.sm.go.dlr.de/~bob/scart/scart.html that gives instructions on how to do this; it is written in German, but is not difficult to understand. There is also a GIF image that shows the wiring.

Other Sun frame buffers do not support PAL or NTSC resolutions, so a converter of some kind is required. SunExpress sells the "HyperConverter-1280" (PCV-HYPER-1280) - contact them on 1 800 USE SUNX. Extron and RGB also market a range of scan converters and "trans converters".

As far as 3rd party video cards go, the Parallax XVideo product seems to be well regarded.

Can I drive a TV from any of the frame buffers?

The latest generation of FFB and PGX frame buffers support both composite and seperate sync, so may work with these devices. Older frame buffers will require scan converters.

Why does the ZX console not sync correctly after using Stereo mode?

This is due to the prom thinking the machine is in stereo mode (the prom draws the console mode text) and the machine really being in standard mode.

When you leoconfig the machine into stereo mode, the prom can detect the change from normal->stereo. However it does not detect the change from stereo->normal. The kernel always know what is going on, which is why OpenWindows comes up correctly regardless.

The solution is to keep the machine in stereo mode or to re-boot.

The root cause is that there is inadequate communication of this information to the prom. ZX has implemented this one way, FFB another, and other framebuffers do yet other ways. TGX by the way avoids the whole problem by not providing a config program! Our engineering is proposing a mechanism from kernel to prom; still it will be a long time before our whole product line deals with this.

As an aside, Windows avoids all this because "console mode" is always VGA. When the BIOS has to write something it knows to switch the screen to VGA mode.

How can I write to the frame buffer directly?

The supplementary question here is:

Why aren't programming docs for Sun frame buffers at least available on a NDA basis?

What is gamma correction?

In simple terms, normal CRT monitors do not have a linear relationship between input voltage and output brightness. Consequently there is not a linear relationship between RGB values and the brightness of the colour on the screen. There are simple ways to demonstrate this in the references cited above.

Most 24 bit frame buffers provide a means to apply gamma correction. For the SX or ZX it is done by giving a -g flag to the appropriate configuration program, whereas on the FFB there is a seperate gamma corrected TrueColor visual, used by toolkits such as XGL and OpenGL.

The latter poses a problem in itself; since the same RGB value produces two completely different colours in different visuals, how can tools such as snapshot and imagetool know what the "correct" value is?

If your application has an image that you wish to apply gamma correction to, here is a simple algorithm to create a lookup table:

short gamma_table[256];

void create_gamma_table(gamma_factor)
double gamma_factor;
{
    int i;
    double new;

    for (i = 0; i < 256; i++) {
        new = 255.0 * pow((i / 255.0), 1.0 / gamma_factor);
        gamma_table[i] = (int) floor (new + 0.5);
    }
}

8 bit case:

	/* Create new colormap */
	xcmap = XCreateColormap(display, win,
        DefaultVisual(display, scrn), AllocNone);

    ycmap = DefaultColormap(display, DefaultScreen(display));

	/* Get all colours in default colormap */
    for (n = 0; n < 256; n++)
        xcolours[n].pixel = (long) n;
    XQueryColors(display, ycmap, &xcolours[0], OFFSET);

	/* Allocate colours in new colormap */
	if (!XAllocColorCells(display, xcmap, TRUE, NULL, 0,
                        pixels, 256))
		printf("Failed to allocate colour map info\n");

	/* NB: Ordering of Red, Green and Blue *IS SIGNIFICANT* */
	i = 0;
    for (n = 0; n < 256; n++) {
        xcolours[n].red = gamma_table[cmap[i++] << 8];
        xcolours[n].blue = gamma_table[cmap[i++] << 8];
        xcolours[n].green = gamma_table[cmap[i++] << 8];
        xcolours[n].flags = DoRed | DoGreen | DoBlue;
    }

	XStoreColors(display, xcmap, &xcolours[0], 256);

24 bit case

    if (ximage->depth == 24) {
        int i, j;
        long pixel;
        int r, g, b;

        for (j = 0; j < ximage->height; j++) {
            for (i = 0; i < ximage->width; i++) {
                pixel = ximage->f.get_pixel(ximage, i, j);
				/* Ordering of r,g,b is not significant */
				/* so long as the order is maintained */
                r = pixel & 0xff;
                g = (pixel >> 8) & 0xff;
                b = (pixel >> 16) & 0xff;
                pixel = gamma_table[r] + (gamma_table[g] << 8)
                                         + (gamma_table[b] << 16);
                ximage->f.put_pixel(xim, i, j, pixel);
            }
        }
    }

What's that little round socket for on the back of the FFB2/2+?

    Quark FFB2/2+                                    Stereo Emitter
7 pin mini-din male                             DB9-S 9 pin female  
                                                        __
   _________                                           |  \
 _|         |                6 FT +/-2"                |   \
| |         |==========================================|    |
|_|   P1    |==========================================|P2  |
  |_________|                                          |   /
                                                       |__/

           CONNECTOR PIN ASSIGNMENT

+===========+===================+==========+
|   signal  |       from P1     |   to P2  |
|           |   7 pin mini-din  |   DB9-S  |
+===========+===================+==========+
|    12V    |         3         |     6    |
+===========+===================+==========+
|    DV     |         1         |     7    |
+===========+===================+==========+
|    SYNC   |         4         |     8    |
+===========+===================+==========+
|    SHIELD |     P1 HOOD       | P2 HOOD  |
+===========+===================+==========+

For just the cable to hook FFB2/2+ to your existing emitter this is StereoGraphics part number 69967. The glasses are part number CE2.

Incidentally, StereoGraphics made prototypes of lower cost glasses that have a wire that connects to the framebuffer (no cordless IR transmission). It is unclear if this ever made it into production.

What's the story on PCI?

The first PCI frame buffer from Sun is the PGX. This is an 8 bit device with features and performance comparable to the TGX. It supports a wide range of resolutions, and is configured using a program called m64config rather than the old prom-value method required by the TGX. Also unlike previous frame buffers it does not use sense codes to determine the resolution.

For full details of PCI cards that are supported in the Ultra 30 series, including graphics and other products, see http://www.sun.com/pci.

So can I take a PCI card from my Sun and plug it in my PC (or vice-versa)?

Having said that, I know of people who have developed basic drivers for PC cards, notably the Matrox Milennium II. And before anyone asks, they are not available for download. Because the card doesn't have OBP (Open Boot Prom) firmware it cannot be used as a console device, only as a second head, and without further information from the manufacturer it isn't possible to enable the advanced acceleration features.

How do the FFB2/2+ and the PGX determine their default resolutions?

This mechanism has now been superceded by a system called DDC (Display Data Channel). DDC is a Vesa standard which allows the frame buffer to read information known as EDID (Extended Display Identification Data) from the monitor. This information includes resolutions supported, max width, max refresh, sync type and so forth.

After reading the EDID upon bootup, the firmware looks at the EDID Standard Timing Identifiers. It compares each value against the list of supported resolutions. If there is a match, that resolution is set and the resolution selection process is complete. If not, this process continues until all of the Standard Timing Identifiers have been tested. At this point a resolution of 1152x900x66 is chosen.

The first Sun monitor to support DDC was the Sony "N2" or GDM 20E20.

Can I use a PC monitor on an Ultra 5 or Ultra 10?

What are the pinouts for the 13W3 connectors?

	  1   2   3   4   5
	  o   o   o   o   o
  (o)                         (o)   (o)
   A1   o   o   o   o   o      A2    A3
	6   7   8   9   10

The following is the configuration for the Creator and Creator 3D and all future Frame Buffers.

	1	SCL			 6	SDA
	2	+5V			 7	Reserved [VSYNCH]
	3	SENSE2			 8	SENSE1
	4	Ground			 9	SENSE0
	5	CSYNCH			10	Ground

Analog RGB is 0V (black) to 0.7V (full intensity) into a 75ohm load. CSYNC is a TTL signal into a 75ohm min, 1K typ load. CSYNC is a negative composite sync. Sync on green is not supported.

Is it possible to run a dual headed configuration under Solaris X86?

What frame buffers are supported/work under Solaris 7?

• ZX
  ZX is unsupported in 2.7. Users have reported mixed results in using drivers from 2.6; some were successful but others could not get it to work.
• MGX+
  [JAN 99] Rumour is that Quantum3D is to sell off the MGX family to a third party. If true, Quantum3D will probably not be providing support for the MGX. Certainly no drivers are available for download at the present time.

Cables and adapters

595-4072 ZX Ultra 1 Kit - the full kit required to install the ZX in an Ultra 1

libnoflash: Eliminate Colormap Flashing

To use, simply set the LD_PRELOAD environmental variable, thus:

    % setenv LD_PRELOAD /(mydir)/libnoflash.so.1

NB: If you are using Java applications this library can cause Java to crash with a segmentation violation. This is related to bug 4028760, but fortunately there's a simple work-around; it does not crash if you also preload the Motif library, thus:

    % setenv LD_PRELOAD "/(mydir)/libnoflash.so.1 /usr/dt/lib/libXm.so.3"

fbinfo: Frame Buffer Information

cgsix@0 is TGX Plus                     1280x1024@67 Monitor type 4
ffb@1e  is FFB 75MHz Double buffered    1280x1024@67

fbconf: Frame Buffer Configuration

Please Note: This is a compressed tar file. Save it as fbconf_tar.Z and extract it by typing zcat fbconf_tar.Z | tar xf -