Created attachment 41811 [details]
SGI 1600SW configuration file for X

anaconda just uses the information from Xconfigurator; reassigning to Mike

I can have these modelines built into XFree86 itself, which might
be a cleaner solution.

If you have the Windows .inf file for this monitor, please attach
it, and I can have it autodetected also.

Created attachment 43434 [details]
Windows .inf file from Nine Revolution IV-FP install

This monitor supports three systems:
	1) 3DLabs Oxygen VX1-1600SW, direct digital
	2) Nine Revolution IV-FP, direct digital
	3) Any analog card that can output 1600x1200 (wide format).

Correction.  Make that:
	3) Any analog card that can output 1600x1024, 60Hz.


While you're adding widescreen monitors to the databases, might as well hit this
one:
http://www.sel.sony.com/SEL/consumer/ss5/home/displaymonitors/professionalseries/gdm-fw900_specs.shtml

Panoramic 16:10 aspect ratio 
Horizontal Scan Range: 30kHz - 121kHz 
Vertical Scan Range: 48Hz - 160Hz 
Maximum Resolution: 2304 x 1440 
Recommended Resolution: 1920 x 1200 @ 85Hz 

This monitor gets a lot of professional use, and shows up in operations centers
all the time.

Gentlemen,

I too have the SGI 1600sw flatplanel with the number-nine card.  I have long
been waiting for this panel to be included in your distribution.  XFree86 4.1.0
has support for this monitor but Xconfigurator does not.  I have had to place
the appropriate mode lines in by hand for several years now.  My current dilema
is that I have configured the XF86Config-4 and can run X but when logging out,
my screen gets corrupted and I must power down (rather than shut down
gracefully) to take the system down.  I find that X fails to reset the monitor
properly when logging out and the monitor actually loses sync.  Brice, have you
discovered this problem. 

Redhat 7.1 allows me to use startx from init mode 3 and logout, bringing me back
to a prompt where I can halt the system.  But Redhat 7.2 corrupts my monitor so
characters are unreadable.  In both cases, Xdm fails to logout properly and
reinitiate for the next user.

Any help here would be greatly appreciated.  I would be glad to test fixes if
you have them and can put them in rpm format where I can download them.

I don't know how to solve the bug causing the corrupt console, but
inserting "vga=808" as kernel parameter will make it go away.  You'll get
a framebuffer for the linux console:

# grub.conf generated by anaconda
title Red Hat Linux (2.4.9-21debug)
        root (hd0,0)
        kernel /vmlinuz-2.4.9-21debug ro root=/dev/hde8 hda=ide-scsi vga=808
        initrd /initrd-2.4.9-21debug.img

But the first step is for RedHat to add the monitor to the database.  Then, at
least, people
know that using this monitor is possible.

Gentlemen,

Upon further investigation I have discovered that the problems with corrupted
consoles when logging out of my Xsession seem to be associated with the KDE
desktop.  When using the GNOME desktop, the problem does not exist.

Bryce, using the vga=808 kernel parameter made only one small difference.  That
is, it allowed me to logout of KDE cleanly if I came up in initmode of 3 and
then performed a startx..  Then when logging out, KDE would bring me back to the
console window (text mode) cleanly.  However, this mode does nothing for xdm.

Mharris, how would you like me to proceed with this?  Classify and refile as
another bug?  A KDE bug?

Dunno if this issue is still relevant in Red Hat Linux 9, but I've reassigned
it to the proper component for investigation, etc.

*** Bug 90870 has been marked as a duplicate of this bug. ***

>Created an attachment (id=43434)
>Windows .inf file from Nine Revolution IV-FP install

That is the .INF file for the _video card_, not the one for the monitor, so
it is of no use to me.

The reason that this monitor is not autodetected properly, is because nobody
has ever submitted the proper information which is needed in order for it to
be added to the database.

Someone out there with one of these monitors must have the floppy disk or
CDROM that comes with the monitor, or can track down the proper files
on the appropriate website on the net somewhere for this monitor.

When someone tracks down the proper Windows .INF file for the _monitor_ itself,
I will gladly add this monitor to the MonitorsDB database.  I generally
process all requests such as this one or two times during a development
cycle (one is right now).  If someone attaches it very soon, it has a high
chance of getting into the next database update.

Thanks.

I bought the monitor and #9 card direct from SGI.  I don't remember the monitor
coming with its own floppy or cd-rom.  In fact the card doesn't have one either.
 A few other people claim to have gotten the combo to work, but I've tried their
mode lines with only partial success.

I think modelines by themselves aren't enough.  I have modelines that worked for
somebody else but don't work for me.

Which complicates things significantly.  Getting modelines wrong or getting
monitor database data wrong can physically destroy some monitors.

I do not wish to include random modelines in the server or in our config tools.
I need to have some level of guarantee that user supplied data is valid and
within the ranges of the hardware.  If I stuff some data in which happens
to work for someone, and ends up blowing up a lab full of these things, it
wouldn't look very good for Red Hat.

Created attachment 91717 [details]
.INF Monitor Profile for SGI 1600SW

This is downloaded from <http://www.alexia-media.com/sgi320/> which I find
through a Google search on ".inf" and "1600sw".  It was supposedly downloaded
from the Number Nine site before Number Nine shut down.

Gentlemen,

First, I have the original SGI cdrom to install the Revolution IV for 
SGI.  It is the only CD that comes with the SGI 1600SW for NT 
systems.  I will be happy to make a copy and send it to someone.  
Please email me a name and address and I will send it immediately.

Second, the correct modelines for this monitor are documented with 
the XFree86 documentation.  You can find the settings at the 
following URL:


      http://www.xfree86.org/4.2.0

Click on the  "Information for Number Nine I128 Users" link

Then Click on the "Mode lines for the Silicon Graphics flat panel 
display:" link

These settings work for me.

BTW, I would be happy to send a copy of my Redhat 9 
/etc/X11/XF86config file.  It works beautifully.  This would verify 
the settings.  Additionally, I would be happy to beta test the 
monitor database entry for the SGI 1600SW as well.


Finally, the other problem I reported in this bug report (where my 
system froze when using xdm or gdm has been fixed in release 9.  It 
was a problem I tracked down to the I128 driver for XFree86 and has 
nothing to do with the monitor.  Thanks for fixing that bug

Following is my /etc/X11/XF86Config file for RH 9.  It works VERY well.  I do
not use the SGI Multilink Adapter.  I connect my SGI 1600SW Flat Panel directly
into the digital connection of the Number 9 Revolution IV card.  Also, note the 
HorizSync of 31.5-125 and the VertRefresh of 60-150.

Also note, these are the modelines documented in XFree86.org in my previous
message.  So, they are formally documented and they do work.


# XFree86 4 configuration created by pyxf86config

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "DevInputMice" "AlwaysCore"
EndSection

Section "Files"
# RgbPath is the location of the RGB database.  Note, this is the name of the
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.

# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.

        RgbPath      "/usr/X11R6/lib/X11/rgb"
        FontPath     "unix/:7100"
EndSection

Section "Module"
        Load  "dbe"file:///usr/share/doc/HTML/index.html
        Load  "extmod"
        Load  "fbdevhw"
        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"
        Load  "dri"
EndSection

Section "InputDevice"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
#       Option  "Xleds"         "1 2 3"

# To disable the XKEYBOARD extension, uncomment XkbDisable.
#       Option  "XkbDisable"

# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults).  For example, for a non-U.S.
# keyboard, you will probably want to use:
#       Option  "XkbModel"      "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
#       Option  "XkbModel"      "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
#       Option  "XkbLayout"     "de"
# or:
#       Option  "XkbLayout"     "de"
#       Option  "XkbVariant"    "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
#       Option  "XkbOptions"    "ctrl:swapcaps"
# Or if you just want both to be control, use:
#       Option  "XkbOptions"    "ctrl:nocaps"
#
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbRules" "xfree86"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/psaux"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
EndSection

Section "InputDevice"
# If the normal CorePointer mouse is not a USB mouse then
# this input device can be used in AlwaysCore mode to let you
# also use USB mice at the same time.
        Identifier  "DevInputMice"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "no"
EndSection

Section "Monitor"
# SGI Flat Panel mode lines

# 1600x12024d32
Modeline "1600x1024d32" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 7
+Hsync +Vsync
# 1600x12024d16
Modeline "1600x1024d16" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 5
+Hsync +Vsync
# 1600x12024d08
Modeline "1600x1024d08" 103.125 1600 1600 1656 1664 1024 1024 1029 1030 HSkew 1
+Hsync +Vsync
# 800x512d32
Modeline "800x512d32" 54.375 800 800 840 848 512 512 514 515 HSkew 7 DoubleScan
+Hsync +Vsync
# 800x512d16
Modeline "800x512d16" 54.375 800 800 840 848 512 512 514 515 HSkew 5 DoubleScan
+Hsync +Vsync
# 800x512d08
Modeline "800x512d08" 54.375 800 800 840 848 512 512 514 515 HSkew 1 DoubleScan
+Hsync +Vsync

        Identifier   "Monitor0"
        VendorName   "SGI"
        ModelName    "SGI 1600SW"
        HorizSync    31.5 - 125
        VertRefresh  60 - 150
        Option      "dpms"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "i128"
        VendorName  "Videocard vendor"
        BoardName   "Number Nine Revolution IV (T2R4)"
        VideoRam    32768
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
#       SubSection "Display"
#               Depth     24
#               Modes    "1280x1024" "1280x960" "1152x864" "1024x768" "800x600"
"640x480"
#       EndSubSection
    Subsection "Display"
        Depth       8
        Option      "dac_8_bit"
        Modes       "1600x1024d08" "800x512d08"
        ViewPort    0 0
        Virtual    1600 1024
    EndSubsection
    Subsection "Display"
        Depth       16
        Option      "dac_8_bit"
        Modes       "1600x1024d16" "800x512d16"
        ViewPort    0 0
        Virtual    1600 1024
    EndSubsection
    Subsection "Display"
        Depth       24
        Option      "dac_8_bit"
        Modes       "1600x1024d32" "800x512d32"
        ViewPort    0 0
        Virtual     1600 1024
    EndSubsection
EndSection

Section "DRI"
        Group        0
        Mode         0666
EndSection

Gentlemen,

I have created a copy of the SGI cdrom that installs both the # 9 card and the
SGI  flatpanel.  In it I have found the sgi.inf file that was asked for.  I
append it here.  If you require the cdrom, simply let me know whom to send it to
and the address and I will send it immediately.


;-----------------------------------------------------------------------------
;      SGIFPD.INF
;-----------------------------------------------------------------------------
; Revision History:
;
; 00.01.00   SEP 23, 1998  Initial Revision
; 00.01.01   NOV 10, 1998  Added DefaultDestDir.
;-----------------------------------------------------------------------------
;      Copyright 1998  Number Nine Visual Technology Corporation
;-----------------------------------------------------------------------------

[Version]
InfVersion = 01.02
signature  = "$CHICAGO$"
Class      = Monitor
ClassGUID  = {4d36e96e-e325-11ce-bfc1-08002be10318}
Provider   = %SGI%


[Manufacturer]
%SGI% = SGI


[ClassInstall32]
AddReg = ClassAddReg32


[ClassAddReg32]
HKR,,,,%MonitorClassName%
HKR,,Icon,,"-1"
HKR,,NoInstallClass,,1


[SGIFPD.AddReg]
HKR,,DPMS,,1
HKR,,MaxResolution,,"1600,1024"

HKR,"MODES\640,400",Mode1,  ,"30.0,60.0,+,+"
HKR,"MODES\640,480",Mode1,  ,"31.5,60.0,+,+"
HKR,"MODES\800,512",Mode1,  ,"35.0,60.0,+,+"
HKR,"MODES\800,600",Mode1,  ,"37.7,60.0,+,+"
HKR,"MODES\1024,768",Mode1, ,"48.4,60.0,+,+"
HKR,"MODES\1152,864",Mode1, ,"54.3,60.0,+,+"
HKR,"MODES\1280,1024",Mode1,,"64.0,60.0,+,+"
HKR,"MODES\1600,1024",Mode1,,"72.0,60.0,+,+"

HKR,,ICMProfile,0,"SGI5000K.icm"
HKR,,ICMProfile,0,"SGI5500K.icm"
HKR,,ICMProfile,0,"SGI6500K.icm"


[SGI]
%SGIFPD% = SGIFPD.Install, Monitor\SGX0640


[SGIFPD.Install]
CopyFiles = SGI.CopyFiles
DelReg    = DEL_CURRENT_REG
AddReg    = SGIFPD.AddReg


[DEL_CURRENT_REG]
HKR,MODES
HKR,,MaxResolution
HKR,,DPMS
HKR,,ICMProfile


[DestinationDirs]
DefaultDestDir = 11
SGI.CopyFiles = 23


[SourceDisksNames]
1 = %SGIDiskNameStr%,,


[SourceDisksFiles]
SGI5000K.icm = 1
SGI5500K.icm = 1
SGI6500K.icm = 1


[SGI.CopyFiles]
SGI5000K.icm
SGI5500K.icm
SGI6500K.icm


[Strings]
NNVTCstr         = "Number Nine Visual Technology"
SGI              = "Silicon Graphics Inc."
SGIFPD           = "Silicon Graphics 1600SW FP"
SGIDiskNameStr   = "Revolution IV Windows Driver"
MonitorClassName = "Monitor"

Created attachment 91972 [details]
This is the sgi.inf file from the SGI cdrom to install both the #9 card AND the SGI 1600SW Flat Panel Monitor.

I can send the SGI cdrom if it is required.

Created attachment 91973 [details]
This is my RH 9 /etc/X11/XF86Config file.  It has the correct Modelines as well as horizsync and vertrefresh settings.

Note: The modeline settings are exactly those documented in the XFree86.org
documentation to which I direct your attention above.

Reopening and reassinging to hwdata component/owner for FC3
development cycle.

comment #6 is incorrect, this monitor has no analog inputs.  There was
some kind of $500 box you could buy for it that converted analog VGA
to the monitor's digital signal, but I don't have that box.

By the way, thanks for reopening this, and for posting those xf86
files.  I'll drag the monitor out of the closet and try them soon.

The SGI flat panel is already in MonitorsDB.

Up to and including RH 9, Anaconda failed to recognize and set up the
monitor properly for installs, let alone for proper X configuration. 
Remember, the SGI 1600SW flat panel connects to a digital port on the
NumberNine card.

In order to install RH on my systems, I first had to connect a CRT to
the NumberNine VGA port, install RH, reinstall the SGI panel, boot up
to level 3, configure the /etc/XF86Config file for X, then reboot the
system to level 5.

Will Anaconda now recognize the monitor and configure properly for
installs and X now that it is in the MonitorsDB?  If so, at what
release should I expect this to work?  Is it in the current release of
Fedora?

We do not have access to the hardware described in this bug report
in order to test wether it works with our installer or not, so it's
essentially up to someone who does to test it and provide feedback.

Hopefully it works for you if you test it.

If it does not work however, it is unlikely that we would add
support for it at this stage due to the legacy of the hardware,
as the number of people who would benefit from it would be
extremely low.

If it does not work however, and you decide to hack up support
for it for anaconda, please feel free to submit a new request
against the anaconda component with patches attached and someone
will review them for consideration in a future release.