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
this bug.)

Hi Barry,

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
>what XFree86
>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
beasts.

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!

TTYL

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
computer on.)

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
before.

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
this statement:

    xf86DrvMsg(pScrn->scrnIndex, from, "VideoRAM: %ld kByte\n",
                   pGlint->FbMapSize / 1024);

in xc/programs/Xserver/hw/xfree86/drivers/glint/glint_driver.c

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
severely crippled.)

The glint driver is grabbing the video RAM amount out of one of the
card's registers.

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
kudzu code...

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
8MB.

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):

cd /usr/lib/python2.3/site-packages/rhpl
patch -p0 -b -i /home/whoever/videocard.patch

where the patch was saved as "videocard.patch" in the directory
"/home/whoever".

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:
ID:     None
Name:   None
HorizSync:  None
VertSync:   None

When the gui runs all the resolutions are fine and the gui runs at 
800x600.

However setting properties from this poind does not survive a boot so 
it will never run higher than 640x480.

Any Comments?

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":
and
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
this bug.

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
available.

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.