> I am almost certain that code for adding suspend/resume support to DRM > is going to get rejected when it is submitted to the Linux kernel on > grounds that it is duplicating existing code. The code in DRM CVS for > detecting fbdev and attaching to the PCI ID if it is not there has > already been rejected. > > 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 ... > A properly built fbdev driver should be able to passively load into > the system and only be activated on suspend/resume. It won't become > active until you load fbconsole. Or call the fbdev interface directly... > 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
