[Mesa-dev] [PATCH 2/3] xorg/xvmc: Only set decode buffer when available

[Maarten Lankhorst]

Hey,

On 08/29/2011 10:08 AM, Christian König wrote:
> Am Montag, den 29.08.2011, 00:36 -0400 schrieb Younes Manton:
> [snip]
>> Well, that was what the last discussion was all about, whether or not
>> decode buffers should be handled internally by each driver or
>> externally. It was decided to handle it externally, to simplify life
>> for drivers that want/need multiple buffers and to keep most of the
>> ugliness in XvMC, since VDPAU and VA don't have the same kinds of
>> problems.
>>
>> Anyway, your patch is cleaner for the driver that doesn't want to
>> support multiple decode buffers, but now every state tracker has to
>> deal with drivers with decode buffers and drivers without, and we have
>> to do these if checks at init/cleanup and every frame. The alternative
>> is that you support create_buffer, etc, and just return the same
>> decode buffer each time, and if you don't want to bother creating a
>> new type to represent a decode buffer you can just return anything
>> non-null, like the decoder itself, and just implement the other
>> functions as emty no-ops, that way the state trackers only have to
>> deal with one interface.
>>
>> Anyway, I don't have a strong preference either way, and since we
>> currently only have 2 drivers and 2 state trackers, it doesn't matter
>> much. I'll push this in a couple of days if no other comments.
> I have implementing the vaapi state tracker on my todo list, but not as
> with very high priority. So we would end up with 3 state tracker and 2
> drivers, but honestly my preferences aren't going strongly into the one
> or another preference either.
>
> So I think it is ok to push the patch as it is, since it doesn't make so
> much of a difference.
>
>
Well I suppose I can just return NULL, and nop the others, it doesn't
seem like the create call is being error checked?

~Maarten