Re: [XFree86] noise caused by LCD
Maybe it'snot really coming from the screen? It could be that your CPU is automatically throttled down when idle (perhaps by ACPI or the APM BIOS). Certain types of CPU throttling is known to cause an annoying whine on many machines. If this is the case then it's possible that the whine goes away when the CPU is no longer idle such as when you drag windows. A good test would be to see if the whine goes away when you run CPU intensive programs that don't affect the screen. Carl Thompson Quoting James Nachlin [EMAIL PROTECTED]: Hi listmembers, I have a question that's bugging me and I'm wondering if anyone here has any suggestions: I have a Dell Latitude c600 laptop with the ATI M3 video adapter and a generic Dell laptop LCD. The LCD emits a sort of high pitched buzz or whine. I am using the r128 driver. This whine is not present under Windows, or in the BIOS utility screen. It does not seem to be effected by LCD brightness, or by changing the horizontal and vertical sync rates in the .conf file. I do not believe it's something else on the machine that's emitting the noise. It's not the speakers, as I've tried headphones. One thing that will make this buzzing go away is movement on the screen, like dragging a window. One final note: this sound is present even when the X server is not running (after hitting ctrl-alt-backspace). Sorry if this isn't the right forum for this inquiry. Thanks for your help. Jim ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Problem in Radeon driver on IGP
Here is more information for you on the problems I am having with the IGP patched Radeon driver in non-native RMX modes. Just for sanity's sake can someone send me an XF86Config and server log for the Radeon driver from a computer that works correctly in non-native resolutions with the Radeon IGP mobile chipset? OK, I figured out how to read the registers under Windows, and they were just a little different in RMX stretched modes than under Linux. However, sticking the Windows values into the registers manually in the Linux driver doesn't make any difference. I tried this for all the registers in RADEONInitFPRegisters() and most of the ones in RADEONInitCommonRegisters() and RADEONInitPllRegisters(). None of them made any difference. I noticed that my panel does not return any DDC information and my card defaults to using RMX. Is this the case for the cards that you have tested? Should RMX work correctly? What should the modelines look like when using RMX if I use xvidtune to print them out? I also noticed when trying to troubleshoot that hooking a second monitor to the external monitor port and using the clone options doesn't work. If the X server is started with the external monitor plugged in, it will not work at all. The log looks all right with the external monitor's DDC info correctly detected, but nothing is shown on the screen and the monitor says it is not receiving a signal. It doesn't matter whether the external monitor is an analog monitor or a panel. If the external monitor is connected after the X server is started, then an image appears on the screen but the server does not honor the CloneHSync and CloneVRefresh settings. Switching to some modes runs the monitor outside the ranges specified by these settings! More specifically, as the logical resolution goes down the dot clock, horizontal and vertical frequencies go up. Since the physical resolution is staying the same, I would expect these values all to remain constant. In fact the modelines for RMX stretched resolutions in the log all show them having the same dot clock and frequencies as the default physical resolution. When an analog monitor is hooked up during these RMX modes the screen is distorted (shrunken and off-center) but can be corrected by using the monitors controls. When an LCD is connected during these RMX modes, the effect displayed is similar to the problem I have on the laptop's primary panel! Therefore, I wonder if the server is mistakenly trying to drive the panel at a higher dot clock and frequencies just as it is mistakenly trying to drive the external monitor faster than it should and my panel just can't handle anything besides 65MHz / 48.3KHz / 60Hz. Is this possible? Unfortunately, I cannot figure out where in the driver the actual timings used by the card are set. It would _really_ help if I had any kind of documentation at all on how the Radeon cards are programmed or how the XFree86 Radeon driver works. As another test, I tried setting up my XF86Config file to have two separate device and screen sections for the external monitor rather than using the clone settings. This caused a hard lock of the computer with some messages in the log stating Idle timed out, resetting engine... but I may have had my config file set up wrong (the documentation is vague on this type of setup). So here's the scorecard for my system so far: Works = Accelerated 2D at native panel resolution Doesn't Work * Non-native resolutions (AKA RMX modes) * External monitor on external connector using clone modes (mostly broken but kind of works in certain situations) * External monitor on external connector using separate screen and device sections in the XF86Config * 3D So the driver is pretty much broken at least on my Radeon IGP320M. Thanks, Carl Thompson Quoting hy0 [EMAIL PROTECTED]: - Original Message - From: Carl Thompson [EMAIL PROTECTED] To: hy0 [EMAIL PROTECTED] Sent: Thursday, March 20, 2003 4:02 AM Subject: Re: Problem in experimental Radeon IGP driver The system works fine under Windows XP using non-native resolutions. Using the XFree86 VESA driver, the screen is not stretched in lower than native resolutions so it just uses the middle of the screen and does not have this problem. Playing with the BIOS setting makes no difference. The color depth of the X server makes no difference. Yeah, I was thinking that the driver does not initialize the card properly and other cards more tolerant of it or default to the correct state. Can you send me or point me to documentation on how to program the stretch feature on Radeons? I have some time to take a look at it myself if I can get some documentation. Unfortunally, ATI doesn't have this part of document available for external developers. Most things for stretching control are in RADEONInitFPRegisters function. There are two registers that are most important for the H strech
[XFree86] Re: Problem in experimental Radeon IGP driver
Just wondering if you have any idea what might be causing this problem... Thank you, Carl Thompson Quoting Carl Thompson [EMAIL PROTECTED]: Screenshots (taken with a digital camera) of the problem can be found at http://carlthompson.net/hy0 . However, they are not very clear and therefore make the screen look better than it actually does. The screenshots are at 800x600 logical resolution and the browser window in the screenshot is maximized. The pink and black vertical stripes at the right side of the screen should not be there and are part of the problem. A more detailed analysis follows. It doesn't matter whether or not a non-native resolution is the only resolution in the XFree86 config file. The corruption occurs in all non-native modes (modes 1024x768) but is more pronounced the further you get from the native mode (640x480 is worse than 800x600). Looking at the screen more closely, it appears that perhaps the video card is calculating the proper stretched pixel values for each of the 1024 native horizontal pixels but when it displays them it does not properly display them in the proper places across 1024 pixels of horizontal resolution but in only across the logical horizontal resolution (800 pixels if in 800x600). Therefore, the screen appears messed up as if some horizontal pixels are dropped at regular intervals. The vertical stretching seems to work perfectly. At the right edge of the screen is a vertical stripe of garbage the native pixel width of which is the native screen width minus the logical screen width. (In 800x600 logical the width of the garbage stripe is 224 native pixels and in 640x480 logical it is 384 native pixels.) In other words, the lower the logical resolution the more garbage area on the right side of the screen and more horizontal data is dropped from the left area of the screen. I hope that explanation is not too confusing. Thank you, Carl Thompson Quoting hy0 [EMAIL PROTECTED]: I don't see anything wrong either from the log file and can't reproduce the problem here. Can you try to set only single non-native mode (like 800x600) in your config file instead of doing mode switching? Does the corruption occur to all non-native modes? Hui Vertical stretching seems to work fine; horizontal stretching is broken. Carl Thompson Quoting hy0 [EMAIL PROTECTED]: Can you send me your log file for the non-native mode? Thanks. Hui Hello, When the screen's resolution is switched to anything other than my laptop panel's native resolution (1024x768) the screen is garbled and pretty much unreadable. It does appear to be attempting to scale the new resolution to the screen's native resolution rather than just using the center of the screen, but doesn't seem to be doing it correctly. Thanks for your work on the driver, Carl Thompson ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Problem in experimental Radeon IGP driver
Hello, When the screen's resolution is switched to anything other than my laptop panel's native resolution (1024x768) the screen is garbled and pretty much unreadable. It does appear to be attempting to scale the new resolution to the screen's native resolution rather than just using the center of the screen, but doesn't seem to be doing it correctly. Thanks for your work on the driver, Carl Thompson ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Experimental Radeon IGP 320M Drivers
Hello, I read on the list archives that someone has a preliminary Radeon IGP 320M (AKA Radeon Mobility U1) driver for XFree86 4.3. I Would like to help test them out. Can someone point me to where I can get it or send it to me? Thank you, Carl Thompson ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
