Bug 84834

This would be video driver specific.  ATI users should report their own bugs
separately, and with full information.  I might be able to do something
about the ATI problems perhaps, as I have ATI hardware and docs (although
no LCD display).  I do not have any Nvidia documentation, so any problems
with the "nv" driver like this should be reported to xfree86
please.

Perhaps this isn't driver specific?--I am having *exact* same problem with an 
ATI Radeon 9500 Pro and a Sony SDM-P232 23" flat panel.

A similar problem was encountered and submitted at this bug.

Also talking on the beta list, with others.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84854

Also similar problem reported by here here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84656

I just did a clean install of Phoebe3 and this time I switched cables from DVI
to VGA after the X server had started up.  As I suspected, Phoebe3 had switched
the display to the VGA port.  After installation I tried booting with DVI, and
once again, Phoebe3 switched to the VGA port. 

I'm using a Dell 20" LCD FP2000 in which goes "out of sync" or "idle/safe 
mode" upon entering the RHLinux Phoebe3 installer boot. Some mentioned about 
ATi cards, but I'm using a Geforce 4 Ti4600 (P4, 2.4ghz) and have the same 
problem. Hopefully we see this fixed in an upcoming release :)

Shane) You are using Nvidia hardware, and so your problem will be a totally
separate issue, since Nvidia hardware uses the "nv" driver, and anything
related to issues like this is video driver specific.  This type of stuff
is not handled in generic code that touches all hardware - it is video driver
specific, and in fact specific to the exact video card hardware.

As I said above:
>I do not have any Nvidia documentation, so any problems with the "nv"
>driver like this should be reported to xfree86 please.

If there are any problems with the "nv" driver, they will continue to be
problems until someone reports them to XFree86 directly and the video driver
maintainer can examine them.

This bug report here, is concerning DVI related problems on Radeon hardware,
and since this is a driver specific issue, there is no reason to talk about
Nvidia driver specific problems in this bug report please.

Brian) If there are 2 displays plugged into the card, the DVI port will
always be considered the Primary head by the radeon video driver.  This
is the way the driver is hard coded.

If you're using only singlehead with DVI, then the DVI head should be
the Primary display as well.  I don't have any DVI panels to test or
troubleshoot this with however, so I'm not sure there is anything that
I can do if there is a problem with the Radeon driver and DVI panels,
as I just don't have the hardware to attempt to reproduce the problem.

I just tested with both a CRT and LCD using the VGA and DVI ports, plugging things in at various times and etc.  *I can confirm identical behavior to what Brian Stretch is reporting: Phoebe switches itself over to the VGA port rather than the DVI port no matter what.

However, Brian is using Nvidia card and I am on ATI Radeon 9500... and we have very very similar reports from other users on both types of card (Shane with Nvidia, someone else with an ATI 8500 on the mailing list, some others I dont recall off the top of my head).  Can this really be a driver issue then?  It seems strange to me that both drivers would experience the exact same problem, affecting so many different setups...

The monitor detection code is part of the video driver. So yes, this can
be driver specific.

Please press enter at the end of your line after about 60 characters so
your messages are readable in bugzilla without having to scroll sideways.

Thanks.

This is still a problem for me too using nvidia geforce4 ti with a vga port and
dvi port.  I only have 1 monitor (samsung lcd) hooked up to it.  When I have my
lcd connected to the dvi port, I get a blank screen after text anaconda probe. 
When I have my lcd connected to the vga port, I get the gui install after text
anaconda probe.  So, the output is being forced to the vga port.

As an aside:  I don't have this problem with RH 8.0.  I can hook my monitor up
with the dvi port and install RH 8.0 and it installs perfectly (i.e. I get the
gui installation).

I'm going to send an email to xfree86 shortly here. But I want to 
comment on #9 and #11; that indeed these are almost the same problems. If you 
look at it, it could be Phoebe related.

An update from Mark @ XFree86.org: I don't know much about RedHat's 
installer.  My impression was that they used the vesa driver, not the "nv" 
driver for their installation and it wasn't until later that they configured 
the
"nv" driver.   If they are trying to do the install with the
"nv" driver, that would be a mistake since it has some problems detecting flat 
panels and which head they are on so it usually doesn't "just work" when a 
flat panel is used.

   You could always install in non-graphical mode.


			Mark.
------------------------------

Hopefully this information helps :)

Mark's impression is incorrect.  Our installer attempts to use the driver
which is listed in the Cards database for the detected card.  In almost all
cases, this is the native video driver for the card.  If the native driver
fails to start up, then the installer will fall back to the vesa driver.

>If they are trying to do the install with the "nv" driver, that would be
>a mistake since it has some problems detecting flat panels and which head
>they are on so it usually doesn't "just work" when a flat panel is used.

It would be a mistake of our installer to assume the driver works?  I don't
follow the logic there personally.  I can change this to default to the
"vesa" driver, however doing so will not just change the default driver
used in the installer, but will change the default driver to be "vesa" for
all Nvidia hardware, even at runtime.

We really do not have the resources to maintain 2 separate video driver
mapping databases, one for our installed OS, and one for the installer.
That is just not reasonable.  It's also not reasonable to add hacks to
our installer per video card.

I personally consider this a "nv" driver bug.  It wont get fixed in the
nv driver until fixed upstream however, since we don't have the capability
to do so.  The only thing that I personally can do is:

1) Change the default video driver for both installer+installed system to
   be vesa instead of nv.

or

2) Ask our installer team to make installer hacks to special case Nvidia
   hardware and default to using the vesa driver during install for all
   Nvidia hardware.  I know that "vesa" however does not work properly
   on all Nvidia hardware (GeForce 4 for example) due to past bug reports
   during the development of Red Hat Linux 8.0 where I defaulted the GF4
   to vesa.

Also to be considered, is that "vesa" only works on x86 hardware, and we
can not rely on it working on all other architectures that we support such
as ia64, x86_64, ppc, ppc64.  So the true fix here, is to fix the "nv"
driver to do the right thing.

I am carbon coying some of our installer developers so they can comment
as to wether or not installer hacks specific to Nvidia can be incorporated
or not.

Mark Harris-
Thanks for your time and posting in this particular bugzilla thread. You 
suggest to: â1) Change the default video driver for both installer+installed 
system to be vesa instead of nv.â How do you do this? On my gaming rig, I 
donât have a previous Linux build installed. How would I modify the installer 
to use Vesa instead of NV? 
 
Thanks again, hope to hear from you,
Shane Smart

Ugh.  I hate to say it, but it sounds like the best thing to do is simply
release note this problem and post fixed binaries in Red Hat Updates as soon as
they're available, assuming that the problem isn't fixed before RH8.1 goes gold.
 It's just very confusing as to why RH8.0 worked and Phoebe doesn't, and why are
ATI users having the same problem? 

Also, it's clear that Red Hat needs to dip into the leftover IPO money kitty and
buy Mike a flat panel and appropriate video card :-).  Maybe nVidia can slide a
shiny new GeForce FX5600 your way?  (Though the FX series probably breaks all
sorts of additional things...)  Samsung has a slightly cheaper replacement of
their excellent 191T coming out soon, should be very nice, if you can live with
1280x1024 res.  19" panels are the best bang/buck IMHO. 

I'm sure the problem will be fixed before gold :) At least I hope. I did try 
working with text-mode and that works ;)

Sorry, you misunderstood me.

What I mean, is that the default video driver used by our installer in
graphical install mode, is the exact same driver that will be used in
XFree86 on the installed system.  The driver used, is the one listed
in the "Cards" video card to video driver mapping database.  Whatever
is listed there, is what the installer will use, and what your installed
system will use.  If the listed driver fails for whatever reason during
install, the installer will try to fall back to the "vesa" driver.

_I_ can change the default driver to be "vesa", however that does not just
change it in the installer, it changes it both in the installer, and it
makes it the default video driver used in your installed system.

Basically, whatever is listed in the "Cards" file in the hwdata package,
is the driver that anaconda (the installer) will use during installation.

As such, it is nontrivial to make the installer use vesa, but the installed
system use "nv" for one or more specific cards.  Adding some kind of
infrastructure to allow this, would be IMHO a complex mess, and would
really only be working around video driver bugs.

At this point in time, there is no way that our installer will be modified
to do anything differently for any particular hardware.  Users who have
the problem described in this bug report will have to perform a text mode
installation due to the buggy broken "nv" driver.

For future development however, I there are several options:

1) Add a new flag to the "Cards" file called INSTALLER_DRIVER, which if
   present is the driver for the installer to use.  This is a bad idea,
   as it requires additional maintenance of the driver database by the
   distribution vendor, to work around bugs in the XFree86 video drivers.
   It also does not really handle non-x86 architectures very well, and also
   requires kludges to the installer.  Since the "nv" driver is the only
   problem driver here, I do not believe spending the time to do this kind
   of a hack is a good use of our engineering resources.

or

2) I can change the default video driver to "vesa" for any video card that
   is reported to have problems with the "nv" driver (or any other driver)
   during installation, due to driver bugs, or whatever other reason.  This
   also means that the "vesa" driver will be the default video driver used
   on the user's installed system as well, unless the user manually configures
   X to use the native video driver themselves.

or

3) Our installer is modified with hard coded per-video-card ugly hacks to
   use a particular driver during install, where the native default driver
   in the cards database is known to be broken (the nv driver in this
   example).  I consider this to be an ugly hack to work around inadequacies
   of the broken X driver.  I do not know if our installer team will consider
   this type of hack or not.  If not, then only option 1 or 2 are available,
   and likely if they do not consider #3 to be viable, then they wont
   consider #1 to be any more viable either I presume.

So the most likely scenario is that in our future development, any video
hardware which fails during installation, will have the default driver changed
in our Cards database to the "vesa" driver, which will then end up being used
on that video card both for installation, as well as post installation XFree86
usage.

The real solution, is for XFree86 to have working video drivers by default,
and then we don't need to worry about any kind of ugly hacks.  Only people
who have access to the technical specifications of a given video card however
stand any real chance of making the hardware work properly with a given
native video driver.  Red Hat does not have the technical specifications
for this particular hardware, and thus can not really do much about the
native video driver being broken, other than use "vesa".

Maybe there should be a manual override that users could invoke to select which
video head to use (inconvenient for the user but generic), rather than attempt
to add complexity to the vidcard database (convenient for the user but error
prone)?  Maybe reintroduce the "Test video mode" feature and add a "switch
heads" button there?  Given the reality of XFree driver bugs it looks like we
really need that test feature, even though it's annoying for 99% of the users
out there.  Maybe put a "Use VESA driver" override button there too? 

Release noting the recommendation to switch video heads or try textmode install
if the correct video head is not autodetected in graphical install mode is a
good idea.  That's probably all that's needed really given that we're dealing
with a recently introduced bug that ought to be correctable. 

Also, the nv driver *thinks* it started correctly, so there's nothing to trigger
a fallback to VESA. 

>Ugh.  I hate to say it, but it sounds like the best thing to do is simply
>release note this problem and post fixed binaries in Red Hat Updates as soon as
>they're available, assuming that the problem isn't fixed before RH8.1 goes gold.

Sorry, but if this isn't fixed in XFree86.org sources prior to my
final XFree86 build for our next release, it just will not be fixed
in the final release either.  I do not have Nvidia technical specs,
and I've only got 2 Nvidia cards present to test with, and no DVI
hardware.  Even if I had DVI hardware, and one of every single Nvidia
card here, I would be unable to fix the problem without Nvidia specs,
and that simply is not going to happen.

Assuming this problem does not get fixed in time by upstream, then
it will remain a problem probably for many months, as we simply do
not provide XFree86 updates for single bug fixes, nor for one video
driver problem.  We generally release XFree86 erratum only when there
is a major XFree86 security problem which requires an update, and at
that time, we generally include all of the bug fixes that have
accumulated in the mean time.

We will not respin and QA test an entire XFree86 package set
just for one specific video card problem or even one specific
video driver problem either.  It is just not economically feasible
to do so.  Not as long as XFree86 ships as one huge monolithic
source code build anyway.  If the video drivers were built individually,
that might be an option to ship one video driver update.  But it is
not an option at this point in time.

>It's just very confusing as to why RH8.0 worked and Phoebe doesn't, and

It's not confusing to me at all.  Red Hat Linux 8.0 shipped with XFree86
4.2.0, and Phoebe beta ships with XFree86 4.3.0.  The 4.3.0 nv video
driver is extensively changed compared to the 4.2.0 driver.  There are
hundreds of opportunities for the video driver changes to create problems
in the 4.3.0 codebase that were not present in the 4.2.0 codebase, since
the driver changed dramatically in the last 1+ years since the code
was frozen for the driver that appears in Red Hat Linux 8.0 (4.2.0).

So, it is completely feasible that driver changes occured in the nv driver
in 12+ months of XFree86.org development, which broke the driver, and
perhaps were not adequately tested by XFree86.org and/or driver maintainers.

>why are ATI users having the same problem? 

Well, ATI users would not be having this problem because this problem
is specific to the "nv" driver.  However, it is entirely within the
realm of possibility however that ATI users may indeed be having a very
similar problem.  Coincidences do indeed happen in this world.  But any
coincidence between an Nvidia user experiencing this kind of a problem
using the "nv" driver, and an ATI user experiencing this problem with
the given ATI driver, are just that - a coincidence, since as I have
stated rather clearly before, this is not a generic problem, because
the code used to detect monitors and LCD panels, is not generic X server
code.  It is video driver specific source code, contained in the video
driver specific directory.  That would be radeon_driver.c in the Radeon
driver, and radeon_driver.c is not part of the "nv" driver, so the
problem is definitely not "one" problem common to 2 drivers.  It is
2 problems that are coincidentally similar, which are individual driver
problems.

I don't really see it to be very beneficial to comment on this further in
bugzilla however, as we already know the problem (the nv driver has bugs
in it), and the solution (wait for upstream development to fix the driver).

bstretch) I appreciate your suggestions, but they are only workarounds for
the real problem, and there is already a viable workaround for this problem,
which is to use text mode to install.  Increasing the complexity of the
installer is not IMHO a good idea.

We already have plans for future releases of Red Hat Linux, to remove X
configuration from the installation phase and push it into the "firstboot"
phase which occurs post install.  When this happens, problems such as this
one, which are caused by buggy video drivers, will not happen during install
anymore.

We are setting out to make the installation of Red Hat Linux more simpler,
and to present first time users with less confusing questions.  We're also
setting out to make video configuration just work out of the box as much
as possible, with as little as possible user intervention.  Making any
card specific and/or driver specific hacks, or making any kind of custom
installer kludge/option, just makes things more complicated for users, and
does not simplify anything.

The only options I see happening at all for this release, are the ones I
described above.  Anything more complex than the above would be way too
much change at this stage of development, and is just not going to happen.

Once our release is finalized, then future options can be considered, however
as I've stated above, I do not forsee it being a problem in the future,
as firstboot will handle X configuration.  Hopefully also, the nv driver
will be fixed and work properly too.

Well, I can live with using text-mode. Text mode isn't that bad, I mean, its 
the same thing w/o the GUI. I'm just hoping Nvidia releases a updated copy of 
their Linux driver build upon the RHLinux 8.1 release. Mark, thanks for 
clearing this up for us. Looking forward the gold release of RHLinux 8.1 :)

Ditto what Shane said. 

I meant to imply that hopefully the nv bug would be fixed upstream in time for
RH8.1, not that you should fix it Mike, though I still think RH should buy you a
panel and DVI card so you'll have a better chance of seeing these fun problems
before betas go out.  Besides, one should never miss an opportunity to request
cool toys :-). 

I didn't realize that XFree was *that* monolithic.  And yes, nVidia needs a good
whack with the cluebat for not being more open with their documentation.  Now I
understand why we're left with the textmode install fallback as the only viable
solution, thanks. 

Mike, thanks for all your comments.  You're right; given the relative
infrequency the problem, it doesn't make sense for RH to spend a lot of time
hacking away at a temporary fix.  Text mode install is fine.  I would, however,
put a notation in the release notes so newbies that happen to have h/w similar
to mine (geforce 4 ti 4200 dual head vga/dvi and samsung lcd monitor) won't
freak when 8.1 appears to not install [assuming they read release notes, of
course :)].

Thanks again and can't wait for 8.1!

Wait, so is this affecting you guys only during the graphical  installer?

For me, it happens post-install as well.  E.g., using X is entirely impossible,
even after a successful text install.

Just seeing if we're all on the same page here.

M Rothenberg:  This only affects me at install.  I have a geforce4 ti 4200 with
vga port and dvi port.  I have it hooked up to my lcd thru the dvi port.  When I
install pheobe 3, the anaconda probe finds my monitor, geforce4 ti 4200 etc and
tries to load the "nv" driver, which gives me a blank screen.  So, I use text
mode install, then when installation is done, I boot to prompt, change
xf86config to change reference from "nv" to "vesa", restart X, and I've got X
working fine.  I then did a second pheobe install on same box, but used vga
connection rather than dvi.  I got the gui install from the very start and had
no problems with X at all.  So, to me it looks like the "nv" driver is forcing
the output from dvi to vga.

Changing the bug Summary from "phoebe forces blah blah" to "nv video
cards do not work well with DVI" to more accurately describe the problem,
because this has nothing to do with Phoebe beta, Red Hat Linux 9, nor
with Red Hat specifically.

The problem is that the "nv" driver never has supported DVI hardware in
the past, and now it has "some" support, but it is not very good.  Please
report any bugs with DVI support using the "nv" driver to XFree86.org
bugzilla so that the "nv" driver maintainer whom works at Nvidia, is aware
of the problems and can investigate and fix them.

Changing bug status to UPSTREAM pending upstream solution being made
available.  Please report issue at http://bugs.xfree86.org

Thanks.

A fellow Slashdot reader pointed me to the "FlatPanel" option, and a little
digging turned up the relevant documentation in the nv man page:

       Option "CrtcNumber" "integer"
              nForce2, Quadro4, GeForce4 and NV30 may have two video  outputs.
              The  driver attempts to autodetect which one the monitor is con-
              nected to.  In the case that autodetection picks the wrong  one,
              this  option  may be used to force usage of a particular output.
              The options are "0" or "1".  Default: autodetected.
                                                                                
       Option "FlatPanel" "boolean"
              The driver usually cannot autodetect  the  presence  of  a  flat
              panel  so this option should be set when used with a flat panel.
              With this driver a flat panel will only work if it was POSTed by
              the  BIOS,  that  is, the machine must have booted to the panel.
              Default: off.
                                                                                
I'm happily using nVidia's closed-source drivers now so I haven't experimented
with these nv options, but I suspect some of the rest of y'all can make use of
them. 

I'm processing UPSTREAM flagged bug reports for upstream fixes currently, and
noticed that this bug was flagged upstream but has no upstream bug URL, and I
was unable to find an upstream bug report of this issue in XFree86 bugzilla
located at:

    http://bugs.xfree86.org

Closing bug report as WONTFIX as I'm unable to track upstream until a bug
report has been filed upstream, and the URL provided for tracking.  If this
issue is still relevant in the latest XFree86 packages in rawhide, after
reporting upstream at http://bugs.xfree86.org, feel free to add the bug
report URL to this report and reopen if you'd like the issue to be tracked
and any fixes from upstream investigated for inclusion in future Red Hat
XFree86 updates.

Severn forces the selection of the VGA port instead of DVI but doesn't hose the
video card, which is an improvement.  RH9 did the same thing (forced VGA port
but otherwise worked) on the new box I built for a friend with a shiny new
GeForceFX 5600 card (nForce2 motherboard);  I'll assume Severn would've done the
same.  So things are fixed enough for users to work around the problem.  Install
nVidia's closed-source drivers and you can switch back to DVI. 

Or do the textmode install thing.  Whichever. 

*** This bug has been marked as a duplicate of 88360 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.