On Tue, Sep 27, 2011 at 12:22 PM, Eric Anholt wrote:
> On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark 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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel