Xperia 10 V (zambezi): Enabling all cameras + Hardware video on Sailfish OS

parth007 · 29 October 2026 02:53

A bring-your-own-firmware guide.

Following up on sonyxperiadev/bug_tracker #875: Sony confirmed they will not ship the Xperia 10 V camera userspace through the Open Devices (SODP) program, the v4b binaries carry the Xperia 10 IV camera modules instead. The correct files only exist in the stock retail firmware (XQ-DC54, 68.2.A.3.123). This guide gets all cameras + hardware video working by patching the stock files you extract from your own device - - no Sony binaries are shared here.

It builds on @balta’s guide (forum.sailfishos.org/t/guide-how-to-enable-all-cameras-on-xperia-10-v/35267, github.com/balta3/sailfish-xperia-10v-tweaks) and adds full sensor calibration, the main-camera OIS fix, and hardware H.264 encode.

Confirmed working on Sailfish OS 5.2.0.22 (the fixes survived the upgrade from 5.1.0.11, where they were originally developed).

This flashes the oem/dtbo partitions and edits vendor files, and needs root (devel-su). To enter fastboot mode: power the phone off, then hold Volume Up while plugging in the USB cable to enter the bootloader (the LED turns blue), and run the fastboot commands from your PC. Back up what matters and be ready to re-flash via fastboot if needed.

Why this is needed (the #875 summary)

github.com/sonyxperiadev/bug_tracker

[zambezi][PDX235] v4b binaries ship Xperia 10 IV camera modules; 10 V camera modules, OTP parsers and Codec2 service missing

opened 03:47AM - 20 Oct 26 UTC

closed 09:52AM - 28 Oct 26 UTC

parthpatel007

bug

**Platform:** zambezi (SM6375 / blair) **Device:** Xperia 10 V – XQ-DC54 (pdx235…) **Kernel version:** 5.4 (SODP-based kernel as used by Sailfish OS 5.1.0.11, kernel-techpack-camera) **Android version:** Android 13 binaries (Sailfish OS 5.1.0.11 / libhybris on top of the SODP adaptation) **Software binaries version:** SW_binaries_for_Xperia_Android_13_5.4_v4b_zambezi **Previously working on** Has always been a problem with the SODP binaries on the Xperia 10 V. Everything below works on the 10 V stock firmware (68.2.A.3.123), and works on SODP after using the matching stock files. **Description** The zambezi binaries are missing several Xperia 10 V specific camera and media files, so the cameras and video recording don't fully work on SODP-based builds: 1. **Camera modules:** `/odm/lib64/camera` contains the Xperia 10 IV modules `com.sony.sensormodule.murray_{tele,uwide,front}.bin` plus `zambezi_wide.bin`. The stock 10 V modules are `com.qti.sensormodule.{qtech_imx582, lce_hi847, le_hi846_back, le_hi846_front}.bin` with their `com.qti.tuned.*` files. 2. **OTP/EEPROM parsers and sensor libraries missing:** `com.qti.eeprom.hi846_back_eeprom.so`, `com.qti.eeprom.hi846_front.so`, `com.qti.sensor.{imx582,hi847,hi846_back,hi846_front}.so`. 3. **Power sequence types:** the stock 10 V modules use `SENSOR_WL2868C_*` power types 13–16, which the SODP camera kernel rejects ("Invalid Seq type"). Mapping them to 1–4 (VANA/VDIG/VIO/VAF) works. 4. **Main camera OIS:** the stock IMX582 module contains a dummy OIS init setting (register 0, addr/data type 0). Sony's stock kernel skips the generic OIS init (`cam_ois_dw9784`), but the SODP driver sends it and `cam_cci_i2c_write_table_cmd` returns -EINVAL, so the main camera never opens. Replacing it with the DW9784 write 0x7012 = 1 fixes it. 5. **Video:** the binaries ship the Qualcomm Codec2 libraries (`libqcodec2_*`) but neither the `vendor.qti.media.c2@1.0-service` binary nor OMX encoder libraries, so there is no hardware video encoder. 6. **Device tree:** the EEPROM nodes for main, ultrawide and telephoto (`eeprom@0/2/3`) have no MCLK, reset GPIO, pinctrl or cam_clk (only `eeprom@1` does), unlike Sony's stock device tree, so OTP calibration reads fail. **Symptoms** - Telephoto: wrong focus motor definition (`murray_tele` = GT9772, the 10 V uses GT9769). - Ultrawide: preview turns black whenever exposure compensation is not 0 (AEC drops to minimum line count / gain 0). - Ultrawide: pink cast and pink centre spot (no OTP / lens-shading calibration). - Main camera (with stock module): `cam_ois_apply_settings: Failed in Applying i2c wrt settings` → `Cannot apply Init settings: rc = -22`. - EEPROM: `cam_vana get failed -22`, `cam_vdig get failed -22`, CCI timeout on slave 0x42 (-110); CamX `Invalid index for EEPROM data`. - Video: gst-droid / MediaCodec reports no hardware support for `video/avc`; only the "software" Codec2 service exists. **How to reproduce** 1. Flash the v4b binaries to oem_a on an Xperia 10 V running an SODP-based build. 2. Open the camera on the telephoto, or on the ultrawide with exposure compensation not 0. 3. Try to record video (no hardware H.264 encoder). 4. With the stock 10 V camera modules: try the main camera (OIS init fails) and check the EEPROM reads in dmesg. **Additional context** With the stock 10 V files (power types converted, OIS dummy entry replaced), EEPROM nodes given the sensors' clock/reset/regulators, and the stock Codec2 service added, all four cameras (incl. OIS and factory calibration) and hardware video recording work. Requests: - Could a future zambezi binaries release include the 10 V camera modules, tuning files, OTP parsers, sensor libraries and the Codec2 service, ideally in an SODP-compatible form? - May community projects (e.g. Sailfish OS users) redistribute these specific camera configuration files to fix their devices? If not, what is the recommended way? I can provide logcat/dmesg excerpts, file offsets and the patches on request.

The SODP v4b zambezi binaries are missing the 10 V-specific camera and media files:

/odm/lib64/camera ships the 10 IV modules (murray tele / ultrawide / front + zambezi_wide) instead of the 10 V sensors: IMX582 (main), HI847 (tele), HI846 (ultrawide + front), with their tuning files.
Several HI846 / IMX582 / HI847 OTP/EEPROM parser and sensor libraries are absent.
Codec2 libraries are present, but the Codec2 service binary + OMX encoder libs are not → no hardware video encode.
The device tree’s EEPROM nodes lack MCLK, reset GPIO, pinctrl and clock settings.

Sony (Alin Jerpelea) closed ticket #875 as “cannot be fixed” the OS and stock variants use different software implementations. So SODP is a dead end, and the fix is to transplant the correct files from each device’s own stock firmware.

Prerequisites

XQ-DC54 with Sailfish X, bootloader unlocked, fastboot + SSH (key auth) working, Developer Mode + devel-su root.
Sony v4b binaries flashed to oem_a: fastboot -S 512k flash oem_a <v4b>.img This is essential — on the older v3a the camera provider crash-loops with dlopen failed: cannot locate symbol "__emutls_get_address" (the Qualcomm stats libs’ dependency isn’t exported there; v4b exports it via /odm/lib64/libofflinelog.so).
Your own stock firmware: download XQ-DC54 68.2.A.3.123 with XperiFirm, extract super.sin, and pull from vendor_a / odm_a:
- the 10 V camera modules (IMX582, HI847, HI846) and their tuning files,
- the OTP/EEPROM parsers and sensor libs,
- the Codec2 service + vendor libs. (A sin extractor + debugfs does this. Keep these files to yourself – they are Sony proprietary and must not be redistributed.)

A. Re-enable the camera stack

Jolla disables the camera stack on this port. Re-enable:

the camera provider (60-sfos-camera-provider.rc),
mediaextractor (needed later for video; also removes a record freeze),
and fix the lens labels so each sensor maps to the right slot.

B. Correct sensor modules (from your stock firmware)

Replace the 10 IV modules in /odm/lib64/camera with converted stock 10 V modules. Two changes are needed per module:

Power types: stock uses WL2868C power types 13–16; the SODP kernel rejects those → remap to 1 - 4.
Deploy through a bind-mount overlay on /odm/lib64/camera (e.g. a sfos-camera-overlay.service that mounts /var/lib/sfos-camera/odmcam) so you never modify the signed oem image directly.

This brings up front (HI846), ultrawide (HI846) and telephoto (HI847) with tap-to-focus and flash.

C. Device-tree (dtbo) patch

The SODP device tree is missing camera rails/nodes. Patch and flash a dtbo that adds:

the OIS LDO rails (cam_vaf / OIS supply, with regulator control + voltages), and
MCLK, reset GPIO, pinctrl and clocks on the main/ultrawide/tele EEPROM nodes.

Keep a copy of the original dtbo so you can restore it (fastboot flash dtbo …).

D. Main camera (IMX582 + DW9784 OIS) - - the trickiest one

Both Sony modules contain a dummy OIS init entry (regAddr 0, addr/data-type 0). The SODP kernel’s cam_cci_i2c_write_table_cmd() returns -EINVAL on type 0, giving:

cam_ois_apply_settings: Failed in Applying i2c wrt settings
Cannot apply Init settings: rc = -22

and the main camera won’t open.

Fix: patch that dummy entry into the real DW9784 “set control mode” write 0x7012 = 1, WORD/WORD (i.e. 654 7012 1 655 2 2 …), which is the same write Sony’s own kernel driver performs.

If the chip still NACKs after that, the DW9784 needs Sony’s full boot sequence → port cam_ois_dw9784 into the kernel (it’s GPL, present in the SODP / community kernel: check ID, update OIS firmware if needed, select the BMI260 gyro, run gyro-offset calibration).

Fallback (3 cameras): flash the dtbo-camfix-noois variant and skip the main-cam OIS module - front, ultrawide and telephoto all still work.

E. Hardware video (Codec2)

v4b ships Codec2 libs but no service (only Qualcomm libqcodec2_* / libqc2*, no OMX), so gst-droid reports No hardware support found for video/avc and falls back to a software encoder. The kernel side is fine (msm_vidc, /dev/video/venus_enc+venus_dec, vpu20_* firmware). To get hardware H.264:

Copy the stock vendor.qti.media.c2@1.0-service (32-bit) + its vendor libs into /vendor/lib: libcodec2_hidl@1.0.so, libcodec2_vndk.so, libstagefright_bufferpool@2.0.1.so, libdisplayconfig.qti.so, vendor.display.config@2.0.so; and copy android.hardware.media.c2@1.0.so into the vendor namespace.
ABI shim: Jolla’s libui is newer than the stock Codec2 libs expect (new GraphicBufferMapper::lock/unlock signatures). Build a small ARM32 shim (libsfos_c2shim.so, clang -target armv7a-linux-androideabi29) that forwards the old lock(handle,uint32,Rect const&,void**,int*,int*) / unlock(handle) calls, and LD_PRELOAD it in the service’s .rc.
Add the vintf manifest (IComponentStore default) and set the stock props debug.stagefright.c2inputsurface = -1 and debug.stagefright.ccodec = 4 (without these, a 64-bit client + 32-bit service hangs on GraphicMetadataBuffer).
Reboot (rc/manifest/prop changes need it).

Result: hardware H.264 encode :- recording saves and plays back (HW decode is available too). Add only new files; back up and replace media_codecs.xml / media_codecs_performance.xml with the blair versions.

Record start/stop freeze (~10 s “not responding”): this is CameraService::playSound loading VideoRecord.ogg / VideoStop.ogg, which needs media.extractor; Jolla disables mediaextractor, so getService waits ~5 s at start and at stop. Re-enabling mediaextractor (Part A) removes it.

Result

All four cameras + hardware video on the Xperia 10 V, using only files extracted from your own stock firmware.

Download the toolkit

Everything above — the stock-module patch script, the dtbo patch tools (+ a GPL dtbo image), the ARM32 Codec2 shim (source + binary), the codec2/extractor scripts, and a FIRMWARE-FILES.md listing exactly what to pull from your own firmware is packaged here (GPL-3.0, no Sony files):

You supply the stock camera modules / tuning / OTP / sensor libs / Codec2 files by extracting them from your own XQ-DC54 68.2.A.3.123 (super.sin); the scripts sha256-verify them. Please don’t repost Sony blobs - - extract them from your own firmware.

Credits: @balta’s camera guide and tweaks repo for the original enablement route; the Sony Open Devices and Sailfish OS communities.

yusssufff · 29 October 2026 06:47

Thank you for your work!
I added your work’s link to the next community meeting, in case @jolla and @mal can give some feedback (but maybe we are a little to close to the meeting day for that)

qiankai · 5 November 2026 07:36

I followed your tutorial, and the camera functionality is now working; however, there is an issue with the hardware decoding information. The error details are provided below.

\[root@Xperia10V defaultuser\]# gst-launch-1.0 -v filesrc location=/home/defaultuser/Videos/test.mp4 ! qtdemux ! h264parse ! droidvdec ! videoconvert ! fakesin
k sync=false
library “libandroidicu.so” needed or dlopened by “/system/lib64/libmedia.so” is not accessible for the namespace “(default)”
Setting pipeline to PAUSED …
Pipeline is PREROLLING …
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)5.1, profile=(string)high, codec_data=(buffer)01640033ffe1002327640033ac131a58360f79fffc0a0009fda808080a000003000200000300781e2c490b01000528ee0572c0fdf8f800, width=(int)852, height=(int)480, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)640/639, colorimetry=(string)bt709
Redistribute latency…
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)5.1, profile=(string)high, codec_data=(buffer)01640033ffe1002327640033ac131a58360f79fffc0a0009fda808080a000003000200000300781e2c490b01000528ee0572c0fdf8f800, width=(int)852, height=(int)480, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)640/639, colorimetry=(string)bt709, coded-picture-structure=(string)frame, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, lcevc=(boolean)false
ERROR: from element /GstPipeline:pipeline0/GstDroidVDec:droidvdec0: Could not initialize supporting library.
Additional debug info:
../gst/droidcodec/gstdroidvdec.c(357): gst_droidvdec_create_codec (): /GstPipeline:pipeline0/GstDroidVDec:droidvdec0:
Failed to start the decoder
ERROR: pipeline doesn’t want to preroll.
Setting pipeline to NULL …
Freeing pipeline …

Raymaen · 5 November 2026 08:54

That ist really awsome, you guys rock!! I hope there will be soon a solution, that is less complicated to get running for (lets call them) “noobs” or people that are not too deep into coding… like me…

qiankai · 5 November 2026 09:43

Extracting the official firmware is a bit of a hassle, but everything else is very convenient—you just run the scripts directly.

parth007 · 5 November 2026 13:52

gst-launch-1.0 -v filesrc location=test.mp4 ! qtdemux ! h264parse ! droidvdec ! fakesink sync=false

grep -il "avc" /vendor/etc/media_codecs*.xml

ps -A | grep -i c2

journalctl -b --no-pager | grep -iE "codec2|droidmedia|MediaCodec" | tail -40

Thanks for testing. The camera and recording fix covers encode only. I haven’t verified hardware decode yet, so this is useful. The icu line is probably just linker noise. The real error is that droidvdec can’t create the decoder, which probably means the Codec2 service has no working AVC decoder. Could you try it as defaultuser instead of root and send the output of the commands above? I’ll try to reproduce it on mine.

qiankai · 5 November 2026 17:23

(post deleted by author)

qiankai · 5 November 2026 17:27

thanks, i’ll send the results tomorrow when i’m free.