On 6/16/05, Dave Airlie <[EMAIL PROTECTED]> wrote: > You haven't seen intelfb then, it is a train wreck of code and I've no > idea if it works on most chipsets, it certainly will blow up with wierd > BIOS configs and funny screen, I won't load it on any platform as-is.. > > it mainly gives us > a) some semblance of backwards compatibility for people > who don't want their system to break when fbdev is loaded but do want a > DRM.. > b) a step by step path forward as opposed to big breakage path, > 1. make radeon fbdev sit on top of stub driver do nothing with > drm. - merge to kernel test it, make sure nothing breaks.. > 2. start hooking radeon DRM into mix, but only small things, merge > to kernel, prove nothing breaks.. > 3. next step etc..
Doesn't all this do is defer the day we load the 12 fbdev drivers on x86? Sooner or later we need to load and debug those fbdev drivers. I don't see that the scaffolding really buys us anything; the root problem is that the existing fbdev drivers need to get tested on the x86. The source of everyone's fear is loading these drivers, that's the problem that needs to be addressed. For people that don't want to participate in debugging the fbdev drivers on x86 leave the current DRM drivers in the tree. How about another approach that reverses the sequence, it doesn't involve any new code to being with... 1) appeal on LKML for everyone to load the 12 fbdev drivers on x86 and report bugs. 2) we fix all of those bugs. 3) next we minimally bind DRM and fbdev with a common symbol so that they can only be loaded together and put it in the mm build. This will shake out more bugs. 4) let the mm patch into the rc kernel series - more people, more testing 5) By now it should be safe to force loading of them both. 6) since they both safely load, now we can start adding hooks between them. If people have problems during this process the old DRM driver is left in the tree. They can revert back to it while the fbdev problem gets fixed. > > Us "kernel" people like to have a lots of merge to kernel points where we > add no new functionality just scaffolding but make sure we don't remove > any either... its like building anything, you can't call scaffolding a > waste of time even though you might remove it all in the end... > > Dave. > > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / airlied at skynet.ie > Linux kernel - DRI, VAX / pam_smb / ILUG > > -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- 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_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
