* [PATCH 1/2] media: i2c: ov08x40: Implement the selection API
@ 2026-09-04 13:45 Pierre Pinon
2026-09-14 14:00 ` Oleg Keri
0 siblings, 1 reply; 6+ messages in thread
From: Pierre Pinon @ 2026-09-04 13:45 UTC (permalink / raw)
To: Jason Chen, Jimmy Su, Sakari Ailus, linux-media
Cc: Pierre Pinon, Mauro Carvalho Chehab, Hans de Goede, linux-kernel
ov08x40 implements none of the selection targets: its pad ops carry only
enum_mbus_code, get_fmt, set_fmt and enum_frame_size, and ov08x40_open()
states "No crop or compose" outright.
libcamera requires V4L2_SEL_TGT_CROP_BOUNDS, V4L2_SEL_TGT_CROP_DEFAULT
and V4L2_SEL_TGT_CROP from a sensor driver
(Documentation/sensor_driver_requirements in the libcamera sources), and
warns that support is scheduled to become mandatory. Without them it
falls back to "crop == active area" for every mode:
'ov08x40 18-0036': Failed to retrieve the sensor crop rectangle
'ov08x40 18-0036': The sensor kernel driver needs to be fixed
The practical consequence is worse than a warning. Because the crop
rectangle is what distinguishes a binned mode (full-array crop, reduced
output) from a cropped one (reduced crop, 1:1 output), libcamera cannot
tell that 1928x1208 and 1928x1088 are 2x2 binned views of the whole
array. It therefore never selects them, and satisfies small requests by
centre-cropping the full resolution mode instead. On an IPU7 platform
using the CPU software ISP, that path is unusable: the debayer window
desyncs from the real line stride and every non-native resolution
produces a uniformly saturated image.
The mode register lists program only the low bytes of the vertical
window (0x3803, 0x3807) and the output size (0x3808-0x380b). The
horizontal window (0x3800/0x3801, 0x3804/0x3805) and the high bytes of
the vertical window (0x3802, 0x3806) are never written and keep their
power-on values, so they cannot be derived from the driver source. They
were read back over I2C from the sensor on a Dell Pro 14 Premium PA14260
and are identical in every mode:
0x3800/0x3801 = 0x0000 x_start = 0
0x3804/0x3805 = 0x0f1f x_end = 3871
0x3802 = 0x00 y_start high byte
0x3806 = 0x09 y_end high byte
Combining those with the per-mode low bytes gives:
mode crop (left, top, w, h) output binning
3856x2416 (0, 0, 3872, 2432) 3856x2416 1:1
3856x2176 (0, 112, 3872, 2208) 3856x2176 1:1
1928x1208 (0, 0, 3872, 2432) 1928x1208 2x2
1928x1088 (0, 120, 3872, 2192) 1928x1088 2x2
The margins are consistent throughout: 16 columns and 16 or 32 rows for
the 1:1 modes, and exactly 8 columns and 8 rows once the binned modes
are scaled down, which supports the reading of the high bytes above.
Report the full readable array as 3872x2432 for V4L2_SEL_TGT_CROP_BOUNDS
and V4L2_SEL_TGT_NATIVE_SIZE, and the largest mode's crop for
V4L2_SEL_TGT_CROP_DEFAULT.
Two caveats, since I have no datasheet for this sensor. First, only the
3856x2176 and 1928x1088 modes could be exercised on this hardware --
libcamera never selects the other three -- so their register values were
read directly and the remaining rows are derived from the same measured
high bytes. Second, this sensor's largest mode reads the whole array, so
CROP_DEFAULT (the active area) and CROP_BOUNDS (the readable area) come
out equal; if OmniVision or Intel can confirm the true active area
differs, CROP_DEFAULT should be narrowed accordingly.
Signed-off-by: Pierre Pinon <pierre@pinon1.fr>
---
drivers/media/i2c/ov08x40.c | 70 +++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c
index 5eaf454f4763..3de06e19803c 100644
--- a/drivers/media/i2c/ov08x40.c
+++ b/drivers/media/i2c/ov08x40.c
@@ -17,6 +17,15 @@
#include <media/v4l2-fwnode.h>
#define OV08X40_REG_VALUE_08BIT 1
+
+/*
+ * Full readable pixel array. The X window registers (0x3800/0x3801,
+ * 0x3804/0x3805) and the high bytes of the Y window (0x3802, 0x3806) are never
+ * programmed by the mode register lists, so they keep their power-on values;
+ * these were read back from the sensor as 0x0000-0x0f1f and 0x00/0x09.
+ */
+#define OV08X40_NATIVE_WIDTH 3872U
+#define OV08X40_NATIVE_HEIGHT 2432U
#define OV08X40_REG_VALUE_16BIT 2
#define OV08X40_REG_VALUE_24BIT 3
@@ -151,6 +160,9 @@ struct ov08x40_mode {
/* Exposure calculation */
u16 exposure_margin;
u16 exposure_shift;
+
+ /* Analogue crop rectangle, in native pixel array coordinates */
+ struct v4l2_rect crop;
};
static const struct ov08x40_reg ov08x40_global_regs[] = {
@@ -1232,6 +1244,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2416_regs),
.regs = mode_3856x2416_regs,
},
+ .crop = {
+ .left = 0,
+ .top = 0,
+ .width = 3872,
+ .height = 2432,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1247,6 +1265,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2176_regs_800mbps),
.regs = mode_3856x2176_regs_800mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 112,
+ .width = 3872,
+ .height = 2208,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1263,6 +1287,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_1928x1208_regs),
.regs = mode_1928x1208_regs,
},
+ .crop = {
+ .left = 0,
+ .top = 0,
+ .width = 3872,
+ .height = 2432,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 0,
.exposure_margin = OV08X40_EXPOSURE_BIN_MAX_MARGIN,
@@ -1278,6 +1308,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2176_regs_1500mbps),
.regs = mode_3856x2176_regs_1500mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 112,
+ .width = 3872,
+ .height = 2208,
+ },
.link_freq_index = OV08X40_LINK_FREQ_749MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1293,6 +1329,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_1928x1088_regs_1500mbps),
.regs = mode_1928x1088_regs_1500mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 120,
+ .width = 3872,
+ .height = 2192,
+ },
.link_freq_index = OV08X40_LINK_FREQ_749MHZ_INDEX,
.exposure_shift = 0,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -2055,10 +2097,38 @@ static const struct v4l2_subdev_video_ops ov08x40_video_ops = {
.s_stream = ov08x40_set_stream,
};
+static int ov08x40_get_selection(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_selection *sel)
+{
+ struct ov08x40 *ov08x = to_ov08x40(sd);
+
+ switch (sel->target) {
+ case V4L2_SEL_TGT_CROP:
+ mutex_lock(&ov08x->mutex);
+ sel->r = ov08x->cur_mode->crop;
+ mutex_unlock(&ov08x->mutex);
+ return 0;
+ case V4L2_SEL_TGT_NATIVE_SIZE:
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ sel->r.left = 0;
+ sel->r.top = 0;
+ sel->r.width = OV08X40_NATIVE_WIDTH;
+ sel->r.height = OV08X40_NATIVE_HEIGHT;
+ return 0;
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ sel->r = supported_modes[0].crop;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static const struct v4l2_subdev_pad_ops ov08x40_pad_ops = {
.enum_mbus_code = ov08x40_enum_mbus_code,
.get_fmt = ov08x40_get_pad_format,
.set_fmt = ov08x40_set_pad_format,
+ .get_selection = ov08x40_get_selection,
.enum_frame_size = ov08x40_enum_frame_size,
};
base-commit: 26cf1fa3d28a98a0cb08ae1929c71f681e5d2dcc
--
2.55.0
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/2] media: i2c: ov08x40: Implement the selection API
2026-09-04 13:45 [PATCH 1/2] media: i2c: ov08x40: Implement the selection API Pierre Pinon
@ 2026-09-14 14:00 ` Oleg Keri
2026-10-02 9:49 ` [PATCH v2] media: i2c: ov08x40: Implement get_selection Pierre Pinon
0 siblings, 1 reply; 6+ messages in thread
From: Oleg Keri @ 2026-09-14 14:00 UTC (permalink / raw)
To: Pierre Pinon
Cc: Sakari Ailus, Jason Chen, Jimmy Su, Mauro Carvalho Chehab,
Hans de Goede, linux-media, linux-kernel
Hi Pierre,
On Fri, Sep 04, 2026 at 03:45:23PM +0200, Pierre Pinon wrote:
> The mode register lists program only the low bytes of the vertical
> window (0x3803, 0x3807) and the output size (0x3808-0x380b). The
> horizontal window (0x3800/0x3801, 0x3804/0x3805) and the high bytes of
> the vertical window (0x3802, 0x3806) are never written and keep their
> power-on values, so they cannot be derived from the driver source.
They are written, just not per mode: ov08x40_global_regs has
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
{0x3804, 0x0f},
{0x3805, 0x1f},
{0x3806, 0x09},
which is exactly what you read back, so the first caveat in the message
can go. The same five rectangles and the 3872x2432 array also match
what I see on a Lenovo Yoga Slim 7x Gen 11 (Qualcomm CAMSS, 2 lanes)
with libcamera.
One small thing you may want to consider: V4L2_SEL_TGT_CROP for
V4L2_SUBDEV_FORMAT_TRY returns the active mode's crop here. Looking up
the mode that matches the TRY format in the subdev state, the way
ov08x40_get_pad_format() does, would keep a TRY set_fmt and a TRY
get_selection consistent.
Thanks,
Oleg
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH v2] media: i2c: ov08x40: Implement get_selection
2026-09-14 14:00 ` Oleg Keri
@ 2026-10-02 9:49 ` Pierre Pinon
2026-10-02 17:24 ` Oleg Keri
0 siblings, 1 reply; 6+ messages in thread
From: Pierre Pinon @ 2026-10-02 9:49 UTC (permalink / raw)
To: okerixx
Cc: hansg, jason.z.chen, jimmy.su, linux-kernel, linux-media,
mchehab, pierre, sakari.ailus
Report the crop of each mode, derived from the window registers in
ov08x40_global_regs and the mode lists, so that libcamera can tell the
2x2 binned modes apart from cropped ones and select them.
Signed-off-by: Pierre Pinon <pierre@pinon1.fr>
---
Hi Oleg,
Thanks a lot for the review, and for checking the rectangles on the
Yoga Slim 7x. You were right about ov08x40_global_regs, I had missed
those writes. v2 looks up the mode matching the TRY format as you
suggested.
While reworking that path I noticed a pre-existing issue on 2-lane
setups such as yours: ov08x40_open() initialises the TRY format to
supported_modes[0] (3856x2416), which is a 4-lane only mode, and probe
likewise sets cur_mode to it regardless of mipi_lanes. On a 2-lane
sensor the TRY format is therefore 3856x2416 right after open, while
the closest 2-lane mode, and so the TRY crop, is 3856x2176. I left it
out of this patch to keep it focused; I can send a separate fix that
picks the default mode according to mipi_lanes, if that sounds right
to you.
Changes in v2:
- Rebase onto media/next, which adds the client_info argument to
.get_selection
- Reword the commit message: the X window and Y window high bytes are
programmed in ov08x40_global_regs, not left at power-on values (Oleg)
- Return the TRY mode's crop for V4L2_SUBDEV_FORMAT_TRY (Oleg)
- Move the OV08X40_NATIVE_* defines out of the OV08X40_REG_VALUE_* group
drivers/media/i2c/ov08x40.c | 85 +++++++++++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c
index 6de0c17e6..d202e3d5a 100644
--- a/drivers/media/i2c/ov08x40.c
+++ b/drivers/media/i2c/ov08x40.c
@@ -38,6 +38,14 @@
#define OV08X40_REG_CHIP_ID 0x300a
#define OV08X40_CHIP_ID 0x560858
+/*
+ * Full readable pixel array, as programmed by the X window (0x3800-0x3801,
+ * 0x3804-0x3805) and Y window high byte (0x3802, 0x3806) registers in
+ * ov08x40_global_regs.
+ */
+#define OV08X40_NATIVE_WIDTH 3872U
+#define OV08X40_NATIVE_HEIGHT 2432U
+
/* V_TIMING internal */
#define OV08X40_REG_VTS 0x380e
#define OV08X40_VTS_30FPS 0x09c4 /* the VTS need to be half in normal mode */
@@ -151,6 +159,9 @@ struct ov08x40_mode {
/* Exposure calculation */
u16 exposure_margin;
u16 exposure_shift;
+
+ /* Analogue crop rectangle, in native pixel array coordinates */
+ struct v4l2_rect crop;
};
static const struct ov08x40_reg ov08x40_global_regs[] = {
@@ -1232,6 +1243,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2416_regs),
.regs = mode_3856x2416_regs,
},
+ .crop = {
+ .left = 0,
+ .top = 0,
+ .width = 3872,
+ .height = 2432,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1247,6 +1264,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2176_regs_800mbps),
.regs = mode_3856x2176_regs_800mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 112,
+ .width = 3872,
+ .height = 2208,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1263,6 +1286,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_1928x1208_regs),
.regs = mode_1928x1208_regs,
},
+ .crop = {
+ .left = 0,
+ .top = 0,
+ .width = 3872,
+ .height = 2432,
+ },
.link_freq_index = OV08X40_LINK_FREQ_400MHZ_INDEX,
.exposure_shift = 0,
.exposure_margin = OV08X40_EXPOSURE_BIN_MAX_MARGIN,
@@ -1278,6 +1307,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_3856x2176_regs_1500mbps),
.regs = mode_3856x2176_regs_1500mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 112,
+ .width = 3872,
+ .height = 2208,
+ },
.link_freq_index = OV08X40_LINK_FREQ_749MHZ_INDEX,
.exposure_shift = 1,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -1293,6 +1328,12 @@ static const struct ov08x40_mode supported_modes[] = {
.num_of_regs = ARRAY_SIZE(mode_1928x1088_regs_1500mbps),
.regs = mode_1928x1088_regs_1500mbps,
},
+ .crop = {
+ .left = 0,
+ .top = 120,
+ .width = 3872,
+ .height = 2192,
+ },
.link_freq_index = OV08X40_LINK_FREQ_749MHZ_INDEX,
.exposure_shift = 0,
.exposure_margin = OV08X40_EXPOSURE_MAX_MARGIN,
@@ -2056,10 +2097,54 @@ static const struct v4l2_subdev_video_ops ov08x40_video_ops = {
.s_stream = ov08x40_set_stream,
};
+static int ov08x40_get_selection(struct v4l2_subdev *sd,
+ const struct v4l2_subdev_client_info *ci,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_selection *sel)
+{
+ struct ov08x40 *ov08x = to_ov08x40(sd);
+ const struct v4l2_mbus_framefmt *framefmt;
+ const struct ov08x40_mode *mode;
+
+ switch (sel->target) {
+ case V4L2_SEL_TGT_CROP:
+ mutex_lock(&ov08x->mutex);
+ if (sel->which == V4L2_SUBDEV_FORMAT_TRY) {
+ framefmt = v4l2_subdev_state_get_format(sd_state,
+ sel->pad);
+ mode = v4l2_find_nearest_size_conditional(supported_modes,
+ ARRAY_SIZE(supported_modes),
+ width, height,
+ framefmt->width,
+ framefmt->height,
+ filter_by_mipi_lanes,
+ ov08x);
+ } else {
+ mode = ov08x->cur_mode;
+ }
+ sel->r = mode->crop;
+ mutex_unlock(&ov08x->mutex);
+ return 0;
+ case V4L2_SEL_TGT_NATIVE_SIZE:
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ sel->r.left = 0;
+ sel->r.top = 0;
+ sel->r.width = OV08X40_NATIVE_WIDTH;
+ sel->r.height = OV08X40_NATIVE_HEIGHT;
+ return 0;
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ sel->r = supported_modes[0].crop;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static const struct v4l2_subdev_pad_ops ov08x40_pad_ops = {
.enum_mbus_code = ov08x40_enum_mbus_code,
.get_fmt = ov08x40_get_pad_format,
.set_fmt = ov08x40_set_pad_format,
+ .get_selection = ov08x40_get_selection,
.enum_frame_size = ov08x40_enum_frame_size,
};
--
2.55.0
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v2] media: i2c: ov08x40: Implement get_selection
2026-10-02 9:49 ` [PATCH v2] media: i2c: ov08x40: Implement get_selection Pierre Pinon
@ 2026-10-02 17:24 ` Oleg Keri
2026-10-05 8:15 ` Pierre Pinon
0 siblings, 1 reply; 6+ messages in thread
From: Oleg Keri @ 2026-10-02 17:24 UTC (permalink / raw)
To: Pierre Pinon
Cc: hansg, jason.z.chen, jimmy.su, linux-kernel, linux-media,
mchehab, sakari.ailus
Hi Pierre,
v2 works here on the Lenovo Yoga Slim 7x Gen 11 (2-lane, libcamera 0.7.2
simple pipeline). A 1920x1080 request selects the binned 1928x1088 mode,
which reports crop (0,120)/3872x2192 within bounds 3872x2432, and the
full-resolution stream uses 3856x2176.
Tested-by: Oleg Keri <okerixx@gmail.com> # Lenovo Yoga Slim 7x Gen 11
> I can send a separate fix that picks the default mode according to
> mipi_lanes, if that sounds right to you.
Yes, please do. It makes no sense to default to a mode a 2-lane board
can't use.
Oleg
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] media: i2c: ov08x40: Implement get_selection
2026-10-02 17:24 ` Oleg Keri
@ 2026-10-05 8:15 ` Pierre Pinon
2026-10-05 8:53 ` Oleg Keri
0 siblings, 1 reply; 6+ messages in thread
From: Pierre Pinon @ 2026-10-05 8:15 UTC (permalink / raw)
To: okerixx
Cc: hansg, jason.z.chen, jimmy.su, linux-kernel, linux-media,
mchehab, pierre, sakari.ailus
Hi Oleg,
On Fri, Oct 02, 2026 at 07:24:20PM +0200, Oleg Keri wrote:
> v2 works here on the Lenovo Yoga Slim 7x Gen 11 (2-lane, libcamera 0.7.2
> simple pipeline).
>
> Tested-by: Oleg Keri <okerixx@gmail.com> # Lenovo Yoga Slim 7x Gen 11
Thanks for testing!
> Yes, please do. It makes no sense to default to a mode a 2-lane board
> can't use.
Sent here:
https://lore.kernel.org/linux-media/20261005065535.16137-1-pierre@pinon1.fr/
For the record, on the Dell (IPU7 behind an Intel CVS, 2 lanes),
libcamera now picks the binned 1928x1088 mode for 1080p, and that mode
still does not stream: the IPU7 firmware rejects every frame with
INSYS_MSG_ERR_CAPTURE_HW_ERR_BAD_FRAME_DIM.
This is the issue discussed under v1 2/2, "media: i2c: ov08x40: Do not
expose the broken 1928x1088 binned mode":
https://lore.kernel.org/linux-media/20260904134604.595685-1-pierre@pinon1.fr/
In short:
- Jimmy relayed that the CVS firmware decodes and re-packs the sensor's
MIPI stream, and only supports 3856x2176 linear and 1928x1088 sHDR,
while the driver programs 1928x1088 as linear.
- Sakari suggested having the CVS driver reject the other sizes.
With your Yoga feeding the sensor into CAMSS, I assume there is no such
vision chip in between, which would explain why the mode works there.
Is that right?
I'll follow up in that thread.
Pierre
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] media: i2c: ov08x40: Implement get_selection
2026-10-05 8:15 ` Pierre Pinon
@ 2026-10-05 8:53 ` Oleg Keri
0 siblings, 0 replies; 6+ messages in thread
From: Oleg Keri @ 2026-10-05 8:53 UTC (permalink / raw)
To: Pierre Pinon
Cc: hansg, jason.z.chen, jimmy.su, linux-kernel, linux-media,
mchehab, sakari.ailus
On Mon, Oct 05, 2026, Pierre Pinon wrote:
> With your Yoga feeding the sensor into CAMSS, I assume there is no such
> vision chip in between, which would explain why the mode works there.
> Is that right?
Yes, as far as I can tell. The sensor sits on a CCI bus and its two
lanes go straight to CSIPHY4 of CAMSS, nothing in between. The binned
1928x1088 mode streams fine here and is what a 1080p request ends up
using.
Oleg
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-05 8:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-04 13:45 [PATCH 1/2] media: i2c: ov08x40: Implement the selection API Pierre Pinon
2026-09-14 14:00 ` Oleg Keri
2026-10-02 9:49 ` [PATCH v2] media: i2c: ov08x40: Implement get_selection Pierre Pinon
2026-10-02 17:24 ` Oleg Keri
2026-10-05 8:15 ` Pierre Pinon
2026-10-05 8:53 ` Oleg Keri
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®