[Samsung Galaxy S 5 Unified Development] cal002:
I debugged the torch issue (more on that below, wtf does xda combine

two postings that should be seperate without asking, it confused me like hell),

and stumbled over the issue that logd drops messages.

Is this a known issue? I couldn't find any mention via google

or xda search.

You can run "logcat -b events -s liblog" to see the counts of dropped

messages, which are in the hundreds after enabling some debug in

camera related libraries. Since liblog writes in non-blocking mode,

and logd deliberated drops to the lowest priority and scheduling

class, it seems deliberate and might make sense on production release.

But for debug it is hurtful.

I tried to change loblog to use blocking write -> startup hangs at some point.

Then I tried to play with chrt and renice and socket settings in /proc/sys/net,

which improved it a little.

If you have any hints how to get reliable debug logs, please let me know.

---------- Post added at 23:41 ---------- Previous post was at 22:59 ----------

The torch issue, i.e. using the Flashlight QS tile causes mediaserver to crash

when the torch is turned off, which causes the QS icon to disappear

until mediaserver restarts.

The root cause is a bug in Samsung's binary camera.msm8974.so. I'm not so good

at reverse engineering, but superficial inspection shows it is simliar to the source

code in hardware/qcom/camera/QCamera2/. I get it maps ZSL (zero shutter lag)

and PREVIEW channels to the same internal channel, but screws up if ZSL mode

is changed while preview is active, causing this on stopPreview():

06-15 21:30:01.860 7560 7630 V CameraFlashlight: stopPreview(0)
06-15 21:30:01.860 7560 7630 V CameraWrapper: camera_stop_preview->B1058000->B107A0C4
06-15 21:30:01.860 7560 7630 W QCamera2HWI: [KPI Perf] stop_preview: E
06-15 21:30:01.860 7560 7687 W QCamera2HWI: stopPreview: E mCameraId=0
06-15 21:30:01.860 7560 7687 E QCamera2HWI: stopChannel: can't stop channel because of NULL
06-15 21:30:01.860 7560 7687 W QCamera2HWI: unpreparePreview: E mCameraId=0
06-15 21:30:01.860 7560 7687 W QCamera2HWI: unpreparePreview: X mCameraId=0
06-15 21:30:01.861 7560 7687 W QCamera2HWI: stopPreview: X rc=-2147483648
06-15 21:30:01.861 7560 7630 W QCamera2HWI: [KPI Perf] stop_preview: X
06-15 21:30:01.862 7560 7630 V CameraFlashlight: setPreviewWindow(0) buf 0x0
06-15 21:30:01.862 7560 7630 V CameraFlashlight: setPreviewWindow &mHalPreviewWindow 0xb1072010 mHalPreviewWindow.user 0xb1072000
06-15 21:30:01.862 7560 7630 V CameraWrapper: camera_set_preview_window->B1058000->B107A0C4
06-15 21:30:01.862 7560 7630 W QCamera2HWI: set_preview_window : E
06-15 21:30:01.862 7560 7630 W QCamera2HWI: set_preview_window : X, rc 0
06-15 21:30:01.862 7560 7630 V CameraFlashlight: release(0)

I.e. stopPreview() doesn't really stop, the stop happens after release() but at this

time the preview window is gone and it crashes.

And the ZSL mode switch if forced beause it is off by default,

then frameworks/av/services/camera/libcameraservice/CameraFlashlight.cpp

first starts the preview and only then changes the flash mode to TORCH,

and device/samsung/klte-common/camera/CameraWrapper.cpp

then forces forces ZSL to on during setParameters().

For comparison, a simple torch app like

https://github.com/repat/mosf/blob/master/src/de/repat/mosf/Flashlight.java

sets the parameters first before starting the preview (and doesn't even bother

to set a preview window, which seems to violate the API but turns out to be faster).

At the moment I just commented out the line in CameraWrapper.cpp which

forced ZSL on, which seems to work fine. Except when ZSL is toggled in the

Snap camera app (after developer options have been enabled by 10 clicks

on the red eye reduction icon). It causes some exception in the Java layer

and requires a manual "restart qcamerasvr" to recover.

So the question is how to solve it. Maybe force a stopPreview + startPreview

in CameraWrapper.cpp when ZSL mode is changed? Or prevent the

ZSL mode change after preview is started?