🚀 go-pugleaf

The image corruption occurs because some of the framebuffers have hardware
state, and that state is not preserved/restored across context switches.
The most notable example of that state is the RasterOp accelerators on
many of the color framebuffers.

There is no hardware-level interlock.  And since most applications,
including SunView and screen{dump,load}, access the framebuffer by
mmap()ing it and writing directly, the kernel doesn't have a chance to
single-thread the operations in the device driver.  SunView handles this
problem by providing locking aound screen update operations; the lock is
at the pixwin level.

The worst result is a corrupted image in the dump.  The image will still
be screenload'able, it will just look bogus.  The problem with
non-loadable screen images was separate, I believe: a bug in some 3.x
versions of the byte-length-[en,de]coding software, fixed in 4.0.

Screendump was designed to be able to take snapshots of the contents of
the framebuffer, regardless of what had put those bits there.  So it
doesn't assume that any particular window environment is running (or for
that matter, any window system at all).  Screendump could be made more
robust, by having it check whether it is running under a SunView
environment and, if so, using pw_lock() to ensure exclusive access to the
framebuffer during the copy-out operation.  But there is no way to ensure
"atomic" screendumps in the general case.

Beau James					beau@ultra.com
Ultra Network Technologies			sun!ames!ultra!beau