All, I've been looking a bit at dri2 as a way to handle video display (in addition to just GL stuff). Basically it seems like a convenient way to share buffer handles between Xorg driver and client video player app. (Yes, I know about Xv.. no, it isn't useful if I want to avoid a memcpy.)
The basic differences compared to some 3d/gl app: 1) color format.. video content would (most likely) be in some YUV format. No problem for DRI2GetBuffersWithFormat, passing a fourcc as the 'format' value seems sane. 2) attachment points.. for GL you might triple or double buffer. For video you might have >16 buffers. This mostly seems ok, most of the existing dri2.c code seems like it would tolerate me requesting non-existing attachment points. The one bit of awkwardness is that DRI2SwapBuffers doesn't let me specify *which* buffers I want to swap. Maybe I could cope by playing some games by changing buffer name to buffer object mappings. The tricky thing to keep in mind is that in the video case the buffers would be displayed in a seemingly random (to the xorg driver) order, if B-frames are present.. decode order != display order 3) cropping.. in case you are actually trying to share buffers without copy between video codec and Xorg, you probably have some codec edges that need to be cropped out. So you need some way to request buffers larger than the target drawable, and specify some x,y offset into that larger buffer to find what should appear on screen. In some cases it might even be that the x,y offset is changing frame by frame. Some of these issues go away if you do a blit/colorconvert on client side into the DRI2 buffer. This seems to be what intel vaapi driver (and probably others) are doing currently. Although my ideal goal is to push this to xorg side, and let xorg driver decide whether to blit, or use an overlay, etc. The approaches I can think of to deal with this are: 1) add DRI2Get/SetProperty sort of messages. Some things like cropping offsets and perhaps actual requested buffers sizes could be set as properties. There are some things that are a bit iff'y about this. For example, changing crop should apply on the next SwapBuffers. The good news is it would be easy to later define new properties as the need arises. 2) Add additional parameters to GetBuffers and SwapBuffers 3) Define some new msgs with extra parameters... DRI2GetBufferWithFormatAndMore, etc. Anyone have some opinions on the best approach to take? Anyone else given some thought to this sort of thing before? BR, -R _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
