Red Hat Bugzilla – Bug 27687
Neomagic 256av fails to configure properly
Last modified: 2007-04-18 12:31:29 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Going through the graphical install, when we get to the probing of the video device it chooses Neomagic 256 with 256k of VRAM. The chip actually has 2.5 meg of VRAM. It is not possible to set the correct amount of VRAM here so I set 2 meg. When you reach the page in the install for choosing resolutions, regardless of what choice is made, the "test" button always brings up an 800x600x16 screen. When installation was complete, the X system was running 800x600 though the xconfig files seem to be set for 1024x768. Also, sound (which runs through the neomagic chip as well) is not working. Reproducible: Always Steps to Reproduce: 1.Do normal graphical install 2.try "test" button with various resolutions 3.Leave the setting on 1024x768x16 Actual Results: Regardless of resolution selected, I get 800x600 Expected Results: Should get the correct resolution, 1024x768 and sound should be configured. Target machine is a Sony PCG-F480 laptop with 128m ram and a Neomagic MagicMedia 256AV+ with 2.5 meg of VRAM. Installation type "laptop" with everything as default. If you want me to run tests, I can. I'm a software engineer but haven't had much experience with X configuration files so if you want me to swap servers or do other things, please describe how.
Try booting with the 'nofb' option and see if the behavior changes. This will run the installer with the native X server instead of the framebuffer server. It sounds like this is more of an X problem than an installer problem. Try this as well: after you've done a test of the X configuration in the installer, press <ALT><CTRL><F2> and look at the /tmp/XF86Config.test file. Down at the bottom of the file, you should see a resolution setting. What does it say? If the installer is writing a correct screen resolution to the file, but X comes up in a lower resolution, it either means the installer is writing out refresh rates in the XF86Config.test file that are too low or that X just has a problem with that resolution on that card/monitor combination.
Currently, the resolution shown in the XF86Config-4 file is 1024x768, though the server still comes up in 800x600. When the system was probing the monitor it didn't find an exact match for the LCD panel and used "DCC probed parameters" instead. I'm not sure if these are correct, if you can give me a range of refresh values that you would expect for a 60hz refresh LCD panel, I'll compare/try them and report the results. (Note: windows reports the LCD panel is "plug-and-play" and running at 60hz 1024x768) I will do a reinstall with "nofb" and run the other tests you suggested and have results back to you by friday morning at the latest.
We (Red Hat) should really try to resolve this before next release.
Did a re-install with "nofb" the results from the probing of the video hardware and RAM were identical to the original. However, based on the suggestion by "bfox" that the refresh rates for the panel may be set too low, I went back and changed from a DCC probed monitor to a generic 1024x767x60hz LCD panel. This raised the values from what DCC probing reported. The system now works properly in 1024x768x16bitx60hz mode. It appears the problem was that the DCC probing was not returning correct values, though I'm not sure why because windows seemed to have no problem probing them when it was installed. One of the following must be happneing. 1. The hardware is returning incorrect DCC probing values 2. The software is not able to read the characteristics of the monitor and is returning bad values rather than returning "unknown" Otherwise, the system appears to be working after manually choosing the monitor, though it doesn't seem this should be necessary. Does using "nofb" on install have any effect on which version of the X server is eventually permanently installed?
Using the 'nofb' option has no effect on the server that is used after installation. What it means is that the installer will use the native X server instead of the framebuffer server. We've seen some cards behave strangely during the X configuration testing because you have the framebuffer X server running the installer, and then a native X server is started when you press the test button. But that's apparently not the problem here. What does the installer initially probe your monitor to be? Also, can you send me the output of ddcprobe? Press <CTRL><ALT><F2> and type 'ddcprobe' and you should see the probing data from the video card and monitor.
*** Bug 26295 has been marked as a duplicate of this bug. ***
ddcprobe reports Vesa 2.0 MagicMedia 256AV 48k Memory Installed = 39*64k blocks = 2496kb <all the standard res modes from 640x480 to 1600x1200> EDID Read Failed (no DCC-capable monitor attached) Obviously this is the reason it is having problems with the LCD panel. Since this is a dual-output chip, is it possible the prober is going after the wrong connector (or doesn't realize there are two?) Windows seems to be able to probe the monitor ok, so the functionality must be there someplace. It does seem to be probing the amount of VRAM on the chip correctly, so I suppose the reason the installer reports 256k instead of 2.5 meg is simply because there IS NO 2.5 meg choice on the menu of the installer.
Unfortunately, we don't currently have a way of probing LCD's. We can detect if the monitor connected is an LCD, but we don't have a way of detecting the resolutions it can support. Does the installer initially put the monitor under 'DDC Probed Monitor', but the actual entry says 'Unprobed Monitor'?
I think the problem stems from having the default hsync and vsync rates set too low if the monitor can't be probed. I have upped the rates, so this should be fixed now. Please reopen if the problem reappears.