On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote: > Anyway, I really want a slightly different approach than what Jon is > doing, that is a 3 modules scenario: > > - A basic "stub" module that attaches to the PCI card. It doesn't > touch the hardware per-se (thus won't break your VGA console, though > radeonfb without fb console shouldn't either, the problem you have is > a bug). That stub contains the "common" code like IRQ handling, card > type detection, maybe vram detection etc... And some locking facility > > - Depending on the above, an optional "fbdev" module that provides > the fbdev interface & mode setting > > - Depending on the first one too, but independant from the "fbdev" > one, the DRM module providing the radeon DRM kernel interface
What's the advantage of this if the fb part of the driver is typically needed? (I'm assuming it'll be used for modesetting at the very least in Linux.) Is it just to avoid issues with the VGA driver? Maybe it's the right way to go in the long run, but I see no problem with Jon's approach as an intermediate (if not final) step. Jesse ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
