patches/6.19: cameras: add dw9719 i2c_device_id table fix - #2123

I didn't create an issue for it, but I see the same behaviour on my Surface Book 1, and have confirmed the front camera is re-enabled with this patch and correctly shows an image. (The rear camera is detected after applying this patch, but shows only a green screen if selected in the fedora f44 gnome camera app).

Thanks for testing on Surface Book 1! Great to see the fix working for the front camera.

The green screen on the rear camera is likely a separate issue.

Tested this patch on a Surface Book 2 (13") — kernel 6.19.8-arch1-3-surface, libcamera v0.7.1 — and it resolves the camera regression. ✅

Method: applied just the dw9719 hunk from this PR on top of the stock v6.19 drivers/media/i2c/dw9719.c, built it as an out-of-tree/DKMS module against the running kernel's headers (gcc 16.1.1, matching the kernel), and swapped it in.

Before (stock dw9719, OF-match only):

• VCM i2c-INT347A:00-VCM (software_node dw9719-0) unbound; forced bind → -ENODEV.
• ov8865 lens sub-notifier loops need …CAMR, trying dw9719-0 → direct match not found; cio2_notifier_complete() never fires.
• 0 sensor→CSI-2 links; cam --list empty.

After (patched dw9719 with the i2c_device_id table):

dw9719 i2c-INT347A:00-VCM: ... probed
# /sys/bus/i2c/devices/i2c-INT347A:00-VCM/driver -> .../drivers/dw9719
# media graph: entity 43: dw9719 3-000c  type V4L2 subdev subtype Lens
# sensor->csi2 link count: 3

$ cam --list
Available cameras:
1: Internal back camera  (\_SB_.PCI0.I2C3.CAMR)   # OV8865
2: Internal front camera (\_SB_.PCI0.I2C2.CAMF)   # OV5693

The i2c_device_id table lets the IPU-bridge-instantiated VCM bind by name, which satisfies ov8865's lens sub-notifier and unblocks the hierarchical cio2 notifier — front and rear cameras now enumerate. Confirms the fix works beyond the Surface Pro 6 in #2101; adding Surface Book 2 13" to the verified-devices list. (IR OV7251 is linked in the media graph but not exposed as a regular camera, as expected.)

Hey I'm newish ( brand new ) to patching. Do I just download the repo and build? or do I have to clone the repo and apply the patches?
Also, just checking the pathes are applied to the repo kernal?
Ta

Hi @fbd-ss — welcome, happy to help! 👋

Quick clarification first: this repo doesn't contain the kernel source itself, only the patches that linux-surface applies on top of the mainline kernel (the actual source lives in linux-surface/kernel). The files under patches/6.19/ are applied to that kernel at build time — this PR just adds a hunk to patches/6.19/0013-cameras.patch. So you don't download this repo and "build" it; it's a patch set, not a buildable kernel, and the patches are applied to the kernel source for you as part of the compile process — not by hand.

Because this PR isn't merged yet, the prebuilt linux-surface kernel packages don't include it, so updating packages won't get you the fix just yet. A few options, easiest first:

1. Wait for it to merge. Once a maintainer merges this and it ships in the package repo, a normal linux-surface kernel update will include it — no building required. Lowest effort.

2. Build just the one driver (no full kernel rebuild). The fix only touches a single file (drivers/media/i2c/dw9719.c), so you don't have to recompile the whole kernel — you can build just that module against your running kernel's headers and load it (I used DKMS for this on a Surface Book 2). Much faster than a full build, but it does involve a few manual steps.

3. Full kernel build. Follow the wiki guide: Compiling the Kernel from Source. Clone linux-surface/kernel, make sure this PR's change to 0013-cameras.patch is in the patch set, then build & install per the wiki.

If you just want working cameras with the least hassle, go with option 1 (or the official packages once it lands). If you want it now and are comfortable with a few terminal commands, tell me which distro you're on and I'll write up the DKMS steps for option 2.

@toor11 Thanks for the reply, appreciate it. I wouldn't mind trying option 2 if its not too much hassle. I'm comfortable with the terminal, but have never patched anything yet.

Glad to help with option 2 — it's not bad at all. The fix lives in one file (drivers/media/i2c/dw9719.c), so we build just that module with DKMS instead of the whole kernel.

First, one quick check — this only works if you're already running the linux-surface kernel:

uname -r

You should see -surface in there (e.g. 6.19.x-...-surface). If you don't, you're on the stock distro kernel and the cameras won't enumerate even with this module — the rest of the Surface camera bridge isn't present. Sort that first (linux-surface install guide), then come back here. Also tell me the full uname -r so I can make sure the patch matches your kernel.

1. Install DKMS + your kernel's headers + build tools

• Arch: sudo pacman -S dkms base-devel plus the headers matching your kernel (linux-surface-headers)
• Debian/Ubuntu: sudo apt install dkms build-essential plus the matching linux-headers-...-surface
• Fedora: sudo dnf install dkms kernel-devel make gcc (matching your surface kernel)

2. Create the DKMS source dir /usr/src/dw9719-surface-1.0/ with three files:

Makefile:

obj-m := dw9719.o
KDIR ?= /lib/modules/$(shell uname -r)/build
PWD  := $(shell pwd)
all:
	$(MAKE) -C $(KDIR) M=$(PWD) modules
clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean

dkms.conf:

PACKAGE_NAME="dw9719-surface"
PACKAGE_VERSION="1.0"
BUILT_MODULE_NAME[0]="dw9719"
DEST_MODULE_LOCATION[0]="/updates"
AUTOINSTALL="yes"
MAKE[0]="make KDIR=/lib/modules/${kernelver}/build"
CLEAN="make clean KDIR=/lib/modules/${kernelver}/build"

dw9719.c: take the file from your kernel's source and add the two pieces from this PR — (a) right after MODULE_DEVICE_TABLE(of, dw9719_of_table);:

static const struct i2c_device_id dw9719_id_table[] = {
	{ .name = "dw9718s", .driver_data = (kernel_ulong_t)DW9718S },
	{ .name = "dw9719",  .driver_data = (kernel_ulong_t)DW9719  },
	{ .name = "dw9761",  .driver_data = (kernel_ulong_t)DW9761  },
	{ .name = "dw9800k", .driver_data = (kernel_ulong_t)DW9800K },
	{ }
};
MODULE_DEVICE_TABLE(i2c, dw9719_id_table);

and (b) add .id_table = dw9719_id_table, inside the dw9719_i2c_driver struct (next to .probe / .remove).

3. Build & install

sudo dkms add -m dw9719-surface -v 1.0
sudo dkms build -m dw9719-surface -v 1.0
sudo dkms install -m dw9719-surface -v 1.0 --force
dkms status        # should show: dw9719-surface/1.0, ...: installed

4. Reboot. On boot the patched module loads, the VCM binds, and both cameras enumerate. Verify with:

modinfo dw9719 | grep i2c:dw9719     # the alias that proves the fix is in
cam --list                            # should list front + back cameras

Because it's a DKMS module it'll auto-rebuild on future kernel updates, and it becomes redundant (harmless) once this PR merges. Shout if any step errors out — paste the output and I'll sort it.

I didn't create an issue for it, but I see the same behaviour on my Surface Book 1, and have confirmed the front camera is re-enabled with this patch and correctly shows an image. (The rear camera is detected after applying this patch, but shows only a green screen if selected in the fedora f44 gnome camera app).

Same here on my Surface Pro 5 too.

Status update for maintainers. Since this was opened, the one-hunk fix has now been independently confirmed working on four devices:

• Surface Pro 6 — original report (Surface Pro 6 camera not working — ipu_bridge creates no CSI-2 links #2101)
• Surface Book 2 (13") — kernel 6.19.8, libcamera 0.7.1 (above)
• Surface Book 1 — @busywait
• Surface Pro 5 — @YicenLab

In each case the front camera re-enumerates once the dw9719 VCM binds via the added i2c_device_id table. Thanks @busywait and @YicenLab for testing on your own hardware. 🙏

The rear-camera "green screen" a couple of testers mention is a separate, pre-existing IPU3 issue unrelated to this VCM-binding fix — this PR does not touch that path.

The branch still rebases cleanly on current master (GitHub shows it mergeable). @qzed — you reviewed the comparable camera PR #1867; would you mind taking a look when you have a moment? Happy to rebase or split it differently if that would help.

Quick follow-up on the rear-camera green screen several people mentioned in this thread (separate from this PR, which is correct as-is): root cause found and fixed. The ov8865 driver only programs its registers on runtime-PM resume, and the VCM's PM device link (plus wireplumber holding the VCM subdev open) keeps the sensor permanently awake — so the format userspace negotiates never reaches the hardware, CIO2 hits a payload mismatch, and the stream stalls on one bogus frame. Fix submitted to linux-media (https://lore.kernel.org/linux-media/20260609232255.13559-1-eng.juri@gmail.com/) and to the surface kernel as #2169. No change needed to this PR — the VCM fix here is a prerequisite for autofocus and stands on its own.

surface-pro6-camera-report.md

• Device: Microsoft Surface Pro 4
• Kernel: 6.19.8-surface-3 (linux-surface)
• OS: Ubuntu 26.04
• libcamera: v0.7

Applied DKMS fix, got similar results to @kiddconk; front camera working, rear camera green (haven't attempted to fix this separate issue yet)

Ok, I think this is not super-useful, but sharing anyhow. I'm on Surface Pro 6, Ubuntu 24.04. I worked through this issue manually before finding this, and ended up migrating back to the old 6.17.13-surface-2 kernel using this process:

https://gist.github.com/patcon/a80adb97920dc5378b1bd265ba683450

Since finding this issue, rather than applying a patch, I was curious what was the last linux-surface kernel built for debian was, without the regression.

Linux kernel removed tables in 6.19 kernel here (Oct 29, 2025):
torvalds/linux@15faf0f

debian surface-linux migrated 6.18 => 6.19 here (Mar 13, 2026):
177ac06

Last surface-linux debian kernel before Mar 13 was debian-6.18.7-1 (Jan 25, 2026):
https://github.com/linux-surface/linux-surface/releases?page=2#release-debian-6.18.7-1

So basically, in the meantime to this fix landing, if you're looking for a working linux-surface kernel pre-regression, look for a release before Mar, for your flavour.

Thank you so much

Status update for maintainers. Since this was opened, the one-hunk fix has now been independently confirmed working on four devices:

* **Surface Pro 6** — original report ([Surface Pro 6 camera not working — ipu_bridge creates no CSI-2 links #2101](https://github.com/linux-surface/linux-surface/issues/2101))

* **Surface Book 2 (13")** — kernel 6.19.8, libcamera 0.7.1 (above)

* **Surface Book 1** — @busywait

* **Surface Pro 5** — @YicenLab

In each case the front camera re-enumerates once the dw9719 VCM binds via the added i2c_device_id table. Thanks @busywait and @YicenLab for testing on your own hardware. 🙏

The rear-camera "green screen" a couple of testers mention is a separate, pre-existing IPU3 issue unrelated to this VCM-binding fix — this PR does not touch that path.

The branch still rebases cleanly on current master (GitHub shows it mergeable). @qzed — you reviewed the comparable camera PR #1867; would you mind taking a look when you have a moment? Happy to rebase or split it differently if that would help.

We can also add Surface Go 2 into that list as that was the device the original fix was tested with. The PR continues to be cleanly mergeable.

Confirmed working on Microsoft Surface Go (1st gen), kernel 6.19.8-surface-3, Linux Mint. THANKS!!

Had the exact same symptom — all three sensors detected by ipu3-cio2 (INT33BE, INT347A, INT347E) but zero sensor→CSI-2 links in the media graph. Spent a long time chasing ACPI SSDT overlays and manual media-ctl linking before finding this PR.

Applied the fix by building just the dw9719 module out-of-tree with DKMS (no full kernel rebuild needed). After reboot:

• modinfo dw9719 | grep alias shows alias: i2c:dw9719 ✅
• media-ctl -d /dev/media0 -p shows sensor→CSI-2 links ✅
• cam --list lists both front and rear cameras ✅
• Capture at 1280x720 ~30fps confirmed ✅
• Cheese works ✅

Adding Surface Go 1st gen to the confirmed devices list. Hope this helps get it merged.

The i2c_device_table that was removed from dw9719 in kernel version 6.19 has been readded upstream starting from kernel 7.1.6. I have tested on Surface Go 1 and 2.

Libcamera now recognises both front and back cameras on both devices.

There is still an issue with the back cameras producing a green image but this is being addressed as a separate issue.

Hopefully this will simplify the updating and release of an updated Linux surface kernel.

kernel 7.1.6. I have tested on Surface Go 1 and 2.

I'm on OpenSUSE Tumbleweed with Surface Go 2 and I can confirm that with 7.1.6 kernel I got something for the first time from cam --list:

nick@SGO2:~> cam --list
[0:01:35.473411444] [5834]  INFO Camera camera_manager.cpp:340 libcamera v0.7.2
[0:01:35.557060470] [5835]  WARN IPAProxy ipa_proxy.cpp:196 Configuration file 'ov8865.yaml' not found for IPA module 'ipu3', falling back to '/usr/share/libcamera/ipa/ipu3/uncalibrated.yaml'
[0:01:35.578872232] [5836]  INFO IPAProxyIPU3Worker ipu3_ipa_proxy_worker.cpp:505 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_ipu3.so with IPC fd = 29
[0:01:35.582289202] [5835]  WARN CameraSensor camera_sensor_legacy.cpp:502 'ov8865 2-0010': No sensor delays found in static properties. Assuming unverified defaults.
[0:01:35.582446260] [5835]  INFO Camera camera_manager.cpp:223 Adding camera '\_SB_.PCI0.LNK0' for pipeline handler ipu3
[0:01:35.582478941] [5835]  INFO IPU3 ipu3.cpp:1140 Registered Camera[0] "\_SB_.PCI0.LNK0" connected to CSI-2 receiver 0
[0:01:35.587692525] [5835]  WARN IPAProxy ipa_proxy.cpp:196 Configuration file 'ov5693.yaml' not found for IPA module 'ipu3', falling back to '/usr/share/libcamera/ipa/ipu3/uncalibrated.yaml'
[0:01:35.612348418] [5837]  INFO IPAProxyIPU3Worker ipu3_ipa_proxy_worker.cpp:505 Starting worker for IPA module /usr/lib64/libcamera/ipa/ipa_ipu3.so with IPC fd = 34
[0:01:35.616210089] [5835]  WARN CameraSensor camera_sensor_legacy.cpp:502 'ov5693 4-0036': No sensor delays found in static properties. Assuming unverified defaults.
[0:01:35.616441695] [5835]  INFO Camera camera_manager.cpp:223 Adding camera '\_SB_.PCI0.LNK1' for pipeline handler ipu3
[0:01:35.616503473] [5835]  INFO IPU3 ipu3.cpp:1140 Registered Camera[1] "\_SB_.PCI0.LNK1" connected to CSI-2 receiver 1
Available cameras:
1: Internal back camera (\_SB_.PCI0.LNK0)
2: Internal front camera (\_SB_.PCI0.LNK1)