Red Hat Bugzilla – Bug 108681
system-config-display only allows 800x600 on Diamond FireGL 1000 Pro, with any monitor configured
Last modified: 2008-08-02 19:40:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Description of problem:
redhat-config-xfree86 does not appear to allow selection of resolutions above
800x600 on a Diamond FireGL 1000 Pro, no matter what kind of monitor is
selected. Editing /etc/X11/XF86Config manually allows higher resolutions, however.
Version-Release number of selected component (if applicable):
redhat-config-xfree86-0.9.15-1, hwdata-0.101-1, fedora-release-1-2
Steps to Reproduce:
1. Install Fedora Core.
2. Go through the firstboot wizard.
3. Press control-alt-F1.
4. rm /etc/X11/XF86Config
5. run redhat-config-xfree86
6. Notice that no monitor has been detected via DDC, and that you are only
allowed to select 640x480. Select a Generic 1280x1024 (or 1024x768 or whatever
-- anything above 800x600).
7. Try to choose a new, higher resolution.
Actual Results: After specifying the monitor, I can only choose 800x600. I
can't choose anything higher!
Expected Results: I expect to be able to choose 1024x768, since I can manually
patch my XF86Config as follows to get it to work as I wish:
--- XF86Config.bogus 2003-10-30 18:33:54.000000000 -0800
+++ XF86Config.works 2003-10-30 18:56:55.000000000 -0800
@@ -106,10 +106,10 @@
- DefaultDepth 8
+ DefaultDepth 16
- Depth 8
- Modes "640x480"
+ Depth 16
+ Modes "1024x768"
At a resolution of 800x600, any color setting above 256 colors doesn't seem to
"stick" (I think that's the case for Thousands, that's absolutely the case for
Millions). That could be the same bug for all I know, so I haven't filed a
separate bug for that, at this point.
[root@shur root]# ddcprobe
Videocard DDC probe results
Description: 3DLABS PERMEDIA2 REF
Memory (MB): 0
Monitor DDC probe results
Monitor DDC Probe failed.
On this card/computer/etc., DDC probing of the monitor appears to always fail,
even with a monitor that probes perfectly well on a newer computer/card.
The video RAM returned by the DDC probe is totally bogus. This is what XFree86
itself detects. according to this line in /var/log/XFree86.0.log:
(--) GLINT(0): VideoRAM: 8192 kByte
I have not tried Red Hat 8.0 or 9 on this computer yet. A similar computer (same
type of video card, same type of CPU, same type of motherboard) is running Red
Hat 7.3 without problems, but RHL 7.3 didn't come with redhat-config-xfree86 so
the comparison may be irrelevant.
Red Hat 9 happens to work fine for the video configuration, because in
that release Anaconda (I think; it happens in the installer anyway)
asks me to specify the amount of video RAM.
One of these days I need to glance at the redhat-config-xfree86 source
code to see what it's doing... (I doubt I'll be doing this within the
next week though)
Can you try the redhat-config-xfree86 that shipped in RHL 9 to see if
the behavior has changed?
Do you mean trying r-c-xf86 from RHL9 on an RHL 9 installation, or
installing it into Fedora Core and trying that? I assume you mean the
latter, but I'm not 100% certain. Either way, I'll try to do this soon
(in the next week or so).
Try to downgrade your Fedora Core's redhat-config-xfree86 to the
r-c-xfree86 that shipped in RHL 9 and see if that works. If that
works, then something changed in r-c-x between RHL 9 and FC1.
Sorry I took so long to do this.
Anyway, I've tried it now. With RHL 9's r-c-xf86, I get tons of
resolution options (going all the way to 2048x1536), and
256/thousands/millions of colors. No matter what I choose (for 800x600
or up anyway; I didn't try choosing 640x480) it actually appears to
set 800x600 with 256 colors, though...
Is there anything else you want me to try?
Hmm, I can't think of much else to try. I don't have a Diamond FireGL
card in the test lab so I'm not able to reproduce this behavior on my
test machines. To be honest, the FireGLs don't seem to be that common
anymore. I haven't seen any similar reports with more recent hardware.
If I had one in-house to test with I might be able to figure out what
is going on. However, given the age of the card I'm not sure that it
would be worth the time. I'm going to close this report as 'wontfix'
Reopening bug and reassigning to myself. I now happen to own this
hardware, so I'm investigating this bug further (because I can). I
already have additional information to add to this report, but I just
started looking into this again so I'm not quite ready to add that
info just yet.
(BTW I very highly doubt I will be asking for Red Hat's help in fixing
Here's some info that might be helpful to you in trying to get
this to work...
>The video RAM returned by the DDC probe is totally bogus. This is
>itself detects. according to this line in /var/log/XFree86.0.log:
>(--) GLINT(0): VideoRAM: 8192 kByte
Just to clarify a bit, "DDC probing" (Display Data Channel) in a
nutshell is a plug and play signal sent to the monitor from the
video card, which if the monitor supports DDC, it returns it's
plug and play information, known as "EDID" block. This data
contains various information about the monitor's capabilities.
DDC probing does not tell the X server how much videoram is
on the card however, as that is a function of the card, not
the monitor. Each video driver has it's own code for probing
the video hardware to determine how much video memory is
present, but that is a separate unrelated operation from
the DDC probe.
Most X drivers do have the correct code to properly probe the
video hardware and determine the correct amount of video memory,
but there are some drivers which rely on the end user to supply
this information due to lack of hardware documentation needed
to properly implement memory detection.
The good thing, is that most hardware from the last 5 years or
so which is supported, the drivers do have code to properly
detect the amount of video memory. The bad thing, is that there
are some drivers for older hardware for which this information
was never made available from the manufacturers, and nobody was
able to figure it out by trial and error of poking at card
registers, so the VideoRAM setting must be manually supplied.
Very very old Nvidia hardware fits into this category (Riva era.)
as well as Matrox G400 and a couple other old mga cards. There
are various other older hardware to which video memory can't
be automatically detected as well, and they'll need manual
intervention too. I believe the FireGL 1000 is one of these
The config tool determines the amount of video memory present
from the video driver's probing routines essentially, and so
if the driver can't detect video memory correctly, then our
config tool will assume the amount of video memory is whatever
the video driver defaults to if it hasn't been specified. So
if 8192Kb is given, it will restrict the resolution choices
to modes that fit within this amount of video memory. DRI and
other things also use video memory, so the config tool might
make some guesses about reserving memory for DRI/Xv operation,
etc. but I'm not sure about that for certain.
If I remember correctly, the FireGL 1000 boards were a bit of
an oddball also. I'd have to check to be certain, but there
were some 3Dlabs cards which kept texture memory completely
separate from framebuffer memory back in that time era. and
this might be one of them. Alan would know the details for
sure. Also, some of these old cards have a separate 2D chip
built in, often an old Cirrus Logic or something for 2D, with
the 3D engine being 1 or more separate chips. On these boards
each chip shows up as a separate video chip, which makes
hardware detection and autoconfiguration take on a whole new
world of pain. ;o)
Not sure if any of this info will be useful to you for fiddling
with this, but I hope it turns out to be. You may also want
to poke at the glint driver sources for more clues to how
the driver hardware detection works, etc.
Hope this helps!
I'll re-read your comment more carefully in the next day or two to try
to understand it in detail, but are you saying that the video RAM
figure shown by "ddcprobe" doesn't actually come from DDC probing?
At this point I'm starting to suspect that the guilty component is
actually pyxf86config, but I haven't read enough of its source yet to
be 100% sure -- it's just a hunch at this point.
If I run system-config-display (or redhat-config-xfree86 in Fedora
Core 1) like this:
system-config-display --set-videoram=8192 --forceui
*then* everything works properly. ("8192" is showing up both in
XFree86.0.log/Xorg.0.log and on the VGA BIOS screen when I turn the
AFAICT from all that I've seen so far is that the X server is
successfully detecting (or guessing) the video RAM but that the config
tool is getting confused somehow...
>I'll re-read your comment more carefully in the next day or two to try
>to understand it in detail, but are you saying that the video RAM
>figure shown by "ddcprobe" doesn't actually come from DDC probing?
Correct. DDC (Display Data Channel) is strictly a communication
channel between the video adaptor and the monitor to allow the
video driver or other software to probe the monitor for it's
plug and play settings.
Video memory is a function of the video card itself and unrelated
to DDC probing.
An additional complexity is that the 'ddcprobe' utility probes
the monitor pnp data differently than the video drivers do. This
causes a few inconsistencies, since the video driver is always
going to do a better job because it knows the hardware more
intimately. The ddcprobe utility for simplicity just uses the
video BIOS to probe the monitor (VBE), as that is generic way that
works on all video hardware. Unfortunately it isn't very flexible,
and doesn't always work properly. It also only works on x86
architecture. The video drivers use one of two methods. The
"good" drivers directly probe the monitor via talking direct
to the hardware and using the i2c bus. This code is much more
complicated than using the BIOS, and it is very specific to the
hardware and how it is wired. This gives the best results when
it is correctly programmed. Some of the drivers don't have
direct DDC/i2c code and also use the video BIOS instead.
So you may find that the results of ddcprobe may differ from
the video driver's log file messages for DDC info depending
on the hardware. That's normal. Unfortunately there's no
easy way to do ddcprobe the way the video driver does it as
it is very hardware specific.
>AFAICT from all that I've seen so far is that the X server is
>successfully detecting (or guessing) the video RAM but that the
>config tool is getting confused somehow...
That's possible. I believe the tool parses the X server output,
so if any of the drivers write out the video memory in a slightly
different text pattern, our tool might not pick it up correctly.
People reported bugs to us for Xconfigurator about this problem
If you find this to be the case, it would be nice to fix both
our tool to handle this better, but also to fix the video driver
if it is using a slightly different log file message than the
others do. If this is the case, let me know and I'll try to
change the driver as well.
Ok, thanks for all the information, this is very very helpful!
I'm looking at this again, because this FireGL card may end up
becoming my main graphics card for the near future. I think the
problem isn't pyxf86config either, now...
I'll probably have more info later tonight, but there are at least two
bugs I'm bumping into. One is in the rhpl package. The other bug is
probably in either the kudzu package or the video card's BIOS.
The rhpl bug is now bug 138332.
In case it's relevant (I don't really know if it is yet), the code
that prints the video RAM amount to the logs in the glint driver is
xf86DrvMsg(pScrn->scrnIndex, from, "VideoRAM: %ld kByte\n",
pGlint->FbMapSize / 1024);
vbetest under MS-DOS claims this card has 512KB of video RAM. That's
the same figure that ddcprobe is obtaining from kudzu. So, the card's
BIOS is lying through its teeth. (Actually, after playing around with
vbetest, it looks like the video BIOS isn't just lying -- it's
The glint driver is grabbing the video RAM amount out of one of the
It seems to me that the config tool is asking pyxf86config or rhpl
(depending on where in the code you're talking about), and those in
turn are asking kudzu (although it looks like there may be
special-case code in rhpl itself, too). I don't see anything anywhere
grepping the X log files, although I'm still looking at the rhpl and
I think rhpl is where a fix/workaround needs to be added. I expect to
have a patch later today.
Created attachment 106292 [details]
videocard.py patch for rhpl-0.148: assumes 8MB if a Permedia2 card supposedly has < 2MB
This patch automatically assumes 8MB of RAM for Permedia2 cards that report
less than 2MB. (A Permedia2 card with less than 2MB of RAM is a physical
impossibility. My experience, BTW, is that 4MB and 8MB are much more common
than 2MB. Google searches seem to suggest this too.)
This patch does let the user set a resolution/depth that exceeds the available
RAM if the card has less than 8MB. However, testing with 2MB VideoRAM specified
in xorg.conf (after creating xorg.conf using "system-config-display
--reconfig") showed that Xorg gracefully backs down to a lower resolution. IMO
that's better than rejecting valid configurations for someone who has 4MB or
Sorry about the newbie question here. How do you apply this patch and
where as I have the Diamond Fire GL 1000 Pro video card?
As root, run (for example):
patch -p0 -b -i /home/whoever/videocard.patch
where the patch was saved as "videocard.patch" in the directory
Then run system-config-display again. (If you still have problems
after applying the patch, then make sure you are manually specifying
your monitor if it wasn't detected automatically. If that still
doesn't work, try "system-config-display --reconfig".)
Thanks you so much...it worked great! I have all the resolutions back
and they all work. Fedora core 3 even sees the card correctly now, but
to get it to work I did have to run the reconfigure command. Thank you
for taking the time research this issue and acually fix the problem. I
know it just a patch, but this just makes me get more interested in
linux and learning more and more about it. Thanks again.
This issue is also happening on a Cirrus Logic GD544x. I have applied
the patch and it has not resolved the issue.
When I run "system-config-display --set-videoram=8192 --forceui" all
my resolutions become avalilble however when running it, prior to it
starting i get;
ddcprobe returned bogus values:
When the gui runs all the resolutions are fine and the gui runs at
However setting properties from this poind does not survive a boot so
it will never run higher than 640x480.
Re: comment #22
My patch is specific to Permedia2 video cards, which is why it didn't
work for you. Without having a GD544x of my own, I'm not sure I can
develop a safe patch to do for it what my patch does for Permedia2
cards. (BTW in your case, something like "--set-videoram=1024" or 2048
would be closer to reality, although if you know the exact amount, go
ahead and use that number.)
With old video cards like these, you must also manually specify the
type of monitor you have (there's a tab for this in
system-config-display). If your monitor brand/model is not in the
list, file a separate Bugzilla for that and choose one of the
"generic" models in the meantime.
If that still doesn't work, I don't know what to suggest, sorry...
Well i better have a go at creating a patch. I guess the only things
that would change would be;
if cardData["DRIVER"] == "i810":
if (cardData["CHIPSET"] == "PERMEDIA 2") and (cardMem < 2048):
Do you agree?
This isn't a reply to comment #24 (I forgot about that comment and will need to
reply to it later), but just a general comment about the hardware involved in
It turns out that my Diamond FireGL 1000 Pro is incapable of DDC under Windows
XP, too. (I haven't had a chance to try earlier Windows releases, so I don't
know if DDC ever worked. DDC certainly doesn't work in XP, though, but the
card/driver seems to work otherwise.)
The behaviour of X under FC6 is significantly different, so I'd appreciate any
reports of this still being relevant. In particular the X server will aim for
pretty large resolutions by default, and s-c-d will trust the X server's list of
available resolutions rather than guessing (usually wrongly) how much VRAM is
So, marking this as NEEDINFO from reporter. Please reopen if this is still an
issue for you in FC6.
NEEDINFO timeout, resolving as INSUFFICIENT_DATA.