Re: Radeon 8500 with TFT/DVI uses 60Hz modes only
Two ways to change it, 1. use Option IgnoreEDID 2. use Option NoDDC and Option MonitorLayout TMDS, NONE With above two methods, you'll also need to provide the proper timings for your panel, either from HorizSync and VertRefresh or from a Modeline. Since there are some panels having problem with their non-native modes, the driver uses the internal scaler inside Radeon chips (RMX - Ratio Matrix eXpension) for these modes by default. I'm not sure what kind of tearing you see with the playback on [EMAIL PROTECTED], changing this may or may not help. You can also try to use [EMAIL PROTECTED] mode (the native mode of your panel) and set the color depth to 16. Hui - Original Message - From: Patrick Mau [EMAIL PROTECTED] To: Michel Dänzer [EMAIL PROTECTED] Cc: Patrick Mau [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, October 05, 2003 8:08 AM Subject: Re: Radeon 8500 with TFT/DVI uses 60Hz modes only On Sun, Oct 05, 2003 at 01:26:32PM +0200, Michel Dänzer wrote: Do you really need more than 60 Hz though (and if yes, what for?), given that 60 Hz is probably optimal for the panel, and it shouldn't flicker, or does it? Hallo Michel, thanks for your reply, because my first attempt didn't reach the list. I'd really like to use modes above 60Hz for video playback. Maybe this is completly wrong, but to me it seems that video streams with 25fps have less tearing with 75Hz refresh rates. But aside from that, I just wonderd why Windows can program those mode timings, although XFree just seems to see the 60Hz modes from DDC. That's why I included the DDC Information. If someone wants to comment on my remarks about video playback, I'd appreciate that. Thanks, Patrick ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Radeon 9200: can't get DVI working
- Original Message - From: Burkhard Leun [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 5:20 AM Subject: Re: [XFree86] Radeon 9200: can't get DVI working XFree86 4.3.x detects the card (chip id 0x5961, see log) and even the DFP on the primary port, but a signal is only produced on the (not connected) secondary VGA port. This is something new. It's supposed to work the same as 9000 cards, but apparently it isn't. I haven't seen a 9200 with a DVI port so far. What's the brand name of your card? I'll try to get one for the test. The card is from club-3d (www.club-3d.com). For now you can try to comment off following two lines in RADEONRestoreFPRegisters (radeon_driver.c), see if this makes any difference. -OUTREG(RADEON_TMDS_PLL_CNTL,restore-tmds_pll_cntl); - OUTREG(RADEON_TMDS_TRANSMITTER_CNTL,restore-tmds_transmitter_cntl); It makes a big difference - it seems to work now. A quick test shows only a minor (possibly acceleration related) problem: the picture is flickering if a window (menu) is opened at a screen border. I had the same effect with the windows driver, disabling cursor and bitmap optimization (the highest of 5 levels) cured it there. Thank you very much for your help. Of course I'm willing to do other tests with the card if it would be useful for driver development. Can you try to comment off one line at a time of above two lines and let me know which line causes the problem. Thanks, Hui Burkhard Hui -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Radeon 9200: can't get DVI working
- Original Message - From: rda [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 03, 2003 8:40 PM Subject: Re: [XFree86] Radeon 9200: can't get DVI working I am having exactly this problem with a Radeon 7500 card (OEM = PowerColor) -- as an added complication it appears to be vary with the digital monitor attached. I can get output from XFree to the DVI port when a (borrowed) Sony XDM-72 monitor is attached, but not when my Apple Studio Display 17 LCD is attached. The Apple monitor works with the same hardware in Windows and with RH9 in text mode. I am also using the CVS ati and radeon drivers downloaded today. I have spent much time trying various config files without success. Unfortunately, I am too much a newbie to find the radeon_driver.c file to make the suggested edit. Where is it? Any other suggestions? Could the MonitorLayout option be relevant here if there is only a single monitor attached and it is detected by DDC? This looks like a TMDS transmitter's problem rather than CRTC timing or monitor detection problem. Posting your log file will help to identify the problem. Regards, Hui TIA bob ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
I'm willing to poke around with the stuff, but I lack docs concerning the chipset. As for the obvious things, I did patch Ben's kernel driver to work with my setup, but the radeon driver in X is far more confusing without documentation. I'll see what I can find out ... I would be grateful for any tidbits of information you could send me... You can send your request to [EMAIL PROTECTED] for 9000 Register Spec. Let me know if you need any other info. Regards, Hui Cheers, Simon --- Simon Urbanek Department of computer oriented statistics and data analysis Universitätsstr. 14 86135 Augsburg Germany Tel: +49-821-598-2236 Fax: +49-821-598-2280 [EMAIL PROTECTED] http://simon.urbanek.info ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Radeon 9200: can't get DVI working
XFree86 4.3.x detects the card (chip id 0x5961, see log) and even the DFP on the primary port, but a signal is only produced on the (not connected) secondary VGA port. The hardware is working (tested with windows). I'm using a newer driver version (4.3.99) with explicit support for the card (I've also tried 4.3.0 with binary driver from Schneider-Digital and got no signal at all). Has anybody this card working with DVI? Any hints? This is something new. It's supposed to work the same as 9000 cards, but apparently it isn't. I haven't seen a 9200 with a DVI port so far. What's the brand name of your card? I'll try to get one for the test. For now you can try to comment off following two lines in RADEONRestoreFPRegisters (radeon_driver.c), see if this makes any difference. -OUTREG(RADEON_TMDS_PLL_CNTL,restore-tmds_pll_cntl); -OUTREG(RADEON_TMDS_TRANSMITTER_CNTL,restore-tmds_transmitter_cntl); Hui TIA, Burkhard ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] multihead configuration with radeon 7000 cards
There is a bug in X4.3 (used by RH9) for dual-head setup with two or more radeon cards. The bug has been fixed in the CVS code. You can try the binaries in http://www.xfree86.org/~alanh/ (XFree86, ati_drv.o and radeon_drv.o) if you don't want to compile it yourself. I tested 4-head Xinerama setup with 2 Radeon 7500 cards (should be the same with radeon 7000) and worked fine for me. Regards, Hui - Original Message - From: Jihong Ren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 04, 2003 7:16 PM Subject: [XFree86] multihead configuration with radeon 7000 cards I am now trying to set up multihead display with a AGP radeon 7000 card and two PCI radeon 7000 cards. However, I couldn't get it to work even with just the AGP card and 1 PCI card. I believe my XFree86config file is correctly written. When I try startx, it reports: Reloading /usr/X11R6-CVS/lib/modules/drivers/radeon_drv.o Symbol xf86SetDDCproperties from module /usr/X11R6-CVS/lib/modules/drivers/radeon_drv.o is unresolved! This error was reported several times on the mailing list. However, I did not find where the fix is. (http://www.mail-archive.com/[EMAIL PROTECTED]/msg00298.html) Could anybody tell me whether it is possible to set up multihead display with these cards in Linux (Redhat 9.0 with XFree86 4+)? If not, what about windows? If not, could anybody recommend some graphics cards that are known to work for multihead display? Your help is highly appreciated! Jihong ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI IGP 340M - Dual head on a lapltop
Please double check the sync ranges specified for your external CRT: HorizSync 50-90 VertRefresh 60 For 60 Hz refresh, HorizSync is too high for the three modes listed in you config file (they need 48.4, 37.9 and 31.5 respectively). Regards, Hui - Original Message - From: Brandon Wittenburg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:13 AM Subject: Re: [XFree86] ATI IGP 340M - Dual head on a lapltop Thanks Alex. If you've a spare moment would you mind looking at my current XF86Config file? http://www.656.org/ati/XF86Config The XFree86.0.log is at http://www.656.org/ati/XFree86.0.log Just please let me know if something jumps out as being horribly wrong (I've stripped comments, so it is pretty easy to read through). I submitted a second email concerning my problem yesterday with more accurate information. Mainly that the chipset is an IGP 320M, not 340M as I had previously believed. When defining two screens, two monitors, and two devices and I am getting a clone of the primary head on the secondary head. Xinerama says that it is enabled in the log, but you couldn't tell by looking at the display. From the bugzilla record below I gather I'll need the cvs to use the patch. Is this correct? Thanks for your help. Brandon On Tue, 2003-07-01 at 08:38, Alex Deucher wrote: the radeon driver supports dualhead. you can either do it with two screen entries and xinerama or with my mergedfb patch (http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=276). the IGP chipsets do not support HW 3D yet. Make sure your screen entries do not contain the videoram option as that will prevent dualhead from working. check the radeon and XF86Config man pages for more info. Alex Hello, I've an hp ze4430 laptop. It contains an ATI Radeon Mobility U1 (IGP 340M w/ 64MB shared memory). I am currently using the radeon driver that I believe was shipped with XFree 4.3. This graphics card has the ability to extend the desktop to 2048x78 using an external monitor. I have been unable to find any documentation about such a feature being supported (or not) by the radeon driver. I have attempted to obtain such a result by trying everything I know to do in my XF86Config file. I can get a 2048x768 desktop using the Xinerama option, but the extra desktop space does not display on the external monitor, rather in empty space next to the laptop's flat panel. I've also been successful cloning the display on both monitors using different methods (MonitorLayout and CloneDisplay). Does anyone know if the current radeon driver supports this feature or of any documentation that may contain information that will help me achieve this setup? Regards, Brandon Wittenburg __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: *** GMX Spamverdacht *** Re: Re: Radeon 9800 AGP driver
- Original Message - From: Mike A. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 16, 2003 9:48 PM Subject: [XFree86] Re: *** GMX Spamverdacht *** Re: Re: Radeon 9800 AGP driver On Sat, 14 Jun 2003, Dexter Filmore wrote: Date: Sat, 14 Jun 2003 19:09:51 +0200 From: Dexter Filmore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Subject: Re: *** GMX Spamverdacht *** Re: Re: Radeon 9800 AGP driver You could get yourself a copy of the live CD distro Knoppix and put in a demo machine with 9800 at your vendor... Or just buy the thing and return it if it makes trouble. Why purchase one of the most expensive possible video cards for use in a Linux system where it is currently completely unsupported, and merely 'might work for 2D only (or might not)' with an ugly hack of lying about the PCI ID in the config file? Specifying a 9700 ID should work for 9800/9600. If you don't like this hack, attached is the patch for current CVS code. It contains 2D support for 9800/9600/M10/IGP7000/IGP9000. It also has fixes for bug 26, 193, 342(?), 351 and a few other things. I'll run a few more tests before sending it to Kevin. Especially when there are experts here clearly stating it isn't supported. ATI's binary drivers on their website also don't support this card (or didn't about 4 days ago at least), however there is a website in (Germany?) which has ATI drivers that support this card, although the name escapes me. I guess you mean http://www.schneider-digital.de/html/download_ati.html. If you want 3D support now for the cards = 8500, you can try them and they should work. Regards, Hui If you're looking for ATI hardware with open source driver support that has working 3D, Radeon 8500 and 9000 are the highest supported cards right now. The 9500Pro and 9700 Pro are additionally supported 2D only right now. For complete details of unequivocal truth, examine the Radeon driver source code: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon*.[ch] Hope this helps. TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 x4.3.99.5_radeon_allinone.diff Description: Binary data
Re: [XFree86] XFree4.3 problem with external display resolution on notebook
- Original Message - From: Uwe Walter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:28 AM Subject: [XFree86] XFree4.3 problem with external display resolution on notebook Hello! XFree 4.3 solved a lot of annoying problems with my Dell C640 notebook and its ATI Radeon Mobility! :-) Thanks a lot to all of you for that! However, I have a new one, I am seeking help with. Environment: - SuSE 8.1 on Dell C640 notebook - ATI Radeon Mobility 7500 - XFree 4.3.0 (SuSE version from 27 February 2003 release) (more infos in the logfile) - internal display: Samsung LTN150P1-L02 panel with 1400x1050 resolution - external display when attached to docking station: NEC panel with 1280x1024 resolution With the old XFree 4.2 I could have a line like this Modes 1400x1050 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 in the screen section and XFree would choose a 1400 resolution if the notebook was operating on its own display and 1280 when attached to the docking station since the external panel that the external panel is only capable of. Unfortunately XFree 4.3 insits of using a 1400 resolution even if the laptop is docked and the internal panel is off. As the attached logfile shows, the internal panel is still recognized and XFree 4.3 choses a 1400x1050 VIRTUAL resolution. This means, the external panel is driven with compatible physical 1280 but virtual 1400 with the mouse scrolling the virtual area at the screen borders. How can I please get rid of this and return to the old behavior, so that XFree 4.3 does not ever use a virtual resolution but instead defaults to the maximum resolution of the active panel, be it internal (1400) or external (1280)? Setting Virtual 1280 1024 does not help. I also played with the Clone options but just couldn't find a solution. Can anybody please shed some light on this? Meanwhile, you have to remove 1400x1050 from your Modes line to prevent it is used as virtual size for your external display. The internal panel is always connected and 1400x1050 is a valid mode for it regardless if an external display is connected. Setting Virtual 1280 1024 should prevent 1400x1050 mode in principle, the driver doesn't seem to handle this correctly. PanelOff is currently only implemented to turn off display, nothing to do with mode validation. The old driver worked the way you described accidentally, may not be reliable/desired in other cases. Hui Thanks a lot in advance, Greetings, UW(e) ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Can't change hsync from 60Hz on secondary display - Radeon Mobility 9000 (M9)
- Original Message - From: Knutsen, Mark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:32 PM Subject: RE: [XFree86] Can't change hsync from 60Hz on secondary display - Radeon Mobility 9000 (M9) Try to remove all spaces from 30.0 - 95.0 and 50.0 - 160.0. Success! Now I can get 75Hz @ 1600x1200 on my external monitor by adding just these two driver options: Option CloneHSync 30.0-95.0 Option CloneVRefresh 50.0-160.0 ...and removing all but 1600x1200 from the Modes line in the Screen section. The external monitor is detected and clone mode is automatically set. So, spaces aren't allowed inside these option strings of the radeon driver. Yet the Red Hat phoebe3 beta puts spaces in the HorizSync and VertRefresh ranges of the Monitor section. Is this a bug in XFree86 or in Red Hat? These options are handled differently from those standard sync range lines. Currently these strings are simply read by sscanf(s, %f-%f, ...) which won't return correct results if there are spaces inside the strings. A bit of string parsing here should get these options more tolerant. Also, the laptop's backlight is on even though the cover is closed; is this a known bug as well? A patch has been submitted for some related problems, not sure if it can solve your problem. If you want to try, I can send it to you off the list (there are many other things, too big to post here). Hui -Original Message- From: hy0 [mailto:[EMAIL PROTECTED] Sent: Saturday, March 22, 2003 9:40 PM To: [EMAIL PROTECTED]; Knutsen, Mark Subject: Re: [XFree86] Can't change hsync from 60Hz on secondary display - Radeon Mobility 9000 (M9) (BTW: thanks for the help so far; I appreciate it!) What about the CloneMode and CloneHSync options? Well, I tried. What I got was a 640x480 60Hz window on a 1600x1200 virtual screen. This is similar to the behavior I got with the default config, which only showed 640x480 even though the Modes line was 1600x1200 1400x1050 ... 640x480. I removed all but 1600x1200, and that's the config I'd been running with before I started to ask questions about the low 60Hz refresh rate. Turn on the Clone options, and 640x480 reappears. Why? Here's a log diff between configs with and without Clone driver options turned on: 22c22 (==) Log file: /var/log/XFree86.0.log, Time: Thu Mar 20 15:08:12 2003 --- (==) Log file: /var/log/XFree86.0.log, Time: Thu Mar 20 15:15:24 2003 463a464,467 (**) RADEON(0): Option CloneDisplay 2 (**) RADEON(0): Option CloneMode 1600x1200 (**) RADEON(0): Option CloneHSync 30.0 - 95.0 (**) RADEON(0): Option CloneVRefresh 50.0 - 160.0 Try to remove all spaces from 30.0 - 95.0 and 50.0 - 160.0. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] DRI disbled for on the Primary Head ??
On Sam, 2003-03-15 at 03:06, Philippe Moutarlier wrote: At last, I got my dual head working : but NOT with the ATI 7500 PCI. It worked right out of the box with an nVidia PCI, though. What's wrong with the radeon dirver and 2 ATI cards ?? It's called a bug. :\ Indeed, I've fixed this on my machine. I'm putting it together along with many other things. Hopefully I can get all patches out next week. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Experimental Radeon IGP 320M Drivers
Here is the X4.30 patch for supporting IGP cards (2D only). Hui 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 x430_radeon_1_igp.diff Description: Binary data
Re: [XFree86] Why is the CrtScreen option missing in the 4.3.0 radeon driver?
CrtScreen option was introduced in X4.20 to let the mode validation routine for flat panel to fall back to the standard CRT routine. While it solved some problems, it also caused quite a few nasty problems on certain panels (especially on laptop panels). After X4.20, with better mode routines for flat panels merged into CVS, this option was removed. About that time, a lot of OEM cards started showing up on the market. Some of these cards have the monitor detection problem (caused by inconsistent BIOS rules) as you've experienced. The CrtScreen option in the older versions actually helped to workaround this problem in some cases (as you did), although it's not originally intended for this option. To properly solve the monitor detection problem, a patch was put together later. Unfortunally, with time running out, the patch was too big to be merged in for X4.30 release. This leaves the monitor detection problem for certain OEM cards unsolved. Hopefully we can get the proper solution for this problem into CVS in the near future. Meanwhile you probably have to stay with the version that worked for you. Hui Hi, I've already asked Marc Aurele La France this question, who maintains the ATI driver. He told me to post my question to this address, so here it goes: /me wrote: [...] I'm using a radeon 8500 (from hercules) video adapter and just upgraded XFree86 from 4.2.99 to 4.3.0. When I first tried to use the ati driver in 4.2.x I ran into the problem, that my monitor was not detected correctly. I got the error message | (EE) RADEON(0): No valid mode found for this DFP/LCD although I had just a CRT screen connected to the vga output. I had a look at the log file and it said I should try Option CrtScreen in my XFree86Config... and it worked well for me. It seems that in version 4.3.0 of XFree86 this option has been removed from the radeon driver and I'm getting the same error message as above when I try to start X11. (No valid mode...) On the XFree86 webpage I found the option crt_screen in the ATI Adapters README file. This option doesn't work as well. ;( Why has this option been removed and how do I set up X11 to work properly on my system? I'm sending my XFree86Config and my XFree86.0.log as an attachement. The commented part is a relict from the fglrx driver test, that didn't work well with 4.2.x and doesn't work with 4.3.0 at all. thanks, Daniel -- eat(this); // delicious suicide ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [XFree86(TM) Bug Report] ATI Radeon 7000/VE, window or menu moving problem at 1280x1024 24bpp
From: George Lindholm [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Date: Thu, 27 Feb 2003 15:22:41 -0800 Kevin Oberman wrote: Known bug in line drawing acceleration in Radeon driver prior to 4.3. It is supposed to be fixed in that release, but I have not tried it yet. It's actually gotten worse the last couple of days. A couple of days ago I was just getting horizonal lines alongside the cursor. With the 4.3 release, I'm getting lines all over the screen (2048x1536x24, Radeon 7500) Ouch! Sounds like the NoLineAccel option for the ati driver needs to be re-implemented. It was in CVS for quite a while but was removed when the driver was believed to be fixed. (I only read the CVS logs and have nothing to do with actually fixing the code.) This may not be the line drawing problem. When you said getting lines all over the screen, did it appear to be noise/snow or to be some residual lines from previous drawing not being erased? If it's first case, that would be display buffer under flow problem. Otherwise it's line drawing problem. To narrow down the problem, try following two things: 1. Change to lower resolution (like 1024x768) or color depth (like 16 bpp), does the problem still happen? 2. Use Option SWcursor in your config file, will this alleviate the problem? If these two things have effects on your problem, it's the display buffer problem. This problem is caused by memory latency to display buffer. It depends on the type of memory on your card, the resolution/depth you are using, and hardware cursor mode, etc. There is a way to calculate the bandwidth requirement and set corresponding registers to avoid this problem. But this is not implemented in current radeon driver, instead, the driver just uses the default BIOS settings which worked fine for most cases, but may have problem with high resolution modes on some cards. 4.3 release can indeed make this problem more evident when it uses ARGB cursor. If this is proven to be the case, hopefully it can be taken care of in the near future. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86-4.3.0rc2 and Radeon VE - sometimes works, sometimes not
There are some known problems with OEM cards (it appears to be your case). The fixes for these problems haven't been merged into 4.3 release because there is not enough time. Meanwhile you can try two thing: 1. Make sure your monitor is connected during the boot. Don't plug/unplug monitor(s) after boot. 2. Use Option CloneDisplay 0 If you still have the same problem and you know how to deal with source code, you can try following patch. http://penguinppc.org/~daenzer/DRI/radeon-ddc.diff Hui I am testing XFree86-4.3.0rc2 (binary from ftp.xfree86.org) on Linux-2.4.20, with Radeon VE, ECS K7S5A and Duron-1000. Problem is: sometimes X starts, sometimes they just show infamous message: (EE) RADEON(0): No valid mode found for this DFP/LCD I search on google, and solution was to add: Option CrtScreen But it didn't help, I got still same message. Strange thing is - XFree86-4.2.0 _always_ starts well. I have only problem with 4.3.0rc2. Is it problem with my configuration? I attached XF86Config and XFree86.0.log. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: [XFree86]xf86cfg signal 11 with 4.2.99.902 on Compaq N800w (Radeon)
Looks like the int10 initialization routine is not happy with your system and resulting in corrupted video BIOS image. Can you try following two things together and post the resulting log file? 1. Comment off following 3 lines in radeon_driver.c. if (!info-FBDev) if (!RADEONPreInitInt10(pScrn, pInt10)) goto fail; This will let driver bypass int10 initialization and use the legacy vbios location directly. Then do a make install in ati directory. 2. in the Screen section of your config file add DefaultDepth 24 in the corresponding Display SubSection (Depth 24) add Modes 1600x1200 or whatever mode your panel supports. Hopefully these can narrow things down a bit. Hui On Thu, 20 Feb 2003, mel kravitz wrote: I am coming in here late, what does XF86Config file 'screen' section say? This is a laptop? I assummed from your /var/log/XFree86.0.log file you were using the 'radeon' driver. You can of course try it. Switching ati to radeon gives the same failure. i see from this file :(XFree86.0.log), XF86Config.new log II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) RADEON(0): PCI bus 1 card 0 func 0 (==) RADEON(0): Depth 8, (==) framebuffer bpp 8 (II) RADEON(0): Pixel depth = 8 bits stored in 1 byte (8 bpp pixmaps) (==) RADEON(0): Default visual is PseudoColor (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) --- you set this to run in 'Default Depth 8'? Its the default xf86cfg generated file - adding 'DefaultDepth 24' still chokes. Thanks for the suggestions :/ Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 24 SubSection Display Depth 1 EndSubSection SubSection Display Depth 4 EndSubSection SubSection Display Depth 8 EndSubSection SubSection Display Depth 15 EndSubSection SubSection Display Depth 16 EndSubSection SubSection Display Depth 24 EndSubSection EndSection (II) Setting vga for screen 0. (II) Loading sub module vgahw (II) LoadModule: vgahw (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor=The XFree86 Project compiled for 4.2.99.902, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) RADEON(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module int10 (II) LoadModule: int10 (II) Loading /usr/X11R6/lib/modules/libint10.a (II) Module int10: vendor=The XFree86 Project compiled for 4.2.99.902, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) RADEON(0): initializing int10 (WW) RADEON(0): remove MTRR a - c (WW) RADEON(0): set MTRR c - 10 (WW) RADEON(0): Bad V_BIOS checksum (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (WW) RADEON(0): remove MTRR 0 - 1000 (--) RADEON(0): Chipset: ATI Radeon Mobility M9 Lf (AGP) (ChipID = 0x4c66) (--) RADEON(0): Linear framebuffer at 0x8800 (--) RADEON(0): MMIO registers at 0x8038 (WW) RADEON(0): remove MTRR 8038 - 8040 (--) RADEON(0): VideoRAM: 65536 kByte (64-bit DDR SDRAM) (WW) RADEON(0): remove MTRR 8038 - 8040 (II) RADEON(0): CloneDisplay option not set -- defaulting to auto-detect (II) RADEON(0): Primary Display == Type 2 (II) RADEON(0): Panel ID string: FF FF (II) RADEON(0): Panel Size from BIOS: 65535x65535 Symbol xf86SetDDCproperties from module /usr/X11R6/lib/modules/drivers/radeon_dr v.o is unresolved! -- David Brownlee - CTO Purple Interactive - (0)20 8742 8880 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M
Unfortunately there probably isn't enough time to get IGP 320/340 support in the 4.3 release. I just got my IGP 320M laptop working (2D only), but the time is running out for more testing. Although IGP 320M is a M6 based chip, its UMA issue and other problems can cause the existing Radeon driver to hang in quite a few places. The changes are not just adding device IDs and need more testing. If you are willing to do some tests, I can send the driver on my system to you off the list (you'll need 4.2.99.9xx server to run it). Regards, Hui - Original Message - From: Brandon and Andrea Williams To: [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 10:34 PM Subject: [XFree86] XFree86 4.3 Radeon Mobility IGP 320M I have an HP ZE4145 notebook, which uses the ATI Radeon Mobility IGP 320M chipset. I have been anxiously awaiting your 4.3 release in hopes that this chipset would be supported. I am attaching the error log generated when I try to start the X server. This is from Red Hat's 8.1 beta which was released on February 15. I know it doesn't have the most current 4.3 beta, but I have tried that as well, and it didn't even detect the card as the Radeon Mobility 1U, which the Red Hat beta does. Could you provide me some insight or support on why the X server is failing to start? Please let me know if you need any additional information. Thanks, Brandon Williams - Original Message - From: MELLERS Adrian [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 5:14 AM Subject: [XFree86] Compaq EVO n1005v Hi, I don't know if this problem has been reported or if I am in fact barking up the wrong tree. I have been busy downloading the newest XFree86 release's now for the past few weeks. I have a laptop a Compaq EVO n1005v which is quite a new model In fact it took two months for contact to supply drivers and rompaqs to get the display functioning in Windows 2000. As soon as I try to load X on the laptop the system freezes requiring a reboot, fsck kicks in and fails and a single use mode scan is required. I am running Debian 3.0 updated from the unstable ftp site. I have included a listing of lspci. lspci.txt I am currently downloading 4.2.99.902 to test. I read somewhere that the ATI Radeon Mobility U1 chipset was to be supported in the next release of XFree86. I'm going to play with my kernel now to see if that helps. Cheers Adi. Technical Support Etam UK Tel +44 (0) 1623 835959 x 3310 E-mail [EMAIL PROTECTED] This e-mail message and any attachments are intended for the addressee only. If you have received this in error please delete it permanently from your mail box and do not store or disseminate the information contained in this mail by any method. Thank you ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] ATI Radeon M9 and XFree86 4.2.99.902 Problem.
There is a bug causing this problem. Try to specify the mode you want explicitly. For example, in the Screen section add DefaultDepth 24 in the corresponding Display SubSection (Depth 24) add Modes 1600x1200 Hui I've got a Dell Inspiron 8200 laptop with a ATI Radeon M9 video adapter and a 15 UXGA (1600x1200) display. I've installed the latest Gentoo Linux distribution 1.4rc2 and successfully compiled XFree86 version 4.2.99.902. When I attempt to run XFree86 after generating an XConfig file using the XFree86 -configure command the process dumps out with the followingerror. (EE) RADEON(0): No valid mode found for this DFP/LCD I then tried hand editing the XConfig file and added the following to the monitor section. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility)
- Original Message - From: Michel Dänzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: hy0 [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, February 02, 2003 7:31 PM Subject: Re: [XFree86] 4.2.99.4 no display, locked keyboard(Radeon7500Mobility) On Son, 2003-02-02 at 12:51, Michel Dänzer wrote: On Son, 2003-02-02 at 06:09, hy0 wrote: Judging from current situation, we probably should take RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the cursor routines. I'd prefer fixing those functions instead. After some more thought, polling for _VBLANK_SAVE in both is probably safest for 4.3.0. Here's what I'm talking about, what do you think? Yes, this should work. Thanks. Hui -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)
- Original Message - From: Michel Dänzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 01, 2003 6:39 PM Subject: Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility) On Mon, 2003-01-27 at 10:14, Nathaniel Gray wrote: I guess this doesn't happen with DRI disabled? Looks like pure luck to me that RADEONWaitForVerticalSync() ever returns when the DRM handles vertical blank interrupts. I'll look into fixing that if noone beats me to it. True, the problem doesn't occur unless DRI is enabled. This patch works for me with DRI enabled, can you (or anyone seeing the problem, for that matter) try it? There could still be an even worse problem if the vertical blank interrupt stops working for some reason (I've seen that happen after some weird 3D client crashes). Another possibility would be polling the CRTC_VBLANK_SAVE bit in the CRTC_STATUS register. Kevin, Hui, anyone interested, what do you think? It appears RADEONWaitForVerticalSync can cause some race conditon with DRM WaitVBlank routine. If this is the case, Michel's patch should work. Since the display driver can also use CRTC2 (different from CRTC1's vblank condition) when DRI is enabled, this makes things more complicated. Judging from current situation, we probably should take RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the cursor routines. The WaitForVerticalSync functions were added for avoiding flickering problem when switching between ARGB and BW cursors. This problem is much less severe than having WaitForVerticalSync to time out, particularly if ARGB cursor is not used as default (has this been decided?). We can work this thing out after 4.3 release. Hui 2. I was using KDM and after exiting X my machine would lock up as it tried to restart the login screen. I think that even without KDM I couldn't restart X after I started it once. I'm not positive about this though. Can you verify that? Would be interesting to know. Nope, I can't verify it. I guess my system just got into a bad state somehow. I'm using 4.2.99.4 right now and have successfully restarted X many times. So you have verified that it only happens with a display manager. :) I haven't tried using KDM again though. Probably still happens with that? One possibility is one or more processes keeping the DRM open (Qt comes to mind) long enough to prevent the next server generation from enabling the DRI. That causing a lockup would still be a bug, but this might give opportunities for workarounds. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] No External Monitor on Radeon Mobility M7 LW greater than laptop's LCD resolution
I've tried everything I can find to get my laptop to shut the LCD screen and use ONLY the external CRT at 1280x1024. My T30 has a 1024x768 LCD screen, and this updated radeon driver won't drive the external CRT greater than 1024x768... This worked fine in XFree86 4.2.1 w/the CrtScreen option. I've tried a multitude of options of the new Clone... options and the paneloff. There is a small bug in the current CVS code affecting your case. If you have the latest CVS code, you can try to apply attached patch. If you don't have the source, you can try to change the Modes from Modes 1280x1024 to Modes 1280x1024 1024x768 in your HomeScreen screen section. Hui radeon_fp_mode.diff Description: Binary data
Re: [XFree86] Re: Have you dropped radeon 7200 support?
On Sat, 25 Jan 2003, hy0 wrote: Thanks for the explanations, now I can see what this is about. However I still have some concerns about this code. Indeed, Radeon chips do have 0x1c0 (misnamed MPP_TB_CONFIG) as SEPROM_CNTL register. Modifying/restoring its SCK_PRESCALE field is unlikely to be the cause of this screen corruption problem. In the current code path, even for a properly POSTed card, MEM_CNTL is set to zero and then restored back. This step may cause some side effect to the memory controller. Properly initializing MEM_CNTL/MEM_SIZE should take several steps (I may miss something): 1. wait for memory control idle (MC_STATUS). 2. configure each channel (MEM_CNTL). 3. reset memory (MEM_SDRAM_MOD_REG). 4. check if each channel works correctly. Simply setting MEM_CNTL to zero and then restoring it back may put memory controller in some bad state. To me, this only means more registers need to be saved, and later restored in a specific order. It should be possible to determine such a sequence from the BIOS init code. It would be for Mach64 and Rage128 variants, I know. But I don't happen to have a Radeon BIOS Kit at the moment. Asic initialization involves not only register writes with correct values, but also state waiting, delaying, resetting, etc. Yes, there are initialization tables in Radeon chips embedded in the BIOS images like in Mach64 and R128, but these tables only got standardized in the relative new versions of BIOS. This means using these tables will introduce compatibility problems with old chip/BIOS. While it's possible to resolve these compatibility problems, it will take a lot of work and tests, don't think it's an option for the upcoming v4.3. Anyway, back to this patch, why does it have to set MEM_CNTL to 0? If you simply comment off OUTREG(RADEON_MEM_CNTL, 0) in PreInt10Save, will the patch still work for your special cases? It's interesting how these special cases out-number the single more common case of not having to re-POST the adapter... I agree the re-POST bug could be quite common for secondary card, since BIOS code itself may not be well designed/tested to run under such conditions. Be that as it may, the attached should work as a temporary workaround. Looks like a good workaround, thanks. Hui Marc. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon 7500 Mobility)
On Mon, Jan 27, 2003 at 09:30:09PM +0100, Michel Dänzer wrote: On Mon, 2003-01-27 at 20:48, Charl P. Botha wrote: With NoAccel only (i.e. NO SWcursor) I don't have these messages, but I do get the same symptoms: blank screen and locked keyboard. BTW, how do you verify that the keyboard is 'locked'? None of the caps-lock, scroll-lock or num-lock keys work, judging by their accompanying leds. This is getting weird, assuming ctrl-alt-bs won't let you quit X. Just checked recent changes, can't think of a reasonable explanation. One remote possibility is the SURFACE_CNTL change. In principle, this change shouldn't cause any problem. But I've seen some strange things with this register on other chips. Can you try this: move save-surface_cntl = 0; into #if X_BYTE_ORDER == X_BIG_ENDIAN pass and replace it with old save-surface_cntl = RADEON_SURF_TRANSLATION_DIS If still no luck, I'll try to reproduce this thing here. Hui -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon 7500 Mobility)
- Original Message - From: Charl P. Botha [EMAIL PROTECTED] To: Michel Dänzer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 7:03 AM Subject: Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon 7500 Mobility) On Sun, Jan 26, 2003 at 02:50:22PM +0100, Michel Dänzer wrote: On Sun, 2003-01-26 at 03:36, Charl P. Botha wrote: I just built 4.2.99.4 from CVS on my Radeon 7500 Mobility laptop. Starting X yields a blank display and a locked keyboard. Attempting to kill X or shutdown the laptop via ssh results in a complete system lockup. 4.2.99.3 works perfectly on the *exact* same configuration. I've attached my XFree86.0.log although it seems to be normal. [...] (WW) RADEON(0): Restoring MEM_CNTL (), setting to 2d002d01 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0400), setting to 0400 Have you been following the discussion about this code? Do any of the workarounds suggested in that thread (about '7200 support') help? Thanks for pointing this out Michel. I just tried the workaround on 4.2.99.4 as documented in http://www.mail-archive.com/xfree86@xfree86.org/msg00961.html by Hui. The MEM_CNTL and CONFIG_MEMSIZE warnings do not appear in my XFree86.0.log (attached) anymore, but I still get the same symptoms: black screen, dead keyboard, machine locks up completely if I attempt a shutdown via ssh. I have confirmed (again) that 4.2.99.3 works perfectly on the exact same configuration. MEM_CNTL problem shouldn't cause machine to lock up. To narrow down your problem, as Michel suggested, can you disable DRI to see if the lockup still happens? Hui Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: XVideo extention shows erroneous picture on ATI radeon
On Thursday 23 January 2003 09:24, hy0 wrote: On Die, 2003-01-21 at 23:19, Hans Korneder wrote: An xvideo picture (actually an video stream) of the size 1920x1080 should be shown in a window of the size 1024x576 (the monitor size is 1280x1024). What actually being displayed is the right hand side of the image, about 80% of the picture, and on the left hand side of the window a pink bar is being displayed. IIRC, the radeon driver advertises a larger maximum Xv image size than the hardware can actually handle. Vladimir? Any way to find out the actual image size the hardware can handle? Is there something like a table of proven capabilities of the cards? Here's an excerpt from an old post I have on this topic. I don't think the radeon driver has code to skip pixels, and its offscreen images code sets the limit at 1024x1024. All Radeon chips support 2Kx2K hardware overlay surface which should be able to handle this case. Not sure if the problem is related to offscreen images code, is v4l driver involved here? It could also be some hidden bug in overlay down-scaling code. Hui There's no v4l driver involved here, at least not that I'm aware of. Do you have a sample piece of code which can verify the 2Kx2K capabilities? The problem can be reproduced here with the code attached. Hans I can get your code running correctly on my system (with some modifications, like xv_port). Anyway, since you mentioned the pink bar in your first post, this reminds me of the pink colorkey color used in the old driver. Maybe you should try the latest CVS code to see if it still has the same problem. You can try XvQueryEncodings function. It returns the encoding structure which usually contains max image size information. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
- Original Message - From: Marc Aurele La France [EMAIL PROTECTED] To: hy0 [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 8:06 AM Subject: Re: [XFree86] Have you dropped radeon 7200 support? On Thu, 23 Jan 2003, hy0 wrote: No, but these warnings are special: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Hey! I have these as well, exactly: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Don't know if they could explain the problem though. Since they have something to do with memory, I am tending to think so, because one of the other symptoms of this problem is that even once I exit the Xserver, the console display is corrupt, as if video memory was being tampled on. Indeed, this is the most outstanding thing in common between both of you. I suspect it could be related to int10. Something like Option NoInt10 and/or not loading the int10 module might work for testing that, assuming the BIOS initializes the card on bootup. I noticed there is a patch (CVS radeon_driver.c v1.72) a few weeks ago which enabled some __alpha__ path code for initializing MEM_CNTL etc. Not sure if the change is added intentionally or accidentally and if it's well tested on all supported cards. This doesn't seem to cause problem on all my cards. But it still looks suspicious. The code also writes to some MPP registers which don't even exist on Radeon chips. This is only partially true. The register does in fact exist. It's just that the driver refers to it with an incorrect name. The register has more to do with the chip's PCI memory decoding than with MPP. Anyway, this change was introduced to fix two separate problems: 1) If MEM_CNTL and CONFIG_MEMSIZE are not re-initialised to their power-up value, a BIOS bug ends up corrupting the chip's memory interface. 2) If the misnamed MPP_TB_CONFIG register is not set properly, a bug in the chip causes it to return zeroes for read-outs of its PCI ROM. Both issues have been seen using various Radeon cores, including R200, RV200, etc. The second problem appears to be a carry-over from the original R128 core. I've been able to duplicate the behaviour using a number of Rage 128's (where MPP_TB_CONFIG is indeed correctly named). The Rage 128 aspect of this issue has yet to be dealt with in our code. All these issues show up when an attempt is made to initialise the adapter more than once between resets (i.e. reboots). For secondary adapters, this occurs when the server is re-run. For primary adapters, when used on platforms that don't make the initialised adapter BIOS available. The original patch submission for this #ifdef'ed itself for Alpha's. But the truth is that these are adapter issues. That they show up more on certain architectures than others is irrelevent. Thanks for the explanations, now I can see what this is about. However I still have some concerns about this code. Indeed, Radeon chips do have 0x1c0 (misnamed MPP_TB_CONFIG) as SEPROM_CNTL register. Modifying/restoring its SCK_PRESCALE field is unlikely to be the cause of this screen corruption problem. In the current code path, even for a properly POSTed card, MEM_CNTL is set to zero and then restored back. This step may cause some side effect to the memory controller. Properly initializing MEM_CNTL/MEM_SIZE should take several steps (I may miss something): 1. wait for memory control idle (MC_STATUS). 2. configure each channel (MEM_CNTL). 3. reset memory (MEM_SDRAM_MOD_REG). 4. check if each channel works correctly. Simply setting MEM_CNTL to zero and then restoring it back may put memory controller in some bad state. Since Cedric doesn't seem to have this problem with old CVS code, maybe he can try to change the current CVS code from #if 0/* !defined(__alpha__) */ back to #if !defined(__alpha__) See if it can make any difference. At least we can rule out MEM_CNTL related code being the cause. All in all, bringing up an un-POSTed card takes quite a few steps (not only MEM_CNTL). This is not properly/completely implemented in the current Radeon driver which makes multi-card set up unreliable. Hui Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA
Re: [XFree86] Re: XVideo extention shows erroneous picture on ATI radeon
On Die, 2003-01-21 at 23:19, Hans Korneder wrote: An xvideo picture (actually an video stream) of the size 1920x1080 should be shown in a window of the size 1024x576 (the monitor size is 1280x1024). What actually being displayed is the right hand side of the image, about 80% of the picture, and on the left hand side of the window a pink bar is being displayed. IIRC, the radeon driver advertises a larger maximum Xv image size than the hardware can actually handle. Vladimir? Any way to find out the actual image size the hardware can handle? Is there something like a table of proven capabilities of the cards? Here's an excerpt from an old post I have on this topic. I don't think the radeon driver has code to skip pixels, and its offscreen images code sets the limit at 1024x1024. All Radeon chips support 2Kx2K hardware overlay surface which should be able to handle this case. Not sure if the problem is related to offscreen images code, is v4l driver involved here? It could also be some hidden bug in overlay down-scaling code. Hui Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Xv for the Radeon 8500 on PPC
On Mit, 2003-01-22 at 14:34, David Brown wrote: Has anyone had any luck getting Xv to work with a Radeon 8500, using XFree86 on Linux 2.4 / PowerPC? I'm able to load the server extension fine; any application that uses Xv looks like it creates a hardware overlay, but the video surface just stays black. The video is being put somewhere, but certainly not on the screen. I replied to this before (Reply-To: munging considered harmful?): The problem isn't PPC specific and should be fixed in CVS. Depending on what distro you're using there may be working snapshot packages. It probably is the false monitor detection problem again, happened on some OEM cards. The driver placed hardware overlay to the CRTC for another port which doesn't actually have a monitor connected, but driver thinks there is. Try to connect the monitor to the DVI-I port with a DVI-I to VGA adapter, see if this makes any difference. Hui -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Have you dropped radeon 7200 support?
On Mit, 2003-01-22 at 03:26, Brian J. Murrell wrote: On Mon, Jan 20, 2003 at 11:15:17PM +0100, Michel Dänzer wrote: No, but these warnings are special: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Hey! I have these as well, exactly: (WW) RADEON(0): Restoring MEM_CNTL (), setting to 29002901 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0200), setting to 0200 Don't know if they could explain the problem though. Since they have something to do with memory, I am tending to think so, because one of the other symptoms of this problem is that even once I exit the Xserver, the console display is corrupt, as if video memory was being tampled on. Indeed, this is the most outstanding thing in common between both of you. I suspect it could be related to int10. Something like Option NoInt10 and/or not loading the int10 module might work for testing that, assuming the BIOS initializes the card on bootup. I noticed there is a patch (CVS radeon_driver.c v1.72) a few weeks ago which enabled some __alpha__ path code for initializing MEM_CNTL etc. Not sure if the change is added intentionally or accidentally and if it's well tested on all supported cards. This doesn't seem to cause problem on all my cards. But it still looks suspicious. The code also writes to some MPP registers which don't even exist on Radeon chips. Hui -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Radeon 9000 problems
I've just installed a Sapphire Radeon 9000 with ATI's fglrx drivers, and I can't get the dual head to work properly; the second screen is always just a copy of the first. Can anyone help? It's a known problem and has been fixed in the new version of driver (probably hasn't been released yet). Check ATI site for the new release. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [XFree86(TM) Bug Report] Radeon 9700TX support
Regarding: Radeon 9700TX support Email: [EMAIL PROTECTED] XFree86 Version: 4.2.1 protocol Version 11, rev 0 OS: Gentoo 1.4rc2 with Linux kernel 2.4.19-gentoo-r10 i686 Area: Xserver Server: XFree86 (The XFree86 4.x server) Video Card: ATI Radeon 9700TX scanpci tells me nothing so this info is from the Dell website. They seem to be the only ones selling this card. Memory: 128MB Controller: ATI Radeon Controller speed: 263MHz Data width: 256-bit RAMDAC: 350MHz It seems to be identical to the Radeon 9700 Pro but with a reduced controller speed. Try the latest CVS code or wait for v4.3 release, it's supported there. Or go to ATI site for the FireGL binary driver if you want 3D support. Hui ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Xpert]Xinerama + Radeon = No error + No Worky
The problem is caused by one of your monitor not being detected. If both of your monitors were connected during boot time (if not, try it), this is probably another instance of the monitor detection problem with some OEM cards (the card id reported by your log file indicates you have an OEM card). This problem started to surface recently with more and more OEM cards hitting market. If this is the case for you, the latest CVS code won't help too much except it'll print out a warning message. There is no workaround and we have to rewrite the monitor detection code for these cards. I'm planning to do this shortly but I don't have any OEM card on my hand at the moment. If you're willing to test, I'll send you the driver when it's ready. Hui Normally I wouldn't mind compiling, but I think it's understandable for X if I'm a little trepidious :) . However, I am anxious enough to do so this weekend or the next, if there aren't any other less adventourus suggestions! :) Thank you for the advice -- I'm sorry that I didn't find that earlier thread on my own. -Gryn (Adam) On Fri, Nov 01, 2002 at 04:50:37PM +0100, Michel Dänzer wrote: On Fre, 2002-11-01 at 16:02, Adam Luter wrote: On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: Attached are my XF86Config-4 and XFree86.0.log files. I believe I have correctly setup my XF86Config-4 file, however my second monitor does not receive any signal. This time I promise not to forget to attach the files! Sorry :) Your config looks fine to me, and the log looks similar to the one someone else posted recently, i.e. everything looks fine except the driver doesn't mention the second head at all. As I said in that other thread after looking at the source, the driver seems to ignore the second head under some circumstances I don't understand; maybe Hui Yu or Kevin E. Martin would. There's also a good chance for this to work better in current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Only 16 bpp mode via DVI, when 24 bpp is shown
The problem is likely caused by PANEL_FORMAT@FP_GEN_CNTL (bit 3) not being set correctly. Radeon cards support 18 and 24 bit panel formats. With panels supporting EDID 1.x, there is no way from EDID data to tell what the actual panel format is. In this case, we can set PANEL_FORMAT to 1 (24 bit). 18 bit panels should be able to handle 24 bit format by truncating the data. With panels supporting EDID 2.0, the panel color depth can be derived from color/luminance description field, but I'm not sure if this is really worth of doing. Simply setting PANEL_FORMAT to 1 will probably work on most of panels. In case some 18 bit panels cannot handle 24 bit format correctly, perhaps we can use DAC_6BIT option to overwrite it (I know the name of this option doesn't make sense here, since digital panel doesn't use DAC). Hui I have been able to reproduce this problem on a DFP with a Radeon VE. I'll be looking into the problem and let you know what I find. Kevin On Sun, Oct 27, 2002 at 02:01:09PM +0100, Christof Ameye wrote: I can confirm: I have the same problem with my Radeon 8500 DVI output to my 18 LCD. If I use the analog output, it works fine: full 24 bit. But that's not an option if you have DVI. Same applies for my tests with windows: DVI delivers perfect 24 bit display in MS windows. It must be a radeon driver problem. At the highest resolution I also have this problem: one missing vertical pixel line around pixel column +-1024 (not a black line, really a missing line), which I again don't have in windows. It really it is strange around so if you have a 'd' on the screen with the long bar being on column 1024, it simply looks like a 'c' ! Christof Holger Isenberg wrote: On Sat, 26 Oct 2002, Mark Vojkovich wrote: You guys are likely misinterpreting what you are seeing. Most digital flat panels are only 6 bits per component! Yes, I know. But the Compaq TFT7010 is not, that's why I choose it. With Windows98 it shows true 24bpp colors on the same machine. -- Holger Isenberg [EMAIL PROTECTED] http://mars-news.de ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon clone mode bug(s) + fix
Michel Dänzer [EMAIL PROTECTED] writes: So the second part of the code in xf86XVAdjustFrame() is the problem? Yes, the problem is that part is called at all. IMHO we should just call RADEONAdjustFrame for cloned display as it is an internal task, not related to any other XFree86 activity. The rest of the server only knows about the primary (and secondary) screen. So this is the correct fix and not a workaround. But what if pScrn-AdjustFrame() is called from outside the driver? AdjustFrame for cloned screen should never be called from outside I think. The outside doesn't even know of the clone display. Yes, this is a bug. As Michel suggested, we should use a dedicated RADEONCloneAdjustFrame() function to separate CloneAdjustFrame from pScrn-AdjustFrame() completely. For primary and secondary displays, my patch doesn't change anything. Some parts of clone mode and secondary display code were separated intentionally, though they are identical at present. Clone mode code can be extended to twinview like feature if there is a need in future. -- Krzysztof Halasa Network Administrator ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon 9000
Hi, The patch for Radoen 9000, M9 and Radeon 9700 2D support has been submitted and will be in XFree CVS tree in the near future. 9000 and 8500 don't share the same IDs, that's for sure. Meanwhile specifying ChipID in the config file with a 8500 or 7500 ID is a correct solution for getting 9000 or M9 to work with the existing X4.2xx Radoen dirver (2D part only, note this won't work with 9700). If you specify ChipID with a 8500 ID (0x4242 for example), it will only work with the single head config. If you want both heads to work correctly with a dual-head/Xinerama setup, use a 7500 (0x5157) or a VE ID (0x5159 for example). Although 9000 uses the same 3D core as used in 8500, its 2D features (dual-head, tvout, etc) actually follow 7500. When you use a 7500 or VE ID, make sure to disable DRI. Although the 2D part of radeon DRI support is likely to work fine with radeon.o kernel driver on a 9000 (this is because the 2D DRI support only uses DMA to send 2D commands, doesn't even use the microcode for 2D commands), any ogl app (like ogl screen savers) will lock whole thing up if DRI is enabled. The failure experienced by Arkadiusz in http://www.xfree86.org/pipermail/xpert/2002-September/020561.html is probably caused by the bug with DDA rountines in the old X4.20 driver, this has been discussed before and has been fixed in XFree CVS tree. Hope this helps Hui I recently recieved a Radeon 9000pro mac edition and hacked it to work by just adding the PCI id as stated in other posts (but in the driver this time), this cards ID is 0x4966. Is it true that there are 9000's with 8500 ID's? ani On Wed, 11 Sep 2002, Alexander Stohr wrote: Hello, What 0x4243 is supposed to mean? It's a pci id of AIW Radeon 8500 DV. So another unsupported one. No, according to the PCI ID database on www.yourvote.com 0x4243 the piggy back firewire port of the 8500 DV. This is indeed not a grafics chip at all. Who the heck has come up with that bogus ID? In the PCI device listing you will clearly find the correct ID of this ATI Radeon 9000 card: 0x4966 Charl is finally most right with his proposal: ChipId 0x4966 (i dont use that because when i am developing i am always having a full X11 tree handy and then i just add the IDs directly into my code, a few seconds recompile of the ddx driver module and its done...) you had two IDs in your specific case, thats why: only primary function 0 does identify the chip, any further device functions only do have different IDs if they do provide something different with the same silicon, a thing that is often seen on intel's bus bridges. Perhaps it has not made into linux kernel yet. kernel? support in kernel is required for DRI. I'm trying to get XFree working even without DRI. The write meant something different - the coding of DRI partially is kernel based and uses the constant defines from linux kernel header files (which do originate from the yourvote.com site). As the Radeon 9000 is a pretty new board the Linux kernel is possibly just updating this, but the DRI project hasnt identified this addition. Thats a development thing users should not care to much. For users there is just the method of browsing their pci configuration and add the yet not known compatible devices to their config file by the ChipID statement. Also try this: Option ChipId 0x4243 XFree drivers do not support 0x4243. It will not work. that boy was hoaxing with his suggestion or using the FAQ template? If still does not work try ati.2 drivers from http://gatos.sf.net/ gatos drivers also don't support 0x4243 (don't support my radeon, too) must be the same boy as above btw. how PCI IDs are managed? Vendor (like ATI) gets some ID space (as in with MAC on network cards) and does whathever it wants in that assigned space? Or maybe vendor is required to register each product in some global database? There is an organsiation called PCI Special Interests Group (www.pcisig.com) that does work on specs. Its a big business club. And it registers the misc companys with a vendor ID. The device IDs are in the duty of the respective vendors. Each of these IDs is 16 bits wide. If you use up 50 device IDs a year, you will have mor than 1000 years of time until you have to register for a secondary vendor ID. ps. response from ati support sucks, automated message ;/ hmm. that means customer support got your mail. ;-) anyways X11-DRI drivers are supported by their respective vendors. -Alex. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
On Thu, 12 Jul 2002, Dr. Andrew C. Aitchison wrote: This breaks DDC on my white box Radeon 7000. Patch to fix this attached. lspci -v -n 01:00.0 Class 0300: 1002:5159 Subsystem: 174b:7112 ... http://www.pcisig.com/membership/vid_search/by_vendor_id/?vendor_id=174btyp e=h suggests that 174b is PC Partner. http://www.pcpartner.com/product-ATI.html suggests they make motherboards wth onchip ATI graphics. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna Hi, Just got a chance to try the latest CVS code, I noticed above patch is in the CVS. However, this patch breaks the DELL VE card detection (at least on my DELL's card). The subsystem vender ID of my DELL VE card is 0x1002 (ATI's ID) and the bit 12 of subsystem card ID is reserved for DELL. It appears some OEMs do not follow this rule. In my next patch, if no other issue, I'll change it to test ATI's ID instead of DELL's ID. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 7500 DVI
Yes. Hi, Does the standard xfree86 'ati' driver for an ATI Radeon 7500 drive the DVI output? I'm after DVI output but would (quite strongly) prefer an open source solution. Regards ~Colin. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
I've been thinking about this and it's not clear to me if or how we could determine which is the primary display. If we can't, it wouldn't be all too useful. In current dual-head mapping scheme, DVI port is always treated as the primary head (first screen, using CRTC) if a monitor (whether a CRT or a FP) is connected there. This is inherited from the earlier M6 laptop support. Under this scheme, you can try DDC_DVI type first. If something is detected there, use it as the primary display, And then try DDC_VGA, DDC_CRT2, BIOS settings in turn for the 2nd display. If DDC_DVI fails, try to look at the BIOS settings (assuming bios can be accessed) to make sure there is nothing connected (a lot of laptop panels do not support DDC). If indeed there is nothing connected, then you can try DDC_VGA, DDC_CRT2 and BIOS settings in turn to determine the primary display. This should work with all existing cards AFAIK. Another possibility would be falling back to defaults for display and DDC type based on chip ID etc. That (and maybe options to override them) should do for laptops without a BIOS, for which I consider this most important. Chip ID doesn't reflect actual connector types and DDC types used, especially when more and more OEM cards are out there. Not sure if there will be some OEM cards for which above scheme doesn't work and we have to add an option. Hui -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
There is no beak, but there is no fall through for 7 or 3: agpMode mode 7 1 6 1 5 1 4 7 3 1 2 3 1 1 Exactly, and then agpgart picks the highest set bit from mode which is supported by the chip and the bridge. My bad. I was looking at the code I modified a while ago for debugging agp fast write. It let all valid bits to pass through (including bits for FW and SB) to agpgart driver. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Recommendations for card with DVI support (1600x1200)
There was a problem with certain panels working at high pixel clock (typically at 1600x1200) on a Radeon board. It has been fixed in the current CVS code. If you just want to give it a quick try, I can send you the binary driver off the list. Hui I'm currently staring at RH7.3 on a ViewSonic VP201mb (1600x1200) attached to the DVI port on an ATI Radeon 7500. Xscreensaver seems to occasionally tickle an Xserver bug (every few weeks), but I haven't had a chance to investigate, so I don't know whether it is a core or driver issue. I haven't seen it on my Matrox G450 yet, but I just upgraded that machine. Might be fixed upstream already ... I need to check the changelog. Regards, Bill Rugolsky ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
On Tue, 2002-07-23 at 22:54, hy0 wrote:
If you set ForcePCIMode on any other architecture, DRI support will be
disabled.
(FIXME: I'm probably misunderstanding this option. How would one
force an AGP Radeon card to work on the PCI bus? Or a PCI Radeon card
(are there any?) to work on the AGP bus? Are there dual-bus
integrated Radeon cards floating around, which can sit on either the
PCI or AGP bus?)
For AGP board, you can force it to use PCI GART instead of default AGP
GART.
This option can be used in following cases:
(1) You have a PCI card.
PCI GART will be used automatically in that case.
That's what I thought when I tried this a few months ago, but it turned out
not the case. When I tried a PCI 7500 on a x86 machine with dri-tnl branch
code, I was expecting RADEONDRIAgpInit to return FALSE and the driver to
fall back to PCI mode. But amazingly, it went through RADEONDRIAgpInit
successfully (on a PCI board!) and treated the board as an AGP board with
DRI enabled. The driver went through all mode initialization stuffs
correctly, and of course, finally locked up when trying to do some
accelerated 2D drawings. When I used ForcePCIMode option, I got DRI working
correctly on that PCI board. It only failed after I played some 3D games for
a while, the cause of failure might not be PCI gart related after all (I
didn't look into it). In addition, I also got the pcigart worked with an AGP
7500 board on that x86 system.
To automatically identify a Radeon PCI card, the PCI subsystem ID (not
device id) has the info. But this is not implemented in the current driver.
If we can't figure out a more general and reliable way to identify a PCI
card (there should be), this method (subsystem ID) can be used.
(2) You have an AGP card, but the agpgart kernel driver doesn't support
the
AGP bridge chipset on your motherboard.
Ditto.
(3) The AGP GART doesn't work correctly.
I'm not sure the current status of pcigart support. It didn't work
reliably
a few month ago.
Still doesn't seem to work on x86 but works fine on alpha and powerpc at
least. Weird.
As said above, I actually got it worked on a x86 system with both PCI and
AGP 7500 card, just not sure how reliably it works on all other systems.
I still think we should consider carefully if we want to document these
options.
IMO, this is a very useful option, especially when a lot of systems appear
to have stability problems with AGP gart. Like the VT switching lockup
problem on some systems, this option is worth to try (you may need to enable
PCIGART_ENABLE compile option first in both 2D and kernel drivers).
Comparing to using AGP gart, using PCI gart might slow things down by 20-30%
in 3D applications, it's still a good option if your agp gart doesn't work
reliably.
AGPMode
Legal values for the AGPMode Option are 1 through 4 inclusive. (Note
that
although 3 is accepted as a legal value, very few systems will support
it.)
(FIXME: on PCs, does XFree86 actually override the AGP mode as set in
the system BIOS?)
During initialization, 2D driver calls into the kernel agpgart driver to
set
specified AGP mode. There is no 3x AGP mode. If you set it to 3, the
agpgart
kernel driver will set it to 2x.
Actually, the value of this option is processed in this switch
statement:
switch (info-agpMode) {
case 4: mode |= RADEON_AGP_4X_MODE;
case 2: mode |= RADEON_AGP_2X_MODE;
case 1: default: mode |= RADEON_AGP_1X_MODE;
}
As you can see, anything except 2 and 4 will set 1x. Even 4 and 2 may
fall back to lower transfer rates depending on the capabilities of the
chip and the AGP bridge. agpgart handles that.
There is no break in above switch statement. 3 LSBs will fall through.
If agpMode=7, 7 will be passed to the agpgart driver. This is not a bug,
agpgart driver
(see agpgart_be.c) will use the highest bit according to AGP bridge's
capability.
That's why I said if you use AGPMode = 3, you'll end up with 2x.
Hui
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
- Original Message - From: James Ralston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 1:56 AM Subject: [Xpert]adding radeon driver documentation Attached is the first draft. Good to see the new Radeon man page being worked on. I'll try to explain some of FIXMEs below. In particular, the following cards are known to work (FIXME: check list): ATI Radeon 8500 series All-In-Wonder Radeon 8500 All-In-Wonder Radeon 8500DV Radeon 8500 128MB Radeon 8500 64MB Radeon 8500LE ATI Radeon 7500 series All-In-Wonder Radeon 7500 Radeon 7500 ATI Radeon 7000 series Radeon 7000 (also known as the Radeon VE) ATI Radeon series Radeon All-In-Wonder Radeon 64MB DDR (VIVO) Radeon 64MB SDR Radeon 32MB DDR Radeon 32MB SDR ATI Radeon Mobility series Radeon Mobility M6 Radeon Mobility M7 The supported chips (series) in the list are almost complete, except 7200 series (new version of old Radeon). I'm not sure if we should list all memory+connector configurations here. There are quite a few OEM versions of Radeon boards which may have different configurations. Note that the following cards are known not to work with the radeon driver. Support for these cards will be added in a future release of XFree86 (FIXME: check both of these assertions): ATI Radeon 9700 series ATI Radeon 9000 series These cards (also M9, using the same RV250 core as 9000) will be supported (at least 2D part) in the near future. Note that not all monitors and not all Radeon cards support the VESA DDC/CI standard. If DDCMode is enabled, but the monitor and/or card does not support the VESA DDC/CI standard, then XFree86 will emit a warning message and use the standard VESA mode timings instead. All Radeon cards can do DDC probe, while some old CRTs or LCDs may not be DDC capable. The advantage of not using DDCMode is that the VESA standard mode timings are supported by virtually all monitors. Additionally, a monitor which does not support the VESA standard mode timings will almost certainly not support the VESA DDC/CI standard. The last statement is a bit confusing and may not be true. Traditionally, the driver uses lookup-best-refresh routine looking for the best refresh mode within standard VESA modes according to the specified VRefresh/HSync ranges. It should work well for most of displays. The advantage of using DDCMode is that your particular monitor may support non-standard non-VESA) mode timings which are better (e.g., a higher refresh rate) than the VESA standard mode timings. Additionally, for flat panel displays being used in analog mode, DDCMode will avoid using unstable modes (some VESA standard modes don't really work with these panels). This is okay. VideoKey Option This Option can be used to override the default video key value (FIXME: what does the video key do? Why would one want to override the default value?) VideoKey (aka colorkey) color is used by hardware overlay for displaying. The hardware overlay image is only visible on the colorkey color. When an application (like gtv) calls into driver for displaying a frame of video, the driver will paint the background of the application window to the colorkey color so that the hardware overlay can display on it. When another window overlaps on top of the video window, the overlay (video image) will be covered as long as the colors in the overlapped window do not match the colorkey color. If one color in the overlapped window matches the colorkey color, that part of window will appear to be transparent (you can see thru it to the underneath video image). To avoid this, you can specify an uncommon color to your system as the colorkey. The following Options are designed for Radeon cards with multiple video ports, Specifying these Options for cards without multiple video ports will have no effect. (FIXME: is this true?) True. The Options are: Option CloneDisplay boolean If set to true, then the DVI port will be cloned onto the CRT port. The default is false (meaning, the DVI port will not be cloned onto the CRT port). This option may be set to default on in future after more tests. All clone mode stuffs shouldn't have any effect if only one monitor connected or if there are two Screen sections. FIXME: the Here is a hack for cloning first display on the second head comments in radeon_driver.c (in the RADEONPreInitModes function) seem to imply that if both the DVI and CRT ports are being used, and both have displays connected to them, and only one screen is defined in XF86Config, and CloneDisplay isn't being used, then the monitor connected to the CRT port will be driven according to the capability of the monitor/panel connected to the DVI port. But the VE and M6 have both DVI and CRT ports comments (in the RADEONGetBIOSParameters function) seem to imply that if both the DVI and CRT ports are being used, and both have displays connected to them, and
Re: [Xpert]ATI Radeon patch testing
The combination of two methods will make the auto-detection more reliable. Sounds promising. Will you do that anyway, or should I look into it? Meanwhile I don't have much time on this. Go ahead to do it if you have time, I'll be glad to help if you need any more information. One thing I was a little worried about is that enumerating through all 4 DDC types can be slow. In order for DDC detection working with some old panels, I have to use several delays in DoDDC routine which makes it kind of slow. You probably can ignore DDC_MONID type, I haven't seen it ever being used. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
Not every machine has a BIOS. In that case, there are a few more things (in addition to panel size) we need to worry about before it can work reliably. Things like PLL ref clock, display type ... are all derived from video BIOS image. As for non-native modes (resolution lower than panel size), by default, radeon driver will use the internal ratio matrix expansion (RMX) unit to scale the display down. It works not only for all standard VESA modes, it'll work also for any mode between 320x200 and panel size, for example 600x500. That was just an example why using virtual resolution as panel size doesn't work in general. Virtual resolution should not be used as panel size, it never has. Is the DDC detection OK? No, because we don't have a way to determine the display type yet (do you happen to know a way which doesn't require a BIOS?). If I hardcode info-DisplayType = MT_LCD; info-DDCType = DDC_DVI; DDC works (nice!), but there's still the same flicker. Option DDCModes isn't used, but I assume not providing any Modes is mostly the same. I took a shortcut in determining the display type -- thru video BIOS settings. It works in most of cases, but not really reliable as seen in your case (I have comments on this inside the code, I think). A more proper way to enumerate through all DDC types and probe potential connected monitors. Once you have EDID data, you can derive its display type. This should work in your case. But, in general, you cannot conclude there is no display connected if the DDC detection fails. A lot of laptop panels simply are not DDC capable, the panel info is hardcoded into the BIOS image (this may not apply to you). The combination of two methods will make the auto-detection more reliable. As for the flicker problem, maybe you can print out all PLL parameters and CRTC settings used by driver and compare them with the settings used for FBDev. If the driver cannot access BIOS, it'll use the hardcoded PLL parameters, I'm not sure if they are correct in your case. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
Hmm, with XF86-4.2 I had to use CrtScreen to get a display, now I had to set: Option CloneDisplay 1 Is that the intended way to do it? Yes. This option is supposed to be on by default. Since that part of code is not well tested, it's default off for now. Anyone who wants to mirror the 2nd display should turn on this option. Without either one, I don't get a display on my CRT (which is my only monitor, somehow the card thinks I have a flat panel which I don't have). It's strange. Are you using one of mibile cards (M6/M7)? From what I know, only mobile cards for internal qualification behave like this. The retail mobile cards are usually built into a laptop which has a LCD connected. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon Mobility M6/7 LW on IBM Thinkpad T30 (Simultaneous CRT/LCD Display)
Excellent!! I compiled a fresh XFree distribution and moved the drm kernel driver radeon.o and agpgart.o away from the kernel-module search paths. Now I am getting exactly what I want on both the CRT and the LCD. The CRT has a refresh rate of 75 Hzwhere its usable :-) However! DRI isnt working. Relevant lines from XFree86.0.log (the whole file is at http://www.senfamily.org/xfree/XFree86.0.log_20020711 ): [drm] failed to load kernel module radeon (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. If I cant use the radeon.o from the kernel, where can I compile one from? Its not obvious where in the Xfree tree it is. 'make World' under xc didnt seem to produce one. DRI didn't work because you don't have the kernel driver (radeon.o) on your system. To compile DRI kernel driver, go to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel directory, do 'make -fMakefile.linux'. You may have compile problem if you are using some new version of kernel. If so, you can download a version of Linux kernel (like 2.4.18) from www.kernel.org which should contain the standard DRI kernel driver (not Gatos one). Also, how about AGP? Should I be using: Option AGPMode 1 in the device section? Do I need agpgart.o from the kernel for AGP support? You don't have to specify AGPMode, the default is 1x. You can use this option to set 2x or 4x mode. You do need agpgart module for DRI to work, the best way is to compile it into the kernel. If you want to use it as a separate module, make sure to load agpgart.o before radeon.o. Last but not the least, where can I get the source for the ati_drv and radeon_drv modules that you sent me? I sent two patches to xfree a few months ago, the first is in current CVS, not sure if the second got in yet (the patches are too big, they may take quite a bit time to merge). Anyway, those patches are not quite complete. At present I really don't have much free time to sync with current CVS and make another patch. I'm thinking, maybe a little latter, I'll put everything together with the 2D support for all the new cards on my systems and make a patch to the CVS code. Before then, if you want the code, I can send you the source with no new card support. Thanks VERY much! DS ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon Mobility M6/7 LW on IBM Thinkpad T30 (Simultaneous CRT/LCD Display)
It looks like you are still loading Gatos drm kernel driver (can't get too much from your corrupted log file). The drivers I sent you will NOT work with any Gatos drivers, it will lock up for sure if you still have the Gatos version of drm kernel driver (radeon.o) on your system to be loaded. Try to disable DRI or replace the DRI kernel driver (radeon.o) with the one from stock X4.2 or from Linux distributions like RH7.3. Specifying ati or radeon in your config file should give the same result. If not, your drivers are broken somehow. If you prefer to using Gatos drivers, posting your problem to Gatos forum may help you better. But I doubt they will have a better solution for your current problem. Hui - Original Message - From: D. Sen [EMAIL PROTECTED] To: hy0 [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 9:06 AM Subject: Re: [Xpert]ATI Radeon Mobility M6/7 LW on IBM Thinkpad T30 (Simultaneous CRT/LCD Display) Well I tried your drivers. In short, they didnt work. Both the LCD and CRT came up with distorted lines (which can best be described as noise) and my machine froze. I tried using ati and radeon in the card section and have attached my XF86Config-4. The logs can be found at http://www.senfamily.org/xfree/XFree86.0.log_HUI and http://www.senfamily.org/xfree/XFree86.0.log_HUI.radeon The XF86Config-4 file was also overwritten with garbage after I tried to use radeon as my driver. (This could be a file system corruption due to the freeze + rebooting) So far, a single monitor configuration using the old radeon (GATOS?) driver is working best for me. I reported that using ati and a dual headed configuration worked too. However, power management is broken in that configuration. The screen distorts if the machine is left alone for a while or the machine is put into 'suspend/sleep' mode. I am stuck with a 50 Hz refresh display on the CRT with both the multi-headed 'ati' driver and the single-headed 'radeon' driver. I have chosen to use the 'radeon' as it seems to support power management. DS hy0 wrote: If you are trying to mirror your LCD on the CRT, try attached binary drivers. This is a version with the native 2nd-head mirroring feature for X4.2x. Simply replace radeon_drv.o and ati_drv.o on your system (under /usr/X11R6/lib/modules/drivers/). Use just the single head config for your LCD (remove all the dual-screen stuffs from your config file). The driver will detect and bring up your CRT to its best refresh (suppose your CRT is DDC capable, if not, there are options let you configure it). You can also configure two heads with different resolution with some special options (let me know if you ever need them), the driver will handle panning. This approach is better than the dual-screen approach in following ways: 1. With dual-screen, DRI is disabled. You can enable DRI with this one. 2. Overlay won't work on your CRT with the dual-screen setup. It'll work here. 3. Less overhead. With dual-screen, only half of video ram can be used for one screen... 4. With dual-screen, you may have problem with the hw cursor on your 2nd head (not sure if it's fixed). 5. should be easier to setup with this one. Attached drivers have been tested by several people on a few M6 based laptops and other systems. It should work with M7 based systems. If you want to give it a try, let me know whether it works for you. If not, send me your log and config file. Hui - Original Message - From: D. Sen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 08, 2002 4:43 PM Subject: Re: [Xpert]ATI Radeon Mobility M6/7 LW on IBM Thinkpad T30 (Simultaneous CRT/LCD Display) Michel Daenzer wrote: On Mon, 2002-07-08 at 17:24, D. Sen wrote: Well, I think I set up my XF86Config-4 to do what you suggested. I am including it with this email. However, X crashes on me when I try to invoke startx (including /var/log/XFree86.0.log as well). If I change the screen directive for the Card1 device from Screen 1 to Screen 0, I get a display on the external CRT (the LCD is just backlit with a blank screen). Any ideas? [...] (II) RADEON(0): Shutting down Xvideo subsystems (II) RADEON(0): membase=0xe800 memsize=0x0400 gpSize=0x0008 This looks like you're using GATOS drivers, does the crash occur with stock XFree86 drivers? Specifying the ati driver as opposed to the radeon driver does work better. X isnt crashing anymore. I am also getting a display on both the LCD and the CRT screen. However, I dont seem to be able to change the refresh rate on the CRT. I have tried quite a few different modelines but the refresh rate doesnt change from the 50 Hz (It seems to pick the modeline from the bios settings for the clock rate, etc) The new XFree86.0.Log is at http://cafebleu.no-ip.org:9135/xfree
Re: [Xpert]Dual head Radeon 7500 questions
I guess what Michel was trying to say is: add something like BusID PCI:1:0:0 to both of Device sections in your config file. If it still doesn't work, post your log file. I've got the bus id as noted below, yet I get the same thing, mirrored images on both monitors. Radeon VE here. Michel Dänzer wrote: On Tue, 2002-07-09 at 11:54, John Gibson wrote: I have a ATI Radeon 7500 that I am trying to get dual heads working on. Currently I have a mirror of my desktop on each viewsonic monitor. Below is my XF86Config-4 file. Thanks in advance for any help anyone can give. I can only guess without seeing the log, but you probably need to put the bus ID of the chip in both device sections. -- Until later: Geoffrey [EMAIL PROTECTED] I didn't have to buy my radio from a specific company to listen to FM, why doesn't that apply to the Internet (anymore...)? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: ATI Radeon VE dual head support? [PATCH for Dell OEM boards]
The patch has been submitted and will soon be integrated into CVS. Attached is the binary driver for X4.2. Replace /usr/X11R6/lib/modules/drivers/radeon_drv.o if you are using X4.2 (or RH7.3). It may not work with other versions of X. The driver definitely needs more tests, so let me know if you have any problem with it. Hui Have these changes made it into CVS? I'm having the same problem as others in this thread using the Dell OEM Radeon VE (i.e. 2nd display doesn't work). If not, can I help out by testing these changes? Thanks. -- Chris Egolf http://www.ugholf.net [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert radeon_drv.tgz Description: application/compressed
Re: [Xpert]ATI Radeon VE ( Dell OEM version )
Is the ATI Radeon VE the same as the 7000? I read this somewhere. Yes Any idea if 4.2 will work with this? Yes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE ( Dell OEM version )
You can try X -configure after installing X4.2. If it still doesn't work, send your log file. Thanks for responding. I've gone through the steps of installing the 4.2 binaries and running the xf86cfg. One issue is that 4.2 source files may have been installed, and other files installed - which prevents startx from working. The configuration program works, but xwindows will not start. Do you suggest doing a fresh install of redhat 7.1, then the 4.2 binaries and xf86cfg ? or any other suggestions/steps to have this work? The system purchased is listed here: http://www.tigerdirect.com/applications/SearchTools/item-Details.asp?sku=TSA -21-10AX -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of hy0 Sent: Friday, May 17, 2002 1:26 AM To: [EMAIL PROTECTED] Subject: Re: [Xpert]ATI Radeon VE ( Dell OEM version ) Is the ATI Radeon VE the same as the 7000? I read this somewhere. Yes Any idea if 4.2 will work with this? Yes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE ( Dell OEM version )
This feature will soon be in CVS. I have a test build for X4.2, let me know if you want to give it a try. Hi, I have a Dell OEM ATI Radeon VE with a DVI interface on it. There is _not_ a vga interface on it. Only the DVI. I have a converter (that came with the card) that goes from the one DVI connector to two (2) VGA connectors. I would like to connect a monitor to each of these VGA connectors, and run Xinerama to span an X Desktop across both of them . But before I do that, I was wondering...is it possible to configure X in this way? Currently, I can only get the first monitor (the first interface) to work. Is there something I can do make the X talk to BOTH monitors? I'm running: Linux: Slackware 8.0 Kernel: 2.4.18 XFree86: 4.2 If there currently isn't a way of doing this, is there a plan to add this support to X in the future? - Thanks, Todd ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: ATI Radeon VE dual head support? [PATCH for Dell OEM boards]
We have bought a number of Dells with the OEM RadeonVE card. I can certainly confirm that they are strange compared to the out-of-box Radeon VE QY, although the PCI vendor id is identical. Have a look at: http://wetlogic.net/stewart/xfree-radeon-ve/radeon-ve-dell.jpg to see the card and the single connector on the board. Unlike the retail version of the board I have, this board does not duplicate output on both connectors, but instead displays only on cable 1 (the blue connector on the Y-adaptor in the picture), and nothing at all on cable 2. Nice picture. Just to add, Dell also has a different Y-adaptor with two DVI-D outputs (working for the same card) as disscussed below. When I tried a dual-head configuration that works successfully on a retail version of the Radeon VE versions, I found two problems which I patched: - The first problem is that the primary interface does not report the BIOS value that radeon_driver.c expects in the function RADEONGetBIOSParameters(). Instead, it reports only a CRT on the secondary connector. In the single-headed case this works correctly. In the dual-head case things would also work correctly except that when RADEONPreInit() is called on the second screen instance, it checks for BypassSecondary and quite silently returns FALSE. This stumped me for a long time since there were no error messages in the X log file that indicated why Screen 1 was completely ignored in my XF86Config-4. I'm not sure I understand why it is an error ifthe BIOS doesn't claim to detect a second monitor. Does this mean the user must reboot in order to attach a second monitor, or in many cases just because it happened to be off at boot time? In my patch, I commented the return out, but I think it's worth opening a discussion (I'm not on Xpert, so please Cc me). The behavior as a result of this change is that if there's a second screen definition and the card is multi-head, and there's at least one monitor attached, the second monitor is pre-initted. Current driver uses BIOS settings to detect connected monitors, this requires you to have correct monitors connected during the boot (some versions of BIOS can handle hot-plug, which will set correct settings even after boot). Ideally the driver should do monitor probe itself (scan through all DDC types and try to talk to the possible connected monitors). Even more, it should handle hot-plug interrupt, so that you can swap or plug a monitor even after X started. But all this takes time and man power to get implemented. BypassSecondary is used when only one monitor connected to the second CRT port while you have dual-head setup in the config file. I remember there was some problem before this flag was added. So be careful to comment it out. In you case, it seems you didn't have all monitors connected during the boot, the BIOS didn't detect one of your monitor which causes it's bypassed. - The second problem is that the secondary monitor on the OEM Dell Radeon VE uses DAC2 for output. There was actually a bit of commented out code in RADEONInitCrtc2Registers() already, so I simply added an option named Crt2Dac2 and tested for it there. The true maintainers of this code may want to add another boolean field to RADEONEntRec and hunt for the option elsewhere, if they think that's cleaner. Thesecond screen definition in my XF86Config-4 now looks like: Section Device Identifier ATI Radeon 1 Driver radeon BoardName Radeon BusID PCI:1:0:0 Option AGPMode 4 Option Crt2Dac2 Screen 1 EndSection DELL card can be auto detected from Sub-System Card ID of PCI configuration space. So you don't really need an option for it's special configuration. Yes, for DELL's two CRTs adaptor, you need to turn on TV DAC to drive secondary CRT (RADEON_DAC2_DAC2_CLK_SEL). For dual DVI-D cable, things are more complicated, mode validation routines have to be added and FP2 registers need to be programmed for the second flat panel. The third problem, which I didn't deal with, is that the DDC info for the two monitors attached was swapped. In other words, the DDC info listed for screen 0 (the monitor displaying the settings listed in the Screen 0 Section, also the monitor connected to the first cable) appeared in the section of the log file dedicated to screen 1, and vice versa. This wasn't a big enough problem for me to solve, and since it's hard to solve it without yet another option, I decided to forego it. The DDCType from DELL card's BIOS does not follow the old rule, it need to be hard coded. I have working code on my system for both 2-CRT and 2-DVI adaptors. The code has lots of other changes since XF4.20, part of them is being merged into current CVS tree. I can send you a copy if you
Re: [Xpert]ATI Radeon VE dual head support?
Try to add BusID PCI:1:0:0 in both of your device sections. I do believe my ServerLayout section is correct as well. I've attached a log file as well as my entire XF86Config. I will feely muchly indebted if someone can help me with this! I am, BTW running a genuine ATI card. Came in an ATI retail box, even. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE dual head support?
Have you put Screen 0 and Screen 1 in your SeverLayout section? If yes, post your log file. x420 supports VE dual-head setup. However if you are using some OEM version of VE card (like DELL's) you might be out of luck. After hours of net searching, I've been unable to find any information about whether or not the Radeon driver supports the dual-head cards. X runs just fine, but I'm unable to set up multiple displays-- I'm stuck with one display mirrored on two monitors. While stereo-scopic vision is nifty and all, I'd prefer something a little more useful... Has anyone gotten dual-head working on the Radeon VE? IS this even supported in the driver? If so, how? Any help would be appreciated, considering I bought this card simply because it was dual-head. I'm running 4.20, and here are the relevant sections of my XF86Config file: Section Device Identifier RadeonVE VendorName ATI BoardName Unknown Driver ati Screen 0 EndSection Section Device Identifier RadeonVE2 VendorName ATI BoardName Unknown Driver ati Screen 1 EndSection Section Screen Identifier Screen 1 Device RadeonVE Monitor nanao DefaultDepth 24 Subsection Display Depth 24 Modes 1024x768 ViewPort0 0 EndSubsection EndSection Section Screen Identifier Screen 2 Device RadeonVE2 Monitor gateway DefaultDepth 24 Subsection Display Depth 24 Modes 1024x768 ViewPort0 0 EndSubsection EndSection ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE dual-head problems
I've been trying to configure a dual-head system using ATI Radeon VE on Linux RedHat 7.2, Xfree86 4.1.0 (as it comes in RH7.2). The card is the Dell version of Radeon VE, which doesn't have two connectors on it, but a larger one, from which a Y cable can adapt to a pair of analog or digital style connectors. Current dual-head support has known problems with some OEM cards. The dual-head problem with DELL/VE card has been reported before, hopefully this can be resolved in the near future. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon VE dualhead
You can try to use HorizSync 80 and VertRefresh 75 (be careful, check your monitor manual first) instead of HorizSync 64 and VertRefresh 60. Or you can simply try to remove HorizSync 64 and VertRefresh 60 lines from both of your Monitor sections, radeon driver will use the sync ranges from the EDID (this may not work for you if your monitors have multi separate sync settings). Your monitors seem to only support 1280x1024@75Hz. If you force it to 1280x1024@60Hz as you did, it may have the problem as you experienced. BTW, your monitors use analog input, you don't need Option CrtScreen lines. hy - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 11:42 AM Subject: Re: [Xpert]Radeon VE dualhead Here is the attachments I meant to include... -- Today's funny quote of the day: I have flabby thighs, but fortunately my stomach covers them. www.GCFL.net (The Good, Clean Funnies List): Good, clean funnies five times a week, FOR FREE no ads in the mailings! The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
