[Mesa-dev] [PATCH] RFC: refactor out dri2 proto code into libdri2

Rob Clark rob.clark at linaro.org
Tue Sep 27 11:42:49 PDT 2011


On Tue, Sep 27, 2011 at 12:22 PM, Eric Anholt <eric at anholt.net> wrote:
> On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark <rob.clark at linaro.org> wrote:
>> Since I was working on some extensions to DRI2 protocol for handling
>> video, it occurred to me that it might be easier to extend the
>> protocol if there weren't N different copies of dri2.c floating around
>> in various different src trees..  also, for video, with one or two
>> other small extensions (ie. standard way to mmap() GEM buffers), I
>> think it should eventually be possible for DRI2 to be directly used
>> by end applications (ie. for sw video decoders, etc).  So refactoring
>> this out into a shared library pretty much seemed like the right-
>> thing-to-do.
>>
>> This patch updates mesa to remove two nearly identical copies of DRI2
>> protocol code.  The error, wire->event, and event->wire stuff is split
>> out into some callbacks, as this was really the only differences
>> between the two copies of dri2.c (and also, other than name changes,
>> the main difference between what is in mesa and vaapi).  Also, from
>> looking at the git history, it appears that these callbacks are the
>> main place where there have been any changes to this code in the last
>> couple years.
>>
>> Temporary home for libdri2 tree is here:
>>
>>   git://people.freedesktop.org/~robclark/libdri2
>>
>> Eventually I can make patches for libva and libvdpau.. but I started
>> with mesa because that was something I actually had a way to test.
>
> Splitting out the code is definitely better than the copy and paste
> disaster we had before.
>
> I'd rather see us move to using XCB instead even more.  But for that, I
> had issues with wiring up the event handling bits (which wants to
> intercept events inside the GL and not expose them to the client).
>

I'd started to look at the XCB DRI2 code.. but what I managed to find
(and maybe I wasn't looking in the right place) was somewhat
incomplete.. and I didn't want to figure out enough of XCB to add
additional messages ;-)

But long term, I suppose underneath the libdri2 API we can replace the
proto building/parsing stuff with XCB?  I guess it won't be as
asynchronousy with req/reply stuff split out, but I'm not entirely
sure if that is something that would hugely benefit mesa anyways.

BR,
-R


More information about the mesa-dev mailing list