Re: xf86-video-tegra or xf86-video-modesetting?

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 11/26/2012 07:01 AM, Alex Deucher wrote:
> On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
...
>> With the common base that could be shared I meant all the modesetting
>> code and framebuffer setup that xf86-video-modesetting already does.
>> I've been wanting to add support for planes as well, which comes with
>> another set of standard IOCTLs in DRM.
>>
>> Rewriting all of that in different drivers doesn't seem very desirable
>> to me and sounds like a lot of wasted effort. And that's not couting the
>> maintenance burden to keep up with the latest changes in the generic
>> modesetting driver.
>>
> 
> You don't really end up rewriting it, most people just copy the
> modesetting driver, change the name, and start adding acceleration; in
> which case, the work is already done.  Also, the generic code doesn't
> change much.  Based on other ddxes, you rarely have to change the
> modesetting and framebuffer code.  Most of the work ends up being the
> device specific acceleration and memory management code.
> Also, depending on what hardware is available, I'm not sure
> traditional 2D engines will gain much over shadowfb other than hw
> accelerated buffer swaps for GL.  In my opinion something like glamor
> is the best bet for mapping legacy X APIs on to modern GL hw.

Rather than have every driver cut/paste the modesetting code, can't the
modesetting core of the DDX be pulled out into a utility library or
similar, so that it can just be compiled/linked into all the DDXs
without actually duplicating the code? That way there's no code
duplication, but each DDX can still be flexible about all the
HW-specific code without making a monolithic DDX.