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 (worksperfectly here with an external CRT on an M9 in a TiBook IV), please trythis 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
Attachment:
X-FbDevOff.log
Description: Binary data
Attachment:
X-FbDevOn.log
Description: Binary data