xf86-video-tegra or xf86-video-modesetting?

Alex Deucher alexdeucher at gmail.com
Mon Nov 26 16:51:55 PST 2012

On Mon, Nov 26, 2012 at 6:14 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/26/2012 07:01 AM, Alex Deucher wrote:
>> On Sun, Nov 25, 2012 at 8:37 AM, Thierry Reding
>> <thierry.reding at avionic-design.de> 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.

If someone has the time to look into it further, it could probably be
done.  I'm not sure there would be much to share at the end however.


More information about the xorg-devel mailing list