tplink-kasa-kc110: ship vendor OV2735 libsns (fixes no video), ultimate majestic

[moontwister]

Two changes to the KC110 device profile added in #99, so the device produces video once CI builds it. The built image was hardware-verified on a KC110 (streams 1080p out-of-the-box).

The CI-registration half of this PR is dropped: the matrix has been derived from the tree since #120, and the KC110's NOT_BUILT opt-out is removed by #132 instead. BR2_PACKAGE_JSONFILTER=y needed no change here — #128 had already removed it from this defconfig, so the rebase inherited that.

1. Ship the vendor OV2735 libsns — fixes no video

OpenIPC's opensdk libsns_ov2735.so does not drive this OV2735: the sensor i2c init aborts (hi_i2c_wait_txfifo_notfull / hi_i2c_abortprocess) and the sensor never streams — MIPI detects no valid frame, VENC stays idle, /image.jpg hangs.

This ships the vendor libsns_ov2735.so (from the device's stock firmware, same provenance as the rest of the HiSilicon stack) as a device-overlay payload — the documented pattern for a sensor lib the SoC osdrv doesn't correctly provide. It loads cleanly against OpenIPC's libisp/lib_hiae, so no other files are needed, and it is scoped to this device's overlay (cannot affect other boards).

Hardware-proven by a bidirectional, single-variable swap on a live KC110: opensdk libsns → no video; vendor libsns → instant 1080p — on both firmware HEAD and the 2026-06-17 release.

2. Select the ultimate majestic variant (consistency)

The defconfig sets BR2_OPENIPC_VARIANT="ultimate" but omitted BR2_OPENIPC_MAJESTIC, so it fell back to the lite default (general/Config.in). This aligns the device with its declared variant, matching the two other devices that set it (both hi3516ev300_ultimate_*).

Device builds clean (rootfs 6440 KB / 8192 KB NOR).

[openipc-ai]

Thanks for this, and sorry it sat. Three changes are bundled here and they've diverged in status.

The CI registration — the master.yml matrix line — is what makes this branch conflict. Since #120 the matrix is derived from the tree rather than listed, and devices that existed but were in no matrix at the time (the KC110 among them) were frozen into a NOT_BUILT opt-out in .github/scripts/ci-matrix.py. I've opened #132 to remove the KC110 and the Tapo TC70 v3 from that set, which is this half of your PR done the way the selector now wants it. Because a change to ci-matrix.py can't narrow, #132 runs the full matrix, so the KC110 gets its first-ever build there.

The other two changes are untouched by any of that and still wanted:

• BR2_OPENIPC_MAJESTIC="ultimate" — consistent with the only two other devices that set it, both hi3516ev300_ultimate_*.
• the vendor libsns_ov2735.so overlay for the no-video bug. This is the part I can't verify from here, and it's the interesting one.

Could you drop the master.yml hunk and rebase on master? That leaves a focused PR, and PR CI will then build hi3518ev200_ultimate_tplink-kasa-kc110 narrowed to just that device — so we'd see the overlay actually go through a build.

One thing while you're in there: please also drop BR2_PACKAGE_JSONFILTER=y if it's still selected — #128 removed it from all 97 defconfigs after firmware/#2304.

[openipc-ai]

Thanks — this is exactly what was asked for. The master.yml hunk is gone, it rebases cleanly, and splitting it into two commits with real messages makes it reviewable. The CI half landed separately in #132 (9df259c), so the KC110 is out of NOT_BUILT and building on master now.

What I could verify statically, against master:

• BR2_OPENIPC_MAJESTIC="ultimate" matches the only other devices that set it, both hi3516ev300_ultimate_*. Consistent.
• The blob is the right shape — ELF 32-bit LSB shared object, ARM, EABI5, which is what the arm-openipc-linux-musleabi toolchain wants.
• It survives the rootfs prune. hi3518ev200_ultimate.list strips /etc/sensors/ov2735_i2c_1080p.ini but not /usr/lib/sensors/libsns_ov2735.so, so the overlay copy makes it into the image. Worth stating because that list is exactly where a new overlay file goes to die.
• jsonfilter: ignore my earlier note — this defconfig never selected it, so there's nothing to drop. My mistake.

One thing worth recording in the commit message rather than changing:

hisilicon-osdrv-hi3516cv200 already installs its own libsns_ov2735.so (line 77 of the .mk), so this overlay overrides it rather than filling a gap. They are genuinely different builds — 23076 bytes here vs 17988 upstream — which is consistent with the KC110 needing the MIPI variant while the osdrv ships the DVP/i2c one, matching the ov2735_mipi_1080p.ini and patched load_hisilicon this device already carries.

That is the right call for the fix, but it does pin this device to the vendor blob permanently: if firmware ever updates its own libsns_ov2735.so, the KC110 will keep using yours and nobody will notice. Since a binary is not something a future maintainer can diff, could you add a line to the commit message saying where the blob came from — which stock TP-Link firmware image and version you pulled it out of? That is the piece of context that cannot be recovered later.

To actually build it, a maintainer needs to approve the workflow run. The run is sitting at action_required (the first-time-contributor gate), so no build has happened on this branch yet. Once approved it narrows to just hi3518ev200_ultimate_tplink-kasa-kc110, so it is one device's worth of runner time.

Nothing here blocks merging on my side beyond seeing it build.

[openipc-ai]

Heads-up on a false green, and a bit of noise incoming — nothing you need to do.

I approved the workflow run, and it came back green, but it did not actually build anything:

ci-matrix: self-test ok (107 devices, 15 smoke, 39 cases)
ci-matrix: 0/107 devices (needs_build=False) --- nothing that reaches a build

That is a timing artifact, not a problem with your branch. The run was created at 18:10, and #132 — the PR that takes the KC110 out of NOT_BUILT — merged at 18:24. So the selector evaluated the pre-#132 tree, where this device was still opted out of CI, and correctly narrowed to nothing. Approving a run later does not recompute its base; it just releases what was already queued. Note the 107 devices: master is at 110 now.

Reopening the PR to force a fresh evaluation against current master (reopened is one of the workflow's triggers). You will get a close/reopen notification — please ignore it, the branch is untouched.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restore KC110 video with vendor OV2735 library and ultimate Majestic

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Package KC110's vendor OV2735 sensor library to restore reliable 1080p video.
• Select ultimate Majestic so runtime capabilities match the declared firmware variant.

Diagram

graph TD
  CFG["KC110 defconfig"] -->|selects| BUILD["Buildroot image"] -->|produces| FW["KC110 firmware"] -->|runs| MAJ["Ultimate Majestic"] -->|serves| VIDEO["1080p video"]
  LIB["Vendor OV2735 lib"] -->|device overlay| BUILD
  FW -->|initializes| SENSOR["OV2735 sensor"] -->|frames| VIDEO

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Repair the OpenSDK OV2735 driver

• ➕ Avoids shipping a proprietary binary payload
• ➕ Could fix other boards using the same sensor and SoC stack
• ➖ Requires deeper hardware debugging or reverse engineering
• ➖ Broadens regression risk beyond the KC110
• ➖ Delays a fix already isolated and validated on hardware

Recommendation: Use the device-scoped vendor library as the immediate fix because bidirectional hardware testing isolates it as the working component and the overlay prevents impact on other boards. An upstream OpenSDK driver repair remains the preferable long-term replacement if equivalent initialization can be implemented and validated.

Files changed (2) +1 / -0 · 1 not counted

Bug fix (1)

libsns_ov2735.soPackage the working vendor OV2735 sensor library _{not counted}

Package the working vendor OV2735 sensor library

• Adds the stock KC110 sensor library as a device-only overlay payload, replacing the incompatible OpenSDK implementation at runtime. The vendor library initializes the sensor successfully and restores hardware-verified 1080p streaming.

devices/hi3518ev200_ultimate_tplink-kasa-kc110/general/overlay/usr/lib/sensors/libsns_ov2735.so

Other (1) +1 / -0

hi3518ev200_ultimate_tplink-kasa-kc110_defconfigSelect the ultimate Majestic runtime variant +1/-0

Select the ultimate Majestic runtime variant

• Sets 'BR2_OPENIPC_MAJESTIC="ultimate"' so the KC110 no longer inherits the lite default. This aligns the packaged Majestic runtime with the device's existing ultimate firmware declaration.

devices/hi3518ev200_ultimate_tplink-kasa-kc110/br-ext-chip-hisilicon/configs/hi3518ev200_ultimate_tplink-kasa-kc110_defconfig

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit c6a15e9 ⚖️ Balanced

Results up to commit c6a15e9

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[openipc-ai]

One more close/reopen notification from me, sorry — last one. Explaining so the churn on your PR makes sense.

My first attempt to re-trigger this raced GitHub: when I reopened at 18:58, refs/pull/108/merge was still parented on 82ab2e7, one commit before #132 took the KC110 out of NOT_BUILT. So the run faithfully checked out a tree where this device is opted out and correctly built nothing.

I then assumed re-running the workflow would pick up the newer base. It does not — a re-run pins the merge commit computed when the run was first created, so attempt 3 checked out the identical 81d4d99 and reached the identical decision. That was my mistake, not a CI bug.

The merge ref has since been recomputed to dc5c2fc, parented on current master 9df259c, where the KC110 is in the build set. Reopening once more, which creates a genuinely new run pinned to that merge commit.

Your branch has not been touched at any point.

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit c6a15e9

[openipc-ai]

Built, and properly this time. Run 33106540798 checked out the right base:

HEAD is now at dc5c2fc  Merge c6a15e92b... into 9df259cb6...   <- current master
ci-matrix: self-test ok (110 devices, 15 smoke, 39 cases)
ci-matrix: 1/110 devices (needs_build=True) --- narrowed to the affected devices
Firmware (hi3518ev200_ultimate_tplink-kasa-kc110)   SUCCESS

Fit is a non-issue on this board:

- uImage:          [1776KB/2048KB]
- rootfs.squashfs: [6276KB/8192KB]

and no entry in hi3518ev200_ultimate.list reported "matched no file", so the exclude list is not stale against the tree your overlay produces.

Note the earlier Firmware SKIPPED entries still visible in the check list — those are the two runs against the pre-#132 base and can be ignored; the one that matters is the named device job above.

So: the defconfig change and the overlay compile and fit. What CI cannot tell us is whether the vendor blob actually fixes the no-video symptom — that needs the camera. If you have flashed this image on the KC110 and have video, say so on the PR and that is good enough for me.

Still useful whenever you get to it: which stock TP-Link firmware image and version the .so came from, in the commit message. It is the one thing about a binary that cannot be recovered later.

[openipc-ai]

Merged as 2ca0796 — and an apology for the runaround at the end.

I told you "nothing here blocks merging on my side beyond seeing it build", it built, and I then asked for hardware confirmation and the blob's provenance before merging. That was moving the goalposts after you had already done everything asked, and it was the wrong call. The bar I stated was the bar.

The provenance question stands only as a nice-to-have: if you happen to remember which stock TP-Link image the .so came from, drop it in a comment here and it will be in the history for whoever next has to reason about that binary. Not needed for anything.

Thanks for coming back to a PR that had sat since June, and for splitting it cleanly when asked.