Subject: SPXg support, last call
To: None <port-vax@NetBSD.org>
From: Blaz Antonic <blaz.antonic@siol.net>
List: port-vax
Date: 11/14/2005 17:21:04
Hello,

As it happens I'm still out of job so I figured I'd finally finish the
work on SPXg driver that I intended to make almost a year ago after a
fellow Vaxenthusiast provided me with hardware and I feel kinda bad for
not doing it yet even though there were no promises given :-) Back then
I asked for framebuffer identification information and recieved
absolutely no response (not a single one). I can hardcode the values to
make the driver work on my machine and disregard other combinations of
hardware out there and will do just that if I receive no response again
but that's the last ting I want to do. So - pretty puhhlease - if you
happen to own a 4000/60 with SPXg/gt or 4000/9x with either LCPSX, SPXg
or SPXgt, send me the output of the following commands:

1: for Vaxstation 4000/9x:

>>> e 25800000

(or for VS 4000/60)

>>> e 20020000

for ALL COMBINATIONS of S3 switch (the one that chooses between serial
and glass console) and switch onboard your LCSPX / SPXg / SPXgt (the one
that switches between 66 Hz and 72 Hz refresh rate). Note that there are
actually two switches on the framebuffer card, only one of them actually
does something; the other one appears to be unconnected. You can easily
access these switches by removing top cover of your Vaxstation. This
means 4 combinations (serial/66 Hz; serial 72 Hz; glass 66 Hz and glass
72 Hz) of output - can you do that ?

*WARNING* Your monitor may or may not be capable of operating at the
other refresh frequency, depending on what kind of monitor you've got. I
suggest you use serial console for this process as did I. My monitor
displays the 72 Hz image incorrectly because of back porch timing
problems but it syncs at this frequency without any problems (i.e. there
is a ghost image appearing at the left edge of the screen). I suppose a
change of timing parameters might fix that. 

Note that (at least on my machine) it is not necessary to power off the
machine for S3 switch change to take effect as far as output of exmaine
command is concerned. It will not affect console operation (so if you
booted with serial console it will still respond normally, ditto for
glass console - it is just a bitfield that changes). This means you can
power up the machine with serial (or glass; whichever you prefer)
console enabled, write down the output of above command, toggle S3
switch, write down the output again, toggle S3 switch back to initial
position, power off the machine, open the cover, toggle the refresh
frequency switch, power the box up again, write down the output of above
command, toggle S3 and write down the output for the very last time.
This saved me quite some time as POST takes a while with heaps of RAM.
YMMV; don't blame me if your box explodes.

2: and (for both 4000/60 with SPXg/gt and 4000/9x):

>>> show config

(the part pertaining to the framebuffer device, the rest of your config
is irrelevant) - I only need one of these, even though it changes when
you toggle the refresh frequency select switch.

The output of the first command should look like:

>>> e 25800000
  P 25800000 C3DDC3DD

and the second one with irrelevant stuff snipped:

2        SP3D    OK
                      SPXG  6Mpixel FB Highres 66Hz V1.3

Thank you. I'm doing this for you guys y'know :-)

Q: Why is it important that I get response from LCSPX owvers even though
they won't benefit from this driver directly at all ? 
A: I want to eliminate false positives for the driver to be able to
coexist with others in GENERIC kernel. 

An unrelated remark: it would really be great if somebody finally got
around to fixing the 4000/90 keyboard interrupt triggering bug in
"autodetection" code which prevents keyboard from working in kernel when
S3 is set to glass console. 

Blaz Antonic
-- 
Hi! I'm a signature virus!
Copy me into your signature to help me spread!