[Mesa-dev] [PATCH v1] Android: Add an error handling for the null buffer

Emil Velikov emil.l.velikov at gmail.com
Thu Mar 30 14:27:23 UTC 2017


Hi Zhou-hao,

On 30 March 2017 at 10:53, Zhuo-hao Lee <zhuo-hao.lee at intel.com> wrote:
> Add an error handling to droid_swap_buffers() to handle the undefined
> case of dri2_surf->buffer==null.
> We found that when running CTS testAbandonRepeatingRequestSurface on
> Chromebook, the test would fail. After digging, we found that the
> Android framework relied on an undefined behavior to abort the camera
> transmission. Therefore, we added an error handling to return
> EGL_BAD_SURFACE to Android framework to force the camera transmission.
>
> the testAbandonRepeatingRequestSurface test flow:
> (https://android.googlesource.com/platform/cts/+/android-7.1.1_r23/
> tests/camera/src/android/hardware/camera2/cts/RobustnessTest.java#921)
>
> testAbandonRepeatingRequestSurface {
> 1. Create surface for the camera
> 2. Setup camera parameter, callback function and underlying surface
> 3. Setup repeating request to camera and start capture 60 frames
> 4. Poll 60 frames from Camera and put to surface
> 5. Release the surface texture <-- From now, Android framework will
>    call droid_swap_buffers() with dri2_surf->buffer=null
> 6. Expect the camera's repeating request stop and get the last
>    frame number <-- Time out here because Camera isn't aborted
> 7. Checking for the frame number
> }
>
> The problem is happened after step 5 releasing the underlying surface
> texture. The step 6 expects that the camere is aborted and should
> trigger onCaptureSequenceCompleted() callback. This solution adds an
> error handling which will return EGL_BAD_SURFACE to android framework
> to force camera tramission be aborted.
>
One of the Google/CrOS developers proposed an alternative solution
[1], which seem better imho.
Perhaps you can help by reviewing or testing it ?

-Emil

[1] https://patchwork.freedesktop.org/patch/147322/


More information about the mesa-dev mailing list