Bug 112073

Oh, and my remark above about many problems is _not_ a complaint about
the quality of XFree86, bug fixing speed or anything similar; I just
meant to indicate that I have tried to dig up additional information
but failed to find the exact similar problem elsewhere. My apologies
for the poor wording.

Created attachment 96526 [details]
XFree86 log with successfully started with startx

This is a XFree86.0.log file from when X is started using startx and DVI output
works. Except for the timestamp the only differences are

[root@localhost log]# diff -u XFree86.0.log-working_startx
XFree86.0.log-nonworking_gdm
--- XFree86.0.log-working_startx	2003-12-14 21:35:44.000000000 +0100
+++ XFree86.0.log-nonworking_gdm	2003-12-14 21:34:04.000000000 +0100
@@ -37,7 +37,7 @@
 (**) FontPath set to "unix/:7100"
 (**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
 (==) ModulePath set to "/usr/X11R6/lib/modules"
-(--) using VT number 8
+(++) using VT number 7
 (II) Open APM successful
 (II) Module ABI versions:
@@ -61,7 +61,7 @@
	ABI class: XFree86 Video Driver, version 0.6
 (II) PCI: Probing config type using method 1
 (II) PCI: Config type is 1
-(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
+(II) PCI: stages = 0x03, oldVal1 = 0x80004860, mode1Res1 = 0x80000000
 (II) PCI: PCI scan (all values are in hex)
 (II) PCI: 00:00:0: chip 10de,01a4 card 0000,0000 rev b2 class 06,00,00 hdr 80
 (II) PCI: 00:00:1: chip 10de,01ac card 10de,0c11 rev b2 class 05,00,00 hdr 80

Created attachment 96527 [details]
XF86Config file

There is no technical reason that I can think of, where gdm and startx
should operate differently, because the X server is what reads the
XF86Config config file, and it will invoke the server identically in
each case.

If you start your system, and run "startx" then quit, then run
"startx" again several times does it work properly, or does it fail
the second or third time, etc?

Also, do the same for gdm as well.

One other thing, I see you are using a different VT depending on
wether you're using startx or gdm.  Do you have Red Hat Graphical
Boot (rhgb) enabled?  If so, disable rhgb entirely and try again.

TIA

Right, now I'm really puzzled; I hope the following makes sense.

First of all thanks for the followup. Judging from the log files gdm
and startx are using the same config file, so you are right that there
are no differences there.

My system is FC1 upgraded from RH9, so even if graphical boot was on
it wasn't used. I have disabled it just to be sure.

Then I did something slightly silly - I upgraded to the latest
versions of the kernel, initscripts etc., and this has caused startx
to stop working. The only difference in the log file is that startx
now also uses VT 7.

Forcing startx to run on VT 8 (startx -- vt8) makes it work again, but
doing the same with gdm makes no difference there. The difference
between the log files is the oldVal1 value shown above; with startx it
is always 0x00000000 and with gdm it is always 0x80004860, independent
of the VT used, so something appears to differ between the two ways of
starting X.

startx only works properly once. When exiting X the display does not
switch back to text; instead the graphical display is left on.
Subsequent attempts cause the DVI port to be shut off completely.

So, to summarize:
I'm only able to get output on the DVI port when X is on VT 8 and
oldVal1 is 0x00000000; this is the case when using startx -- vt8. In
all other cases (gdm on any VT with oldVal1 0x80004860, startx on VT 7
with oldVal1 0x00000000) there is no output on the DVI port.

FWIW, I have tried using the driver from ATI, and it appears to have
the exact same problem - the log indicates that the display is
detected  correctly, but there's no display on the DVI port. The
analog port works fine.

I can confirm this bug on clean Fedora Core 1 with Powercolor Radeon
9200 SE video card and Samsung Syncmaster 191T on DVI port.  The DVI
port works perfectly well (1280x1024 60hz) every OTHER invocation of X
(that is, one invocation has no signal on DVI, the next has signal on
DVI, the next has no signal again...) -- again the only distinction in
the XFree86 log is whether it shows VT 7 or VT 8:

[rob@bluedog log]$ diff XFree86.0.log XFree86.0.log.old
21c21
< (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan  6 00:19:57 2004
---
> (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan  6 00:19:40 2004
42c42
< (--) using VT number 7
---
> (++) using VT number 8

This is a known and possibly fixed problem, check here:
http://bugs.xfree86.org/show_bug.cgi?id=673

Apparently you can try the latest driver from
http://www.xfree86.org/~alanh/

I will do that a bit later and tell you if anything changes
(I have the same prob - no DVI on 9200).

Uhm, yes DVI works with the latest driver/server from the link above. 

However it's not worth the trouble: the picture quality is noticeably
worse - red color is quite misconverged with the other two, which is
seen on any small text, any resolution. Dunno if it's the card
(Sapphire Ati Radeon 9200 64Mb) or the monitor (Viewsonic VP171s) but
going back to good old analog link...

Created attachment 97246 [details]
antialias problem

Oops. This is actually an antialiasing problem with Xft applications.
Strangely, it disappears if I either switch to Gnome (from WindowMaker) or run
gnome-font-properties and then restart an application.

Yes! I can confirm that running with the latest radeon_drv.o from Alan
Hourihane makes the DVI port work very nicely.

Thanks for the hint.

I can confirm this too (radeon_drv.o of date 2003-12-03).

Is XFree86 4.4.0 going into FC2?

Uhm. But you don't necessarily need to ship the whole of XFree 4.4 in
FC2. Just the latest drivers will do. Is that planned?

I somehow missed Alex's reference in comment #8 to the upstream bug
report which contains a patch from Hui Yu at ATI, which claims to fix
this problem.  I have looked at the patch and it is very trivial,
and appears to be a very low risk patch that should not affect any
other hardware.

As such, I have queued the patch for inclusion in a future XFree86
build, which will probably be available within the next week or so
in rawhide.  I'll update this report when there is something
available for testing.

Thanks.

XFree86-4.3.0-55 doesn't seem to include the fix unfortunately. Had to
revert to the binary driver provided by xfree86.org.

Can we expect the fix to appear in one of the Fedora Core 2 test 
releases? It's just a trivial one-liner and has been confirmed 
as working by at least four people already.

Is this the patch?
http://bugs.xfree86.org/attachment.cgi?id=604&action=view

If not, please attach the one liner as a unified diff attachment
taken from the root of the tree, and I'll review it.

It should be. I've just checked - it was actually commited to XFree
CVS together with a bunch of other radeon fixes:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c?only_with_tag=xf-4_3_99_14
but I'm not asking you to include them all. :)

Someone has confirmed via email a patch that allegedly fixes this
issue, and I have applied it to 4.3.0-59.  I do not have the
hardware to test this personally, however I have added it, and hope
that it fixes the problems you've encountered.  Please test the
new release once it is available in rawhide, and provide feedback
as to wether or not it works for you.

If you need a driver for Fedora Core 1, you can extract the
radeon_drv.o file out of the main XFree86-4.3.0-59.i386.rpm, and
rename the old driver, and drop this one in it's place for test
purposes.

Hope this helps, and thanks in advance for testing.

4.3.0-59 is in rawhide now.  Please test it, and close this bug
as "RAWHIDE" if it is now fixed, otherwise please set status back
to "ASSIGNED".

The 4.3.0-59 works fine for me. Thanks - I was just about to build my
own patched package. I'm not allowed to do any changes to the bug
status though.

Ok, thanks for the update.

Closing as fixed in 'RAWHIDE'

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-118.html

Uh, why not issue an errata for FC1 also? I understand that FC2 is
just around the corner, but it still seems a bit improper to me.

Hi Alex,

Fedora Core 1, Red Hat Enterprise Linux 3, and Red Hat Linux 9 all
share XFree86 4.3.0 from the same src.rpm.  The package is configured
slightly differently on each OS release due to dependancies on a
particular compiler version for some features, etc. but the base
code is shared.  As such, any bug fixed for 4.3.0 will come from the
same src.rpm for all OS releases.  Whenever erratum is released for
a particular OS release, that release will benefit from all bugfixes
applied to date, unless they are release specific in some manner
(which is rare).

The reason this is released for RHEL 3 only, is that an update
was made available for RHEL 3 for other reasons, and this bug fix
just happened to be included along with the quarterly updated for
RHEL 3.

Technically the bug is against FC1, and I'd marked it as "RAWHIDE"
above, which at the time meant "Fixed in rawhide, and also will
be present in any future erratum released for FC1".  That still
holds true now, however this bug alone is not enough reason to
release an erratum for FC1.

Rest assured however that there will be further updates for FC1
made available in the future which will include this bug fix and
all others, however RHEL3 errata and FC1 errata are not necessarily
released in tandem, unless they are security updates.  We do not
generally release updates for software for FC except for security
reasons, so you should see this fix in the next security update
for FC1.

If you require the fix immediately, I can make rpm packages available
to you on people.redhat.com for FC1, however there are no plans
to release official FC1 erratum for the time being, unless there
are security issues discovered in X which require immediate fixing
and release.  The 4.3.0 src.rpm will recompile for FC1 once the
spec file is edited and a few macros tweaked (documented in spec
file).

Hope this helps.

Hi Mike,

oh, that's fine with me. I actually have been using the rawhide
version for months, and just upgraded to FC2 with no trouble. But I
have a question about "future updates for FC1". Is there any rule or
policy about for how long updates for the previous FC are going to be
produced, after the new release is out? Couldn't find it anywhere. 

Oops. Should have looked at the FC FAQ. Two to three months, it seems.