rec@arris.com (Roger Critchlow) (12/14/90)
A progress report on bringing up X11R4 on a
ViewSonic PV1M card (probably an STB ET4000 card)
Fixed Frequency Paper White VGA Monitor
386/ix 2.0.2 with X11R3, TCP/IP, ...
For some reason, 386/ix insists on programming my VGA in a monochrome
mode. This maps the CRT controller and other registers to ports 0x3B?.
For other reasons, Herr Roell insists on programming the VGA in color
mode. This saves and restores the CRT controller and other registers
from and to ports 0x3D?.
The result is that the VGA is totally hosed by the server. On return to
the console VT after xinit, the text on the screen is a cloud of snow and
/bin/su -c 'init 0' is the only way to go.
I have patches to X/mit/server/ddx/at386/vga/{vga.h,vgaHW.c,et4000/driver.c}
which make it sensitive to the io port mapping of the VGA card and allow
me to recover the VGA after xinit. I will post these soon.
But here's a further puzzle which I would like some help with before I stay
up all night again. If I run:
xinit
then the server comes up, but the monitor fails to achieve vertical sync
and the X cursor doesn't seem to track correctly. However, if I run:
sttymode VGAC80x25; xinit
then the server comes up, the monitor achieves vertical sync, the X
cursor tracks correctly, focus is given to the xterm window, the server
pans, and everything works.
sttymode simply issues an ioctl() to reset the video mode to a VGA
80x25 color text mode. In all other ways the machine and Xconfig are
unchanged.
Anyone have a bright idea about this?
Finally, a point of clarification about the [+-][hv]sync flags in Xconfig.
flag bit result
----------------------------------------------
+hsync 1 negative horizontal sync pulse
-hsync 0 positive horizontal sync pulse
+vsync 1 negative vertical sync pulse
-vsync 0 positive vertical sync pulse
The polarities of the sync pulses are used to signal the vertical resolution
to the monitor. Roell's server automatically selects the correct sync
polarities based on the vertical display size, but someone, namely me, who
was trying to set the sync polarities explicitly found the results puzzling.
-- rec --roell@informatik.tu-muenchen.dbp.de (Thomas Roell) (12/14/90)
>For other reasons, Herr Roell insists on programming the VGA in color >mode. This saves and restores the CRT controller and other registers >from and to ports 0x3D?. Silly me. >The result is that the VGA is totally hosed by the server. On return to >the console VT after xinit, the text on the screen is a cloud of snow and >/bin/su -c 'init 0' is the only way to go. Calling vpix would do the same job. >I have patches to X/mit/server/ddx/at386/vga/{vga.h,vgaHW.c,et4000/driver.c} >which make it sensitive to the io port mapping of the VGA card and allow >me to recover the VGA after xinit. I will post these soon. Ok, everybody is welcome to send ME the patches, but in general, I like to coordinate the work by myself. I allready worked on this problem, and got a solution. It's now under beta-test. Other beta-testers are welcome. But they must have a REAL GOOD KNOWLEDGE OF VGA-PROGRAMMING. >Finally, a point of clarification about the [+-][hv]sync flags in Xconfig. > > flag bit result > ---------------------------------------------- > +hsync 1 negative horizontal sync pulse > -hsync 0 positive horizontal sync pulse > +vsync 1 negative vertical sync pulse > -vsync 0 positive vertical sync pulse > >The polarities of the sync pulses are used to signal the vertical resolution >to the monitor. Roell's server automatically selects the correct sync >polarities based on the vertical display size, but someone, namely me, who >was trying to set the sync polarities explicitly found the results puzzling. This is a TRUE bug. The meaning of +hsync is obviously a positive horizontal sync pulse. This will also be fixed. - Thomas -- _______________________________________________________________________________ Mail: Thomas Roell (c/o Daniel Hernandez) Inst. f. Informatik / Technische Universitaet M"unchen Arcisstr. 21 / 8000 Munich 2 / Fed.Rep. of Germany E-Mail (domain): roell@lan.informatik.tu-muenchen.dbp.de UUCP (when above fails): roell@tumult.{uucp | informatik.tu-muenchen.de} -------------------------------------------------------------------------------