高通平台Dump Camera RAW Image

這邊是之前在sdm429/msm8937開發的經驗(mm-camera not camx) Android版本是11(R) Qualcomm提供兩種dump RAW image的方式 一個是使用RDI(RAW Dump Interface) adb shell setprop persist.vendor.camera.rdi.mode enable 另外就是Dump preview frame adb shell setprop persist.vendor.camera.raw_yuv 1  adb shell setprop persist.vendor.camera.preview_raw 1  adb shell setprop persist.vendor.camera.dumpimg 16711696  兩種的差別是, 如果使用RDI, 出來的RAW會是MIPI CSI2 Format (Chromatix那邊要選擇MIPI) 但如果使用dump preview frame, 則會是QCOM RAW格式 (Chromatix那邊要選擇Packed) MIPI ------> VFE ----> ... (MIPI CSI2) (QCOM RAW) 會有這樣的差別我的猜測是如果是RDI, 則是MIPI一過來就dump出來 但如果是dump preview frame的話, 則會經過VFE pack成QCOM RAW後才dump Dump出來的RAW圖可能會比原圖更大一些(因為qcom會做align, 會塞padding) 計算方式可以參考hardware/qcom/camera/QCamera2/stack/mm-camera-interface/src/mm_camera_stream.c Function mm_stream_calc_offset_raw

主管Coaching

主管Coaching

說以後有問題不要在會議上講, 我們私底下討論

蝦毀? 案子有問題不就是在會議上提出, 尋求解決方案嗎
回答說提出這些問題會影響團隊士氣

要一群搞BSP壓根沒碰過前後端的人一周內生出第一版可以動的backend service, 完全不同領域的東西
很多人連前後端的概念, database存取, RESTAPI等等都還不太熟悉, 剩至沒聽過的

想想schedule這樣排一定很多問題, 至少要額外給出一些給大家study的時間, 提出來結果說影響團隊士氣

士氣? 大家看到你這schedule就沒士氣了好嗎

然後呢, 他說結果是好的啊, 東西也有在時間內弄出來, 他schedule沒有問題

反而說我之後遇到問題要想如果在時間內達到要求, 不是直接說做不到

拜託, 那也是我額外花一堆時間幫忙處理才生出來的

說是雙贏, 額外花我的時間跟我說雙贏

弄出來就說雙贏, 那如果最後沒弄出來, 我看就是我們的問題, 跟你schedule沒關係喔

新主管sucks

Android flash GSI image

首先從Android CI下載GSI image,
https://ci.android.com/builds/branches/aosp-android11-gsi/grid?

注意如果你的裝置的起始版本是Android 8.1, 8.0之前的, 要使用"_ab"的image,
ex. aosp_arm64_ab

然後解壓縮下載下來的image, 裡面會包含幾個檔案, 比較重要的有:
system.img
vbmeta.img

燒錄步驟:
1. adb reboot bootloader

2. fastboot --disable-verification flash vbmeta vbmeta.img

3. fastboot erase system && fastboot flash system_a system.img
(注意一定要先erase, 否則會corrupt)

4. fastboot erase userdata

5. fastboot reboot

就能開進GSI Android了

Reference:
https://source.android.com/setup/build/gsi

A good material for C

 http://shihyu.github.io/books/index.html

 https://medium.com/swlh/my-preparation-journey-for-google-interviews-f41e2dc3cdf9

[LeetCode] 50. Pow(x, n)

我覺得這題應該算Easy,

如果說歸在Medium的原因,

應該是看你能不能一次把Edge Case考慮到位.


題目很單純,

給定x, 輸出x的n次方

大致上需要考慮的Edge Case:

n = 0的情況

x = 1 or x = -1

跟平方的結果overflow的情況.

sqrt(x)的實作方法

從A tour of Go裡面學到的

給定一個值x, 找出z, 使得z平方最接近x
(找出x的平方根)

裡面提到可以運用Newton's Method

z -= (z * z - x) / (2 * z)

z從1開始猜,
跑個十次, 每次的值會越來越接近x

double sqrt(int x) {
    double z = 1;
    for (int i = 0; i < 10; ++i) {
        z -= (z * z - x) / (2 * z)
    }
    return z;
}

關於shared library

Compile Time:
編譯時系統預設會從/lib, /usr/lib尋找so檔.

但如果你的so檔不在預設目錄裡面,
就必須指定, ex:
g++ -L /usr/local/lib -I /usr/local/include test.cc -lfoo -o test

-l: 程式會用到libfoo.so這個library
-L: 從/usr/local/lib位置尋找library
-I:  從/usr/local/include位置尋找header

Runtime:
執行時找不到library的情況

1. LD_LIBRARY_PATH
設定後會從這個目錄找library, ex:
LD_LIBRARY_PATH=/usr/local/lib test

指定目錄後執行test

2. 添加系統預設搜尋目錄
在/etc/ld.so.conf裡面添加目錄
然後執行sudo ldconfig更新目錄cache

接著再執行test

3. 編譯時加入rpath選項
rpath可以指定執行時搜尋目錄
g++ -L /usr/local/lib -I /usr/local/include -Wl,-rpath=/usr/local/lib test.cc -lfoo -o test