|
|
b71ff4cd3c
|
perf(local-tool): Windows KL520 cold-boot connect 106s → ~40s(跳過多餘 reset)
背景:
Windows 實測 KL520 首次 connect 耗時 106 秒,原因是 reset 流程內部重複
firmware load:
1. 進來 Loader → load firmware (35s) → Comp/U
2. reset 退回 Loader → bridge 重啟
3. reconnect 進來又是 Loader → load firmware (30s) → Comp/U
4. Loader reconnect 第一次常 fail(15s timeout)
總共 ~65s 花在「砍掉剛載好的 firmware、再載一次」的白工上。
根因:先前修的 needsReset 邏輯不管 firmware 新舊一律 reset。但 Error 15
只發生在「Comp/U 是上次 session 殘留」的情境;「本次 connect 內部剛載的
Comp/U」session 是乾淨的,不需要 reset。
修法(條件性 reset):
- server/scripts/kneron_bridge.py:connect handler 新增追蹤本次有無走
firmware load flow,return 多帶 `fresh_firmware_loaded` bool
- server/internal/driver/kneron/kl720_driver.go:Connect 讀 flag,若為
true 就 skipReset(firmware 剛載的,session 已乾淨)
驗證(2026-04-21):
- `/tmp/test_bridge.py` 拔插 USB 後跑 `connect (fw=Loader) →
fresh_firmware_loaded=True → skip reset → load_model → inference`
→ 11 detections(person×8, tie×3, latency 332ms)
- Mac UI Comp/U 殘留路徑:reset → 11 bbox ✓
- Mac UI Loader cold-boot 路徑(拔插後):skip reset → 11 bbox ✓
預期效益:
- Windows cold-boot(常見):106s → ~40s(省 65s)
- Mac 跨 session(常見):~15-20s 不變
- 極少數(Windows device 未斷電但跨 server session):走完整 reset
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-21 11:09:25 +08:00 |
|
|
|
30d0ff5695
|
fix(local-tool): 推論 bbox 標註不顯示 — 前端 canvas 尺寸 + KL520 reset + 延長 timeout
症狀:Mac 版上傳單張圖推論,畫面完全沒有 bbox 標註。實測追根因後發現
兩層獨立問題疊加(前端 + 後端),擇一修復都無法解決。
## Layer 1: 前端 canvas 尺寸對不上 img 顯示尺寸
- camera-inference-view.tsx renderedSize 初始值硬寫 {w:640, h:480}
- ResizeObserver 理應在 <img> load 後 fire,但實測沒 fire 或時機不對
- 結果 overlay canvas 永遠用 640×480 畫,bbox 嚴重偏位或跑出 canvas
修法(camera-feed.tsx + camera-inference-view.tsx):
- <img> 加 onLoad handler,decode 完立刻用 getBoundingClientRect 回報
- ResizeObserver effect 進來先檢查 img.complete && naturalWidth > 0,
是就立刻 report(cover HMR / cached image)
- effect 依賴加 streamUrl / batchImageUrl,換圖會重觀察
- renderedSize 初始值改 null,overlay 改為拿到真實尺寸才 render
- setState callback 用 prev 比對,同尺寸不觸發 render
- camera-overlay.tsx 加 [bbox-debug] console.log 保留(debug 成本低,
對未來排查有幫助)
## Layer 2: KL520 推論炸 ApiKPException Error 15
- kp.inference.generic_image_inference_send 回 SEND_DATA_TOO_LARGE
- 試過 image 尺寸(516×640 / 640×794 / 640×640 host pad)、numpy vs
bytes、明確傳 width/height — 全部炸
- Python bridge 直接測試(/tmp/test_bridge.py)做完整
`connect → reset → reconnect → load_model → inference` 序列 → 11 個
detection 正常回傳
- Go driver 走 `connect → load_model → inference` 跳過 reset
根因:commit ddf0eb8(2026-04-16)「KL520 首次 connect 跳過 reset」當時
為解 Windows 60s HTTP timeout 的優化。但副作用:KL520 若 session 間
firmware 殘留(fw=KDP2 Comp/U),直接 load_model + inference 100% 炸
Error 15。必須走完整 reset → 退回 Loader → 重新載 firmware → Comp/U
流程才能得到能 inference 的 session。
修法(kl720_driver.go):
- 移除「KL520 跳過 reset」特例,讓 KL520 和 KL720 都走 needsReset → restartBridge
- 註解記錄 trade-off:KL520 connect 時間 ~2s → ~15-20s(macOS),
Windows 可能 60s+
## HTTP timeout 配套調整
- device_handler.go ConnectDevice timeout 60s → 120s
- Windows worst-case(~65s:Loader reconnect 16s + firmware load 31s +
reboot 8s + reconnect 5s)留 buffer,避免 504 CONNECT_TIMEOUT
## Bridge 清理
- kneron_bridge.py 清掉中途試驗遺留的 `_host_preproc` 死碼
(還原成原版 _correct_bbox_for_letterbox)
- 加了 debug log(Inference: sending / parse done / EXCEPTION with
traceback)保留,未來排查 inference 路徑很有用
## 驗證(function 層)
/tmp/test_bridge.py 三種尺寸全通過:
- 516×640 直式 → 11 detections (person×8, tie×3) latency 308ms
- 1920×1080 横式 → 0 detections(合成圖,正常)
- 512×512 正方 → 0 detections
## 待使用者驗證
- Mac UI 實測:上傳 ~/Downloads/000000000459.jpg 應見 11 個 bbox 精準框住
- Windows 實測 connect 耗時 + timeout 是否足夠
- Linux 實測
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-21 01:12:10 +08:00 |
|
|
|
6c21beb7b6
|
fix(local-tool): Linux AppImage bundled Python + udev 單次密碼
Linux AppImage 掃不到 Kneron 裝置的根因是 Wails app 端三個 locator
完全沒讀 AppRun 已 export 的 VISIONA_BUNDLE_LIB_DIR,導致:
- locateBundleDataDir 找不到 models.json → seed user data dir 失敗
- locateBundledPythonAssets 找不到 python tarball + wheels
→ ensurePythonRuntime(Auto) fallback 到 system Python
→ system Python 缺 numpy / kp / pyusb → bridge scan silent fail
→ "No Kneron devices detected"
修復:
1. 三個 locator 優先讀 VISIONA_BUNDLE_LIB_DIR / VISIONA_BUNDLE_BIN_DIR
(AppRun 已 export),AppImage 佈局 usr/lib/visiona-local/{data,python,wheels}
一次到位
2. AppRun 加 VISIONA_PYTHON_MODE=bundled — Linux AppImage 強制走內嵌
Python,避免 system Python 環境差異(符合 R4「完全離線內嵌」決策)
3. InstallUdevRule 合併 pkexec:cp + reload-rules + trigger 用
pkexec sh -c 一次提權,使用者只需輸入 1 次密碼(原本 3 次)
4. build-appimage.sh 加硬檢查:
- python tarball 缺失 → 自動 make vendor-python-linux,仍缺就 exit 1
- wheels 數量 < 4 → 自動 make vendor-wheels-linux,仍不足就 exit 1
- 驗證關鍵 wheel(numpy / opencv / pyusb / kp)存在,少任一 exit 1
5. Makefile payload-linux 同步加硬檢查(python tarball 必存在,
wheels ≥ 4 個)
6. 參照 edge-ai-platform POC 補齊 visiona-local/wheels/linux/ 的
KneronPLUS-2.0.0-py3-none-any.whl(POC 已驗過可用)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-18 23:15:52 +08:00 |
|
|
|
4e3dc3e504
|
fix(local-tool): Linux udev rule 自動偵測安裝 + pkexec FUSE 修復
兩個修復:
1. pkexec cp 失敗:AppImage 的 FUSE mount(/tmp/.mount_vision*)有特殊
權限,pkexec 提權後的 root process 無法讀取 user mount 的 FUSE 檔案。
修法:先用 os.ReadFile 把 rule 讀到 /tmp/visiona-local-99-kneron.rules
(普通使用者權限可寫 /tmp),再 pkexec cp 從 /tmp 到 /etc/udev/rules.d/。
同時修 server API endpoint 和 Wails 啟動流程兩處。
2. 啟動流程自動偵測 udev:Stage 4 probeDeviceListAndComplete 解析
/api/devices response 的 udevHint 欄位。Linux + 0 裝置 + udevHint=true
→ 自動找 bundle 裡的 99-kneron.rules → 複製到 /tmp → pkexec cp 安裝
到 /etc/udev/rules.d/ → reload udev。會彈 Linux 圖形化密碼框,使用者
輸入密碼即完成。取消密碼不阻擋啟動流程(log 記錄跳過)。
Wails 控制台 Stage 4 會顯示細步文案:「偵測到 USB 權限未設定,正在
安裝(請在密碼視窗輸入密碼)...」
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-17 00:02:37 +08:00 |
|
|
|
db272cac5a
|
feat(local-tool): Linux udev rule 未安裝偵測 + 一鍵安裝 UX
使用者在 Ubuntu 上 scan 不到 Kneron 裝置。根因:Linux 預設 USB 裝置
權限是 root only,非 root 使用者的 kp.core.scan_devices 因 permission
denied 而 silently 回傳 0 裝置。需要安裝 udev rule。
修法三層:
1. Server:GET/POST /api/devices 在 Linux + 0 裝置 + udev rule 不存在
時帶 udevHint: true
2. 新增 POST /api/system/install-udev:用 pkexec 提權安裝 99-kneron.rules
+ reload udev(彈 Linux 圖形化密碼對話框)
3. 前端 devices page:udevHint=true 時顯示 amber 色 banner 提示 +
一鍵安裝按鈕,成功後自動 rescan
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 23:20:28 +08:00 |
|
|
|
ddf0eb8147
|
fix(local-tool): KL520 首次 connect 跳過不必要的 device reset
使用者 Windows 上 connect KL520 耗時 60+ 秒且前端收到 504 timeout。
根因分析(從 log 逐行推斷):
1. server 啟動後首次 connect → needsReset=true → restartBridge()
2. reset 送出 → KL520 reboot → 退回 KDP2 Loader 模式(USB Boot 裝置,
reset = firmware 從 RAM 清掉)
3. USB 重新枚舉 8 秒 → 新 bridge process → 嘗試 reconnect
4. Loader 模式的 connect_devices_without_check 不穩定 → attempt 1 fail
(16 秒 timeout) → attempt 2 成功 (4 秒)
5. 載 firmware fw_scpu.bin → 31 秒
6. firmware loaded → 再次 reboot → 5 秒後 reconnect
7. 總時:8 + 16 + 4 + 31 + 5 = 64 秒 > 前端 60 秒 HTTP timeout → 504
但 KL520 是 USB Boot 裝置,每次斷電 firmware + model 就會清掉,connect
時本來就是 clean state。server 啟動後主動 reset 是多餘的——它把完整
firmware 砍掉再重載一次,浪費 60 秒且 Loader 模式 connect 不穩定。
這個 reset 邏輯最初是為 KL720 設計的:KL720 是 flash-based 裝置,
firmware 和 model 保留在 flash,reset 清 stale model 才有意義。
修法:needsReset 條件加上 chipType == "KL720"。KL520 跳過 reset,
直接使用已有的 firmware。如果 KL520 真的有殘留 model 要清(理論上
不會因為它是 RAM-based),下次 load_model 前的 restartBridge 會處理。
修復後 KL520 connect 預期時間:2-5 秒(一次 connect + set_timeout)。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 22:49:01 +08:00 |
|
|
|
8cd5751ce3
|
feat(local-tool): M8 重構 — Wails 控制台 + 瀏覽器 Web UI(R5 決策)
依 R5 五輪決策把 visionA-local 從「Wails 內嵌 Next.js」重構為「Wails
本機伺服器控制台 + 瀏覽器 Web UI」模式(類比 Docker Desktop / Ollama)。
程式碼變動
- M8-1 砍 yt-dlp 全套(後端 resolver / URL handler / 前端 URL tab /
Makefile vendor / installer / bootstrap / CI workflow,-555 行)
- M8-2 砍 Mock 模式全套(driver/mock、mock_camera、Settings runtimeMode、
VISIONA_MOCK 環境變數,-528 行)
- M8-3 ffmpeg 從 GPL 切換到 LGPL 混合方案:Windows/Linux 用 BtbN 現成
LGPL binary,macOS 自 build minimal decoder-only 進 git
(vendor/ffmpeg/macos/ffmpeg 5.7MB + ffprobe 5.6MB,比 GPL 版省 85% 空間)
- M8-4 Wails Server Controller:state machine、log ring buffer 2000 行、
preferences.json atomic write、boot-id、Gin SkipPaths、shutdown 7+1 秒、
notify_*.go 三平台 OS 通知、watchServer 改 Error state 不 os.Exit
- M8-4b 啟動階段管線 R5-E:6 階段進度 event、20s soft / 60s hard timeout、
stage 5/6 skip 規則、sentinel file、RestartStartupSequence 5 步驟
- M8-5 Wails 控制台 vanilla HTML/JS/CSS(9 檔 ~2012 行)取代 M7-B splash:
state 視覺、log panel、startup progress panel、Stage 6 manual CTA
pulse、shutdown modal、Settings、Dark Mode、i18n 中英雙語
- M8-6 上傳影片副檔名擴充(mp4/avi/mov/mpeg/mpg)
- M8-7 Web UI Server Offline Overlay(role=alertdialog + focus trap +
wsEverConnected 容錯 + Page Visibility)
- M8-8 CORS middleware(127.0.0.1/localhost only + suffix attack 防護)+
ws/origin.go 獨立 WebSocket CheckOrigin 避 package cycle
- MAJ-4 server:shutdown-imminent WebSocket broadcast 機制
(/ws/system endpoint + notifyShutdownImminent helper)
- M8-9 Boot-ID + 瀏覽器 tab 自動重連(sessionStorage loop guard)
品質
- ~105+ 新 unit test + race detector (-count=2) 全綠
- 10 個 milestone 全部通過 Reviewer 審查
- 三方 v2 + v2.1 文件(PRD / Design Spec / TDD)+ 交叉互審紀錄
收錄在 .autoflow/
交付前待處理(M8-10)
- 重跑 make payload-macos 把舊 GPL 77MB binary 換成新 LGPL
- 三平台 end-to-end build 驗證
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-15 17:57:54 +08:00 |
|
|
|
c0317225ca
|
feat(local-tool): yt-dlp 錯誤訊息友善化 + 載入逾時提示
ResolveWithYTDLP 改善:
- 新增 friendlyYTDLPError() 把 yt-dlp 的技術性 stderr 訊息轉成繁中提示
- 涵蓋 9 種常見失敗原因:
年齡限制 / 私人影片 / 已移除 / 版權 / 直播 / 首播 / DRM / 頻率限制 / 無格式
- 錯誤訊息同時附上原始 stderr(方便 debug)
- yt-dlp 未安裝時改用繁中提示
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-13 00:56:15 +08:00 |
|
|
|
aa324cef42
|
fix(local-tool): flash 模型檔案找不到 — 相對路徑未解析
根因:models.json 的 filePath 是相對路徑("data/nef/kl520/xxx.nef"),
但 server working directory 是 {app}\bin\(app.go 設 cmd.Dir = binary 目錄),
所以 server 在 {app}\bin\data\nef\ 找 .nef 檔,找不到。
實際位置:{app}\data\nef\(installer 裝的位置),對應 server 的 --data-dir
由 Wails app 傳入的 %APPDATA%\visiona-local(或 fallback 到 <exe>/../data)。
修法:
- flash.NewService 新增 dataDir 參數
- StartFlash 中把相對 filePath 用 dataDir 拼接成絕對路徑:
"data/nef/..." → 去掉 "data/" 前綴 → dataDir + "/nef/..."
- main.go 傳 dataDir 給 flash.NewService
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 22:03:28 +08:00 |
|
|
|
3c6971febd
|
fix(local-tool): Review M1-M4 + m5 修復 — flash 生命週期 + store 隔離
Review 問題修復:
M1(寫已關閉 channel panic):
- flash service goroutine 改成先等 driver.Flash() 返回,再寫 error 訊息,最後 close
- driver.Flash 返回後保證不再寫 progressCh,消除 race condition
M2(FlashTask 永不清除 memory leak):
- service.go 新增 CleanupTask(taskID) 公開方法
- device_handler.go 的 goroutine 在 `for range progressCh` 結束後呼叫 CleanupTask
M3(同裝置重複 flash taskID 衝突):
- ProgressTracker.Create 改成:舊 task 未完成時返回 nil
- StartFlash 檢查 nil → 回傳 "flash already in progress" 錯誤
M4(前端 flash store 全域不區分 deviceId):
- flash-store.ts 新增 activeDeviceId 欄位
- updateProgress 改接 (deviceId, progress),比對 activeDeviceId 防止混裝
- use-flash-progress.ts 的 WebSocket callback 傳入 deviceId
m5(flash_ws.go 雙重 conn.Close):
- read pump goroutine 移除 defer conn.Close(),由外層 defer 統一關閉
額外修復(S4):
- modelPath 為空時直接回 error 而非傳無效路徑給 driver
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 20:16:24 +08:00 |
|
|
|
44711753ae
|
feat(local-tool): 推論功能完整搬入 — flash 模組 + workspace 推論介面
## 後端(Phase 1)
新增 flash 模組(從 edge-ai-platform 搬入):
- server/internal/flash/service.go:StartFlash + 模型相容性檢查 + 晶片 NEF 解析
- server/internal/flash/progress.go:Flash 進度追蹤器
- server/internal/api/ws/flash_ws.go:WebSocket 推送 flash 進度
- device_handler.go:新增 FlashDevice method + flashSvc 欄位
- router.go:新增 POST /api/devices/:id/flash + WS /ws/devices/:id/flash-progress
- main.go:初始化 flash.NewService 並傳入 router
推論/攝影機/MJPEG/inference WebSocket 之前 M1 已搬好,不需改動。
Python bridge (kneron_bridge.py) 與 edge-ai-platform 完全相同,不需改動。
## 前端 store + hooks(Phase 2)
- stores/flash-store.ts(新):Zustand store — startFlash / updateProgress / retryFlash / reset
- hooks/use-flash-progress.ts(新):WebSocket hook 接收 flash 進度
inference-store / camera-store / inference types / use-inference-stream / use-websocket
之前 M1 已搬好,不需改動。
## 前端 UI 元件(Phase 3)
- components/devices/flash-dialog.tsx(新):模型載入對話框 + 硬體相容性檢查
- components/devices/flash-progress.tsx(新):Flash 進度條 + 錯誤重試
camera-inference-view / camera-feed / camera-overlay / source-selector /
inference-panel / performance-metrics / classification-result / confidence-slider /
video-progress / batch-image-thumbnails 之前 M1 已搬好。
## 前端頁面整合(Phase 4)
- workspace/page.tsx:繁中硬編碼、顯示已載入模型名稱
- workspace/[deviceId]/workspace-client.tsx:加入 FlashDialog 按鈕 + 繁中硬編碼
- devices/[id]/device-detail-client.tsx:加入 FlashDialog + 「進入工作區」按鈕(模型已載入才顯示)
- device-card.tsx:已連線 + 模型已載入時顯示「工作區」快捷按鈕
## 使用者操作流程
裝置列表 → 連線 → 管理 → 載入模型 → 進入工作區 → 選攝影機/圖片/影片 → 開始推論 → 看 bounding box / FPS / latency
或:裝置列表 → 工作區(已有模型)→ 直接推論
## 不搬的東西
- cluster/* 全部不搬(已砍 cluster 功能)
- relay / tunnel 相關不搬
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 20:07:09 +08:00 |
|
|
|
819885c85d
|
fix(local-tool): SPA fallback 改用 Next.js dynamic route shell HTML
根因:點模型卡片 → /models/yolov5-face-detection → server SPA fallback
固定回傳根路徑 /index.html(儀表板) → Next.js CSR router 初始化時
pathname 對不上 → 使用者被跳回儀表板。
修法:spaFallback handler 改成三層 fallback:
1. 精確檔案(/models/index.html 等)
2. Next.js dynamic route shell(把最後一段替換為 _ → /models/_/index.html)
這是 generateStaticParams 產的 placeholder 頁面,Next.js CSR 會從 URL
讀真正的 param 值
3. 根目錄 /index.html(最終 fallback)
這修好了:
- 模型詳情頁 /models/:id 不再跳回儀表板
- 裝置詳情頁 /devices/:id 同理
- 工作區裝置頁 /workspace/:deviceId 同理
- Sidebar active 狀態也會正確(因為 pathname 匹配了)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 19:44:25 +08:00 |
|
|
|
d1ff55005a
|
debug(local-tool): driver install verbose 輸出 + 安裝後自我驗證
- Python script 對每個 PID install 後 capture traceback,不再 swallow
- 裝完立刻 scan_devices() 驗證 SDK 能不能開 handle,印 is_connectable
- 安裝結果完整寫到 server.stderr.log(而不是只回錯誤摘要)
- 判斷 DONE 標記 + 至少一個 OK 才算成功
這讓我們能清楚看到 libwdi 到底是「沒權限 / DLL 載入失敗 / 綁定成功但
裝置 is_connectable 還是 False(代表 driver 層級 OK 但裝置需要重插)」
哪一種情境,而不是只看到籠統的「error 28」。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 07:38:43 +08:00 |
|
|
|
4902cb5531
|
feat(local-tool): Kneron WinUSB driver 透過 KneronPLUS SDK libwdi 安裝
根因:
KP_ERROR_CONNECT_FAILED (error code 28) — Kneron USB 裝置預設沒綁定
WinUSB driver,SDK 無法開 handle。原 .iss 的 pnputil /add-driver 做法
需要 .cat 簽章(Windows 10/11 driver signing enforcement),我們沒有。
參考 edge-ai-platform/installer/platform_windows.go 的 installKneronDriverViaSDK:
KneronPLUS SDK 內建 libwdi wrapper — kp.core.install_driver_for_windows(pid)
libwdi 會自動用臨時自簽憑證,不需要 .cat 檔,只需要 UAC 提權。
實作:
- server/internal/api/handlers/system_driver_windows.go(新):
組 Python script → kp.core.install_driver_for_windows 對 KL520/KL720/KL720_LEGACY →
PowerShell Start-Process -Verb RunAs 提權執行 → 結果寫 temp 檔讀回
- server/internal/api/handlers/system_driver_other.go(新):非 Windows stub
- system_handler.go: NewSystemHandler 新增 pythonBin 參數 + InstallDriver handler
先判斷 runtime.GOOS==windows 才執行
- router.go: 新增 POST /system/install-driver
- main.go: 解析 pythonBin(VISIONA_PYTHON env var → cfg.PythonBin)傳入
前端:
- frontend/src/app/devices/page.tsx:Windows only 多一個「安裝 USB Driver」按鈕
(用 navigator.userAgent 判斷平台)
- frontend/src/stores/device-store.ts:connect 失敗訊息偵測 winusb / error 28 /
KP_ERROR_CONNECT_FAILED 特徵字串,回一條明確的繁中提示引導使用者去點按鈕
Wails app 端:
- visiona-local/app.go: 新增 InstallKneronDriver() binding 作為備用入口(目前前端沒用到,
因為前端跑在 http://127.0.0.1 不是 wails://,但保留給未來 splash 階段觸發用)
- visiona-local/platform_{windows,darwin,linux}.go: installKneronWinUSBDriver 平台實作
/ 跨平台 stub
.iss:
- 移除 pnputil /add-driver 的 [Run] entry(它是 silent-fail 的 dead code,
因為沒 .cat 簽章)
- 新增註解說明:driver 安裝改由 app 端呼叫 libwdi 完成
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 05:25:32 +08:00 |
|
|
|
f8533a6b04
|
fix(local-tool): sidebar icon + Wails Windows icon.ico + 掃裝置路徑修復
sidebar E icon:
- frontend/src/components/layout/sidebar.tsx 左上角的 "E" 方塊換成 <img> 指向
/visiona-logo.png,從 frontend/public/visiona-logo.png serve
Wails 桌面/工作列 icon:
- 把 branding/icon.ico 複製到 visiona-local/build/windows/icon.ico
- Wails v2 Windows build 偵測到這個檔案就會直接用它當 exe embedded icon,
不再從 appicon.png 自動 resize(解析度更好)
掃裝置根因修復:
1. server main.go:新增 resolveBridgeScript() 智慧找 kneron_bridge.py
- 優先 <exe>/scripts/kneron_bridge.py
- fallback <exe>/../scripts/... 對應 Windows installer 的 {app}\bin\ + {app}\scripts\ 佈局
- fallback <exe>/../Resources/scripts/... 對應 macOS app bundle
2. server kneron/detector.go:ResolvePython 重寫
- 最高優先:VISIONA_PYTHON 環境變數(由 Wails 殼層注入)
- 加入 visiona-local 新路徑:%APPDATA%\visiona-local\runtime\venv、
~/Library/Application Support/visiona-local/runtime/venv、
~/.local/share/visiona-local/runtime/venv
- 保留 edge-ai-platform 舊路徑作為 legacy fallback
3. visiona-local/app.go:spawn server 時 export VISIONA_PYTHON=<pyBin>
讓 detector 直接用 Wails 殼層已經 resolve 好的 python interpreter,
不再自己獨立去找造成不一致。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-12 04:59:23 +08:00 |
|
|
|
c54f16fca0
|
Initial commit: visionA monorepo with local-tool subproject
local-tool/: visionA-local desktop app
- M1: Wails shell + Go server + Next.js UI + Mock mode (macOS dmg ready)
- M2: i18n (zh-TW/en) + Settings 4-tab refactor
- M3: Embedded Python 3.12 runtime (python-build-standalone) + KneronPLUS wheels
- M4: Windows Inno Setup script (build on Windows runner)
- M5: Linux AppImage script + udev rule (build on Linux runner)
- M6: ffmpeg (GPL, pending legal review) + yt-dlp bundled
- Lifecycle: watchServer health check, fatal native dialog,
Wails IPC raise endpoint, stale process cleanup
.autoflow/: full PRD / Design Spec / Architecture / Testing docs
(4 rounds tri-party discussion + cross review)
.github/workflows/: macOS / Windows / Linux build CI
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-11 22:10:38 +08:00 |
|