Created attachment 117165 [details]
Rage 128 Pro AGP 16 MB from a Dell PC

This is the particular card that failed.
Another Rage 128 Pro (AGP, 32 MB) worked fine.

Created attachment 117166 [details]
xorg.conf (Try 1)

Created attachment 117167 [details]
Xorg.0.log with Dell D1025TM CRT monitor (Try 1)

The monitor I used here is a 1600 X 1200 capable CRT monitor.

Created attachment 117168 [details]
Xorg.0.log with HP 1740 LCD monitor (Try 1)

The monitor I used here is a 1280 X 1024 native resolution LCD monitor.

Created attachment 117169 [details]
lspci output

Strange. This R128TF chipset is listed as having DFP capability (not in the unconfirmed section). Of course plenty of these chipsets can be given VGA outputs but then I'd expect their connector tables to indicate this.

The old driver got around this by assuming a CRT monitor instead of no monitor. I always thought this was slopiness in lieu of better detection code. But I guess I'll have to go this route as well. It in fact makes up for manufacturer slopiness.

(In reply to Connor Behan from comment #6)

Hi Connor,

Thank you very much for the response.
The thing about Rage 128 is that ATI Technologies appeared to have Apple PowerMac versions of Rage 128 Pro that had both DVI and VGA (I actually bought one at WeirdStuff in Sunnyvale, CA several months ago.), but ATI Technologies does not appear to have such a version for x86 PCs.
I do own PCI version of Rage 128 (16 MB) and AGP version of Rage 128 Pro (32 MB, the one with both DVI and VGA), but of course, they do not work with an x86 PC (i.e., firmware).
I do not own any major Apple products, so I have no way to test these PowerMac version Rage 128 graphics cards.
That being said, I am sure there are some Apple product users who will appreciate if the Rage 128 x.org code worked properly with PowerMac, including DVI.
    Regarding an x86 version Rage 128 Pro with DVI, I have not seen one so far.
Maybe it exists, I have never been able to obtain one.
If I am correct, DVI itself is constructed with some signals from VGA included.
This is how DVI to VGA dongle works by exposing the VGA portion signals, so that an old VGA monitor can be reused with DVI capable graphics cards.

https://en.wikipedia.org/wiki/Digital_Visual_Interface

I am not sure how the monitor type detection is done, but I assume the flat panel you are using is hooked up via the integrated TMDS transmitter.
I assume DVI also uses this.

Regards,

Kevin Brace


> Strange. This R128TF chipset is listed as having DFP capability (not in the
> unconfirmed section). Of course plenty of these chipsets can be given VGA
> outputs but then I'd expect their connector tables to indicate this.
> 
> The old driver got around this by assuming a CRT monitor instead of no
> monitor. I always thought this was slopiness in lieu of better detection
> code. But I guess I'll have to go this route as well. It in fact makes up
> for manufacturer slopiness.

Created attachment 117325 [details] [review]
Likely fix

Yes, when a DFP is detected, the TMDS registers are invoked. Detection is done with i2c but the driver doesn't try VGA-style and DVI-style i2c detection every time. Which one it tries is determined by the BIOS connector table which seems messed up on your card. So this patch makes it more conservative. Does it help?

Also, it's cool to know that some PPC-only cards have VGA and DVI. I'm almost certain that the driver was never able to use both outputs, but patches for that might be reasonable.

Created attachment 117365 [details]
Xorg.0.log with Dell D1025TM CRT monitor (Try 2)

Take a look at the following line somewhere in the log.

(II) R128(0): Output DVI-0 using initial mode 2048x1536

(In reply to Connor Behan from comment #8)

Hi Connor,

Applied the latest patch to the code base that had commit d6dd6c9ad5ba8e4950c9398d93298fea48745263 already applied.
Please take a look at Xorg.0.log.
It appears that 2048 X 1536 screen resolution is being selected.

...
(II) R128(0): Output DVI-0 connected
(II) R128(0): Using fuzzy aspect match for initial modes
(II) R128(0): Output DVI-0 using initial mode 2048x1536
(II) R128(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
...

I am not even sure such a resolution is even supported in the first place, but maybe Rage 128 Pro supports such a resolution for DVI.
That being said, my Dell monitor does not support such a resolution, and I do not believe I own such a monitor in the first place.
The device driver did work correctly with a different Rage 128 Pro 32 MB AGP (Xpert 2000 Pro OEM; a graphics card with an odd 'L' shaped layout), so this issue does not affect true VGA output only cards.
    I do not know exact how the monitor screen resolution detection is done, but I am hoping that INT 10H detection method is being avoided since PowerPC version of the device driver cannot use it, and it is problematic for x86-64 (AMD64) Linux.
Please note that one can use Rage 128 Pro AGP with x86-64 Linux since there were several vendors that had chipsets with AGP support around the time of AMD Athlon 64 launch (i.e., NVIDIA nForce 3, SiS 755 / 760GX, ULi M1689 / M1567, VIA Technologies K8T800).
Many Socket 939 mainboards supported up to 4 GB of RAM, but I do own ASRock 939Dual-SATA2 mainboard, which is capable of 8 GB of RAM if I use their Future CPU port.

http://www.anandtech.com/show/1782
http://www.asrock.com/mb/ULI/939Dual-SATA2/

I happened to own the AM2CPU board that fits into the Future CPU Port to make 939Dual-SATA2 8 GB capable using DDR2 SDRAM.

http://www.asrock.com/mb/spec/upgrade.asp?Model=AM2CPU%20Board

I also own ASRock AM2NF3-VSTA mainboard (NVIDIA nForce 3 250 chipset), so this mainboard can natively support more than 4 GB of RAM with AGP.

http://www.asrock.com/mb/NVIDIA/AM2NF3-VSTA/index.asp

I have not tested your code in an x86-64 environment yet, but I will try it eventually.

Regards,

Kevin Brace


> Created attachment 117325 [details] [review] [review]
> Likely fix
> 
> Yes, when a DFP is detected, the TMDS registers are invoked. Detection is
> done with i2c but the driver doesn't try VGA-style and DVI-style i2c
> detection every time. Which one it tries is determined by the BIOS connector
> table which seems messed up on your card. So this patch makes it more
> conservative. Does it help?
> 
> Also, it's cool to know that some PPC-only cards have VGA and DVI. I'm
> almost certain that the driver was never able to use both outputs, but
> patches for that might be reasonable.

Created attachment 117366 [details]
XAA-based Lubuntu 10.04 Xorg.0.log with Dell D1025TM CRT monitor

Just for your reference, I attached the Xorg.log.0 from Lubuntu 10.04.
The monitor is being detected correctly, and I start Lubuntu with 1600 X 1200 screen resolution.
Please note that the x.org DDX device driver uses XAA (i.e., the code base is from 2010).
I did not use your updated device driver for this experiment.
There must have been a regression within the past 5 years.
The device I used here is Rage 128 Pro Ultra TF.

(In reply to Kevin Brace from comment #10)
> (In reply to Connor Behan from comment #8)
> 
> Hi Connor,
> 
> Applied the latest patch to the code base that had commit
> d6dd6c9ad5ba8e4950c9398d93298fea48745263 already applied.
> Please take a look at Xorg.0.log.
> It appears that 2048 X 1536 screen resolution is being selected.
> 
> ...
> (II) R128(0): Output DVI-0 connected
> (II) R128(0): Using fuzzy aspect match for initial modes
> (II) R128(0): Output DVI-0 using initial mode 2048x1536
> (II) R128(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
> ...
> 
> I am not even sure such a resolution is even supported in the first place,
> but maybe Rage 128 Pro supports such a resolution for DVI.
> That being said, my Dell monitor does not support such a resolution, and I
> do not believe I own such a monitor in the first place.

The only thing my patch does is lie to Xorg that a monitor was detected even though it wasn't. So no information about supported modes is being read. 2048x1536 is just being selected as it is the largest resolution from the default set.

This is an example of why r128 users should write an xorg.conf. Put a line there specifying what resolution you want so that it won't use the largest default anymore. The only reason users of newer cards don't have to worry about this is that newer cards provide more / better-documented ways of announcing that they are VGA and not DVI.

> The device driver did work correctly with a different Rage 128 Pro 32 MB AGP
> (Xpert 2000 Pro OEM; a graphics card with an odd 'L' shaped layout), so this
> issue does not affect true VGA output only cards.
>     I do not know exact how the monitor screen resolution detection is done,
> but I am hoping that INT 10H detection method is being avoided since PowerPC
> version of the device driver cannot use it, and it is problematic for x86-64
> (AMD64) Linux.

Exactly. Writing platform independent code to replace that was one of the hard parts of the randr support. It's just that when that code ALSO fails (due to cards with improper tables), we can only guess and use an xorg.conf to improve that guess.

> Please note that one can use Rage 128 Pro AGP with x86-64 Linux since there
> were several vendors that had chipsets with AGP support around the time of
> AMD Athlon 64 launch (i.e., NVIDIA nForce 3, SiS 755 / 760GX, ULi M1689 /
> M1567, VIA Technologies K8T800).
> Many Socket 939 mainboards supported up to 4 GB of RAM, but I do own ASRock
> 939Dual-SATA2 mainboard, which is capable of 8 GB of RAM if I use their
> Future CPU port.
> 
> http://www.anandtech.com/show/1782
> http://www.asrock.com/mb/ULI/939Dual-SATA2/
> 
> I happened to own the AM2CPU board that fits into the Future CPU Port to
> make 939Dual-SATA2 8 GB capable using DDR2 SDRAM.
> 
> http://www.asrock.com/mb/spec/upgrade.asp?Model=AM2CPU%20Board
> 
> I also own ASRock AM2NF3-VSTA mainboard (NVIDIA nForce 3 250 chipset), so
> this mainboard can natively support more than 4 GB of RAM with AGP.
> 
> http://www.asrock.com/mb/NVIDIA/AM2NF3-VSTA/index.asp
> 
> I have not tested your code in an x86-64 environment yet, but I will try it
> eventually.
> 
> Regards,
> 
> Kevin Brace
> 
> 
> > Created attachment 117325 [details] [review] [review] [review]
> > Likely fix
> > 
> > Yes, when a DFP is detected, the TMDS registers are invoked. Detection is
> > done with i2c but the driver doesn't try VGA-style and DVI-style i2c
> > detection every time. Which one it tries is determined by the BIOS connector
> > table which seems messed up on your card. So this patch makes it more
> > conservative. Does it help?
> > 
> > Also, it's cool to know that some PPC-only cards have VGA and DVI. I'm
> > almost certain that the driver was never able to use both outputs, but
> > patches for that might be reasonable.

(In reply to Kevin Brace from comment #11)
> Created attachment 117366 [details]
> XAA-based Lubuntu 10.04 Xorg.0.log with Dell D1025TM CRT monitor
> 
> Just for your reference, I attached the Xorg.log.0 from Lubuntu 10.04.
> The monitor is being detected correctly, and I start Lubuntu with 1600 X
> 1200 screen resolution.
> Please note that the x.org DDX device driver uses XAA (i.e., the code base
> is from 2010).
> I did not use your updated device driver for this experiment.
> There must have been a regression within the past 5 years.
> The device I used here is Rage 128 Pro Ultra TF.

I guess you can call it a regression. In both cases, a random mode is being guessed from the pool of defaults. If the randr extension is in use, X offers up default modes as large as 2048x1536. If not, it offers ones that are smaller and more likely to work. I'm not sure why.

I have this problem, no screens with usable configuration, no VGA port reported, with the same part number DVI-port-free/VGA port only Rage 128 Ultra card pictured in the first attachment, running server 18.0, kernel 4.3.3, driver 6.10.0 (openSUSE Tumbleweed).

The patch has been tested and released with 6.10.1. Please re-open this if the bug comes back.

6.10.1 works in openSUSE Tumbleweed on comment 14 machine, though with trivial UI font corruption I've never seen on other KDE3 or openSUSE installations, nor using other gfxcards.

http://lists.opensuse.org/opensuse-factory/2016-02/msg00165.html has more behavioral detail.

(In reply to Felix Miata from comment #16)
> 6.10.1 works in openSUSE Tumbleweed on comment 14 machine, though with
> trivial UI font corruption I've never seen on other KDE3 or openSUSE
> installations, nor using other gfxcards.
> 
> http://lists.opensuse.org/opensuse-factory/2016-02/msg00165.html has more
> behavioral detail.

Bug 88767 is the bug for this. The problem is the 2D acceleration of r128 and it first showed up when people started using EXA instead of XAA. Apps like KDM (and other text-heavy programs that link to libXrender) try to composite hundreds of characters per second and a fraction of them end up corrupted. I don't know if a software fix is possible. It may be that the GPU never expected it would have to do that many operations. So it would be interesting to see if other ~2000 era cards that use different EXA drivers are able to handle this.