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: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Sat, 2003-08-02 at 02:24, Simon Urbanek wrote: On Saturday, July 26, 2003, at 01:08 PM, Michel Dnzer 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. Well, as I said before, the behaviour of the second head is basically undefined in this case. It's not a supported configuration. 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. Indeed, it's not stray surfaces getting in the way either. I suspect it's rather a CRTC/DAC/whatnot setup problem. Hui Yu is the man to talk to. :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
Hi Michel (and the rest of the cc club), I upgraded my dri-trunk packages today (xlibmesga-gl1 and xserver-xfree86) from your repository and my dual head config now works! I am an extremely happy bunny. Have you an unfullfilled Amazon wishlist item or something I can bless you with? I have version 2003.07.25-2 of the two packages I mentioned. I also have the drm-trunk-module-src module but have not compiled or inserted the module, so just the xserver stuff fixed this. My current config (Radeon M9 with LCD+Iiyama Vision Master Pro 451) can be found at: http://www.johnleach.co.uk/documents/powerpc/XF86Config-4.dualhead John. On Sat, 2003-07-26 at 12:08, Michel Dänzer wrote: On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote: latest CVS build (by myself) as of yesterday (4.3.99...) 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. Or maybe it's something like http://bugs.xfree86.org/show_bug.cgi?id=521 ? -- GPG KEY: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 HTTP: http://www.johnleach.co.uk signature.asc Description: This is a digitally signed message part
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote:
latest CVS build (by myself) as of yesterday (4.3.99...)
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.
Or maybe it's something like http://bugs.xfree86.org/show_bug.cgi?id=521
?
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.103
diff -p -u -r1.103 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 24 Jul 2003 13:50:23 - 1.103
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 26 Jul 2003 11:02:28 -
@@ -5341,8 +5341,10 @@ static void RADEONRestore(ScrnInfoPtr pS
}
/* Define common registers for requested video mode */
-static void RADEONInitCommonRegisters(RADEONSavePtr save, RADEONInfoPtr info)
+static void RADEONInitCommonRegisters(ScrnInfoPtr pScrn, RADEONSavePtr save)
{
+RADEONInfoPtr info = RADEONPTR(pScrn);
+
save-ovr_clr= 0;
save-ovr_wid_left_right = 0;
save-ovr_wid_top_bottom = 0;
@@ -5360,6 +5362,49 @@ static void RADEONInitCommonRegisters(RA
*/
if (save-bus_cntl (RADEON_BUS_READ_BURST))
save-bus_cntl |= RADEON_BUS_RD_DISCARD_EN;
+
+save-surface_cntl = 0;
+
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+switch (pScrn-bitsPerPixel) {
+case 16:
+ save-surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP | RADEON_NONSURF_AP1_SWP_16BPP;
+ break;
+
+case 32:
+ save-surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP | RADEON_NONSURF_AP1_SWP_32BPP;
+ break;
+}
+
+{
+ unsigned char *RADEONMMIO = info-MMIO;
+
+ ErrorF(%s: Surface 0: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE0_INFO), INREG(RADEON_SURFACE0_LOWER_BOUND),
+ INREG(RADEON_SURFACE0_UPPER_BOUND));
+ ErrorF(%s: Surface 1: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE1_INFO), INREG(RADEON_SURFACE1_LOWER_BOUND),
+ INREG(RADEON_SURFACE1_UPPER_BOUND));
+ ErrorF(%s: Surface 2: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE2_INFO), INREG(RADEON_SURFACE2_LOWER_BOUND),
+ INREG(RADEON_SURFACE2_UPPER_BOUND));
+ ErrorF(%s: Surface 3: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE3_INFO), INREG(RADEON_SURFACE3_LOWER_BOUND),
+ INREG(RADEON_SURFACE3_UPPER_BOUND));
+ ErrorF(%s: Surface 4: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE4_INFO), INREG(RADEON_SURFACE4_LOWER_BOUND),
+ INREG(RADEON_SURFACE4_UPPER_BOUND));
+ ErrorF(%s: Surface 5: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE5_INFO), INREG(RADEON_SURFACE5_LOWER_BOUND),
+ INREG(RADEON_SURFACE5_UPPER_BOUND));
+ ErrorF(%s: Surface 6: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE6_INFO), INREG(RADEON_SURFACE6_LOWER_BOUND),
+ INREG(RADEON_SURFACE6_UPPER_BOUND));
+ ErrorF(%s: Surface 7: info=0x%x, range=0x%x-0x%x\n, __FUNCTION__,
+ INREG(RADEON_SURFACE7_INFO), INREG(RADEON_SURFACE7_LOWER_BOUND),
+ INREG(RADEON_SURFACE7_UPPER_BOUND));
+}
+#endif
}
/* Define CRTC registers for requested video mode */
@@ -5487,22 +5532,9 @@ static Bool RADEONInitCrtcRegisters(Scrn
(pScrn-bitsPerPixel * 8));
save-crtc_pitch |= save-crtc_pitch 16;
-save-surface_cntl = 0;
save-disp_merge_cntl = info-SavedReg.disp_merge_cntl;
save-disp_merge_cntl = ~RADEON_DISP_RGB_OFFSET_EN;
-#if X_BYTE_ORDER == X_BIG_ENDIAN
-switch (pScrn-bitsPerPixel) {
-case 16:
- save-surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP;
- break;
-
-case 32:
- save-surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP;
- break;
-}
-#endif
-
RADEONTRACE((Pitch = %d bytes (virtualX = %d, displayWidth = %d)\n,
save-crtc_pitch, pScrn-virtualX,
info-CurrentLayout.displayWidth));
@@ -6066,12 +6098,13 @@ static Bool RADEONInit(ScrnInfoPtr pScrn
info-Flags = mode-Flags;
+RADEONInitCommonRegisters(pScrn, save);
+
if (info-IsSecondary) {
if (!RADEONInitCrtc2Registers(pScrn, save, mode, info))
return FALSE;
RADEONInitPLL2Registers(save, info-pll, dot_clock);
} else {
-
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Wed, 2003-06-04 at 14:11, Simon Urbanek wrote: 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 -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
latest CVS build (by myself) as of yesterday (4.3.99...) 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 ? Ben. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-07-15 at 16:17, Michel Dänzer wrote: [ citation without new stuff ] Sorry about that, fun time with Evolution. :\ -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree 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 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 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. .../... Probelm 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). That is probably the SURFACE_CNTL problem. 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. Typical with offb, X doesn't properly restore the radeon state to offb graphics mode it seems. Other relevant info: kernel is 2.4.20-ben10 (the devel versions crash), frame buffer works only with video=ofonly. Can you tell me more about the crash ? The benh-devel rsync should work just fine on this config with more radeonfb fixes. Framebuffer should work too without video=ofonly. Can you try my latest devel kernel and tell me ? If it boots but with no framebuffer, can you try to capture the boot log to a file and send it to me. (Please, let's continue the kernel related discussion separately and offlist) 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 -- Benjamin Herrenschmidt [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote: On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: Hi all, I have several problems with the ATI Radeon drivers in XFree 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 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 ? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
Hi Michel, My attempts at using the binary have failed. X reports: (II) LoadModule: radeon (II) Loading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (II) Module radeon: vendor=The XFree86 Project compiled for 4.3.99.5, module version = 4.0.1 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.7 (EE) module ABI minor version (7) is newer than the server's version (6) (II) UnloadModule: radeon (II) Unloading /usr/X11R6/lib/modules-dri-trunk/drivers/radeon_drv.o (EE) Failed to load module radeon (module requirement mismatch, 0) I've tried and failed to build a new dri-trunk package incorporating the patch (most likely a newbie deb package building/xfree86 compiling problem). My package versions are: xserver-xfree86 4.2.1-6 the XFree86 X server xserver-xfree86-dri-trunk 2003.05.04-1 The XFree86 X server [DRI trunk] If this is due to your binary being compiled against a different version of X than my own, what can I do? Should I try it with a 4.3 server? (and if so, are some official debs available?) Could you compile it against a lower version for me? Or shall I just give up on this whilst somebody else with more xfree86 smarts tests it? :( Thanks, John. On Wed, 2003-06-04 at 00:19, 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: Hi all, I have several problems with the ATI Radeon drivers in XFree 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 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 ? -- GPG KEY: B89C D450 5B2C 74D8 58FB A360 9B06 B5C2 26F0 3047 HTTP: http://www.johnleach.co.uk signature.asc Description: This is a digitally signed message part
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote: I have several problems with the ATI Radeon drivers in XFree 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 officail 4.2.1 Isn't expected to work with this. Michel Daenzer's 4.2.1 DRI build 4.2.1? Haven't you tried my current packages for sid? Debian inoffical 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. Have you looked at the code for how the type of one head might have an influence on the other one? Probelm 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 for the digital panel. Although 24-bit mode is enabled (and the server uses 4-bytes per pixel see log below), in fact only 3x4=12 bits are used. I wrote a small proggy that writes directly to the frame buffer and the sequence to set RGB colors (each 4 bit) is 0x00G0RB00 (beware, Macs are big-endian), that is 0x00f0 is fully saturated green, 0xf000 fully saturated red etc. Hmm, sounds like the palette is programmed incorrectly. Hui Yu or Kevin E. Martin might know more about these problems, but I'm not sure if they're reading either of these lists. You could file a bug to the XFree86 bugzilla. 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 (the devel versions crash), frame buffer works only with video=ofonly. Have you reported radeonfb not working to Benjamin Herrenschmidt or the linux-fbdev-devel list? It may also a bug in the radeon driver that it doesn't restore the console mode correctly though. PS: Posting once is enough... -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
