pushing back the bounds of ignorance

[Jon A. Tankersley]

In article <28177 at linus.UUCP> jfjr at mbunix (Freedman) writes:
>
>  We are doing some plotting on Suns (screendump|rasfilter8to1|lpr -v)
>This works sometimes. Sometimes (when others are logged in)
>this gets confused and we get various error messages
>having to do with problems with valloc, /dev/fb etc.
>
>  Is this normal? must we live with this or is there a fix?

Join the crowd.  When you have 3/50's, 3/110's, BW&C 3/60's, BW&C 3/160's,
and BW&C 3/260's and you try to write a generic screendumptool in shell,
it doesn't work.  I asked Sun about some of this.  There are some problems
with the different architectures of the frame buffer.  There is also a
problem with lpr -v.

1) 3/110 suntools w/o specifying -8bit_color_only.
   screendump|rasfilter8to1|lpr -v fails every time.  An lpr -v problem with the
   prism frame buffer of the 3/110.  I guess it should go through
   rasfilter10to1 instead :-).
   screendump|rasfilter8to1|screenload works too.
2) ANYTHING ON THE SCREEN MOVING will screw up screendump.  A clock with a 
   second hand!  A clock that ticks the minute hand during the dump!  Perfmeters
   can do it too.  Screendump doesn't freeze the screen while reading.  The
   best example of this problem is lots of copies of the screen image splattered
   across the top part of the page, usually about 2 lines with 8 images each.
3) 3.2OS, running from the cmdtool window will act like number 2.


I asked Sun about the best way to do this, especially since we have a dual
headed monster, plus lots of 2-desktop systems around.  They recommended a
program that opened /dev/fb and determined the buffer type would work.  Then
a screendump -d /dev/framebuffer would work.  I haven't had time to work on 
this yet....

Sigh...

Hope this helps.
-tank-