On 6/16/05, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > > Three tiers is fine with me and I've never been against it. But we've > > only been talking about this for two years now and no one has stepped > > up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to > > wait another two years to build Xegl so I'm trying to come up with > > some way around the problems. > > You don't need to fix the 67 drivers, I dropped Alan Cox's idea of > vga_class on its arse after I did a full investigation on it (I did a fair > bit of work on it before I dismissed it...) > > I have on my PC somewhere attempt 2 (but I think I lost if in all my > bitkeeper vs git trees), that uses a video_lowlayer.c module that doesn't > bind to anything, but a lowlevel radeon driver links against it, and > registers its handlers for everything (kinda like the DRM does now), then > fbdev and DRM sit on top of it/lowlevel radeon, it looked like a good > idea, but it still needs a bit more investigation.. we haven't been > sitting on our hands on this, I just happen to have 0 time and benh is > working on things which although aren't as "cool" are needed just as much > (the VGA arbiter).. > > I'm also trying to prove architecture with respect to Intel chipsets if I > can so at least it might have a hope of moving beyond radeon... (but a > memory manager becomes more of an issue with Intel chipsets which share > RAM via AGP...)
I just think this is a giant amount of work to save 70K of memory (by allowing a setup which avoids loading fbdev) on desktop x86 machines. It is much simpler to just treat fbdev as the bottom layer and have two tiers instead of three. Wouldn't it be easier to just debug the 12 fbdev drivers that have corresponding DRM drivers to load on the x86? We started doing that with radeon and found two bugs, one was fixed in 24hrs and the other there is insufficient info about the specific laptop model to know what is failing. It's not like the 12 fbdev drivers are chock full of bugs, they are used routinely on other platforms. Even if you move the suspend/resume code from fbdev down to a lower common layer, it's still going to need debugging. If memory is critical there are other ways to reduce it. I just removed 10K from fbdev by moving softcursor support into fbconsole since fbconsole was the only possible user of it. I'll bet there is at least 10K of duplicated code in radeon/radeonfb. Other than saving 70K of memory for x86 users who don't want fbdev, what does a three tier scheme get us? -- 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
