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/[email protected]/) 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)

Confirmed on Surface Pro 6 (IPU3, ov5693 + ov8865 + ov7251), kernel 6.19.8-surface-3, Ubuntu 24.04.

Worth stressing that before this patch no camera worked at all, not just the one with the VCM:

• modinfo dw9719 listed only of: aliases, no i2c:dw9719
• the i2c client created by ipu-bridge was present but unbound — i2c-INT347A:00-VCM, name=dw9719, no driver — while the device itself advertises modalias: i2c:dw9719
• media-ctl -d /dev/media0 -p showed all three sensors with 0 link, and no /dev/v4l-subdev* nodes existed at all
• cam --list was empty

One thing that may save others some time: forcing the bind from userspace does not work as a stopgap.

# echo i2c-INT347A:00-VCM > /sys/bus/i2c/drivers/dw9719/bind
-> ENODEV

Manual sysfs bind still goes through the bus match, and the match is precisely what is missing here.

With the patch applied the VCM binds, v4l2_device_register_subdev_nodes() runs, the links appear, and both front and rear cameras enumerate — so it fixes the front sensor too, which has no VCM of its own.

For anyone testing without rebuilding a whole kernel: dw9719 is a module, so it can be built out-of-tree against linux-headers-surface. With Secure Boot (sig_enforce=Y) it needs signing with an enrolled MOK afterwards. Note that the IPU3 chain does not survive a module reload — ipu_bridge builds the fwnode graph once at load — so reboot after installing rather than trying to hot-swap.

Thanks for tracking this down.

thanks @toor11
but i need some help here

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);:

and

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

Can't find the line MODULE_DEVICE_TABLE(of, dw9719_of_table); in

https://github.com/linux-surface/kernel/blob/v6.18-surface-devel/drivers/media/i2c/dw9719.c

and what do you mean with struct (next to .probe / .remove). ?

at the end of the file it looks like

MODULE_DEVICE_TABLE(i2c, dw9719_id_table);

static DEFINE_RUNTIME_DEV_PM_OPS(dw9719_pm_ops, dw9719_suspend, dw9719_resume,
				 NULL);

static struct i2c_driver dw9719_i2c_driver = {
	.driver = {
		.name = "dw9719",
		.pm = pm_sleep_ptr(&dw9719_pm_ops),
	},
	.probe = dw9719_probe,
	.remove = dw9719_remove,
	.id_table = dw9719_id_table,
};
module_i2c_driver(dw9719_i2c_driver);

MODULE_AUTHOR("Daniel Scally <[email protected]>");
MODULE_DESCRIPTION("DW9719 VCM Driver");
MODULE_LICENSE("GPL");

Where exactly should the patch code be inserted?

thanks for explaining

ok sorry so it has to go into

https://github.com/linux-surface/kernel/blob/v6.19-surface-devel/drivers/media/i2c/dw9719.c

So i inserted the patch code and at the end of the file it looks like this now:

static const struct of_device_id dw9719_of_table[] = {
	{ .compatible = "dongwoon,dw9718s", .data = (const void *)DW9718S },
	{ .compatible = "dongwoon,dw9719", .data = (const void *)DW9719 },
	{ .compatible = "dongwoon,dw9761", .data = (const void *)DW9761 },
	{ .compatible = "dongwoon,dw9800k", .data = (const void *)DW9800K },
	{ }
};
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);

static DEFINE_RUNTIME_DEV_PM_OPS(dw9719_pm_ops, dw9719_suspend, dw9719_resume,
				 NULL);

static struct i2c_driver .id_table = dw9719_id_table = {
	.driver = {
		.name = "dw9719",
		.pm = pm_sleep_ptr(&dw9719_pm_ops),
		.of_match_table = dw9719_of_table,
	},
	.probe = dw9719_probe,
	.remove = dw9719_remove,
};
module_i2c_driver(dw9719_i2c_driver);

MODULE_AUTHOR("Daniel Scally <[email protected]>");
MODULE_DESCRIPTION("DW9719 VCM Driver");
MODULE_LICENSE("GPL");

Does this look right to you?

Thanks for trying it — good instinct, but there are two problems in what you pasted, both in the driver-struct block.

First, this line is not valid C:

static struct i2c_driver .id_table = dw9719_id_table = {

The declaration stays exactly as it already is in the file:

static struct i2c_driver dw9719_i2c_driver = {

and .id_table = dw9719_id_table, is an ordinary member inside that struct — nothing replaces the existing declaration.

Here is the full corrected tail of the file (this matches v6.19-surface-devel exactly):

static const struct of_device_id dw9719_of_table[] = {
	{ .compatible = "dongwoon,dw9718s", .data = (const void *)DW9718S },
	{ .compatible = "dongwoon,dw9719", .data = (const void *)DW9719 },
	{ .compatible = "dongwoon,dw9761", .data = (const void *)DW9761 },
	{ .compatible = "dongwoon,dw9800k", .data = (const void *)DW9800K },
	{ }
};
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);

static DEFINE_RUNTIME_DEV_PM_OPS(dw9719_pm_ops, dw9719_suspend, dw9719_resume,
				 NULL);

static struct i2c_driver dw9719_i2c_driver = {
	.driver = {
		.name = "dw9719",
		.pm = pm_sleep_ptr(&dw9719_pm_ops),
		.of_match_table = dw9719_of_table,
	},
	.probe = dw9719_probe,
	.remove = dw9719_remove,
	.id_table = dw9719_id_table,
};
module_i2c_driver(dw9719_i2c_driver);

MODULE_AUTHOR("Daniel Scally <[email protected]>");
MODULE_DESCRIPTION("DW9719 VCM Driver");
MODULE_LICENSE("GPL");

The two changes versus the current file are:

1. The dw9719_id_table array plus MODULE_DEVICE_TABLE(i2c, …) go right after the existing MODULE_DEVICE_TABLE(of, dw9719_of_table); line.
2. .id_table = dw9719_id_table, goes inside the existing dw9719_i2c_driver struct, after .remove = dw9719_remove,.

Your paste had everything else right — keep module_i2c_driver(dw9719_i2c_driver); as-is. And a heads-up: editing the source file alone doesn't change anything until that module is actually rebuilt and loaded, so you'll still need to rebuild the driver (or the kernel). If the build errors, paste the first error line and I'll take a look.

@toor11 Thanks for teaching me.

Before i try now your patch - is there any thing i can do about the failing rear camera as well?

@toor11 Thanks for teaching me.

Before i try now your patch - is there any thing i can do about the failing rear camera as well?
I have already submitted the patch.
#2169

@toor11

I have already submitted the patch.
#2169

Ohh... thanks. !!!
Can you teach me how to apply this patch as well ?

@rocky-III The patch in #2169 is a kernel patch — you apply it to the kernel source tree, not this repo. Since you're on Arch-based (per earlier comment), easiest path:

1. git clone https://github.com/linux-surface/kernel.git && cd kernel
2. git checkout v6.19-surface-devel (or your kernel branch)
3. curl -L https://github.com/linux-surface/linux-surface/pull/2169.patch | git am
4. Build/install per your distro's kernel build process (e.g., makepkg -si if using the linux-surface AUR package, or make -j$(nproc) && sudo make modules_install install)

If you just want the one file fix without a full kernel rebuild, the change is in drivers/media/i2c/dw9719.c — add the dw9719_i2c_id table back. But the proper fix is the kernel PR #2169 since it includes the device tree binding update too.

@toor11 Thank for explaining

actually I'm on a Debian based system... what does this change in your description ?

@rocky-III The patch in #2169 is a kernel patch — you apply it to the kernel source tree, not this repo. Since you're on Arch-based (per earlier comment), easiest path:

1. `git clone https://github.com/linux-surface/kernel.git && cd kernel`

2. `git checkout v6.19-surface-devel` (or your kernel branch)

3. `curl -L https://github.com/linux-surface/linux-surface/pull/2169.patch | git am`

4. Build/install per your distro's kernel build process (e.g., `makepkg -si` if using the linux-surface AUR package, or `make -j$(nproc) && sudo make modules_install install`)

If you just want the one file fix without a full kernel rebuild, the change is in drivers/media/i2c/dw9719.c — add the dw9719_i2c_id table back. But the proper fix is the kernel PR #2169 since it includes the device tree binding update too.

@toor11
could help once more - i'm on Debian

@rocky-III Sorry, I had that backwards — you're on Debian, not Arch. One important thing to know up front: PR #2169 (the rear-camera ov8865 fix) is still unmerged, so it is not yet in the prebuilt linux-surface Debian packages nor in the surface-devel kernel branch. You have two options:

Option 1 — simplest, no risk (recommended): wait for the merge.
Once #2169 is merged into the surface patches and a new linux-image-surface is published to pkg.surfacelinux.com/debian, you just run sudo apt update && sudo apt upgrade and reboot. Nothing to build, nothing that can go wrong. If you're in no rush, do this.

Option 2 — build from source to get it now.
This is the linux-surface "compile from source" flow applied to a Debian machine (from the official wiki), with the #2169 fix folded in:

# 1. Build dependencies
sudo apt install build-essential binutils-dev libssl-dev bison flex libelf-dev ccache debhelper

# 2. Stock 6.19 kernel source
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
git checkout v6.19
git switch -c v6.19-surface

# 3. Surface patches repo
git clone https://github.com/linux-surface/linux-surface.git ~/linux-surface

# 4. Fold the unmerged ov8865 fix into the camera patch file (this is what #2169 changes)
curl -L https://github.com/linux-surface/linux-surface/pull/2169.patch -o /tmp/2169.patch
patch -p1 < /tmp/2169.patch   # run from ~/linux-surface

# 5. Apply all surface patches to the kernel (now including the ov8865 fix)
cd linux
for i in ~/linux-surface/patches/6.19/*.patch; do patch -p1 < "$i"; done

# 6. Configure from your current running kernel's config
cp /boot/config-$(uname -r) .config
make olddefconfig

# 7. Build the Debian packages (this takes a while)
make -j "$(getconf _NPROCESSORS_ONLN)" deb-pkg LOCALVERSION=-ov8865

# 8. Install
sudo dpkg -i ../linux-headers-*.deb ../linux-image-*.deb ../linux-libc-dev-*.deb

Then sudo update-grub, reboot, and pick the new kernel — uname -r should show -ov8865.

Honestly, for someone who's not already comfortable compiling kernels, Option 1 is the better call — a from-source build with a patch-in-patch is easy to get subtly wrong, and one driver fix isn't worth the risk of a boot problem. If you do go the source route and any step fails, paste the exact error here and I'll walk you through it.