If you're still having problem with your radeons with dual-head (dvi/analog), you might want to know the reason for your problems.
The problem is in readonfb (as I told you some time ago :-). When your computer boots, the system BIOS will run the Radeon BIOS code, which among other things will scan your connectors to the card and use i2c to get into from the connected monitors. iff you have a DVI monitor (using DVI-D), the BIOS will set the DVI as the primary. the DVI port is connected to CRTC1 on all radeons I've seen so far (dual-heads with DVI). what radeonfb does is this: - it doesn't contain code to control properly the CRTC1/CRTC2 switch - it only contains code to set modes on CRTC1 (DVI) when you use radeonfb programs, they might work since the radeonfb doesn't try to switch CRTC when you use directfb, the radeonfb will try for some reason to switch the CRTC, but does this incorrectly. after you quit the radeonfb program (pressing esc since monitor is not getting sync), radeonfb will restore the state of the last mode (console). it does this by blindly setting the CRTC regs to the values they were before. radeonfb does not support CRTC2 and doesn't know how to handle it. 2.4.19 brought some changes to the code (courtesy of Ben for PPCs) but the same problem still remains. I have worked with the problem for Radeon VE's (original ATI versions, dual heads with DVI as primary). What I did to solve my problems was I took another radeonfb driver (not in stock kernel), it's distributed with mplayer (at least some older version, the newer versions use slightly different apis for radeon as well). you might want to start testing with those. all radeonfb drivers that I've seen contain a bug in setting the CRTC screen offset unless the screen is in 8-bpp mode (trivial to fix). also, so far I've not seen a radeonfb driver that had acceleration for console. I have a version somewhere in old stuff from a project that was dicontinued which does at least work with dual-head DVI VE, fixes the screen offset (needed for flipping in directfb) and also provides console acceleration (which almost works :-), although this will not benefit directfb). I also tried to hack in a vsync-ioctl (ala the patch for matrox in older directfb distros at least) and most of the time it worked although it sometimes hanged the kernel too. I don't know why neither do I care at this point to investigate. I'd suggest for you to try the radeonfb in mplayer. If it works for you, fine. If not, you might want to mail me. I'm currently in the process of shutting down my project and thus have not much time to help you, sorry :-(. such are the ways of The Corporation. What is really needed is to incorporate the new code into the stock kernel code, however the mplayer version of radeonfb has somewhat different structure and that's why ani rejected the patch originally (many months ago). And it seems that there is not much interested in using anything related to the fb if X works, at least from the developers that get paid for their time. I'd be willing to hack on that if I'd get money for it as well but unfortunately that's not the case at the moment. Aleksandr Koltsoff -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
