On 19/08/13 09:08, Christian König wrote: > Am 18.08.2013 14:20, schrieb Emil Velikov: >> On 18/08/13 12:31, Christian König wrote: >>> Am 17.08.2013 23:51, schrieb Emil Velikov: >>>> Otherwise we risk causing memory corruption. >>>> >>>> v2: forgot the mutex_unlock() >>>> >>>> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com> >>> NAK. Failing is actually not correct here, cause we can still make it >>> work by allocating the video buffer later on decoding or uploading of >>> image data. >>> >> Let me see if I get this right >> >> The API dictates that one can create a surface and there is no guarantee >> that a video buffer will be associated with it, is that correct ? > > Actually the API doesn't dictates anything about this (late vs. early > allocation of buffers), it's more like I want to give the driver control > over this. > Makes sense, thanks for the information.
>> Afaics after creating such a surface anyone can call >> vlVdpVideoSurfaceGetBitsYCbCr() thus getting a NO_IMPLEMENTATION, but >> then again who in their right mind would want to do that :) > > Returning NO_IMPLEMENTATION in case a surface doesn't have a backing > store yet probably isn't such a good idea. Just clearing the destination > buffers to black in vlVdpVideoSurfaceGetBitsYCbCr sound like the valid > response to this. > If you don't mind I'll leave this exercise for a later moment. Cheers, Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev