On 6/27/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > You could be a pioneer and write the first stub driver. I've looked at > > the problem and you need about 80% of the fbdev code in the stub. I > > just didn't think it was worth the engineering effort to split 20 > > existing fbdev drivers. Since I didn't want to split the drivers I was > > just using them as the stub. > > Ugh ? 80% ? How did you get that figure ? I'd say less than 10% :) > Unless you count the radeon PM stuff in the stub ...
Depends on what is in the bottom layer. Is mode support there so that we can set a mode at boot? DDC probe? Common functions for start/stop the GPU, .... > > vesafb users should shift to the board specific fb drivers if > > available. If the board specific fb driver isn't working we should > > simply fix it instead of building and entire architecture to avoid > > it's use. > > It's always good to have a fallback solution Right now suspend resume are handled in the fbdev drivers. I don't think it would work in the case of vesafb and DRM. >From what I can tell vesafb use is pretty rare. A while ago I broke things in DRM CVS so that vesafb wouldn't work, it was about two months until we got a complaint. DRM CVS is fixed for vesafb but the long lag indicates that there aren't very many users. After the problem the user switched to radeonfb. Sure we should keep vesafb around but it won't have all of the features of the board specific fbdev driver. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
