[PATCH] Wrong bo handles can be referenced in func call, drmModeAddFB2 due to uninitialized array elements in handles[4]

[Kim, Dongwon]

Kristian,

Seems that this change is needed to support the specific case Matt
described while not hurting anything in the current application as well.
Can you reconsider the patch, please?

Thanks,
DW


On 4/29/14, 3:09 PM, "David Herrmann" <dh.herrmann at gmail.com> wrote:

>Hi
>
>On Tue, Apr 29, 2014 at 10:59 PM, Matt Roper <matthew.d.roper at intel.com>
>wrote:
>> On Tue, Apr 29, 2014 at 01:24:31PM -0700, Kristian Høgsberg wrote:
>>> On Mon, Apr 28, 2014 at 03:26:18PM -0700, Dongwon Kim wrote:
>>> > Need all bo handles in the array, handles[4] to be initialized with
>>>integer value that
>>> > indicates "NOT VALID handle" to prevent any of those uninitialized
>>>from being processed as
>>> > "VALID" handles.
>>>
>>> The format code determines which bo handles are used.  For non-planar
>>>formats
>>> only the first handle is used and the rest can be uninitialized.
>>>
>>> Kristian
>>
>> Some hardware allows/expects stereo 3D to be supported by programming
>> the hardware with separate buffers for the left eye and right eye
>> content.  Drivers for such hardware need both handles[0] and handles[1]
>> to pass the left and right content buffers that get wrapped into a
>> single DRM fb, even though the pixel format is just RGB.  At the time
>> AddFB2 gets called, you don't know yet whether it's going to get
>> displayed on a stereo mode or a mono mode, so if there's something
>> sitting in handles[1], the driver will try to look it up.
>
>You cannot break backwards-compat this way. A lot of user-space
>assumes that only handles[0] is used. Afaik, the kernel has a
>3d-stereo user-capability, so unless it is set, you shouldn't do that
>in the kernel. However, given that weston might set this flag at some
>point, the patch is still right.
>
>Thanks
>David