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

[David Herrmann]

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