Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 6c0586ea authored by Benoît Laniel's avatar Benoît Laniel Committed by Bernhard Thoben
Browse files

kitakami-common: camera: defer start_preview until surface is valid

Some apps like Snap start preview very early to setup camera while initializing
UI. It then calls setPreviewDisplay (set_preview_window) to define the surface
used for preview.

According to https://developer.android.com/reference/android/hardware/Camera.html#setPreviewDisplay%28android.view.SurfaceHolder%29
"This allows camera setup and surface creation to happen in parallel, saving time."

But https://developer.android.com/reference/android/hardware/Camera.html#startPreview%28%29
"Preview will not actually start until a surface is supplied with setPreviewDisplay(SurfaceHolder) or setPreviewTexture(SurfaceTexture)."

However, hero camera hal starts preview with an internal buffer when surface
is not valid / null.

[CAM_ID(0)][]-WARN(setPreviewWindow[204]):Preview window is NULL, create internal buffer for preview
[CAM_ID(0)][]-INFO(startPreview[519]):setBuffersThread is run

On the next set_preview_window call (the one defining the surface), camera hal
restarts preview since it is already running using the internal buffer.

[CAM_ID(0)][]-WRN(setPreviewWindow[187]):Preview is started, we forcely re-start preview

Problem with this is that it deadlocks quite often. It loops here

[CAM_ID(0)][]-INFO(m_mainThreadQSetup3AA[1078]):m_flagThreadStop(1)

Let's handle the situation in the wrapper so no restart is done by the hal.

Change-Id: I762af781e5af96b52407387aa9ae67874a8ab8b6
parent 3d27cfd3
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment