IMX219 / IMX217 sensor support on RTL8735BDM — any plans to add?

Linux Peripherals
1

Hi,

We’re using the RTL8735BDM (AmebaPro2) SDK for a video doorbell product and noticed the sensor driver package supports several IMX-series sensors, but not IMX219 or IMX217.

Are there any plans to add support for these two sensors in an upcoming SDK/driver release? If so, could you share a rough timeline? If not, we’d appreciate knowing so we can decide whether to port a driver ourselves.

Thanks for your help!

2

Hi @deepakkumarbinwal,

Currently, the RTL8735BDM (AmebaPro2) SDK does not support the IMX219 or IMX217 sensors.

We will discuss this request with the relevant team to check whether support for these sensors is planned in a future SDK or driver release.

We’ll update you again once we have more information regarding feasibility.

Thank you.

3

SDK version: Ameba FreeRTOS Pro2 SDK (AmebaPro2 / RTL8735B), release 9.6_r

Issue:
In the v1 KVS WebRTC example (kvs_webrtc_mmf, using lib_amazon’s amazon-kinesis-video-streams-webrtc-sdk-c), the signaling connection — both the WSS channel (wss_api.c) and REST calls (http_api.c) — connects via NetIo_connect() in netio.c. When no CA/cert/key is passed (which is always the case here), it falls back to:
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_OPTIONAL);
with no mbedtls_ssl_conf_ca_chain() call, and no mbedtls_ssl_get_verify_result() check anywhere. So the connection is encrypted but doesn’t verify it’s actually talking to AWS — a MITM with a fake cert would go undetected. The CA cert that AppCredential.c’s searchSslCert() loads is stored but never actually applied to this connection.

What I’ve also found: the SDK ships a newer kvs_webrtc_v2_mmf example using a different stack (transport_mbedtls.c) that does verify properly (real CA chain, VERIFY_REQUIRED, hostname/SNI). But it’s not a drop-in — its own readme requires fetching the actual library source from a separate repo (fetch_aws_lib.sh), which isn’t vendored yet, and its whole architecture (SDP/jitter-buffer/SRTP handling now done in app code, different signaling/peer-connection API) looks like a much bigger rewrite than a patch.

Questions:

  1. Is the v1 netio.c gap already known/fixed in a later release than 9.6_r?
  2. Is v1 (kvs_webrtc_mmf) still meant to be usable/supported going forward, or is v2 the intended replacement for new production designs?
  3. If we just patch v1’s netio.c ourselves (add CA-only verification for NetIo_connect, or switch the signaling calls to a verifying connect variant), is that a safe/sane approach, or is there a reason AWS/Realtek didn’t already do that (e.g. some KVS-specific reason wss_api.c/http_api.c avoid strict verification)?

Basically: should we patch what we have, or is moving to v2 the actual expectation going forward? Any guidance on which path is intended for production use would help.

4

Hi @deepakkumarbinwal,

Regarding your questions about camera sensors, may I know what requirements (e.g., IR cut, etc.) you have for the camera sensor in your product?

Have you decided which camera sensor to use, or are you still evaluating the available options?

This will help us better understand your requirements and provide more suitable support.

Thank you.

5

We are still evaluating the available options but IMX219 is good as it is available and low cost and perform well.