Thank you *so* much!
The driver that's distributed with mplayer works! At first I was getting Ooopses, but my sound card is sharing an IRQ with the video card and switching from OSS to Alsa fixed that problem. Thanks again :-) Adam On Fri, 9 Aug 2002, Aleksandr Koltsoff wrote: > 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.
