Frame Buffer FAQ

Last Updated: 10-Feb-00.

Copyright 1994-2000 Sun Microsystems, Inc.

I wrote this FAQ as a public service, because if I didn't it probably
wouldn't get done. If you've found it helpful, I'm pleased.
However my job has changed over the last 6 or so years, and I don't
get much time to maintain it or to answer questions.

I do try to maintain the accuracy of the information.
However no responsibility is taken - either by me or by
Sun Microsystems Inc. - for any inaccuracies, or for any damage that
may occur as a result of applying this information.

Hey! Where did the utilities go?

I moved them into the main body of the FAQ.
Check out fbinfo the Frame Buffer Info script,
fbconf the Frame Buffer configuration utility
and the latest addition libnoflash, a library
to help prevent colormap flashing on 8 bit frame buffers.

In its simplest meaning, and as far as the Graphics hardware
engineers are concerned, a frame buffer is simply that;
the video memory that holds the pixels from which the video
display (frame) is refreshed.

Nowadays with ever-improving manufacturing techniques, the two are
tightly linked on the same board. Since every graphics device
incorporates a frame buffer, but not all have graphics
processors, the term "frame buffer" has become synonymous
(outside Engineering at least) for a graphics device of any type.

It is perhaps better to talk about "dumb" or unaccelerated
frame buffers - devices such as the cgthree, which perform
no real action other than to provide a video signal to a monitor -
and "smart" frame buffers, which include additional hardware and/or
microcode to accelerate 2D and 3D graphics, etc. But once again,
advancement in technology means that dumb frame buffers are the
exception rather than the rule, and hardware acceleration is
taken for granted.

So applying the rule of common usage, today's definition of a
"frame buffer" is a graphics output device that provides
accelerated 2D or 3D graphics, and a "dumb frame buffer" is a
graphics output device that does not provide any acceleration.

As an aside, the PC world tends to refer to graphics devices
as "video cards". In the workstation world, a Video card
implies full-motion video, either in (as with Sun's VideoPix
or SunVideo products) or out (as in Parallax's XVideo products).

Note: This section does not deal with the older VME bus frame buffers.
If you're really interested in all that, take a look in
the museum.

bwtwo

The bwtwo was the monochrome frame buffer found in the old Sun3 machines
(remember those?). It was also available as an SBus card for Sparc machines
up to the SS20. The MG1 (Monochrome Graphics) was capable of driving
a high resolution (1600x1280) display, and looks similar to a cgthree.

cgthree

When this document talks about the cgthree it refers to an un-accelerated
8 bit SBus frame buffer. It is recognisable by a row of 8 SIL chips
(Single In Line) which provide the Video memory
and look rather like a heatsink.

The cgthree was built onto the motherboard of some entry level machines.

cgsix

Sometimes known as LEGO for Low End Graphics Option,
the cgsix family includes the GX, GX+,
TGX and TGX+ boards. These are
accelerated 2D 8 bit frame buffers. They are the reference point for
graphics support, and are supported in all Sparc machines, subject
to some restrictions on size and revision; for example the older GX/GX+
cards are not supported in the newest Ultra hardware.

The early GX boards were double-width, as were the GX+ boards.
To distinguish the two visually, the double-width GX has several
rows (2x16) of SIL chips, whereas the GX+ has convential DIL chips.

The TGX and TGX+ bear a large LSI chip and 8 RAM chips, and have the
names of the design team printed above the SBus connector.
While there have been at least two versions of the TGX,
the chip rev number has not changed. The TGX+ can be distinguished
by the characters TGXA printed next to the 13W3 connector, and by having
a row of 8 very low profile surface-mounted chips down one side,
compared with the larger chips in an L configuration on the TGX and GX.

The TGX/TGX+ are compatible with the GX/GX+ but are faster and support
more resolutions. (The T stands for Turbo).
The GX/TGX have 1Mb of on-board memory, which gives
them a maximum resolution of 1152x900. The GX+/TGX+ have 4Mb of memory,
which is used for double-buffering and optimisation, and has a maximum
supported resolution of 1600x1280. Note that unlike some PC graphics
adaptors this memory CANNOT be used to give more than 8 bit colour.

The SparcStation LX has an on-board GX with a slot for a 1Mb VSIMM.
This optional extra memory can be used to support higher display
resolutions or for double-buffering.

For information on identifying the cgsix from software, see
elsewhere or use fbinfo.

cgtwelve

The cgtwelve is also known as the GS. This is a large card that takes up
3 SBus slots, and thus can only be used in machines that have 3 slots
horizontally, such as SparcStations 1, 1+ and 2. It provides 8 or 24 bit
graphics, but is fairly slow. It is not supported in 2.5 or later.

GT

The Graphics Tower is a 24 bit accelerated 3D graphics system.
The tower itself is a seperate box, which is connected to the
Sun through a single-width SBus interface card. As a console
frame buffer it is unbearably slow. It is not supported in
Solaris 2.5 and beyond, or in newer Sun machines.

Also known as the SX and spam, this is a very different
kind of frame buffer. Built in to the motherboard on the SS20, it is
also available as an add-on card for SS10 and SS20 (only one add-on card
is allowed). For each display a VSIMM is required; two types are available,
4Mb or 8Mb. The 8Mb VSIMM allows a resolution of 1280x1024 at a depth
of 24 bits; the 4Mb VSIMM allows up to 1280x1024 at 8 bits or 1152x900
at 24 bits. (For the reason why see below.)
System memory can be reserved for use by the SX to improve
performance using the command sxconfig.

It is not supported in SunOs 4.x, except as a console.

leo

Also known as the ZX or T(urbo)ZX, this is a 24 bit accelerated 3D
graphics card. Both cards are double-width, but the TZX also requires
extra cooling in the form of an additional double-width fan card,
so effectively takes up 4 SBus slots.

The only way to distinguish the cards is visually; from a software
viewpoint they appear identical - the TZX reports itself as a ZX.

tcx

These frame buffers attach to the AFX bus (an early version of the UPA bus)
rather than the SBus, and are only supported in the SparcStation 4 and 5.
Also known as the S24, the version for the Sparc 5 is a 24 bit frame buffer
and is a removeable card. The version for the Sparc 4 is 8 bits only
and is built onto the motherboard.

FFB family

The FFB was the first 24 bit frame buffer available for the Ultra machines.
Several models exist; the FFB1 is available in single buffered (known as
the Creator) and double buffered (known as the Creator 3D) formats;
additionally the early Creator 3D is available in 66MHz and 75MHz forms.

The FFB2/2+ is also available in single and double buffered configs,
and also in two physical packages, depending on whether it is mounted
horizontally (for SBus based systems) or vertically (for PCI based systems).

The FFB2 and 2+ each incorporate substantial performance improvements
over the earlier models, and the FFB2+ supports multiple hardware
colormaps which effectively cures colour flashing.

PGX family

The first PGX was based on the ATI Rage II chipset and had 2Mb SGRAM.
It was built onto the motherboard of the Ultra 5 and 10,
and is also available as a PCI card. Because of the memory limitation,
and partly due to architecture restrictions, the official device driver
only supported 8 bit graphics at resolutions up to 1280x1024.
If an alternate driver were available the card could theoretically
support 16 bit TrueColor at 1024x768 or 24 bit TrueColor at 800x600.

PGX24

The second generation Ultras 5 and 10 (code-named Darwin Plus)
have a revised version of the PGX based on the ATI Rage Pro chipset.
Known as the PGX24 it has 4Mb of SGRAM memory and supports both seperate
and composite sync formats. When in seperate sync mode they drive the
VESA standard resolutions from 640x480 to 1280x1024.

The card features 2D Graphics Acceleration and supports
8 bit visuals up to 1280x1024x85Hz and 24 bit TrueColor
visuals up to 1152x900x76Hz, but due to the chipset architecture
the card it cannot support both simultaneously.
Thus any legacy applications that require an 8-bit color visual will
be required to run in the 8-bit mode (disabling 24-bit visuals).
Such applications need to be updated to take advantage of 24 bit visuals;
users should contact the software vendor and request a patch.

AFB family

The AFB or Elite 3D series is the current high-end 3D graphics card.
It supports all the features of the Creator 3D and adds such features
as hardware-accelerated lighting.

The problem is that as with the ZX the Elite is geared towards high-end
applications. It's not a frame buffer for the casual user; in most cases
I would prefer the Creator 3D running at 1600x1200 in 24 bit mode.

There is also some confusion as to whether the Elite 3D is supported with
the 24" monitor. The answer is that yes it's supported, but for technical
reasons the best resolution that you can get is 1280x800. Which considering
how much the AFB and the monitor cost isn't a great bang for your buck.
If you have a 24" monitor get a Creator 3D and run 1920x1200 - it looks
magnificent and displays 6 good sized windows simultaneously.

The on-board frame buffer is called the SX.
It's a 24 bit frame buffer, but in order to use it you need
to order the SS20/SX or purchase some video memory.
For details see the section on the
cgfourteen, above.

The advantages of SX over TGX?

The SX can have more video memory - up to 8Mb,
compared to 1Mb on the TGX or 4Mb on the TGX+.
It can display 24 bit TrueColor
The on-board frame buffer does not take up an SBus slot.

The advantages of TGX over SX?

The TGX is supported under 4.x, the SX is not.
Each SX takes up a SIMM slot, which reduces the maximum amount
of system memory possible, but unless you really need to max out your RAM
(and if you do, you should think about upgrading) this isn't a problem.
The TGX has fractionally better performance on some 2D operations,
but by and large there's not much in it. Unless the system is running 4.x
I'd choose the SX. Or, better still, dual headed with the SX *and* a TGX+.

1280x1024x76

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

Elementary mathematics says that a resolution of 1280 x 1024
and a depth of 24 bits per pixel takes 3.75 Mb. So why is it
necessary to get the 8M VSIMM to support this depth?

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.

You will need a machine that has two frame buffers correctly installed,
together with matching monitors. The frame buffers do not need to be
identical; there are several advantages in having each screen
running on entirely different frame buffers.

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

.
To start up a multi headed configuration you must specify each device
you wish to use using the option -dev, thus:

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

The order that you give them is important for two reasons;
display zero machinename:0.0 comes first,
then display one machinename:0.1 and so on.
By default they are ordered left to right; to change the order you can
use the keywords left,
right, top or
bottom.
Thus the commands:

will start up OpenWindows with fb1 on the left and fb0 on the right, but
in the first instance fb0 will be logical screen 0, and in the second
it will be screen 1.

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

will not have the desired effect; you would need to use:

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

Other keywords can be used after the device name to control such things
as default depth or visual; these are discussed in the manual page
and elsewhere in this document.

By default, CDE will usually start up in single headed mode
with an 8 bit default visual. If you want to run your system
multi-headed or with a different default visual then it's a little harder
under CDE than it is under OpenWindows.

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.

Then edit the file /etc/dt/config/Xservers.
The last line should look something like

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

Comment out this line and then create a new version that has the options you want.
The following example is taken from a real machine. The user's left hand screen
is the console at boot time, but he wanted the right hand screen to display the
dtlogin window and the CDE front panel. The right hand screen is display :0.0
and the default visual is 24 bit TrueColor. The left screen is :0.1 and the default
visual is 8 bit PseudoColor. For further details see the man page for Xsun.

For the SX use the command
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:
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.

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

Kinda-sorta. The pixel clock is not a freely configurable parameter -
you can only use certain predefined values. I believe that the list given above is
comprehensive, but cannot guarantee this. Given that limitation it is possible
to program custom resolutions. For example, here are some suggested values for
1280x1024 @60Hz. (NB: To the best of my knowledge this has not been tested or
authorised by anyone at Sun.)

At the risk of starting to sound like a physics textbook,
the Horizontal time is the time taken to draw one row of pixels -
ie the number of pixels drawn divided by the pixel clock.
The Horizontal frequency is the inverse of the horizontal time.
So for this example,

You can usually find out what frame buffers are available by looking
in the directory /dev/fbs, or examining the output from dmesg.
Most frame buffers announce themselves as cgnumber0,
eg cgthree0, cgsix0, cgtwelve0. A digit other than zero indicates
that either a second frame buffer is present or it has been moved
from its original sbus slot.

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

If you still want to go ahead, the approved method is to call VIS_GETIDENTIFIER
to identify framebuffer. If VIS_GETIDENTIFIER fails you have an older framebuffer.
Call FBIOGATTR or FBIOGTYPE and use the type field to identify the framebuffer
using the #defines in fbio.h. Here is a sample program.
Use at your own risk.

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

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.
This is particularly true in the case of the PCI bus; there should be
no reason why you cannot fill every PCI slot (except any PCI66 slots)
with PGX or 3rd party PCI frame buffers.

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

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

Document 801-6186-10 states that
"Due to configuration restraints, a limit of two TGX or TGXplus
SBus cards are permitted in a SPARCstation 20".
Additionally, the document states that double-width GX cards
(which implies, but may not necessarily include the GX+) are not supported.

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

The Ultra 1 can have up to 3 heads. The Ultra 2 can have up to 5.
This has been tested and is fully supported.
The Elite 3D M6 is supported only in the Ultra 2.

Ultra 5

The Ultra 5 can support up to 4 heads - 3 PCI cards and the on-board PGX.
For a 24 bit display you currently need a 3rd party graphics card,
such as the Raptor GFX.

Ultra 5 and 10

The Ultra 10 can support up to 6 heads -
4 PCI cards, one FFB and the on-board PGX.

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

Up to 2 FFBs plus up to 3 PGXs (8-bit PCI graphics cards) are supported.
You could add a 4th PCI graphics card if the card is a 3 volt
('universal') PCI card type. Although Sun do not currently provide
such a card, one may be available from third parties.

Ultra 150

I believe that only one TGX is supported, but it has
3 SBus slots, and can therefore theoretically take up to 3 heads.

Ultra 450

4 PCI graphics cards is the maximum supported configuration.
However there are documented instances of up to 10 PGX32s
(with v1.9 firmware) being successfully stress-tested in an E450.

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

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.

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 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 ZX is not
supported in the SBus expansion unit.

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.

FFB (AKA Creator)

The supported resolutions for FFB can be found by the command
/usr/sbin/ffbconfig -res \?

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.

PGX

The PGX is the first of the new generation PCI frame buffers -
for details on PCI see below.

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:

NB: the PGX only has 2Mb of on-board memory,
so 1920 x 1200 is obviously unattainable.

PGX24

The newer Ultras 5 and 10 (code-named Darwin Plus) have a revised version
of the PGX based on the ATI Rage Pro chipset. Known as the PGX24
it has 4Mb of SGRAM memory and support BOTH seperate and composite sync
formats. When in seperate sync mode they drive the VESA standard resolutions
from 640x480 to 1280x1024. The following chart shows the resolutions and
available colour depths. Note that when in 24 bit mode the PGX24 only
provides a 24 bit visual, so applications that *require* an 8 bit
PseudoColor visual will not work.

ZX (Leo)

TCX

The default resolution for the TCX is 1152x900
unless you are using the 17" entry level monitor,
which defaults to 1024x768.
By adding an optional 1Mb VSIMM to the slot on the motherboard
this can be increased to 1280x1024.

S24

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.

(1)
Cgfourteen will support 1280x1024@76 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(!)

(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 monochrome display has a resolution of 1152x900 and is
manufactured by Hosiden Electronics.

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

(6) Early models of the Creator and Creator3D examined
a 4th sense bit - 13w3 pin 7.
If this bit was 1 (unconnected) then the resolution was set to
1280x1024x67. If the bit was 0 then the resolution
was set to 1280x1024x76.

SBus devices

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:

install the preferred device in a lower-numbered SBus slot, or

redefine the value of the sbus-probe-list variable.

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:

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

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.

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

UPA and PCI Devices

Basically you follow the same steps as for SBus devices -
the trick is finding the full device path.
At the OK prompt you can use cd and ls to navigate the device tree
until you find the devide you want, then set the alias as shown.

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.

SS20/SX

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.1.1
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).

SS4/TCX

Yes, but you don't want to. The TCX frame buffer will appear to the
system to be an unaccelerated frame buffer, similar to a cgthree.
To get the benefit of the accelerated graphics you wil need to run
Solaris 2.4 or later.

SS5/S24

Yes, but you really don't want to.
As with the SS4, the S24 frame buffer will appear to the
system to be an unaccelerated cgthree.
That means no accelerated graphics plus no 24 bit visuals.

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.

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:

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:

If the screen appears pale and washed out, or too dark, you may wish
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.

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

Use the command xdpyinfo to find the various visual IDs that
your system supports.

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:

Early LCD panels had much stricter timing than CRTs.
They often required a digital interface; the analog
outputs from Sun's frame buffers probably wouldn't work.
In addition, many were designed to be driven by PC
frame buffers which use very different timings and sync,
and therefore could not be used with most of SUN's products.

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:

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.

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.

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

StereoGraphics sell Stereo (3D) viewing equipment for use with
the FFB (1 & 2) and ZX. The system comes in 3 pieces: glasses,
an IR emitter box, and a cable to hook up to the frame buffer.

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.

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:

In this case the heap is around 15MB; this is were memory leaks occur.

Further down you may find a line like this:

F6800000 114704K read/write

This means that the Creator 3D has mapped about 100Mb of virtual address space.
It is not using actual memory (either physical or virtual), just address space.

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.

Newer Sun monitors have multiscan capability which allow them
to be used with PC graphics cards. The latest monitors [Mid-1998],
including the 24" [T-Rex], 21" [Hurricane] and 19" [Cyclone]
have dual inputs and accept both 13W3 (SUN) and HD15 (PC) type connections.
Some older monitors, notably the 17" and 20" N2 monitors will work,
but require a 13W3 to HD15 adaptor.

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 Spec Cables manufacture two different adaptors.
The part numbers are 1396 and 1397; the
catalog lists them as 13W3 Female to HD15 Male converters.
The 1397 is identical to the one sold by
SunExpress,
and works with the same monitors.

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.

Not listed above, but also unsupported, are the CG3 and the SX expander card.

8 bit frame buffers

The TGX and TGX+ are definitely supported in the Ultra series, and are
the preferred solution for multi headed machines.

24 bit frame buffers

The preferred option for 24 bit graphics on Ultra is the FFB.
If users need a second 24 bit display they should look at the
Rasterflex-32 card, which is available
through SunExpress
or from VisiCom.

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.

An often-heard complaint is "Why can't Sun sell a 24 bit
frame buffer for $200 like I can get for my PC?".
Regular viewers will remember that this section of the document
had a detailed explanation of why this wasn't a fair comparison.
However Sun's announcement of support for PCI bus architecture
should change all that. It will now be possible for manufacturers
to release Sun versions of their graphics products.
Whether this boost to competition in the marketplace will result
in a $200 24 bit frame buffer remains to be seen.

The SparcStation 4 with the 17" entry level monitor has a default
screen resolution of 1024x768. Both the monitor and the frame buffer
will support 1152x900. With an additional VSIMM the TCX will support
1280x1024, but I'm not certain that the monitor will.

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:

I've been advised that the SX VSIMMs look very similar to the PrestoServe SIMMs.
The VSIMM has a surface-mounted chip with very fine pins and should have a protective
plastic cover cvlipped over it; the latter has a small battery on it, usually surrounded
by shrunk yellow plastic. Needless to say, the two are *not* interchangeable.

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:

There's a line you're supposed to quote at this point that goes something
like "In accordance with Sun's policy of constant improvement..."

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.

The FFB is supported on the 24" monitor at 1280x800 resolution.
You should install the latest FFB patch (for Solaris 2.5.1 this is 103796).
Higher resolutions (such as 1900x1080@72) can be achieved but do not work
well and are not recommended or supported.

This frame buffer has 15Mb RAM on board, normally used
to provide 96 bits per pixel. That's roughly 32 bits each for
each of the double buffers plus 32 for the Z buffer
(it's more complex than that, but bear with me).

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.

You're not the only one. The difference between Creator
and Creator 3D is the amount of on-board memory.
Creator 3D has 15 MB of 3DRAM whereas Creator has only 5MB.
This makes no difference to the raw geometry rendering speed,
but double buffering and Z-buffering will be performed
in software on the plain Creator, whereas Creator 3D will be
hardware-assisted as it has the extra bit-planes to store this data.

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.

Horizontal Form Factor

Vertical Form Factor

Creator Series 1

Ultra1, Ultra2501-2634

NO

Creator Series 1Server compatible

Ultra1, Ultra2, Ex000501-4127

NO

Creator 3D Series 1

Ultra1, Ultra2501-2633

NO

Creator 3D Series 1Server compatible

Ultra1, Ultra2, Ex000501-4126

NO

Creator 3D Series 175 MHz

Ultra2, Ex000501-3129

NO

Creator Series 2

NO

Ultra30501-4174

Creator 3D Series 2

Ultra2, Ex000501-4173

Ultra30501-4172

Creator Series 3

NO

Ultra10, 30, 60501-4789

Creator 3D Series 3

Ultra450, Ultra2, Ex000501-4790

Ultra10, 30, 60501-4788

Elite 3D m3

NO

Ultra30, 60595-4871

Elite 3D m6

Ultra450, Ultra2595-4878

Ultra30, 60595-4870

Note that this table only shows the configurations that are
supported - ie have been formally qualified after
extensive testing.
Other configurations may work, for example FFB2/2+ or AFB in an Ultra 1,
but are not officially supported.

Although not a frame buffer question, this one pops up time and again.

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 &

If the file did not exist before, create it, and make sure that it is executable.
It may also be necessary to copy the file to $HOME/.dt/sessionetc.
Now restart dtlogin and you should have olwm on the second screen.

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

Some frame buffers support "PAL" and "NTSC" resolutions,
and provide Composite Sync with the appropriate timings.
However converting from RGB + CSYNC to Composite Video
may need additional equipment.

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.

See the previous answer.
There have been quite a few recent PC products that can change a
640x480x60 resolution screen into a tv viewable signal.
These are readily availible at local pc stores and are cheap.
The problem is that these devices generally require seperate sync
(h/vsync) and most frame buffers use combined sync (csync).

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.

There appears to be a problem with the ZX console after using Stereo mode.
After reverting to Mono mode and exiting OpenWindows the console screen
appears not to sync correctly.

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.

This question comes up regularly, in various forms. Sun does not
support direct access to ANY of our frame buffers. The frame buffer
device drivers and interfaces are considered proprietary and are not
publicly documented. The only supported way for a customer to access
a frame buffer is through one of our foundation libraries: X, XIL, XGL
or OpenGL. There are simply too many problems in allowing direct access
by customers, most significantly the fact that the code will break
whenever the hardware changes. By supporting a number of low-level
interfaces, Sun performs any porting for you, so your code
should continue to work regardless of the actual platform.

The supplementary question here is:

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

And the answer is: Programming docs for Sun frame buffers don't exist,
full stop. The level of support and documentation needed to do this across the
product line would be significant. There are several very subtle rules and
restrictions for each device - all have individual differences beyond the
register definitions. Many of these restrictions are not well documented
except in the driver code. Some of them may hang the system if violated.

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:

How the lookup table is applied to the image will depend on
the visual. For 8 bit PseudoColor a transformation will be
applied to the colormap; for 24 bit TrueColor it can be
applied to the image itself. The 24 bit DirectColor case
is left as an excercise for the reader.

8 bit case:

NB: This code is incomplete; it's adapted from an example
in the Colormap FAQ. It's here to demonstrate the principle.

That's the new stereo connector. With FFB2/2+ we moved to
a DIN connector instead of the old RCA type connector.
Here's a diagram showing the pinouts just in case you
need to setup the cable to connect Quark FFB2/2+ Stereo connector
to the infra-red emitter. All the usual disclaimers apply.

On P1 Connector: Pins 2,5,6,7 NOT USED
On P2 Connector: Pins 1,2,3,4,5,9 NOT USEDStereoGraphics
sells a setup that comes in 3 pieces: glasses,
an IR emitter box, and a cable to hook up to the framebuffer.
For the FFB2/2+ the cable+emitter is StereoGraphics part number ESUN.
They also make versions that works with the FFB1 and the ZX.

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.

PCI is a platform independent hardware standard;
for details visit the PCI Special Interest Group at
http://www.pcisig.com.
The intention is that future machines will be developed with PCI
interfaces only. However this doesn't mean that SBus is going away -
there is still a massive installed base which will be supported for
many years to come.

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.

As stated above, PCI is a HARDWARE standard. This doesn't mean that
you can buy an Ultra 30 and plug in the video card from your PC;
Nor can you take a PGX or other PCI card developed for an UltraSparc
machine and plug it into a PC and expect it to work. Although the
physical connections may be the same the Sun will require different
device drivers and on-board firmware.

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.

Until recently, all frame buffers read a "sense code" from the 13W3
connector or adaptor to determine what resolution the monitor supported.

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.

Any PC monitor that is "Plug And Play" should work with the PGX.
Older multisync monitors that do not support "Plug and Play"
can be used, but it may be necessary to reconfigure the card manually
using m64config, since the default resolution (1152x900) may not be
supported by a PC SVGA Monitor and the PGX does not support
the "setenv output-device" EPROM command.

Most of the drivers for x86 are built by third party developers.
SUN does some of the video drivers and gets some others from
Xi Graphics - see www.xig.com
This company also does its own drivers for various os platforms.
They also support dual monitors for x86 as SUN does not at this time.

As usual, what works and what is supported are two different things.
The main Sun supported devices are the FFB and AFB series,
the cgthree and cgsix series (but only TGX and TGX+ in Ultras)
and the PGX series. The S24/TCX and SX are also believed to work.

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.

I've created a small library that will eliminate colormap flashing
in many cases, though not all. It works by intercepting calls to
XAllocColor, and checking the return.
If the allocation failed, it returns the closest read-only match.
Feedback is welcome.
You can download the source
(freely distributable) and the library
compiled for Solaris 2.5.1

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

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

and the library will be picked up automagically.

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:

This is a k-shell script that will determine what frame buffers
are available on your system, what resolution they are running at
and other useful information. Here's an example of the output from the script: