For When You Can't Have The Real Thing
[ start | index | login ]
start > Sun > Multiple Frame Buffers

Multiple Frame Buffers

Created by dave. Last edited by dave, 17 years and 276 days ago. Viewed 3,493 times. #4
[diff] [history] [edit] [rdf]

Notes on Sun Video

This was written for Solaris 2.6 or 7, on an Ultra 5.

Notes on Sun Video

There is the Sun Framebuffer FAQ at


...which is required reading. There is also a local copy of it around somewhere.

Things which that document does not cover:

  1. Telling the xserver (dtlogin and children) that you have two framebuffers

- this is necessary unless you enjoy manually starting your window managers from the console.

- the magic file is /etc/dt/config/Xservers (if that does not exist, copy /usr/dt/config/Xservers to /etc/dt/config/Xservers) and at the bottom you need to say something like

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -dev /dev/fbs/gfxp0 -dev /dev/fbs/m640

- the above is a single line and replaces whatever is there by default.

- replace your -dev parameters with your actual /dev/fbs devices. Or you could make /dev/fb0 and /dev/fb1 symlinks which point at the real devices and use them instead, they will work too.

- order is important. As specified, the screens are started in the order in which they are specified and are assumed to be left-to-right. Display numbers also go left-to-right. So in our example above, the GFX is the left display and is display :0.0, while the Mach64 on-board is the right display and is display :0.1. I think (but I'm not sure) that this controls where dtlogin puts it's login screen -- it will always use :0.0 -- in the example above, note that the dtlogin prompt will not be displayed on the console frame buffer. See the FAQ if you want to change the console device (warning -- changing the console device will require messing around in the PROM, so you should only do it if you have both a vt320 kicking around (because you _will_ f*** it up a couple of times) and a non-trivial amount of spare time to make it work. It is far, far easier to re-arrange your monitor layout on your desk and then change the Xservers file.)

- if you want to change the display order (ie you want :0.0 on the right instead of the left) you can add a [ left | right | top | bottom ] type parameter after the second one -- this parameter tells the Xserver where the new monitor is in relation to the previous one. The parameter "right" is implied if none are present, thus the left-to-right assumption.

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -dev /dev/fbs/gfxp0 -dev /dev/fbs/m640 left

This puts the GFX on the right as :0.0 and the Mach64 on the left as :0.1

- man Xsun is your friend if you want to get _really_ clever, but you are on your own.

- wise hackers merely comment out the existing line so when you f*** things up (and you will), you can undo it easilly.

2. Telling openwindows which resolutions/bit-depths you want -------------------------------------------------------------

- When suns start up, they pick a resolution based on what is in the PROM and what the monitors tell the framebuffers they can do. You can over-ride this by messing around in the PROM (the OK prompt) but a safer way is to change the configuration files. (Why? Because if you mess with the PROM and get it wrong, you've got to truck out the vt320 and hook that up to the serial port in order to fix it. Which is embarassing and annoying.)

- the magic file is /etc/openwin/server/etc/OWconfig, and should be mostly set up for you when the OS is installed or you install the packages for your alternate frame buffer, and can be manipulated directly by editing parameters that look like "res" for resolution (usually width x height x refresh, without the spaces) and depth; or you can use your configuration program like m64config or pgxconfig -- read your manuals and --help screens.

- I don't know if this affects CDE's resolution or bit depth, since I personally don't use CDE.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful: | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt