On Sul, 2004-09-05 at 22:12, Jon Smirl wrote: > Sure you can use this to get around both fbdev and DRM trying to claim > the resource. But it doesn't help at all to fix the problem that fbdev > and DRM are programming the radeon chip in conflicting ways.
Once you have the common structure the rest of the problems go away rather nicely over time. > What is so awful about merging the code? I'm the one doing the all of > the work. I intend to use 95% of the code extracted from fbdev without > change. I'm not getting rid of fbdev capability in the merged code, > I'm just coordinating use of the hardware. It doesn't solve the problem. That is the fundamental part of it. I can put the code in the same place or in different places, the problem you have to fix is co-ordination, and when you fix that not suprisingly you still don't care where the code lives. Create a top level video device object to hold dri and fb info pointers. End of problem #1. Make that top level video object the one which is handling the pci device irrespective of DRI/fb loading first. You've now solved the load order problem. Make DRI tell fb about display layout in X and provide sync functions. You've now solved the Oops problem. After that you can begin to worry about dual head and memory management which is a *lot* harder than you seem to realise and much of which cannot be done user space side for performance reasons. Alan ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
