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 How reproducible: Always 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 @@ Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" - DefaultDepth 8 + DefaultDepth 16 SubSection "Display" - Depth 8 - Modes "640x480" + Depth 16 + Modes "1024x768" EndSubSection EndSection Additional info: 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. ddcprobe output: [root@shur root]# ddcprobe Videocard DDC probe results Description: 3DLABS PERMEDIA2 REF Memory (MB): 0 Monitor DDC probe results Monitor DDC Probe failed. [root@shur root]# 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 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.