Surface Pro 11 (Intel): the infrared camera, face login, and a software-ISP path #2260

Updated 2026-10-08. The Howdy reader at the end is new. With the infrared
driver going upstream, libcamera hands it raw monochrome frames, and the old one
read them as colour: Howdy found a face in none of them. And the rows of an
older frame that show in the infrared picture are an IPU7 bug, with a fix on
linux-media (Kernel, below).

Updated 2026-10-04. Much has moved since 31 August, and this page now
says so:

• the drivers go upstream: imx681 (@AndreGilerson's) is on linux-media at
  v8, and vd55g0 is a separate driver of ours, in review with ST before it
  goes to the list;
• several of the bridge and ov13858 patches are accepted, and Surface Pro 11 (Intel, Lunar Lake) — status, and how to live with it today #2268 keeps
  the current list;
• the illuminator's limit is measured now (Known gaps);
• the rear camera's colour matrix is no longer published here. It was Intel's
  data, and these files now carry only what was measured.

This is a companion to @AndreGilerson's #1990, not a replacement for it. Read
that first: it carries the imx681 and vd55g0 drivers, and a full IPU7
hardware-ISP setup for the two colour cameras -- ipu7-camera-hal.patch with
imx681-uf.json, ov13858-uf.json and both gcss binaries, bridged into
v4l2loopback so ordinary applications just work. If you want the best picture
out of the front and rear cameras, that is the route.

What is here is the part that route does not cover, plus an alternative for the
part it does:

• The infrared camera and its illuminator. surface-camera-bridge.sh takes
  imx681-uf or ov13858-uf and exits on anything else; there is no vd55g0 in
  it. GPIO 1 drives the emitter on this machine. For Patch enabling speakers, mic, camera, suspend and hibernate, and touchpad configuration for surface pro 11 intel. #1990's driver the patch
  is in Patch enabling speakers, mic, camera, suspend and hibernate, and touchpad configuration for surface pro 11 intel. #1990's comments; for the driver going upstream, see the illuminator
  under Kernel below.
• Face login, through Howdy, which nothing else on this machine provides.
• A software-ISP path for the colour cameras, which is a different trade
  rather than a better one: drivers on their way to mainline, against a real
  ISP with Intel's own tuning that has to be rebuilt after kernel updates. If
  you would rather not carry an out-of-tree stack, this works.
• Two driver bugs that are wrong for everyone, whichever path you take.

Tested on Ubuntu 26.04 with kernel 7.0.0-30-generic and libcamera 0.7.0, in
August; the infrared driver since on 7.3-rc kernels.

The hardware

All three hang off the IPU7's input system. The IPU7's processing system --
the hardware ISP -- is not supported by mainline, so libcamera's software ISP
does the work through the simple pipeline handler.

Kernel

The imx681 driver is @AndreGilerson's, and it is on linux-media now, at v8,
with his review folded in. The vd55g0 driver going upstream is a separate
one, in review with ST before it goes to the list. #1990 carries both in
their out-of-tree form. What follows is what we added around them; the current
state of each patch, with links, is in #2268.

ov13858: power the sensor before talking to it. The driver assumes the
rails and clock are already on when probe() reads the chip ID. That holds where
ACPI power resources do it, and not where an INT3472 companion registers them as
regulators, a clock and a reset GPIO for the sensor driver to consume. Without
this the rear camera does not probe at all.
On linux-media, v3, [email protected], not merged yet.

ov13858: cap analogue gain at 15.5x. V4L2_CID_ANALOGUE_GAIN is
advertised as 0..0x1fff and is honest to 0x7ff. At 0x800 the gain halves, and
above that it wanders: 0x1000 behaves as 0x400 did, 0x1fff as 0x7ff. An
autoexposure loop that raises its request and gets back less signal cannot
converge. The cap goes to 0x07c0 rather than 0x7ff, because that is what
ov13b10 and ov08x40 use, it works out as 15.5x -- the usual ceiling for these
parts -- and it measures as the actual peak: 14.23x against 0x7ff's 13.71x.
On linux-media, v2: https://patch.msgid.link/[email protected].

vd55g0: drive the infrared illuminator on ACPI platforms. Which of the
sensor's four GPIOs drives the illuminator comes from the st,leds property,
which ACPI does not provide. For #1990's driver, a DMI match in the driver
supplies it -- GPIO 1 on this machine -- in a patch in #1990's comments; note
that the assignment must go in the ACPI branch of probe, because
vd55g0_parse_dt_gpios_array() is guarded by dev->of_node.
For the driver going upstream, ST and the media maintainers agreed on another
place: ipu-bridge supplies st,leds from a DMI match, and the driver needs no
change. That patch follows the driver; a test version has been run here.

ipu-bridge: sensor entries. ov13858 and the rear sensor's 180-degree
rotation quirk are accepted, in media/next. The imx681 entry goes with that
driver's series; the vd55g0 one will follow its driver. The rear camera also
needed flip controls in ov13858 before libcamera could turn its picture
upright; those are accepted too.

int3472: support the POWER1 GPIO type. Needed for the rear camera's rails.
Jakob Berg Jespersen's patch for this landed instead, in media/next.

staging/ipu7: snoop the input system's writes. The staging IPU7 driver has
the input system write capture buffers without snooping the CPU's cache, and on
x86 nothing invalidates the cache before a buffer is read. So a program that
reads frames with the CPU, Howdy among them, can get rows of an older frame
wherever the scene moved. On the infrared camera here that was 301 frames of
698 at 644x604, and none with snooping on. The rear camera at full size shows
none either way: its 26 MB buffers do not survive in the cache. The ipu6
driver's IPU7 support, which is to take over from this one, leaves snooping off
too; that is untested here.
On linux-media, sent 2026-10-07: https://patch.msgid.link/[email protected].

libcamera

A sensor helper for the imx681. Without one libcamera takes the raw V4L2
gain code for the gain itself: the AGC reads an analogue gain of 1020, decides
the sensor is enormously over-amplified, and holds the exposure down. Mean luma
23.8 against 110.7 with the helper. Twelve lines:

class CameraSensorHelperImx681 : public CameraSensorHelper
{
public:
	CameraSensorHelperImx681()
	{
		/* Measured on the sensor: 64 at 10bits. */
		blackLevel_ = 4096;
		gain_ = AnalogueGainLinear{ 0, 1024, -1, 1024 };
	}
};
REGISTER_CAMERA_SENSOR_HELPER("imx681", CameraSensorHelperImx681)

Sent to libcamera-devel as [email protected], and held at
our request until the kernel driver lands: a helper should not come ahead of
its driver. Until it is in a release, rebuild the packaged version rather than
installing a self-built library over it:

Ubuntu 26.04 ships libcamera 0.7.0-1ubuntu2, which has no CameraSensorHelper
for the Sony IMX681. Without one the software AGC reads the raw V4L2 gain code
as a gain multiplier and holds the exposure down.

This is a twelve-line addition. Rather than install a self-built libcamera over
the packaged one, rebuild the same version with the patch applied, which is
what a distribution backport does and what an archive update will cleanly
replace.

mkdir -p ~/libcamera-deb && cd ~/libcamera-deb
apt-get source libcamera
cd libcamera-0.7.0
cp ~/sp11-imx681-sensor-helper.patch debian/patches/   # the patch from the list
echo sp11-imx681-sensor-helper.patch >> debian/patches/series
sudo apt-get build-dep -y libcamera
dpkg-buildpackage -us -uc -b -j4
cd .. && sudo dpkg -i libcamera0.7_*.deb libcamera-ipa_*.deb libcamera-tools_*.deb \
                      python3-libcamera_*.deb libcamera-v4l2_*.deb gstreamer1.0-libcamera_*.deb

Verifying the rebuild took

The sensor helpers compile into libipa, which is linked into the IPA modules,
not into libcamera.so. So check:

strings /usr/lib/x86_64-linux-gnu/libcamera/ipa/ipa_soft_simple.so | grep -c '^imx681$'

Note the ipa/ directory in that path. Checking
/usr/lib/x86_64-linux-gnu/libcamera/ipa_soft_simple.so finds nothing, because
nothing is there -- and an empty result from a non-existent file reads exactly
like a missing patch.

The list of sensor names in libcamera.so itself is a different database, the
static sensor properties, and will not contain the helper.

The visible confirmation is that this warning stops appearing:

IPASoft: Failed to create camera sensor helper for imx681

vd55g0 still warns with #1990's driver, and that is expected -- there is no
helper for it, and its tuning omits Agc so libcamera never asks.

What the rebuild changes, honestly

The warning goes and the AGC's gain model becomes correct. The picture was
already usable: on a night scene with lamps in frame it measures 21-24 % clipped,
which sounds alarming and is a white ceiling under three lamps rendered as
white. Judge this camera by the frame, not the percentage.

A mild green cast remains on neutral surfaces, spread about 11. That is the
absence of a colour matrix, which was removed deliberately: this sensor's
subject is usually backlit, and a matrix turns clipped regions magenta until the
software ISP learns to desaturate highlights.

Tuning files. These go in /usr/share/libcamera/ipa/simple/.

Neither colour file carries a colour matrix. The matrices that worked here are
Intel's own tuning for these exact modules, read out of the .aiqb files beside
the Windows driver, and these files carry only what was measured on this
machine. Earlier versions of the rear camera's file carried them, corrected for
libcamera's white balance; it no longer does, and without them its colour is
flatter.

These files are written for libcamera 0.7.0. The software ISP changes
underneath: a colour matrix that gave a neutral-grey spread of 1.06 on 0.7.0
gave 13.9 on master. If you move to a newer libcamera, re-measure rather than
carrying these across.

For the front camera there is a second reason. Intel's matrices for it work,
and cannot survive a clipped frame: on a portrait against a window, 29 % of the
frame clipped turns 22 % of it magenta. A front camera's subject is usually
backlit, so that is the normal case rather than the edge case.

The infrared tuning omits Agc entirely, so libcamera leaves exposure and gain
where they are set. Face authentication cannot use a camera whose exposure
depends on what the previous capture left behind. That applies with #1990's
driver. With the driver going upstream libcamera passes the infrared frames
through unprocessed, and the file does not apply.

Face login

Howdy is not packaged for Ubuntu; build from source. It needs libinih-dev and
libevdev-dev, which nothing pulls in, and dlib compiled from pip.

Howdy reads a camera with cv2.VideoCapture and a /dev/videoN path, and
neither half works here:

• OpenCV cannot read the IPU7 capture node. It opens and returns no frames,
  whatever format is requested.
• libcamera's V4L2 shim cannot select which camera a node means. It matches
  the node against each camera's SystemDevices, and all three cameras here
  claim all 32 nodes. The first always wins, and it is not the infrared one.

The way through is Howdy's own plugin seam. The reader at the end of this post
is built on the libcamera Python bindings, selected with
recording_plugin = libcamera and device_path = CAM3 -- a camera id substring
rather than a path. It also drives the illuminator, on at start and off in
release(), so a crash cannot leave the emitter lit.

It reads whichever format libcamera gives it: XRGB8888 with #1990's driver,
which reports the sensor under Bayer codes, or raw R8 with the driver going
upstream, since libcamera 0.7 has no software ISP for a monochrome sensor. It
reads R10 too, untested. It checks which format it got, because validate()
replaces one without saying so, and for a raw format it asks for the full
644x604: at the default 320x240, which is binned, the IPU7 reports a packet too
long on nearly every frame.

Set the sensor exposure in /etc/howdy/config.ini, in lines; 700 worked here,
and the reader uses 400 if it is unset. Keep it under about 70 % of the frame --
1200 lines with the default frame of the driver going upstream -- where the
illuminator stays lit. Enrol several
models at varied poses: one model passed at certainty 3.4 against a 3.5
threshold, which is not a login, and four take it to 2.7. A different person
measures 6.5 and is refused.

PAM goes in gdm-password, which serves both the login screen and GNOME's lock
screen, as sufficient so a failure falls through to the password:

auth    sufficient      pam_howdy.so

Note /etc/pam.d/sudo may be pointless on your machine: if your user has
NOPASSWD in sudoers, sudo never consults PAM for authentication at all.

An open question: can the two paths coexist?

I do not know, and it matters to anyone who wants both good colour pictures and
face login on the same machine.

The infrared path here goes through the mainline intel_ipu7_isys and
libcamera's simple pipeline handler. intel/ipu7-drivers builds
CONFIG_VIDEO_INTEL_IPU7=m, the same module, so installing it replaces the
in-tree one. vd55g0 is not among the sensor drivers it carries, so whether the
infrared camera still enumerates afterwards depends on whether the out-of-tree
input system presents an equivalent media graph. Plausible; untested here.
Upstream, the ipu6 driver is taking over the IPU7, so on newer kernels the
in-tree module is no longer intel_ipu7_isys.

The 50-disable-ipu7-isys.conf in #1990 is not the obstacle -- it is a PipeWire
rule that hides raw ISYS nodes from the device list, and the kernel module stays
loaded. I assumed otherwise at first and was wrong.

If someone has run both, that answer is worth more than the rest of this page.

Related work on IPU6

@dmanresa-saes' #2253 covers the Surface Pro 7+ on IPU6 and reaches the hardware
ISP with Microsoft's own .aiqb calibration. Two things there are directly
relevant here even though the platform differs.

It reports the same thing about the infrared camera, found independently: the
"all black" frame is an unlit illuminator hanging off the sensor's strobe pads,
with nothing in ACPI describing it. Our DMI table naming GPIO 1 is one machine's
instance of that.

It also carries a decoder for the CPFF/.aiqb container, and a detail we did
not have: mainline ISYS delivers RAW10 LSB-aligned while the vendor tuning
assumes Windows' 12-bit alignment. If that holds on IPU7 as well, it would
explain the pre-scale the rear camera's matrices needed here, and it is worth
checking before anyone uses Intel's matrices on this machine.

Known gaps

The illuminator has a duty limit. In August it lit about seven sessions in
ten here, cause unknown. Measured since: it holds while the exposure stays
under about 70 % of the frame, fades just above that, and goes out at 72-75 %;
the board's LED driver, by the look of it. The sensor's own auto exposure goes
past that in the dark, so face login needs a fixed exposure below the limit,
which the Howdy reader sets. The sensor can also cap its own exposure
(MAX_EXPOSURE_LINES); where that limit should come from is a question for ST.

No highlight rolloff in the software ISP. Once a channel pins at maximum the
ratios between channels are false, and a linear colour matrix faithfully
amplifies the falsehood. This is what keeps the front camera's matrix switched
off. Adding rolloff would fix it for every sensor on the simple pipeline.

The infrared camera shares the front camera's name in camera applications.
The name comes from the camera's Location property, built from
V4L2_CID_CAMERA_ORIENTATION. #1990's driver never creates that control, so
there the camera falls through to the sensor model. The driver going upstream
reads the orientation from the firmware, as a sensor driver should, so the
camera is listed as "Internal front camera" -- the same as the colour one,
since both genuinely face front. The naming logic lives in the applications,
not the library: cameraName() in src/apps/cam/main.cpp, duplicated in qcam
and again in PipeWire's libcamera plugin, which is what reaches a desktop
Camera application. Telling the two apart was put to libcamera-devel as an RFC,
[email protected], and narrowed there to appending the
model when two cameras share a location.

The rear camera lands about 24 % darker than Windows on the same scene
minutes apart. Its AGC pins at both ceilings -- 33.3 ms and the sensor's real
14x -- while Windows exposes the same scene at 30 ms and ISO 200. Windows lifts
midtones through a tone curve; libcamera multiplies linearly under a fixed gamma.

Things that cost time here

• /dev/v4l-subdevN is not an identity. The number is assigned in probe order
  and moves when the set of devices or their properties changes. Look the sensor
  up under /sys/class/video4linux/v4l-subdev*/name.
• systemctl reboot over SSH is silently blocked by GNOME's session inhibitor.
  Use reboot -i, and check uptime -s rather than whether SSH answers.
• The first capture after boot is the AGC ramp, not the camera's behaviour.
• The sensor helpers live in libcamera/ipa/ipa_soft_simple.so. Checking
  libcamera/ipa_soft_simple.so finds nothing, and nothing from a file that does
  not exist reads exactly like a missing patch.

The tuning files

ov13858.yaml

# SPDX-License-Identifier: CC0-1.0
#
# libcamera simple-IPA tuning for the Omnivision OV13858 on the Microsoft
# Surface Pro 11 for Business (Intel).
#
# blackLevel MEASURED: mean 64.21, median 64 across all four Bayer channels.
#
# No Ccm. The matrices that worked here are Intel's, read out of the Windows
# driver's tuning data, and these files carry only what was measured on this
# machine. Without one the colour is flatter than it could be.
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
      blackLevel: 4096
  - Awb:
  - Adjust:
  - Agc:
...

imx681.yaml

# SPDX-License-Identifier: CC0-1.0
#
# libcamera simple-IPA tuning for the Sony IMX681 on the Microsoft Surface Pro 11
# for Business (Intel).
#
# blackLevel MEASURED: mean 63.54, median 64 -> 64 << 6 = 4096.
#
# NO Ccm, deliberately, and it is not for want of one. Intel's matrices for this
# module were read out of the Windows driver's tuning database and corrected for
# libcamera's white balance; they work. What they cannot survive is a clipped
# frame. Measured on this camera, same scene:
#
#   frame clipped 29 %  ->  22 % of the frame turns magenta
#   frame clipped  1 %  ->  0.1 %
#
# A front camera points at a person who is very often backlit, so the clipped
# case is the normal case, and a magenta window behind the subject is worse than
# flat colour. This sensor also loses least by going without: its uncorrected
# colourfulness is 18.1 against the rear sensor's 10.8.
#
# The matrices are also Intel's data, and these files carry only what was
# measured here.
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
      blackLevel: 4096
  - Awb:
  - Adjust:
  - Agc:
...

vd55g0.yaml

# SPDX-License-Identifier: CC0-1.0
#
# libcamera simple-IPA tuning for the ST VD55G0 infrared sensor on the
# Microsoft Surface Pro 11 for Business (Intel).
#
# No Agc, deliberately. This sensor exists to light a face with an infrared
# illuminator for a moment and hand back one frame. Automatic exposure has to
# ramp before it settles, and every capture starts that ramp again, so the
# brightness of the first second depends on where the previous run left the
# controls. Face authentication cannot use a camera whose exposure depends on
# what happened last time.
#
# With Agc absent the IPA leaves V4L2_CID_EXPOSURE and V4L2_CID_ANALOGUE_GAIN
# alone, so whatever is set before streaming stays set, and every frame is the
# same. Set them with v4l2-ctl.
#
# blackLevel MEASURED: median and mode both exactly 64 at 10 bits -> 4096.
%YAML 1.1
---
version: 1
algorithms:
  - BlackLevel:
      blackLevel: 4096
...

The Howdy reader

It is also in #2267. Save it as recorders/libcamera_reader.py beside Howdy's
other recorders, and
add the libcamera branch to _create_reader() in video_capture.py.

# Reader plugin for Howdy backed by libcamera.
#
# Howdy's other readers open a /dev/video node. On the Intel IPU7 that does not
# work for this machine's infrared camera: OpenCV cannot read the raw capture
# node at all, and libcamera's V4L2 shim cannot select which camera a node maps
# to, because all three cameras claim all 32 nodes. See NOTES.md.
#
# device_path in the config is used as a substring match against libcamera
# camera ids rather than as a filesystem path.

import configparser
import mmap
import os
import subprocess
import sys
import time

import cv2
import numpy as np

import libcamera as lc

V4L2_CTL = "/usr/bin/v4l2-ctl"

# Formats this reader can turn into a frame, in order of preference.
# XRGB8888 is what libcamera's software ISP makes from a Bayer sensor. A
# driver that reports the infrared sensor as what it is, Y8 or Y10, gets no
# ISP in libcamera 0.7, which debayers Bayer input only: the camera then
# offers just its raw R8, R10 and R10_CSI2P. R8 is all Howdy needs.
READABLE = ("XRGB8888", "R8", "R10")


class libcamera_reader:
	"""Looks like the parts of cv2.VideoCapture that Howdy uses."""

	def __init__(self, device_name, device_format=None):
		self.camera_hint = os.path.basename(device_name.rstrip("/"))

		# Sensor settings come from Howdy's own config so they survive being
		# run from PAM, where the environment is not ours. The environment
		# still wins if set, which makes tuning by hand easy.
		cfg = configparser.ConfigParser()
		cfg.read("/etc/howdy/config.ini")

		def opt(env, section, key, default):
			val = os.environ.get(env)
			if val:
				return val
			try:
				v = cfg.get(section, key)
				if v and v != "-1":
					return v
			except Exception:
				pass
			return default

		self.subdev = opt("HOWDY_IR_SUBDEV", "video", "ir_subdev", "") or self._find_subdev()
		self.exposure = opt("HOWDY_IR_EXPOSURE", "video", "exposure", "400")
		self.gain = opt("HOWDY_IR_GAIN", "video", "ir_gain", "24")

		self.cm = lc.CameraManager.singleton()
		match = [c for c in self.cm.cameras if self.camera_hint in c.id]
		if not match:
			raise RuntimeError(
				"no libcamera camera matching %r; available: %s"
				% (self.camera_hint, [c.id for c in self.cm.cameras])
			)
		self.camera = match[0]
		self.camera.acquire()

		# Ask for a format this reader can read, and check that it was kept:
		# validate() swaps a format the camera does not offer for one it
		# does, without a word, and reading that as XRGB8888 gives Howdy a
		# frame a quarter of the true width.
		cfg = self.camera.generate_configuration([lc.StreamRole.Viewfinder])
		offered = [str(f) for f in cfg.at(0).formats.pixel_formats]
		self.format = next((f for f in READABLE if f in offered), None)
		if self.format is None:
			raise RuntimeError("no format this reader can read; the camera offers %s"
					   % offered)
		cfg.at(0).pixel_format = lc.PixelFormat(self.format)
		if self.format != "XRGB8888":
			# A raw format comes in the sensor's own sizes, and the default
			# is the smallest, a binned 320x240. Take the native frame:
			# Howdy scales to its max_height itself.
			cfg.at(0).size = cfg.at(0).formats.range(lc.PixelFormat(self.format)).max
		if (cfg.validate() == lc.CameraConfiguration.Status.Invalid
				or str(cfg.at(0).pixel_format) != self.format):
			raise RuntimeError("libcamera did not keep %s, it gave %s"
					   % (self.format, cfg.at(0).pixel_format))
		self.scfg = cfg.at(0)
		self.camera.configure(cfg)
		self.stream = self.scfg.stream
		self.width = self.scfg.size.width
		self.height = self.scfg.size.height
		self.stride = self.scfg.stride

		self.allocator = lc.FrameBufferAllocator(self.camera)
		self.allocator.allocate(self.stream)
		self.buffers = self.allocator.buffers(self.stream)
		self.maps = {}
		self.requests = []
		for i, buf in enumerate(self.buffers):
			plane = buf.planes[0]
			self.maps[i] = mmap.mmap(
				plane.fd, plane.offset + plane.length,
				mmap.MAP_SHARED, mmap.PROT_READ
			)
			req = self.camera.create_request(i)
			req.add_buffer(self.stream, buf)
			self.requests.append(req)

		self._sensor("exposure=%s" % self.exposure, "analogue_gain=%s" % self.gain,
			     "auto_exposure=1", "led_mode=1")

		self.camera.start()
		for req in self.requests:
			self.camera.queue_request(req)
		self.started = True

	@staticmethod
	def _find_subdev(name="vd55g0"):
		"""Locate the sensor's v4l2 subdev by name.

		The numbering is not stable: it moves when the set of cameras or
		their properties changes, and a hardcoded path then silently
		addresses a different sensor. Ask the kernel instead.
		"""
		import glob
		for path in sorted(glob.glob("/sys/class/video4linux/v4l-subdev*")):
			try:
				with open(os.path.join(path, "name")) as fh:
					if fh.read().strip().startswith(name):
						return "/dev/" + os.path.basename(path)
			except OSError:
				continue
		return ""

	def _sensor(self, *ctrls):
		"""Set sensor controls. Best effort: a failure here is not fatal."""
		if not self.subdev or not os.path.exists(V4L2_CTL):
			return
		try:
			subprocess.run(
				[V4L2_CTL, "-d", self.subdev, "--set-ctrl", ",".join(ctrls)],
				stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL,
				timeout=5, check=False
			)
		except Exception:
			pass

	def set(self, prop, setting):
		"""Accepted and ignored: libcamera decides format and size."""
		return True

	def get(self, prop):
		"""Answer the frame geometry honestly.

		compare.py computes its scaling factor as max_height / get(HEIGHT),
		so a reader that returns 0 here makes the factor enormous and the
		first resize asks for a hundred gigabytes.
		"""
		if prop == cv2.CAP_PROP_FRAME_WIDTH:
			return float(self.width)
		if prop == cv2.CAP_PROP_FRAME_HEIGHT:
			return float(self.height)
		if prop == cv2.CAP_PROP_FPS:
			return 0.0
		return 0.0

	def probe(self):
		return True

	def record(self):
		return True

	def grab(self):
		ret, _frame = self.read()
		return ret

	def read(self):
		"""Return (ok, frame) with frame as BGR, as Howdy expects."""
		deadline = time.monotonic() + 2.0
		while time.monotonic() < deadline:
			ready = self.cm.get_ready_requests()
			if not ready:
				time.sleep(0.005)
				continue
			frame = None
			for req in ready:
				i = req.cookie
				raw = np.frombuffer(
					self.maps[i], dtype=np.uint8,
					count=self.stride * self.height
				)
				if self.format == "XRGB8888":
					# the sensor is monochrome, so any one of the
					# colour bytes carries the image
					mono = raw.reshape(self.height, self.stride // 4, 4)[:, :self.width, 0]
				elif self.format == "R8":
					mono = raw.reshape(self.height, self.stride)[:, :self.width]
				else:
					# R10: ten bits in sixteen, little-endian; the top eight
					mono = (raw.view("<u2").reshape(self.height, self.stride // 2)
						[:, :self.width] >> 2).astype(np.uint8)
				frame = np.dstack([mono, mono, mono])
				req.reuse()
				self.camera.queue_request(req)
			if frame is not None:
				return True, frame
		return False, None

	def release(self):
		"""Tear down in the order libcamera requires, exactly once.

		stop() before anything is freed, then the requests, then the
		mappings, then the allocator, then the camera. Calling
		Camera::release() twice aborts inside PipelineHandler::stop(),
		which is why this is guarded rather than merely idempotent-looking.
		"""
		if getattr(self, "_released", False):
			return
		self._released = True

		if getattr(self, "started", False):
			try:
				self.camera.stop()
			except Exception:
				pass
			self.started = False

		self._sensor("led_mode=0")

		self.requests = []
		for m in getattr(self, "maps", {}).values():
			try:
				m.close()
			except Exception:
				pass
		self.maps = {}
		self.buffers = []
		self.allocator = None

		try:
			self.camera.release()
		except Exception:
			pass

	def __del__(self):
		try:
			self.release()
		except Exception:
			pass