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.