On Fri, 2005-06-17 at 22:38 +0100, Dave Airlie wrote: > > > > I was going to delete the code that looks for fbdev and conditionally > > takes control since it had been rejected. Should I leave it in? > > I'd leave it in, no-one says DRM CVS has to be exactly what is in the > kernel, it is nice to know what happens when we own the PCI device vs > currently,
Yes, leave it in. I think the only "correct" solution is the 3 module approach. Define a "stub" driver that is only used to be "the" driver for the card and itself provides "hooks" to sub-drivers, and have both radeonfb and radeon DRM (using radeon as an example here) use that stub. Ultimately, we can even move some common code to the stub, like the interrupt stuff. We could do that in a "simple" way by just having the stub driver expose function for registering a list of sub-drivers and pass along some of the callbacks, or we could do it in a "fancy" way by having the sub-driver define a bus type to the device-model and then use the device model own mecanism to have radeon DRM/radeonfb be matches, including possibly use of hotplug. I suppose that should be discussed on the kernel list though. Ben. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
