I maintain this FAQ as a public service, because if I didn't it probably wouldn't get done. If you've found it helpful, please let me know. Or better still, tell my manager [email protected].
I am keen to receive any corrections, updates, suggestions, etc. I can be
contacted by email as [email protected] or by post at
UMTV16-218, 901 San Antonio Road Palo Alto, California 94303
I do try to maintain the accuracy of the information; your assistance is appreciated. 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.
Note for Sun Internal users: You will have to register one of the mirror sites.
So what is a frame buffer anyway?
Introduce me to Sun's frame buffers.
What's this frame buffer on the motherboard of my SS20?
What's the bottom line on 1280 x 1024 on the SX?
How do I start OpenWindows in a dual-headed configuration?
How do I set the resolution of the primary frame buffer?
How do I set the resolution of a second frame buffer?
How do I find what frame buffers I have available? (Updated Oct 98)
What are the restrictions on multi-headed machines?
Can I drag a window from one screen to another?
What resolutions do the various frame buffers support?
What is the default resolution for each frame buffer?
How do I change the console frame buffer?
Will 4.1.3 run on a SS20/SX, SS5/S24 or SS4/TCX?
How do I change the default depth or visual class in OpenWindows?
Why does the screen look paler or darker in 24 bit mode?
How can I display the same tool on multiple windows?
Can I replace the monitor with an LCD display?
What special purpose products are available from third parties?
Why does the Xsun server process appear to be so large?
Can I use a Sun monitor with my PC?
What frame buffers are/are not supported in the Ultra machines?
Why are 24 bit Frame Buffers so expensive compared to a PC?
How do I change the resolution on the SparcStation 4?
How can I tell whether I have the 4Mb or 8Mb SX VSIMM installed?
What is different about the "new" TGX and TGX+?
What set of resolutions do the FFB series support?
Can the FFB1 be used with the new 24" HDTV monitor?
What resolutions does the FFB2/2+ support with the new 24" HDTV monitor?
What set of visuals does the FFB support?
I'm confused by all these Creator boards. What's the story, Morning Glory?
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?
How can I capture the video output from a frame buffer?
Can I drive a TV from any of the frame buffers?
Why does the console not sync correctly after using Stereo mode?
How can I write to the frame buffer directly?
What's that little round socket for on the back of the FFB2/2+?
What's the story on PCI support?
So can I take a PCI card from my Sun and plug it in my PC (or vice-versa)?
How do the FFB2/2+ and the PGX determine their default resolutions?
Can I use a PC monitor on an Ultra 5 or Ultra 10?
What are the pinouts for the 13W3 connectors?
Charles Poynton has also written some excellent FAQs and articles on the subjects of gamma and colour correction.
In the early days, Sun provided seperate "Graphics Processor" or "Graphics Accelerator" and "Graphics Buffer" boards - the processor/accelerator was an add-on (sometimes optional) that provided efficient, tuned hardware pipelines to support graphics functions normally done in software, for example shading, Z-buffering, picking and hidden surface removal.
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).
501-1419
- MG1 bwtwo with D type connector
501-1455 - MG2 bwtwo with 13W3
connector
The cgthree was built onto the motherboard of some entry level machines.
501-1415 - cgthree with 13W3 connector
501-1718
- cgthree with 13W3 connector. Distinguishable from 501-1415 by having 2
crystals (metal oblongs) instead of 1.
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.
501-1481
- Double width GX: Rev 1
501-1645
- Double width GX: Rev 2
501-1672
- Single width GX: Rev 8
501-1996 - Single width GX
501-2325
- TGX - Older model. Chip sometimes printed with Sun logo and TURBO XGX.
501-2922
- TGX - Newer model. New names (mixed case).
501-2253 - TGX Plus. Older
model. Same chip and names as TGX (501-2325)
501-2955 - TGX Plus. Newer
model.
There is no functional difference between the older and newer
versions of the TGX and TGXplus - see Question
20.
cgfourteen
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.
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 supports both 8 and 24 bit visuals, but due to the architecture of the chipset 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.
setenv output-device=screen:r1280x1024x76mYou 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.
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.
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. -dev
, thus: openwin -dev /dev/fb0 -dev/dev/fb1The 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: openwin -dev /dev/fb0 -dev/dev/fb1 left openwin -dev /dev/fb1 -dev/dev/fb0will 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/fb1will not have the desired effect; you would need to use:
openwin -dev /dev/fb0 -dev/dev/fb1 bottomOther 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.
To set the resolution, run the following command as root:
# eeprom output-device=screen:r1280x1024x76then reboot. Alternatively, halt the machine and type
ok setenv output-device screen:r1280x1024x76 ok resetSome frame buffers have their own configuration programs; for the ZX you should use
leoconfig
:
/usr/kvm/leoconfig -m 1280_67while for the SX you should use
cg14config
:
/usr/kvm/cg14config -r 1280x1024@66
/etc/init.d
) or start OpenWindows
($HOME/.xinitrc
).
/usr/kvm/cg14config -d /dev/fbs/cgfourteen1 -r 1280x1024@66Be 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.
#!/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\?=trueThe script presumes sun4m architecture; for sun4c change
/iommu/sbus
to /sbus
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\?=trueNote that the number 4 in
vsetup 4
refers to the sense
code of the monitor. For an incomplete list of sense codes, see
below.
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,0OFFSETAnd this is what the numbers actually mean, taking 1280x1024@67 as an example:
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
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 linesAt 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,
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
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:
dmesg | grep cgYou should see messages similar to this:
cgsix0 at sbus0: SBus slot 2 0x0 SBus level 5 sparc ipl 9 cgsix0 is /iommu@f,e0000000/sbus@f,e0001000/cgsix@2,0 cgsix0: screen 1152x900, single buffered, 1M mappable, rev 11 cgsix1 at sbus0: SBus slot 1 0x0 SBus level 5 sparc ipl 9 cgsix1 is /iommu@f,e0000000/sbus@f,e0001000/cgsix@1,0 cgsix1: screen 1152x900, double buffered, 4M mappable, rev 6If the rev number of the board is 11 or more then the board is a TGX/TGX+
single buffered, 1M mappable
then it is a GX/TGXdouble 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+.
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.
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.
TechSource contacted me to confirm that they support multi-headed configurations on the Ultra 5 and 10 using their Raptor GFX cards.
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.
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.
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://ftp.cs.columbia.edu/.
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 @ 50NB: the PGX only has 2Mb of on-board memory, so 1920 x 1200 is obviously unattainable.
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 8The following resolution values are all taken from the Field Engineer's Handbook, except where stated otherwise.
These are supported resolutions. For ways to customise other resolutions see the note in Question 2.
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
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
1024 x 768 @ 77 1152 x 900 @ 66 1152 x 900 @ 76The first boards (501-1415, 501-8044) only support 1152x900@66. Later boards (501-1718, 501-1909) support 1152x900@76 as well. On these boards, 76Hz is the default.
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.
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 onlyDouble width boards (501-1481, 501-1645) only support 1152x900@66. The single-slot boards (501-1672, 501-1996) support 1152x900@76 as well. On these boards, 76Hz is the default.
The on-board frame buffers in the IPX and LX are also GX. Each supports additional resolutions, as noted above.
1024 x 800 @ 85 1152 x 900 @ 66 1152 x 900 @ 76 1280 x 1024 @ 67 Default1600 x 1280 is not a supported resolution (but may work).
1152 x 900 @ 76
1280 x 1024 @ 67 1280 x 1024 @ 76 Default
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
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 @ 76For a SPARCStation 4, the commands used to set the resolution are slightly different since they address each resolution by the dot clock instead of the refresh rate.
For 1152x 900@66 use 1152x900x94 For 1152x 900@76 use 1152x900x108 For 1280x1024@66 use 1280x1024x117 For 1280x1024@76 use 1280x1024x135
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(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
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.
The colour display has a resolution of 1024x768 and is manufactured by Sharp.
NB: See below for how the FFB2/2+ and PGX determine their default resolution.
Code TGXplus(1) TGX(2) GXplus GX (LSC chip) ------------------------------------------------------------------- 7 1152x900x66 1152x900x66 1152x900x66 1152x900x66 6 1152x900x76 1152x900x76 1152x900x76 1152x900x76 5 1024x768x60 1024x768x60 1152x900x66 1152x900x66 4 1152x900x76 1152x900x76 1280x1024x67 1152x900x76 3 1152x900x66 1152x900x66 1152x900x66 1152x900x66 2 1280x1024x76 1152x900x66 mutant(3) mutant(3) 1 1600x1280x76 1152x900x66 mutant(4) mutant(4) 0 1024x768x77 1024x768x77 1152x900x66 1152x900x66(1) SSLX with the extra VRAM SIMM is the same as the TGXplus.
(2) SSLX is the same as the TGX. SS Voyager is the same as the TGX, except that code 7 is used to tell the system to use the internal LCD display.
(3) Sync timing matches 1280x1024x76, actual pixels displayed are less. Use is not recommended.
(4) Sync timing matches 1600x1280x76, actual pixels displayed are less. Use is not recommended.
Code SX ZX S24 ------------------------------------------------------ 7 1152x900x66 1152x900x66 1152x900x66 6 1152x900x76 1152x900x76 1152x900x76 5 1024x768x60 1152x900x66 1024x768x70 4 1152x900x76 1280x1024x67 1152x900x76 3 1152x900x66 1152x900x66 1152x900x66 2 1280x1024x76(5) 1280x1024x76 1152x900x76 1 1600x1280x76(5) 1152x900x66 1152x900x66 0 1024x768x60 1024x768x76 1152x900x66(5) The 4Mbyte VSIMM drops to 8 bits per pixel in these modes.
Code Creator and Creator3D ----------------------------- 7 1152x900x66 6 1152x900x76 5 1024x768x60 4 1280x1024 (6) 3 1152x900x66 2 1280x1024x76 1 1152x900x66 0 1024x768x77(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-probe-list
, and the
conventional way to select one device over another as the console is to:
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:
output-device
configuration parameter to refer to
that devaliasuse-nvramrc?
configuration parameter to
true
ok show-sbusLook at the list of devices and make sure you really have a ZX (leo) in SBus Slot 2. This is not really needed if you know what you have already.
ok nvalias zx-screen /iommu/sbus/SUNW,leo@2,0 ok setenv output-device zx-screen ok resetAfter 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
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.
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 TrueColorAcceptable depths are 8 or 24; you cannot set a depth of 1. The nearest you can get to simulating a monochrome display is to select a greyscale visual (see below) and specifying the -2d flag to
olwm
.
Acceptable classes are: GrayScale StaticGray PseudoColor StaticColor
DirectColor
and TrueColor
.
NB: 24 bit DirectColor visual is only supported on the S24 or ZX, and
only under OpenWindows 3.4
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
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.
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.ZNote that this information may be out of date.
A ReadMe for XMX V1.0 is available.
In addition, many LCD displays are designed to be driven by PC frame buffers which use very different timings, and therefore cannot be used with any of SUN's products.
Both PC format and Digital frame buffers are available from third party vendors.
Note: Since this analysis was originally written, companies such as RDI and PixelVision have announced flat screens which can be driven by Sun's frame buffers.
See Question 13 for information on graphics products available from third parties.
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.
PixelVision produce LCD displays capable of up to 1280x1024 @ 76Hz, that can be driven from Sun's frame buffers.
RDI produce a 12" 1024x768 LCD monitor which can be driven by Sun's frame buffers.
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#cat20
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.
Ultra Spec manufacture a range of cables, including monitor cables and PC to 13W3 adaptors.
Photon, Mirage and Software Integrators all manufacturers graphics cards which allow Sun and other fixed-frequency workstation monitors to run on a PC.
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. This is particularly noticeable on:
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. The sx and tcx drivers use a particularly large amount of the process address space.
This phenonmenon is not new, nor specific to these 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.
NB: The SX and S24 are 24-bit devices, and if you run OpenWindows in 24 bit mode, then they 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.
SunExpress have such an adaptor, part number 530-2357-01. This has been tested with the following monitors in both DOS and Windows modes:
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.
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.
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> resetThe following script was used to set a dual headed SparcStation 4 with the extra VSIMM and a TGX+ to 1280x1024. The system used two 20" premium monitors.
#!/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
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' . . .The important value is the final value on the
reg:
line. In
this case the value is 00400000, which indicates a 4Mb VSIMM is present. If an
8Mb VSIMM is present the value will be 00800000.
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.
/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.
1920 x 1200 single-buffered 1600 x 1000 single-buffered 1440 x 900 single-buffered 1280 x 800 single-buffered or double-bufferedThis 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.
GrayScale StaticGray PseudoColor StaticColor
DirectColor
and TrueColor
. 24 bit DirectColor visual is
supported.
It also supports a complex set of 8 and 24 bit overlays/underlays, and both linear and nonlinear gamma correction. More information is needed.
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.
Horizontal Form Factor | Vertical Form Factor | |
Creator Series 1 | Ultra1, Ultra2 501-2634 |
NO |
Creator Series 1 Server compatible |
Ultra1, Ultra2, Ex000 501-4127 |
NO |
Creator 3D Series 1 | Ultra1, Ultra2 501-2633 |
NO |
Creator 3D Series 1 Server compatible |
Ultra1, Ultra2, Ex000 501-4126 |
NO |
Creator 3D Series 1 75 MHz |
Ultra2, Ex000 501-3129 |
NO |
Creator Series 2 | NO | Ultra30 501-4174 |
Creator 3D Series 2 | Ultra2, Ex000 501-4173 |
Ultra30 501-4172 |
Creator Series 3 | NO | Ultra10, 30, 60 501-4789 |
Creator 3D Series 3 | Ultra450, Ultra2, Ex000 501-4790 |
Ultra10, 30, 60 501-4788 |
Elite 3D m3 | NO | Ultra30, 60 595-4871 |
Elite 3D m6 | Ultra450, Ultra2 595-4878 |
Ultra30, 60 595-4870 |
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.
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.ts.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 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.
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 Sun frame buffers use combined sync (csync).
There exists a utility for the FFB2+ (Creator series 3) which allows it to provide dual sync. However this is not a supported Sun product and all the usual disclaimers and caveats apply - use at your own risk. The source is not available. The utility can be downloaded from here.
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.
The supplementary question here is:
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); } }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.
/* 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);
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); } } }
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 | +===========+===================+==========+On P1 Connector: Pins 2,5,6,7 NOT USED
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 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.
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.
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.
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 10Pins A1, A2 and A3 carry the Red, Green and Blue signals respectively. On a monochrome frame buffer the signal is carried on Pin A2 (Green).
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
Useful Part Numbers
Having trouble finding a part number? Here are
some useful numbers. If you have any suggestions for additions please let me
know.
Cables and adapters
130-3034 The adapter to
connect the 17-inch entry-level monitor to a SPARCstation - 13W3 male to HD15
female.
595-4072 ZX Ultra 1 Kit - the full kit required to install the ZX in an Ultra 1
To use, simply set the LD_PRELOAD environmental variable, thus:
% setenv LD_PRELOAD /(mydir)/libnoflash.so.1and 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:
% setenv LD_PRELOAD "/(mydir)/libnoflash.so.1 /usr/dt/lib/libXm.so.3"
cgsix@0 is TGX Plus 1280x1024@67 Monitor type 4 ffb@1e is FFB 75MHz Double buffered 1280x1024@67
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 -