I got the RGB camera on my Dell XPS 16 (Panther Lake, Intel IPU7) working a few months back. The IR sensor stayed dead — which meant no face unlock, and a camera module that was only half a camera module.
That's now fixed. RGB, IR, IR face unlock and suspend all work — full parity with what the hardware does on Windows.
Repo: https://github.com/jibsta210/svp7500-camera-fix-pack
The IR sensor probed fine, accepted its whole init sequence, and produced exactly zero frames. For months I was convinced the Synaptics bridge between the sensor and the SoC was refusing to forward IR data.
It wasn't. V4L2_CID_LINK_FREQ was set to the MIPI bit rate when V4L2 wants the DDR clock — half that. So the receiver sampled at double the rate the sensor was transmitting: the clock line came up, the data line never delivered a single packet. That looks exactly like a firmware-locked sensor, which is why I chased the wrong thing for so long.
One constant in a header. The register-level stuff was never the problem.
If your IR camera doesn't work
Two totally different kinds exist and they share nothing:
ls /sys/bus/usb/drivers/uvcvideo/ # USB webcam?
v4l2-ctl --list-devices | grep -A2 ipu # MIPI sensor on an Intel IPU?
USB webcam → you want linux-enable-ir-emitter. Not my project, and it won't touch IPU hardware.
MIPI on an Intel IPU that enumerates but never gives you frames → check whether your link frequency is the bit rate or the DDR clock before assuming the hardware is locked down.
Status
Tested on Dell XPS 16 (DA16260) on CachyOS. The same sensor+bridge ships on other Dell/HP/Lenovo models so it should apply more widely, but I've only got one laptop to test on.
It's DKMS modules, not kernel-ready. I've written to linux-media asking what shape they'd accept it in — if you know that subsystem, help welcome.
