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 > _
Re: [Xpert]turning off XAA feature on Radeon
There is a better solution for what you want in current XFree CVS code. In old X4.2 radeon driver (as in RH73), the CRTScreen option will force the driver to use the same VESA mode for both of your projector and LCD. Since a lot LCDs do not work well with the standard VESA modes, this is probably why you're seeing flickering on your LCD (you are lucky here for just seeing flickering). In the new code, CRTScreen option has been removed. Instead, the driver will bring up both of your projector and LCD individually with their own CRTC parameters. Also, there will be some options to let you pre-configure your projector so that you don't have to plug in your projector before X starts. Just want to add, using CRTScreen option with X4.2 radeon driver could be bad to your LCD if you didn't configure it correctly or you were unlucky. Hui > > Michel: > > Thank you. Your suggestion worked for me. The CRTScreen option forces > XFree86 to search through individual VESA modes. However, for this to > work, the projector should be plugged in and on before starting X. In > addition, there is a loss of image quality (slight flickering) on the LCD. > However, this works and I am very happy. > > I have posted a short web page concerning the use of the HP Pavilion > ZT1290 with Redhat Linux 7.3. I will add this to the page. For those of > you that might be interested, the web page address is > > http://emlab2.nmsu.edu/zt1290.html > > -- > Steve Castillo > > On 28 Aug 2002, Michel Dänzer wrote: > > > On Tue, 2002-08-27 at 23:01, Steven Castillo wrote: > > > > > > I do not want my resolutions to scale to full screen. The reason for this > > > is simple - Most overhead projectors will not sync to the highest > > > native resolution of my laptop - 1400x1050. However since all the > > > lower resolutions scale to this higher resolution (and the scaling > > > produces a low quality image), I am unable to sync to a projector at > > > any resolution! This is a fatal flaw for me. I will have to boot to > > > winxp to use a projector connected to my external laptop video output. > > > > I don't think so. Why didn't you mention anything about an external > > projector in your original post? > > > > The problem isn't the scaling but that the external video is driven from > > the same CRTC as the internal panel by default. Try Option "CRTScreen" > > or the directive > > > > Screen 1 > > > > in the device section. > > > > > > > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 4.3?
> Any ideas as to when 4.3 going to be out? > > I am still having issues with my Dell OEM Radeon VE (I got both screens > working by patching 4.2.0, but screen 2 is blurry) > > I know there was a major patch to ATI Radeon driver that was supposed to fix > a lot of issues. I tried to get the latest source out of CVS, but I can't > seem to get it to compile (or if it does compile, it does not run) Probably > a mix of my own issues and the fact that i am checking out work in progress. > > So, does anyone know when the next stable release is due? Or else does > anyone know how to checkout the latest known STABLE code from CVS? > > Thanks. I compiled the CVS code a few days ago. Doesn't seem to be of any problem in compiling. However the support for Dell VE card is broken because of a new patch. It'll be fixed later. In case you want to try it now. I'll send you the precompiled binary driver on my system (should work with DELL VE for dual-head on X4.2). Hui > > -M > > > ___ > 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: [Dri-devel] Floating point exception in Radeon driver at 1400x1050
> On Sun, 2002-08-11 at 12:04, Mike A. Harris wrote: > > There is an easily reproduceable FPE in the Radeon driver at > > a resolution of 1400x1050. > > According to earlier Xpert posts, it also happens with 1600x1200. > > > I'm just beginning to debug it, but wondered if anyone else has > > encountered this and might already have a solution. > > Have you tried the XFree86 CVS trunk? It is caused by the calculation for DDA registers. It's the leftover from r128 stuffs and is no long needed by radeon chips. XFree86 CVS code had this thing removed several months ago. 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]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
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=174b&typ 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]Dual-Head on DELL OEM Radeon VE's
You can try the latest XFree86 CVS code. Hui > Sorry of this ends up being posted twice, but I never seen it hit the list > the first time around, so I am assuming it was lost. > --- > I am trying to get dual-head (xinerama) working on DELL OEM'ed Radeon VE. I > am using RedHat 7.3, default install. > > Under this configuration, I could not get second monitor to show any signs > of life, but I found the following message on the xpert list that seems to > deal with this exact issue: > > http://www.xfree86.org/pipermail/xpert/2002-April/017038.html > > Following these instructions I configured /exp/X11/XF86Config-4 file, and > got RedHat srpm for XF86 4.2.0. I expanded the srpm, added the patch (I had > to adjust it to new line numbers) and rebuild/installed rpms. > > The result came out to be a bit strange. The dual-head config DOES in fact > produce output on two screens, but while the first one is working fine, the > second one is blurry. Parts of the images on second screen move as I move a > window around, especially between the monitors.It's kind of like the colors > are separating a bit. The on-screen display on my monitors (DELL M991) is > capable of showing current resolution. The first monitor shows 1024x768 @ > 85HZ (as it should be) but strangely enough it shows 69K / 85HZ -- I am not > sure I understand that notation. Both monitors and video card setting in > XF86Config-4 file are same (see attached) I took out modelines and I tried > putting some in, tried changing resolutions, nothing seems to cure this. > > > Anyone have any ideas? > > -Michael > > BTW, Same hw config works fine in dual-head Win2k config. > > -- > XF86Config-4 sans the comments > --- > Section "ServerFlags" > Option "Xinerama" "on" > EndSection > > Section "ServerLayout" > Identifier "Anaconda Configured" > Screen 0 "Screen0" LeftOf "Screen1" > Screen "Screen1" 0 0 > InputDevice"Mouse0" "CorePointer" > InputDevice"Keyboard0" "CoreKeyboard" > EndSection > > Section "Files" > RgbPath "/usr/X11R6/lib/X11/rgb" > FontPath "unix/:7100" > EndSection > > Section "Module" > Load "GLcore" > Load "dbe" > Load "extmod" > Load "fbdevhw" > Load "dri" > Load "glx" > Load "record" > Load "freetype" > Load "type1" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "keyboard" > Option "XkbRules" "xfree86" > Option "XkbModel" "pc105" > Option "XkbLayout" "us" > #Option "XkbVariant" "" > #Option "XkbOptions" "" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "IMPS/2" > Option "Device" "/dev/input/mice" > Option "ZAxisMapping" "4 5" > Option "Emulate3Buttons" "no" > EndSection > > Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName"Monitor Model" > HorizSync 30.0-96.0 > VertRefresh 50.0-160.0 > Option "dpms" > EndSection > > Section "Monitor" > Identifier "Monitor1" > VendorName "Monitor Vendor" > ModelName"Monitor Model" > HorizSync 30.0-96.0 > VertRefresh 50.0-160.0 > Option "dpms" > EndSection > > Section "Device" > Identifier "Radeon0" > Driver "radeon" > VendorName "ATI Radeon VE" > BoardName "ATI Radeon VE" > Option "AGPMode" "4" > BusID "PCI:1:0:0" > Screen 0 > EndSection > > Section "Device" > Identifier "Radeon1" > Driver "radeon" > VendorName "ATI Radeon VE" > BoardName "ATI Radeon VE" > Option "AGPMode" "4" > Option "Crt2Dac2" > BusID "PCI:1:0:0" > Screen 1 > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Radeon0" > Monitor "Monitor0" > DefaultDepth 24 > > Subsection "Display" > Depth 24 > Modes "1024x768" "1024x768" > EndSubsection > > EndSection > > Section "Screen" > Identifier "Screen1" > Device "Radeon1" > Monitor "Monitor1" > DefaultDepth 24 > > Subsection "Display" > Depth 24 > Modes "1024x768" "1024x768" > EndSubsection > > EndSection > > Section "DRI" > Mode 0666 > EndSection > --- > > ---XFree86.0.log--- > > XFree86 Version 4.2.0 (Custom Build: 4.2.0-8) / X Window System > (protocol Version 11, revision 0, vendor release 6600) > Release Date: 23 January 2002 > If the server is older than 6-12 months, or if your card is > newer than the above date, look for a newer version before > reporting problems. (See http://www.XFree86.Org/) > Build Operating System: Linux 2.4.18-5bigmem i686 [ELF] > Build Host: hp002 > > Module Loader present > Markers: (--) probed, (**) from config file, (==) d
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]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
> > 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]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 CR
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
>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 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
Thanks for Kevin merging this large patch I built. Since there are lots of changes involved, some issues will surface with more testing. In fact, I found a few bugs (like in DDC detection and DFP handling) in this patch after the patch was submitted. I haven't got time to make another patch yet. I'm thinking, after putting together the 2D support for all the new cards, I'll submit another patch. For now, I'd like to hear more feedback. Below I'll try to explain some issues raised. > On Thu, 2002-07-11 at 22:27, Kevin E Martin wrote: > > I've just checked in a large patch from ATI. Here's the CHANGELOG > > entry: > > > > 199. ATI patch to: > > - Fix Dell OEM VE card support > > - Add better clone mode support > > - Fix large panel (>= 1600x1200) detection and initialization problems > > - Remove "PanelSize" and "CrtScreen" options since they are no longer > > needed with new CloneMode and improved flat panel support > > At least Option "PanelSize" would still be useful for systems where we > can't determine the panel parameters yet. Current Radeon driver supports two kinds of panel: TMDS panel (usually used for desktop, named as DFP in the driver for some legacy reason) and LVDS panel (usually used for laptop, named as LCD in the driver). The TMDS panels should be DDC capable, if not, the BIOS won't even be able to bring them up to text mode. For this kind of panel, the radeon driver will try to do DDC detection first. If it fails for some reason, the driver will used EDID data detected by BIOS. With the DDC info, the driver can figure out the panel size and bring it up automatically. The laptop (LVDS) panels usually are not DDC capable (some new ones are). The panel size and timing information are hard coded into video BIOS and radeon driver will use it to bring the panel up. The only potential problem here is that some custom version of BIOS doesn't follow the rule and put the panel info to a different place. I haven't come across such a laptop yet and would like to know if someone has one. Only knowing panel size (together with VESA timings) usually is not good enough to bring a LVDS panel up properly. Even with the correct modeline, it's better to know other things (like power delay) to safely turn the panel on/off. Let user to specify panel size can be error prone. Anyway, if there are people out there really requiring this option, I can put it back. 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. If the DDCMode option is enabled, the driver will use the modes listed in the EDID data, which will let the panel to scale down with its own scaler. > > - Add "DDCMode" option to detect and use DDC modes > > - Add "PanelOff" option to disable panel on laptops > > - Fix corrupted console problem > > - Other misc fixes > > (#A.1043, Hui Yu@ATI). > > > > I'd like get some feedback on how it works for others with both desktop > > and laptop Radeons. > > Doesn't quite work on a Titanium PowerBook III (without Option > "UseFBDev", with a 1280x854 modeline obtained by radeonfb via EDID which > works fine with that option). There are flickering lines on the right > side. Is the DDC detection OK? If so, can you try to use DDCMode option? I know something broken with DDC detection in this patch. If so, can you send me your log file? > Also, I think it would be nice if the radeon driver was better > documented, in a manpage and/or programs/Xserver/hw/xfree86/Options. I > don't know what the Clone options are for even after a quick look > through the code, how is an end user supposed to know? Clone mode is for 2nd head mirroring by using CRTC2. Quite a few people asked for this feature (a recent example http://www.xfree86.org/pipermail/xpert/2002-July/019082.html). When I wrote dual-head/panel support for X4.2, I didn't have time to add the 2nd head handling when only one screen is specified. It turns out some people plug in both of their monitors and only have one screen section in their config files. This results in various problems caused by the same CRTC driving two monitors with different capabilities. I agree we need to improve the documentation. Lots of questions appeared on this forum are because of lack of document. A couple of months ago, Achim Bohnet ([EMAIL PROTECTED]) offered to do this work. He helped me a lot in testing this patch. Together we have tested on 10+ different flat panels. And we found a few issues even after the patch was submitted. Not sure if he is still available now. Hui > > > I'll start working on the other patches that have been sent in shortly. > > Great, thanks. > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI proje
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]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]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 "Scr
Re: [Xpert]ATI Radeon VE ( Dell OEM version )
Looks like you are still using X4.02. Try to reinstall X4.20 > log file attached. thx for any help. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of hy0 > Sent: Friday, May 17, 2002 2:25 AM > To: [EMAIL PROTECTED] > Subject: 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 > ___ 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 )
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 )
> 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 )
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.2
Re: [Xpert]Using Radeon with two heads?
> I tried a two-headed configuration, with the CRT defined in separate monitor > and device sections. That worked once or twice, but usually caused the LCD > to bloom. I've tried changing the modules, excluding various ones in some > experiments. It seems to be very sensitive to whether the monitor (a > Viewsonic G810) is connected, so it's some interaction of the laptop BIOS and > DDC, I guess. For example, when I have a single-screen configuration, set to > 1280x1024 (so that both the CRT and LCD can display it), and I've turned the > LCD off with the keyboard function-key control, then when I fire up X the LCD > always turns back on so that both the CRT and LCD are on. > > I've been looking for a way to keep the LCD off so that I can drive the CRT at > a nice high resolution that both the CRT and Radeon support (exceeding the > specs on the LCD). crt_screen option is broken. This option was originally intended to do exactly what you want, but the part of code for turning off panel is missing somehow. So when you use this option, both heads are driven by the same CRTC according to the capability of the CRT connected. This causes the problem on your panel. The new approach to this issue in upcoming driver: When both heads have monitor connected, the driver will always use a different CRTC to control each head and bring both monitor up according to the spec of individual monitor. This does not require the dual-head setup in your config file and two monitors are in "clone" mode. Some people do wish to have two monitors mirroring each other (for example, when connecting a projector to the laptop). There is an option (PanelOff) to turn off your panel if you don't want to see anything there. When in "clone" mode, the two monitors don't have to be in same resolution and DRI, overlay will all work correctly on both monitors. For example, in your case, you can use a normal single-head config with 1600x1200 in the Device section. The driver will bring up your LCD to 1400x1050 and CRT to 1600x1200 (driver will also handle panning). You can turn your LCD off with the PanelOff option. This part of work (along with other things) is being merged into current CVS tree (not finished yet). I have working code in my system. If you want a give it a try, I can send you the binary for x420 or the source. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 7500 with 1600x1200 via DVI offset problem/bug
It's a driver bug, I'll get back to you later off the list. - Original Message - From: "Achim Bohnet" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 10, 2002 9:29 AM Subject: [Xpert]Radeon 7500 with 1600x1200 via DVI offset problem/bug > Hello Xperts, > > we'll try to get an Radeon 7500 + 19'' 1600x1200 TFT via DVI working > but fail so far (Redhat i386 Linux 7.2 + rawhide XFree 4.2.0 rpms from > 1-Apr: *-4.2.0-6.52). > > VGA connectior works but TFT is hard/impossible to sync with the gfx card > signal. > > Best DVI result is with > > Option "NoDDC" > Option "PanelSize" "1600x1200" > > Without NoDDC screen is simply black and the OSM shows a sync to 720x400@70Hz. > Without PanelSize option Radeon driver insists that resolution bigger than > 1024x768 are not possible. > > With PanelSize "1600x1200" and NoDDC the resolutions of 1600x1200 and 1024x768 > via DVI behave like: > > X gives a screen with the lower ~ 16.5 cm okay but the upper > ~ 19.5 cm flicker like hell. Further there's a ghost image of the > mouse cursor: If the mouse cursor is at the bottom the ghost cursor > is at the border of the non- and flicker area (only the upper half > of the cross is visible just as for the real mouse cursor). The > host cursor is always ~ 18 cm to the right and ~ 16.5 cm above the > real cursor. > > Without panelsize the resolution 1024x768 is correctly displayed as > perfect as possible on a 1600x1200 TFT panel ;) > > Appended are the config and log log files, one with NoDDC and one > without NoDDC. > > Do we miss another options? Driver bug? > > Thx, > Achim > -- > To me vi is Zen. To use vi is to practice zen. Every command is > a koan. Profound to the user, unintelligible to the uninitiated. > You discover truth everytime you use it. > -- [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE dual head support?
At the time dual-head features were added, there was no OEM VE card available. The dual-head support in x420 radeon driver hasn't been tested on any OEM card. It turns out DELL has some cards with OEM version of BIOS not working with current driver on their 2nd head. AFAIK, DELL has cards with two DVI-D outputs and with two VGA outputs (all from a dangle). It appears if the 2nd head is connected to a CRT, some register bit (CRT2_ON?) has not been set correctly and you'll get a blank screen. If the 2nd head is connected to a DFP, it's totally not handled. I'm not sure when someone (or myself) can have time to have this support added. Not sure what kind of card you have, maybe you can help to debug it :-) > > Can you explain this a little more further ? > > Do you mean that the OEM chip isn't supported by the XFree driver ? > > I did some test on DELL's OEM Radeon VE card with a 4.2.0 XFree86, and > both cards get initialized, but 2nd screen remain with no signal. > > > Stephane > > ___ > 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 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
