Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems with XFree86
On Saturday, July 26, 2003, at 01:08 PM, Michel Dänzer wrote: On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote: When did you try exactly ? I've seen more fixes for TMDS getting in the CVS recently. I'm not sure what's up here, definitely not something the doc explains. I suspect it's the path of pixel data from the framebuffer to the TMDS transmitter that has an endian problem, I fail to see why SURFACE_CNTL thing would fail, or maybe it's a problem related to surface translation getting in our way ? I suspected that as well. If current CVS still doesn't work (works perfectly here with an external CRT on an M9 in a TiBook IV), please try this patch and post the RADEONInitCommonRegisters output. Thanks for the info. I was out of town so I couldn't test it until now. I built X from the current CVS just a few hours ago with the following results: 1) If I enable FBDev, then I get a nice picture on the TMDS screen, correct colors and nice 24 bit color depth. I also get a white screen on the ADC (VGA) screen. (After booting Ben's .21 kernel with radeon fb drivers you get white ADC screen and console DVI screen. When starting X the white screen goes black and then back to white; I'm running the radeonfb on boot at 8 bpp). The funny thing is that the mouse is correctly displayed on the corresponding screen (i.e. I can move the mouse from one screen to the other). But the ADC screen is otherwise totally white. It is evident that some weird overplotting is taking place since the DVI screen has some painting problems (it looks like the driver thinks that it paints in the ADC fb but in fact it's still on the DVI screen). The nice thing here is that you can get back to the console without problems, but still the second screen is unusable. 2) If I disable FBDev, then the results are exactly same as the version of X I used when first reporting this problem: signal is only on the DVI screen (ADC is blanked), the colors are broken in that weird manner (half-split color bits). Getting back to the console is impossible since both screens get blanked once you try that. I used your patch, but the info doesn't seem very helpful (btw the behavior was the same with/without the patch). I have attached logs from both runs. I'm still very thankful for any help! Ben, can we have the second framebuffer in the kernel *wink*? Your driver still seem to be only working one ;). It's just missing the second fb device :P Cheers, Simon X-FbDevOff.log Description: Binary data X-FbDevOn.log Description: Binary data
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems with XFree86
On Wednesday, June 4, 2003, at 01:19 AM, Michel Dänzer wrote: On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid officail 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inoffical 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) Ok, CVS is the really interesting one. Michel, did you ever commit the fix of SURFACE_CNTL ? That should fix the colors at least on the main aperture It's in, but only handles aperture 0. Can someone try http://penguinppc.org/~daenzer/XFree86/radeon-ap1.diff or http://penguinppc.org/~daenzer/XFree86/radeon_drv.o ? I tried the patch, but without any visible results :(. I was digging a bit more in the wrong colors issue and found out the following: When I'm running the CRT,CRT layout (as opposed to the previous CRT,TMDS) the colors behave differently. In fact is seems like a common endianess-problem: the layout of colors is 0xBBGGRR00 in Mac big-endian notation, but the color on the screen written by the driver are 0x00RRGGBB - that is the colors red and green are swapped and blue is never seen. This is true for both screens. So the summary (CVS XFree): * CRT,CRT mode: swapped 'byte-sex' causes wrong colors, otherwise both screens are OK * CRT,TMDS mode: CRT screen is off, TMDS has split colors - i.e. the low and high 4 bits of the components are interlaced I wanted to look at the code, but I can't seem to find any tech info on the Radeon chip - is it available to the chosen only after signing a NDA? Any help, especially with the CRT+TMDS mode is highly appreciated! Cheers, Simon PS: Additional info for Ben: In fact the kernel radeon driver works with the DFP *only* - in CRT,CRT layout the kernel hangs in the early-boot screen (and doesn't go further - no network etc.). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Problems with radeon driver (ATI Radeon 9000 If (RV250))
Hi all, I have several problems with the ATI Radeon drivers in XFree86 on my Mac G4 Windtunnel (dual 1.4GHz). Summary: 1) CRT + TMDS dual head configuration doesn't work 2) In all configurations colors are completely wrong 3) closing X blanks all monitors I have tested following versions of XFree86: Debian sid official 4.2.1 Michel Daenzer's 4.2.1 DRI build Debian inofficial 4.3.0 latest CVS build (by myself) as of yesterday (4.3.99...) The first two worked even worse (no image at all), so in the following I'll refer to the later two which produce exactly the same results. Problem 1) I have a TMDS flat panel (DVI-D) on the DVI port of the card and an analog flat panel on the ADC port (via ADC2VGA cable). Both panels get correctly detected (see attached log file), but the analog one gets no signal after X is started. Option MonitorLayout CRT, TMDS doesn't help (nothing really changes, since both monitors get correctly detected even wihtout this). I tried all tricks I could think of, but the analog one (on the ADC port) gets no signal (even after X closes). Funny enough, using a DVI2VGA adapter and analog input of the *digital* panel causes both panels to work - i.e. changing the mode of the *panel that works* causes the other one to start working as well. This means that CRT, CRT combination works. It is really annoying since I have a digital panel and I don't want to run it in analog mode which sucks. Problem 2) No matter what combination (dual or single head) the colors are always wrong. This is independent of the depth used (every time differently wrong colors of course). I analyzed it for the 24-bit mode using the digital panel. I wrote a small proggy that writes directly to the frame buffer. I found out that the sequence to set RGB colors (using most significant 4 bit only) is 0x00G0RB00 (beware, Macs are big-endian), that is 0x00f0 is fully saturated green, 0xf000 fully saturated red etc. Since the least significant 4 bits are hard to distinguish visually I can't tell for sure but it looks like they are located at 0xNN0N. At any rate the lower 4 bits and higher 4 bits are split - and hence the colors are broken. Problem 3) Shutting down X blanks both screens - i.e. the frame buffer is not correctly restored. This is somewhat painful since after closing X you can access the box via ssh only. Other relevant info: kernel is 2.4.20-ben10, frame buffer works only with video=ofonly. The system is debian sid (up-to-date). The CVS version of XFree86 was compiled using gcc 3.2 on the same machine. I don't know who's working on the radeon driver, but any help would be appreciated. I'd be delighted to help to track all this further down if possible ... Cheers, Simon XF86Config-4 Description: Binary data x-log Description: Binary data
