Add some fixes for fixing hw timestamp on some Logitech and SunplusIT
cameras. The issues have been previously reported to the manufacturers.
Also include a patch to fix the current hw timestamping logic for ANY
uvc 1.5 model running at under 16 fps.
@HungNien, the logic for empty_ts has slightly changed since v4, would
be great if you could test it on your end.
Tested-by: HungNien Chen <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
Changes in v10: Thanks Sergey and Laruent!
- Fix comments and style
- Link to v9: https://lore.kernel.org/r/[email protected]
Changes in v9:
- Fix bug on add_sample(). Sorry about that, click on send too fast :S
- Link to v8: https://lore.kernel.org/r/[email protected]
Changes in v8: Thanks Sergey!
- Move last_sof save into uvc_video_clock_add_sample().
- Improve comments on add_sample().
- Link to v7: https://lore.kernel.org/r/[email protected]
Changes in v7: Thanks Sergey!
- Fix all negative modulus, including old bug
- Improve doc for 1/4 second accuracy.
- Link to v6: https://lore.kernel.org/r/[email protected]
Changes in v6 (Thanks Sergey!):
- Rebase on top of linus/master
- Add missing host_sof assignment, ups :(. Sorry about that!
- Improve comments for empty TS quirk
- Link to v5: https://lore.kernel.org/r/[email protected]
Changes in v5: Thanks Dan
- Check for !buf on empty TS packets.
- Link to v4: https://lore.kernel.org/r/[email protected]
Changes in v4 (Thanks Laurent!):
- Rebase on top of pinchart/next/uvc
- Use heuristic for UVC_QUIRK_IGNORE_EMPTY_TS
- Link to v3: https://lore.kernel.org/r/[email protected]
Changes in v3 (Thanks Laurent!):
- Rebase on top of pinchart/uvc/next
- Fix hw timestampt handling for slow FPS
- Improve commit message
- Quirk for invalid dev_sof in Logi C922
- Improve commit message
- Allow hw clock updates with buffers not full
- Fix typo and improve messages
- Refactor clock circular buffer
- Improve commit message
- Quirk for autosuspend in Logi C910
- Improve commit message
- Add comments around the quirk
- Create UVC_QUIRK_IGNORE_EMPTY_TS quirk
- Improve comments
- Allow quirking by entity guid
- unsinged int
- Extend documentation of uvc_video_clock_decode()
- uvcvideo on commit message
- Improve comment
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- Require 1/4 sec of data before using the hw timestamps
- Add Tested-by SunplusIT
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Ricardo Ribalda (6):
media: uvcvideo: Support timestamp lists of any size
media: uvcvideo: Ignore empty TS packets
media: uvcvideo: Quirk for invalid dev_sof in Logitech C922
media: uvcvideo: Allow hw clock updates with buffers not full
media: uvcvideo: Refactor clock circular buffer
media: uvcvideo: Fix hw timestamp handling for slow FPS
drivers/media/usb/uvc/uvc_driver.c | 9 +++
drivers/media/usb/uvc/uvc_video.c | 155 ++++++++++++++++++++++++++-----------
drivers/media/usb/uvc/uvcvideo.h | 2 +
3 files changed, 121 insertions(+), 45 deletions(-)
---
base-commit: b14257abe7057def6127f6fb2f14f9adc8acabdb
change-id: 20220920-resend-hwtimestamp-b3e22729284d
Best regards,
--
Ricardo Ribalda <[email protected]>
The tail of the list lives at the position before the head. This is
mathematically noted as:
```
(head-1) mod size.
```
Unfortunately C, does not have a modulus operator, but a remainder
operator (%).
The reminder operation has a different result than the modulus if
(head -1) is a negative number and size is not a power of two.
Adding size to (head-1) allows the code to run with any value of size.
This does not change the current behaviour of the driver, as the size is
always a power of two, but avoid tedious debugging if we ever change its
size.
Reviewed-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 7cbf4692bd875..659c9e9880a99 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -732,7 +732,7 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
goto done;
first = &clock->samples[clock->head];
- last = &clock->samples[(clock->head - 1) % clock->size];
+ last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
/* First step, PTS to SOF conversion. */
delta_stc = buf->pts - (1UL << 31);
--
2.44.0.396.g6e790dbe36-goog
Some SunplusIT cameras took a borderline interpretation of the UVC 1.5
standard, and fill the PTS and SCR fields with invalid data if the
package does not contain data.
"STC must be captured when the first video data of a video frame is put
on the USB bus."
Some SunplusIT devices send, e.g.,
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a
While the UVC specification meant that the first two packets shouldn't
have had the SCR bit set in the header.
This borderline/buggy interpretation has been implemented in a variety
of devices, from directly SunplusIT and from other OEMs that rebrand
SunplusIT products. So quirking based on VID:PID will be problematic.
All the affected modules have the following extension unit:
VideoControl Interface Descriptor:
guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d}
But the vendor plans to use that GUID in the future and fix the bug,
this means that we should use heuristic to figure out the broken
packets.
This patch takes care of this.
lsusb of one of the affected cameras:
Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.01
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1bcf Sunplus Innovation Technology Inc.
idProduct 0x2a01
bcdDevice 0.02
iManufacturer 1 SunplusIT Inc
iProduct 2 HanChen Wise Camera
iSerial 3 01.00.00
bNumConfigurations 1
Tested-by: HungNien Chen <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_video.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 659c9e9880a99..b2e70fcf4eb4c 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -478,6 +478,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
ktime_t time;
u16 host_sof;
u16 dev_sof;
+ u32 dev_stc;
switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
case UVC_STREAM_PTS | UVC_STREAM_SCR:
@@ -526,6 +527,34 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
if (dev_sof == stream->clock.last_sof)
return;
+ dev_stc = get_unaligned_le32(&data[header_size - 6]);
+
+ /*
+ * STC (Source Time Clock) is the clock used by the camera. The UVC 1.5
+ * standard states that it "must be captured when the first video data
+ * of a video frame is put on the USB bus". This is generally understood
+ * as requiring devices to clear the payload header's SCR bit before
+ * the first packet containing video data.
+ *
+ * Most vendors follow that interpretation, but some (namely SunplusIT
+ * on some devices) always set the `UVC_STREAM_SCR` bit, fill the SCR
+ * field with 0's,and expect that the driver only processes the SCR if
+ * there is data in the packet.
+ *
+ * Ignore all the hardware timestamp information if we haven't received
+ * any data for this frame yet, the packet contains no data, and both
+ * STC and SOF are zero. This heuristics should be safe on compliant
+ * devices. This should be safe with compliant devices, as in the very
+ * unlikely case where a UVC 1.1 device would send timing information
+ * only before the first packet containing data, and both STC and SOF
+ * happen to be zero for a particular frame, we would only miss one
+ * clock sample from many and the clock recovery algorithm wouldn't
+ * suffer from this condition.
+ */
+ if (buf && buf->bytesused == 0 && len == header_size &&
+ dev_stc == 0 && dev_sof == 0)
+ return;
+
stream->clock.last_sof = dev_sof;
host_sof = usb_get_current_frame_number(stream->dev->udev);
@@ -564,7 +593,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
spin_lock_irqsave(&stream->clock.lock, flags);
sample = &stream->clock.samples[stream->clock.head];
- sample->dev_stc = get_unaligned_le32(&data[header_size - 6]);
+ sample->dev_stc = dev_stc;
sample->dev_sof = dev_sof;
sample->host_sof = host_sof;
sample->host_time = time;
--
2.44.0.396.g6e790dbe36-goog
With UVC 1.5 we get as little as one clock sample per frame. Which means
that it takes 32 frames to move from the software timestamp to the
hardware timestamp method.
This results in abrupt changes in the timestamping after 32 frames (~1
second), resulting in noticeable artifacts when used for encoding.
With this patch we modify the update algorithm to work with whatever
amount of values are available.
Tested-by: HungNien Chen <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index d6ca383f643e3..af25b9f1b53fe 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
spin_lock_irqsave(&clock->lock, flags);
- if (clock->count < clock->size)
+ if (clock->count < 2)
goto done;
- first = &clock->samples[clock->head];
+ first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
/* First step, PTS to SOF conversion. */
@@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
if (y2 < y1)
y2 += 2048 << 16;
+ /*
+ * Have at least 1/4 of a second of timestamps before we
+ * try to do any calculation. Otherwise we do not have enough
+ * precision. This value was determined by running Android CTS
+ * on different devices.
+ *
+ * dev_sof runs at 1KHz, and we have a fixed point precision of
+ * 16 bits.
+ */
+ if ((y2 - y1) < ((1000 / 4) << 16))
+ goto done;
+
y = (u64)(y2 - y1) * (1ULL << 31) + (u64)y1 * (u64)x2
- (u64)y2 * (u64)x1;
y = div_u64(y, x2 - x1);
--
2.44.0.396.g6e790dbe36-goog
Logitech C922 internal SOF does not increases at a stable rate of 1kHz.
This causes that the device_sof and the host_sof run at different rates,
breaking the clock domain conversion algorithm. Eg:
30 (6) [-] none 30 614400 B 21.245557 21.395214 34.133 fps ts mono/SoE
31 (7) [-] none 31 614400 B 21.275327 21.427246 33.591 fps ts mono/SoE
32 (0) [-] none 32 614400 B 21.304739 21.459256 34.000 fps ts mono/SoE
33 (1) [-] none 33 614400 B 21.334324 21.495274 33.801 fps ts mono/SoE
* 34 (2) [-] none 34 614400 B 21.529237 21.527297 5.130 fps ts mono/SoE
* 35 (3) [-] none 35 614400 B 21.649416 21.559306 8.321 fps ts mono/SoE
36 (4) [-] none 36 614400 B 21.678789 21.595320 34.045 fps ts mono/SoE
..
99 (3) [-] none 99 614400 B 23.542226 23.696352 33.541 fps ts mono/SoE
100 (4) [-] none 100 614400 B 23.571578 23.728404 34.069 fps ts mono/SoE
101 (5) [-] none 101 614400 B 23.601425 23.760420 33.504 fps ts mono/SoE
* 102 (6) [-] none 102 614400 B 23.798324 23.796428 5.079 fps ts mono/SoE
* 103 (7) [-] none 103 614400 B 23.916271 23.828450 8.478 fps ts mono/SoE
104 (0) [-] none 104 614400 B 23.945720 23.860479 33.957 fps ts mono/SoE
Instead of disabling completely the hardware timestamping for such
hardware we take the assumption that the packet handling jitter is
under 2ms and use the host_sof as dev_sof.
We can think of the UVC hardware clock as a system with a coarse clock
(the SOF) and a fine clock (the PTS). The coarse clock can be replaced
with a clock on the same frequency, if the jitter of such clock is
smaller than its sampling rate. That way we can save some of the
precision of the fine clock.
To probe this point we have run three experiments on the Logitech C922.
On that experiment we run the camera at 33fps and we analyse the
difference in msec between a frame and its predecessor. If we display
the histogram of that value, a thinner histogram will mean a better
meassurement. The results for:
- original hw timestamp: https://ibb.co/D1HJJ4x
- pure software timestamp: https://ibb.co/QC9MgVK
- modified hw timestamp: https://ibb.co/8s9dBdk
This bug in the camera firmware has been confirmed by the vendor.
lsusb -v
Bus 001 Device 044: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0x085c C922 Pro Stream Webcam
bcdDevice 0.16
iManufacturer 0
iProduct 2 C922 Pro Stream Webcam
iSerial 1 80B912DF
bNumConfigurations 1
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_driver.c | 9 +++++++++
drivers/media/usb/uvc/uvc_video.c | 11 +++++++++++
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index bbd90123a4e76..723e6d5680c2e 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2574,6 +2574,15 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) },
+ /* Logitech HD Pro Webcam C922 */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x046d,
+ .idProduct = 0x085c,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_INVALID_DEVICE_SOF) },
/* Chicony CNF7129 (Asus EEE 100HE) */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index b2e70fcf4eb4c..d6ca383f643e3 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -558,6 +558,17 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
stream->clock.last_sof = dev_sof;
host_sof = usb_get_current_frame_number(stream->dev->udev);
+
+ /*
+ * On some devices, like the Logitech C922, the device SOF does not run
+ * at a stable rate of 1kHz. For those devices use the host SOF instead.
+ * In the tests performed so far, this improves the timestamp precision.
+ * This is probably explained by a small packet handling jitter from the
+ * host, but the exact reason hasn't been fully determined.
+ */
+ if (stream->dev->quirks & UVC_QUIRK_INVALID_DEVICE_SOF)
+ dev_sof = host_sof;
+
time = uvc_video_get_time();
/*
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 6fb0a78b1b009..cb9dd50bba8ac 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -73,6 +73,7 @@
#define UVC_QUIRK_FORCE_Y8 0x00000800
#define UVC_QUIRK_FORCE_BPP 0x00001000
#define UVC_QUIRK_WAKE_AUTOSUSPEND 0x00002000
+#define UVC_QUIRK_INVALID_DEVICE_SOF 0x00004000
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED 0x00000001
--
2.44.0.396.g6e790dbe36-goog
Isolate all the changes related to the clock circular buffer to its own
function, that way we can make changes easier to the buffer logic.
Also simplify the lock, by removing the circular buffer clock handling
from uvc_video_clock_decode().
And now that we are at it, unify the API of the clock functions.
Tested-by: HungNien Chen <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_video.c | 83 +++++++++++++++++----------------------
1 file changed, 36 insertions(+), 47 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index af25b9f1b53fe..5df8f61d39cd1 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -466,19 +466,28 @@ static inline ktime_t uvc_video_get_time(void)
return ktime_get_real();
}
+static void uvc_video_clock_add_sample(struct uvc_clock *clock,
+ const struct uvc_clock_sample *sample)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&clock->lock, flags);
+
+ clock->samples[clock->head] = *sample;
+ clock->head = (clock->head + 1) % clock->size;
+ clock->count = min(clock->count + 1, clock->size);
+
+ spin_unlock_irqrestore(&clock->lock, flags);
+}
+
static void
uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
const u8 *data, int len)
{
- struct uvc_clock_sample *sample;
+ struct uvc_clock_sample sample;
unsigned int header_size;
bool has_pts = false;
bool has_scr = false;
- unsigned long flags;
- ktime_t time;
- u16 host_sof;
- u16 dev_sof;
- u32 dev_stc;
switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
case UVC_STREAM_PTS | UVC_STREAM_SCR:
@@ -523,11 +532,11 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
* all the data packets of the same frame contains the same SOF. In that
* case only the first one will match the host_sof.
*/
- dev_sof = get_unaligned_le16(&data[header_size - 2]);
- if (dev_sof == stream->clock.last_sof)
+ sample.dev_sof = get_unaligned_le16(&data[header_size - 2]);
+ if (sample.dev_sof == stream->clock.last_sof)
return;
- dev_stc = get_unaligned_le32(&data[header_size - 6]);
+ sample.dev_stc = get_unaligned_le32(&data[header_size - 6]);
/*
* STC (Source Time Clock) is the clock used by the camera. The UVC 1.5
@@ -552,12 +561,10 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
* suffer from this condition.
*/
if (buf && buf->bytesused == 0 && len == header_size &&
- dev_stc == 0 && dev_sof == 0)
+ sample.dev_stc == 0 && sample.dev_sof == 0)
return;
- stream->clock.last_sof = dev_sof;
-
- host_sof = usb_get_current_frame_number(stream->dev->udev);
+ sample.host_sof = usb_get_current_frame_number(stream->dev->udev);
/*
* On some devices, like the Logitech C922, the device SOF does not run
@@ -567,9 +574,9 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
* host, but the exact reason hasn't been fully determined.
*/
if (stream->dev->quirks & UVC_QUIRK_INVALID_DEVICE_SOF)
- dev_sof = host_sof;
+ sample.dev_sof = sample.host_sof;
- time = uvc_video_get_time();
+ sample.host_time = uvc_video_get_time();
/*
* The UVC specification allows device implementations that can't obtain
@@ -592,46 +599,28 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
* the 8 LSBs of the delta are kept.
*/
if (stream->clock.sof_offset == (u16)-1) {
- u16 delta_sof = (host_sof - dev_sof) & 255;
+ u16 delta_sof = (sample.host_sof - sample.dev_sof) & 255;
if (delta_sof >= 10)
stream->clock.sof_offset = delta_sof;
else
stream->clock.sof_offset = 0;
}
- dev_sof = (dev_sof + stream->clock.sof_offset) & 2047;
-
- spin_lock_irqsave(&stream->clock.lock, flags);
-
- sample = &stream->clock.samples[stream->clock.head];
- sample->dev_stc = dev_stc;
- sample->dev_sof = dev_sof;
- sample->host_sof = host_sof;
- sample->host_time = time;
-
- /* Update the sliding window head and count. */
- stream->clock.head = (stream->clock.head + 1) % stream->clock.size;
-
- if (stream->clock.count < stream->clock.size)
- stream->clock.count++;
-
- spin_unlock_irqrestore(&stream->clock.lock, flags);
+ sample.dev_sof = (sample.dev_sof + stream->clock.sof_offset) & 2047;
+ uvc_video_clock_add_sample(&stream->clock, &sample);
+ stream->clock.last_sof = sample.dev_sof;
}
-static void uvc_video_clock_reset(struct uvc_streaming *stream)
+static void uvc_video_clock_reset(struct uvc_clock *clock)
{
- struct uvc_clock *clock = &stream->clock;
-
clock->head = 0;
clock->count = 0;
clock->last_sof = -1;
clock->sof_offset = -1;
}
-static int uvc_video_clock_init(struct uvc_streaming *stream)
+static int uvc_video_clock_init(struct uvc_clock *clock)
{
- struct uvc_clock *clock = &stream->clock;
-
spin_lock_init(&clock->lock);
clock->size = 32;
@@ -640,15 +629,15 @@ static int uvc_video_clock_init(struct uvc_streaming *stream)
if (clock->samples == NULL)
return -ENOMEM;
- uvc_video_clock_reset(stream);
+ uvc_video_clock_reset(clock);
return 0;
}
-static void uvc_video_clock_cleanup(struct uvc_streaming *stream)
+static void uvc_video_clock_cleanup(struct uvc_clock *clock)
{
- kfree(stream->clock.samples);
- stream->clock.samples = NULL;
+ kfree(clock->samples);
+ clock->samples = NULL;
}
/*
@@ -2123,7 +2112,7 @@ int uvc_video_resume(struct uvc_streaming *stream, int reset)
stream->frozen = 0;
- uvc_video_clock_reset(stream);
+ uvc_video_clock_reset(&stream->clock);
if (!uvc_queue_streaming(&stream->queue))
return 0;
@@ -2272,7 +2261,7 @@ int uvc_video_start_streaming(struct uvc_streaming *stream)
{
int ret;
- ret = uvc_video_clock_init(stream);
+ ret = uvc_video_clock_init(&stream->clock);
if (ret < 0)
return ret;
@@ -2290,7 +2279,7 @@ int uvc_video_start_streaming(struct uvc_streaming *stream)
error_video:
usb_set_interface(stream->dev->udev, stream->intfnum, 0);
error_commit:
- uvc_video_clock_cleanup(stream);
+ uvc_video_clock_cleanup(&stream->clock);
return ret;
}
@@ -2318,5 +2307,5 @@ void uvc_video_stop_streaming(struct uvc_streaming *stream)
usb_clear_halt(stream->dev->udev, pipe);
}
- uvc_video_clock_cleanup(stream);
+ uvc_video_clock_cleanup(&stream->clock);
}
--
2.44.0.396.g6e790dbe36-goog
In UVC 1.5 we get a single clock value per frame. With the current
buffer size of 32, FPS slowers than 32 might roll-over twice.
The current code cannot handle two roll-over and provide invalid
timestamps.
Remove all the samples from the circular buffer that are more than two
rollovers old, so the algorithm always provides good timestamps.
Note that we are removing values that are more than one second old,
which means that there is enough distance between the two points that
we use for the interpolation to provide good values.
Tested-by: HungNien Chen <[email protected]>
Reviewed-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Ricardo Ribalda <[email protected]>
---
drivers/media/usb/uvc/uvc_video.c | 24 ++++++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 5df8f61d39cd1..900b57afac93a 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -471,8 +471,31 @@ static void uvc_video_clock_add_sample(struct uvc_clock *clock,
{
unsigned long flags;
+ /*
+ * If we write new data on the position where we had the last
+ * overflow, remove the overflow pointer. There is no overflow
+ * on the whole circular buffer.
+ */
+ if (clock->head == clock->last_sof_overflow)
+ clock->last_sof_overflow = -1;
+
spin_lock_irqsave(&clock->lock, flags);
+ /* Handle overflows */
+ if (clock->count > 0 && clock->last_sof > sample->dev_sof) {
+ /*
+ * Remove data from the circular buffer that is older than the
+ * last overflow. We only support one overflow per circular
+ * buffer.
+ */
+ if (clock->last_sof_overflow != -1) {
+ clock->count = (clock->head - clock->last_sof_overflow
+ + clock->count) % clock->count;
+ }
+ clock->last_sof_overflow = clock->head;
+ }
+
+ /* Add sample */
clock->samples[clock->head] = *sample;
clock->head = (clock->head + 1) % clock->size;
clock->count = min(clock->count + 1, clock->size);
@@ -616,6 +639,7 @@ static void uvc_video_clock_reset(struct uvc_clock *clock)
clock->head = 0;
clock->count = 0;
clock->last_sof = -1;
+ clock->last_sof_overflow = -1;
clock->sof_offset = -1;
}
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index cb9dd50bba8ac..fb9f9771131ac 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -499,6 +499,7 @@ struct uvc_streaming {
unsigned int head;
unsigned int count;
unsigned int size;
+ unsigned int last_sof_overflow;
u16 last_sof;
u16 sof_offset;
--
2.44.0.396.g6e790dbe36-goog
Hello.
On sobota 23. března 2024 11:48:04, CET Ricardo Ribalda wrote:
> Logitech C922 internal SOF does not increases at a stable rate of 1kHz.
> This causes that the device_sof and the host_sof run at different rates,
> breaking the clock domain conversion algorithm. Eg:
>
> 30 (6) [-] none 30 614400 B 21.245557 21.395214 34.133 fps ts mono/SoE
> 31 (7) [-] none 31 614400 B 21.275327 21.427246 33.591 fps ts mono/SoE
> 32 (0) [-] none 32 614400 B 21.304739 21.459256 34.000 fps ts mono/SoE
> 33 (1) [-] none 33 614400 B 21.334324 21.495274 33.801 fps ts mono/SoE
> * 34 (2) [-] none 34 614400 B 21.529237 21.527297 5.130 fps ts mono/SoE
> * 35 (3) [-] none 35 614400 B 21.649416 21.559306 8.321 fps ts mono/SoE
> 36 (4) [-] none 36 614400 B 21.678789 21.595320 34.045 fps ts mono/SoE
> ...
> 99 (3) [-] none 99 614400 B 23.542226 23.696352 33.541 fps ts mono/SoE
> 100 (4) [-] none 100 614400 B 23.571578 23.728404 34.069 fps ts mono/SoE
> 101 (5) [-] none 101 614400 B 23.601425 23.760420 33.504 fps ts mono/SoE
> * 102 (6) [-] none 102 614400 B 23.798324 23.796428 5.079 fps ts mono/SoE
> * 103 (7) [-] none 103 614400 B 23.916271 23.828450 8.478 fps ts mono/SoE
> 104 (0) [-] none 104 614400 B 23.945720 23.860479 33.957 fps ts mono/SoE
How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
Thanks.
> Instead of disabling completely the hardware timestamping for such
> hardware we take the assumption that the packet handling jitter is
> under 2ms and use the host_sof as dev_sof.
>
> We can think of the UVC hardware clock as a system with a coarse clock
> (the SOF) and a fine clock (the PTS). The coarse clock can be replaced
> with a clock on the same frequency, if the jitter of such clock is
> smaller than its sampling rate. That way we can save some of the
> precision of the fine clock.
>
> To probe this point we have run three experiments on the Logitech C922.
> On that experiment we run the camera at 33fps and we analyse the
> difference in msec between a frame and its predecessor. If we display
> the histogram of that value, a thinner histogram will mean a better
> meassurement. The results for:
> - original hw timestamp: https://ibb.co/D1HJJ4x
> - pure software timestamp: https://ibb.co/QC9MgVK
> - modified hw timestamp: https://ibb.co/8s9dBdk
>
> This bug in the camera firmware has been confirmed by the vendor.
>
> lsusb -v
>
> Bus 001 Device 044: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 239 Miscellaneous Device
> bDeviceSubClass 2
> bDeviceProtocol 1 Interface Association
> bMaxPacketSize0 64
> idVendor 0x046d Logitech, Inc.
> idProduct 0x085c C922 Pro Stream Webcam
> bcdDevice 0.16
> iManufacturer 0
> iProduct 2 C922 Pro Stream Webcam
> iSerial 1 80B912DF
> bNumConfigurations 1
>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Laurent Pinchart <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_driver.c | 9 +++++++++
> drivers/media/usb/uvc/uvc_video.c | 11 +++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index bbd90123a4e76..723e6d5680c2e 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2574,6 +2574,15 @@ static const struct usb_device_id uvc_ids[] = {
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) },
> + /* Logitech HD Pro Webcam C922 */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x046d,
> + .idProduct = 0x085c,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_INVALID_DEVICE_SOF) },
> /* Chicony CNF7129 (Asus EEE 100HE) */
> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> | USB_DEVICE_ID_MATCH_INT_INFO,
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index b2e70fcf4eb4c..d6ca383f643e3 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -558,6 +558,17 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> stream->clock.last_sof = dev_sof;
>
> host_sof = usb_get_current_frame_number(stream->dev->udev);
> +
> + /*
> + * On some devices, like the Logitech C922, the device SOF does not run
> + * at a stable rate of 1kHz. For those devices use the host SOF instead.
> + * In the tests performed so far, this improves the timestamp precision.
> + * This is probably explained by a small packet handling jitter from the
> + * host, but the exact reason hasn't been fully determined.
> + */
> + if (stream->dev->quirks & UVC_QUIRK_INVALID_DEVICE_SOF)
> + dev_sof = host_sof;
> +
> time = uvc_video_get_time();
>
> /*
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 6fb0a78b1b009..cb9dd50bba8ac 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -73,6 +73,7 @@
> #define UVC_QUIRK_FORCE_Y8 0x00000800
> #define UVC_QUIRK_FORCE_BPP 0x00001000
> #define UVC_QUIRK_WAKE_AUTOSUSPEND 0x00002000
> +#define UVC_QUIRK_INVALID_DEVICE_SOF 0x00004000
>
> /* Format flags */
> #define UVC_FMT_FLAG_COMPRESSED 0x00000001
>
>
--
Oleksandr Natalenko (post-factum)
Hi Oleksandr
On Sat, 23 Mar 2024 at 13:16, Oleksandr Natalenko
<[email protected]> wrote:
>
> How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
>
> Thanks.
>
First of all you need to enable the hwtimestamps in the driver. You
could do that with
```
rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1
```
Then capture some frames with yavta
```
yavta -c /dev/video0
```
After around 5 seconds all the frames should have a stable fps, the
fps is not stable then your camera is affected with this bug.
Thanks!
Hello.
On pondělí 25. března 2024 8:52:57, CET Ricardo Ribalda wrote:
> Hi Oleksandr
>
> On Sat, 23 Mar 2024 at 13:16, Oleksandr Natalenko
> <[email protected]> wrote:
>
> >
> > How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
> >
> > Thanks.
> >
>
> First of all you need to enable the hwtimestamps in the driver. You
> could do that with
>
> ```
> rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1
> ```
```
$ cat /sys/module/uvcvideo/parameters/hwtimestamps
1
```
> Then capture some frames with yavta
> ```
> yavta -c /dev/video0
> ```
>
> After around 5 seconds all the frames should have a stable fps, the
> fps is not stable then your camera is affected with this bug.
```
$ ./yavta -c /dev/video1
Device /dev/video1 opened.
Device `HD Pro Webcam C920' on `usb-0000:0f:00.3-3.4' (driver 'uvcvideo') supports video, capture, without mplanes.
Video format: MJPEG (47504a4d) 1920x1080 (stride 0) field none buffer size 4147200
…
100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE
101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE
102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE
103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE
104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE
105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE
106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE
…
168 (0) [-] none 168 200914 B 215.183707 215.347066 33.676 fps ts mono/SoE
169 (1) [-] none 169 201141 B 215.271693 215.379066 11.365 fps ts mono/SoE
170 (2) [-] none 170 201005 B 215.303449 215.415057 31.490 fps ts mono/SoE
171 (3) [-] none 171 201195 B 215.335295 215.447062 31.401 fps ts mono/SoE
172 (4) [-] none 172 200933 B 215.557731 215.479072 4.496 fps ts mono/SoE
173 (5) [-] none 173 200973 B 215.587033 215.515063 34.127 fps ts mono/SoE
174 (6) [-] none 174 200698 B 215.616811 215.547063 33.582 fps ts mono/SoE
175 (7) [-] none 175 201290 B 215.646196 215.579075 34.031 fps ts mono/SoE
176 (0) [-] none 176 200807 B 215.675857 215.615073 33.714 fps ts mono/SoE
…
```
Does the above mean the webcam is affected?
Thank you.
>
>
> Thanks!
>
--
Oleksandr Natalenko (post-factum)
Hi Oleksandr
On Mon, 25 Mar 2024 at 10:23, Oleksandr Natalenko
<[email protected]> wrote:
>
> Hello.
>
> On pondělí 25. března 2024 8:52:57, CET Ricardo Ribalda wrote:
> > Hi Oleksandr
> >
> > On Sat, 23 Mar 2024 at 13:16, Oleksandr Natalenko
> > <[email protected]> wrote:
> >
> > >
> > > How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
> > >
> > > Thanks.
> > >
> >
> > First of all you need to enable the hwtimestamps in the driver. You
> > could do that with
> >
> > ```
> > rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1
> > ```
>
> ```
> $ cat /sys/module/uvcvideo/parameters/hwtimestamps
> 1
> ```
>
> > Then capture some frames with yavta
> > ```
> > yavta -c /dev/video0
> > ```
> >
> > After around 5 seconds all the frames should have a stable fps, the
> > fps is not stable then your camera is affected with this bug.
>
> ```
> $ ./yavta -c /dev/video1
> Device /dev/video1 opened.
> Device `HD Pro Webcam C920' on `usb-0000:0f:00.3-3.4' (driver 'uvcvideo') supports video, capture, without mplanes.
> Video format: MJPEG (47504a4d) 1920x1080 (stride 0) field none buffer size 4147200
> …
> 100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE
> 101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE
> 102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE
> 103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE
> 104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE
> 105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE
> 106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE
> …
> 168 (0) [-] none 168 200914 B 215.183707 215.347066 33.676 fps ts mono/SoE
> 169 (1) [-] none 169 201141 B 215.271693 215.379066 11.365 fps ts mono/SoE
> 170 (2) [-] none 170 201005 B 215.303449 215.415057 31.490 fps ts mono/SoE
> 171 (3) [-] none 171 201195 B 215.335295 215.447062 31.401 fps ts mono/SoE
> 172 (4) [-] none 172 200933 B 215.557731 215.479072 4.496 fps ts mono/SoE
> 173 (5) [-] none 173 200973 B 215.587033 215.515063 34.127 fps ts mono/SoE
> 174 (6) [-] none 174 200698 B 215.616811 215.547063 33.582 fps ts mono/SoE
> 175 (7) [-] none 175 201290 B 215.646196 215.579075 34.031 fps ts mono/SoE
> 176 (0) [-] none 176 200807 B 215.675857 215.615073 33.714 fps ts mono/SoE
> …
> ```
>
> Does the above mean the webcam is affected?
Looks like it.... could you try applying this patch and run with
rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1 quirks=0x4000
to see if that fixes it for you?
Thanks!
>
> Thank you.
>
> >
> >
> > Thanks!
> >
>
>
> --
> Oleksandr Natalenko (post-factum)
--
Ricardo Ribalda
On pondělí 25. března 2024 10:25:51, CET Ricardo Ribalda wrote:
> Hi Oleksandr
>
> On Mon, 25 Mar 2024 at 10:23, Oleksandr Natalenko
> <[email protected]> wrote:
> >
> > Hello.
> >
> > On pondělí 25. března 2024 8:52:57, CET Ricardo Ribalda wrote:
> > > Hi Oleksandr
> > >
> > > On Sat, 23 Mar 2024 at 13:16, Oleksandr Natalenko
> > > <[email protected]> wrote:
> > >
> > > >
> > > > How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
> > > >
> > > > Thanks.
> > > >
> > >
> > > First of all you need to enable the hwtimestamps in the driver. You
> > > could do that with
> > >
> > > ```
> > > rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1
> > > ```
> >
> > ```
> > $ cat /sys/module/uvcvideo/parameters/hwtimestamps
> > 1
> > ```
> >
> > > Then capture some frames with yavta
> > > ```
> > > yavta -c /dev/video0
> > > ```
> > >
> > > After around 5 seconds all the frames should have a stable fps, the
> > > fps is not stable then your camera is affected with this bug.
> >
> > ```
> > $ ./yavta -c /dev/video1
> > Device /dev/video1 opened.
> > Device `HD Pro Webcam C920' on `usb-0000:0f:00.3-3.4' (driver 'uvcvideo') supports video, capture, without mplanes.
> > Video format: MJPEG (47504a4d) 1920x1080 (stride 0) field none buffer size 4147200
> > …
> > 100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE
> > 101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE
> > 102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE
> > 103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE
> > 104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE
> > 105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE
> > 106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE
> > …
> > 168 (0) [-] none 168 200914 B 215.183707 215.347066 33.676 fps ts mono/SoE
> > 169 (1) [-] none 169 201141 B 215.271693 215.379066 11.365 fps ts mono/SoE
> > 170 (2) [-] none 170 201005 B 215.303449 215.415057 31.490 fps ts mono/SoE
> > 171 (3) [-] none 171 201195 B 215.335295 215.447062 31.401 fps ts mono/SoE
> > 172 (4) [-] none 172 200933 B 215.557731 215.479072 4.496 fps ts mono/SoE
> > 173 (5) [-] none 173 200973 B 215.587033 215.515063 34.127 fps ts mono/SoE
> > 174 (6) [-] none 174 200698 B 215.616811 215.547063 33.582 fps ts mono/SoE
> > 175 (7) [-] none 175 201290 B 215.646196 215.579075 34.031 fps ts mono/SoE
> > 176 (0) [-] none 176 200807 B 215.675857 215.615073 33.714 fps ts mono/SoE
> > …
> > ```
> >
> > Does the above mean the webcam is affected?
>
> Looks like it.... could you try applying this patch and run with
>
> rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1 quirks=0x4000
>
> to see if that fixes it for you?
On top of v6.8, I've applied the whole v10, and also applied the following change instead of providing `quirks=`:
```
commit 884a61751d979ee9974c08a71c72e88e73bdd87e
Author: Oleksandr Natalenko <[email protected]>
Date: Mon Mar 25 10:28:00 2024 +0100
media: uvcvideo: Quirk for invalid dev_sof in Logitech C920
Signed-off-by: Oleksandr Natalenko <[email protected]>
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 723e6d5680c2e..444d7089885ea 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2573,7 +2573,8 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceClass = USB_CLASS_VIDEO,
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
- .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) },
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT
+ | UVC_QUIRK_INVALID_DEVICE_SOF) },
/* Logitech HD Pro Webcam C922 */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
```
Now I see this:
```
154 (2) [-] none 154 192417 B 42.199823 42.207788 27.779 fps ts mono/SoE
155 (3) [-] none 155 192040 B 42.231834 42.239791 31.239 fps ts mono/SoE
156 (4) [-] none 156 192213 B 42.263823 42.271822 31.261 fps ts mono/SoE
157 (5) [-] none 157 191981 B 42.299824 42.303827 27.777 fps ts mono/SoE
158 (6) [-] none 158 191953 B 42.331835 42.339811 31.239 fps ts mono/SoE
159 (7) [-] none 159 191904 B 42.363824 42.371813 31.261 fps ts mono/SoE
160 (0) [-] none 160 192210 B 42.399834 42.407801 27.770 fps ts mono/SoE
161 (1) [-] none 161 192235 B 42.431824 42.439806 31.260 fps ts mono/SoE
```
without dips in FPS.
What do you think?
>
> Thanks!
>
> >
> > Thank you.
> >
> > >
> > >
> > > Thanks!
> > >
> >
> >
> > --
> > Oleksandr Natalenko (post-factum)
>
>
>
>
--
Oleksandr Natalenko (post-factum)
Hi Oleksandr
That looks good :) !
On Mon, 25 Mar 2024 at 13:51, Oleksandr Natalenko
<[email protected]> wrote:
>
> On pondělí 25. března 2024 10:25:51, CET Ricardo Ribalda wrote:
> > Hi Oleksandr
> >
> > On Mon, 25 Mar 2024 at 10:23, Oleksandr Natalenko
> > <[email protected]> wrote:
> > >
> > > Hello.
> > >
> > > On pondělí 25. března 2024 8:52:57, CET Ricardo Ribalda wrote:
> > > > Hi Oleksandr
> > > >
> > > > On Sat, 23 Mar 2024 at 13:16, Oleksandr Natalenko
> > > > <[email protected]> wrote:
> > > >
> > > > >
> > > > > How do I check whether C920 (046d:082d) is affected too? I have got one, I can run tests on it as long as those will not blow the webcam up.
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > > > First of all you need to enable the hwtimestamps in the driver. You
> > > > could do that with
> > > >
> > > > ```
> > > > rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1
> > > > ```
> > >
> > > ```
> > > $ cat /sys/module/uvcvideo/parameters/hwtimestamps
> > > 1
> > > ```
> > >
> > > > Then capture some frames with yavta
> > > > ```
> > > > yavta -c /dev/video0
> > > > ```
> > > >
> > > > After around 5 seconds all the frames should have a stable fps, the
> > > > fps is not stable then your camera is affected with this bug.
> > >
> > > ```
> > > $ ./yavta -c /dev/video1
> > > Device /dev/video1 opened.
> > > Device `HD Pro Webcam C920' on `usb-0000:0f:00.3-3.4' (driver 'uvcvideo') supports video, capture, without mplanes.
> > > Video format: MJPEG (47504a4d) 1920x1080 (stride 0) field none buffer size 4147200
> > > …
> > > 100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE
> > > 101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE
> > > 102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE
> > > 103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE
> > > 104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE
> > > 105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE
> > > 106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE
> > > …
> > > 168 (0) [-] none 168 200914 B 215.183707 215.347066 33.676 fps ts mono/SoE
> > > 169 (1) [-] none 169 201141 B 215.271693 215.379066 11.365 fps ts mono/SoE
> > > 170 (2) [-] none 170 201005 B 215.303449 215.415057 31.490 fps ts mono/SoE
> > > 171 (3) [-] none 171 201195 B 215.335295 215.447062 31.401 fps ts mono/SoE
> > > 172 (4) [-] none 172 200933 B 215.557731 215.479072 4.496 fps ts mono/SoE
> > > 173 (5) [-] none 173 200973 B 215.587033 215.515063 34.127 fps ts mono/SoE
> > > 174 (6) [-] none 174 200698 B 215.616811 215.547063 33.582 fps ts mono/SoE
> > > 175 (7) [-] none 175 201290 B 215.646196 215.579075 34.031 fps ts mono/SoE
> > > 176 (0) [-] none 176 200807 B 215.675857 215.615073 33.714 fps ts mono/SoE
> > > …
> > > ```
> > >
> > > Does the above mean the webcam is affected?
> >
> > Looks like it.... could you try applying this patch and run with
> >
> > rmmod uvcvideo; modprobe uvcvideo hwtimestamps=1 quirks=0x4000
> >
> > to see if that fixes it for you?
>
> On top of v6.8, I've applied the whole v10, and also applied the following change instead of providing `quirks=`:
Could you send the patch to the ML, so Laurent can apply it on top of my set?
You could add the result of the experiment to the commit message
With those changes
Reviewed-by: Ricardo Ribalda <[email protected]>
Thanks!
>
> ```
> commit 884a61751d979ee9974c08a71c72e88e73bdd87e
> Author: Oleksandr Natalenko <[email protected]>
> Date: Mon Mar 25 10:28:00 2024 +0100
>
> media: uvcvideo: Quirk for invalid dev_sof in Logitech C920
>
> Signed-off-by: Oleksandr Natalenko <[email protected]>
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index 723e6d5680c2e..444d7089885ea 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2573,7 +2573,8 @@ static const struct usb_device_id uvc_ids[] = {
> .bInterfaceClass = USB_CLASS_VIDEO,
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> - .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) },
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT
> + | UVC_QUIRK_INVALID_DEVICE_SOF) },
> /* Logitech HD Pro Webcam C922 */
> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> | USB_DEVICE_ID_MATCH_INT_INFO,
>
> ```
>
> Now I see this:
>
> ```
> 154 (2) [-] none 154 192417 B 42.199823 42.207788 27.779 fps ts mono/SoE
> 155 (3) [-] none 155 192040 B 42.231834 42.239791 31.239 fps ts mono/SoE
> 156 (4) [-] none 156 192213 B 42.263823 42.271822 31.261 fps ts mono/SoE
> 157 (5) [-] none 157 191981 B 42.299824 42.303827 27.777 fps ts mono/SoE
> 158 (6) [-] none 158 191953 B 42.331835 42.339811 31.239 fps ts mono/SoE
> 159 (7) [-] none 159 191904 B 42.363824 42.371813 31.261 fps ts mono/SoE
> 160 (0) [-] none 160 192210 B 42.399834 42.407801 27.770 fps ts mono/SoE
> 161 (1) [-] none 161 192235 B 42.431824 42.439806 31.260 fps ts mono/SoE
> ```
>
> without dips in FPS.
>
> What do you think?
>
> >
> > Thanks!
> >
> > >
> > > Thank you.
> > >
> > > >
> > > >
> > > > Thanks!
> > > >
> > >
> > >
> > > --
> > > Oleksandr Natalenko (post-factum)
> >
> >
> >
> >
>
>
> --
> Oleksandr Natalenko (post-factum)
--
Ricardo Ribalda
On Sat, Mar 23, 2024 at 10:48:02AM +0000, Ricardo Ribalda wrote:
> The tail of the list lives at the position before the head. This is
> mathematically noted as:
> ```
> (head-1) mod size.
> ```
> Unfortunately C, does not have a modulus operator, but a remainder
> operator (%).
> The reminder operation has a different result than the modulus if
> (head -1) is a negative number and size is not a power of two.
>
> Adding size to (head-1) allows the code to run with any value of size.
>
> This does not change the current behaviour of the driver, as the size is
> always a power of two, but avoid tedious debugging if we ever change its
> size.
>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 7cbf4692bd875..659c9e9880a99 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -732,7 +732,7 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> goto done;
>
> first = &clock->samples[clock->head];
> - last = &clock->samples[(clock->head - 1) % clock->size];
> + last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
>
> /* First step, PTS to SOF conversion. */
> delta_stc = buf->pts - (1UL << 31);
>
> --
> 2.44.0.396.g6e790dbe36-goog
>
>
It could be worth mentioning that basically head == 0 is the problematic
case here, but otherwise good catch.
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
On Sat, Mar 23, 2024 at 10:48:03AM +0000, Ricardo Ribalda wrote:
> Some SunplusIT cameras took a borderline interpretation of the UVC 1.5
> standard, and fill the PTS and SCR fields with invalid data if the
> package does not contain data.
>
> "STC must be captured when the first video data of a video frame is put
> on the USB bus."
>
> Some SunplusIT devices send, e.g.,
>
> buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
> buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000
> buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a
>
> While the UVC specification meant that the first two packets shouldn't
> have had the SCR bit set in the header.
>
> This borderline/buggy interpretation has been implemented in a variety
> of devices, from directly SunplusIT and from other OEMs that rebrand
> SunplusIT products. So quirking based on VID:PID will be problematic.
>
> All the affected modules have the following extension unit:
> VideoControl Interface Descriptor:
> guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d}
>
> But the vendor plans to use that GUID in the future and fix the bug,
> this means that we should use heuristic to figure out the broken
> packets.
>
> This patch takes care of this.
>
> lsusb of one of the affected cameras:
>
> Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.01
> bDeviceClass 239 Miscellaneous Device
> bDeviceSubClass 2 ?
> bDeviceProtocol 1 Interface Association
> bMaxPacketSize0 64
> idVendor 0x1bcf Sunplus Innovation Technology Inc.
> idProduct 0x2a01
> bcdDevice 0.02
> iManufacturer 1 SunplusIT Inc
> iProduct 2 HanChen Wise Camera
> iSerial 3 01.00.00
> bNumConfigurations 1
>
> Tested-by: HungNien Chen <[email protected]>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Laurent Pinchart <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 659c9e9880a99..b2e70fcf4eb4c 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -478,6 +478,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> ktime_t time;
> u16 host_sof;
> u16 dev_sof;
> + u32 dev_stc;
>
> switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
> case UVC_STREAM_PTS | UVC_STREAM_SCR:
> @@ -526,6 +527,34 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> if (dev_sof == stream->clock.last_sof)
> return;
>
> + dev_stc = get_unaligned_le32(&data[header_size - 6]);
> +
> + /*
> + * STC (Source Time Clock) is the clock used by the camera. The UVC 1.5
> + * standard states that it "must be captured when the first video data
> + * of a video frame is put on the USB bus". This is generally understood
> + * as requiring devices to clear the payload header's SCR bit before
> + * the first packet containing video data.
> + *
> + * Most vendors follow that interpretation, but some (namely SunplusIT
> + * on some devices) always set the `UVC_STREAM_SCR` bit, fill the SCR
> + * field with 0's,and expect that the driver only processes the SCR if
> + * there is data in the packet.
> + *
> + * Ignore all the hardware timestamp information if we haven't received
> + * any data for this frame yet, the packet contains no data, and both
> + * STC and SOF are zero. This heuristics should be safe on compliant
> + * devices. This should be safe with compliant devices, as in the very
> + * unlikely case where a UVC 1.1 device would send timing information
> + * only before the first packet containing data, and both STC and SOF
> + * happen to be zero for a particular frame, we would only miss one
> + * clock sample from many and the clock recovery algorithm wouldn't
> + * suffer from this condition.
> + */
> + if (buf && buf->bytesused == 0 && len == header_size &&
> + dev_stc == 0 && dev_sof == 0)
> + return;
> +
> stream->clock.last_sof = dev_sof;
>
> host_sof = usb_get_current_frame_number(stream->dev->udev);
> @@ -564,7 +593,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> spin_lock_irqsave(&stream->clock.lock, flags);
>
> sample = &stream->clock.samples[stream->clock.head];
> - sample->dev_stc = get_unaligned_le32(&data[header_size - 6]);
> + sample->dev_stc = dev_stc;
> sample->dev_sof = dev_sof;
> sample->host_sof = host_sof;
> sample->host_time = time;
>
> --
> 2.44.0.396.g6e790dbe36-goog
>
>
On Sat, Mar 23, 2024 at 10:48:04AM +0000, Ricardo Ribalda wrote:
> Logitech C922 internal SOF does not increases at a stable rate of 1kHz.
> This causes that the device_sof and the host_sof run at different rates,
> breaking the clock domain conversion algorithm. Eg:
>
> 30 (6) [-] none 30 614400 B 21.245557 21.395214 34.133 fps ts mono/SoE
> 31 (7) [-] none 31 614400 B 21.275327 21.427246 33.591 fps ts mono/SoE
> 32 (0) [-] none 32 614400 B 21.304739 21.459256 34.000 fps ts mono/SoE
> 33 (1) [-] none 33 614400 B 21.334324 21.495274 33.801 fps ts mono/SoE
> * 34 (2) [-] none 34 614400 B 21.529237 21.527297 5.130 fps ts mono/SoE
> * 35 (3) [-] none 35 614400 B 21.649416 21.559306 8.321 fps ts mono/SoE
> 36 (4) [-] none 36 614400 B 21.678789 21.595320 34.045 fps ts mono/SoE
> ...
> 99 (3) [-] none 99 614400 B 23.542226 23.696352 33.541 fps ts mono/SoE
> 100 (4) [-] none 100 614400 B 23.571578 23.728404 34.069 fps ts mono/SoE
> 101 (5) [-] none 101 614400 B 23.601425 23.760420 33.504 fps ts mono/SoE
> * 102 (6) [-] none 102 614400 B 23.798324 23.796428 5.079 fps ts mono/SoE
> * 103 (7) [-] none 103 614400 B 23.916271 23.828450 8.478 fps ts mono/SoE
> 104 (0) [-] none 104 614400 B 23.945720 23.860479 33.957 fps ts mono/SoE
>
> Instead of disabling completely the hardware timestamping for such
> hardware we take the assumption that the packet handling jitter is
> under 2ms and use the host_sof as dev_sof.
>
> We can think of the UVC hardware clock as a system with a coarse clock
> (the SOF) and a fine clock (the PTS). The coarse clock can be replaced
> with a clock on the same frequency, if the jitter of such clock is
> smaller than its sampling rate. That way we can save some of the
> precision of the fine clock.
>
> To probe this point we have run three experiments on the Logitech C922.
> On that experiment we run the camera at 33fps and we analyse the
> difference in msec between a frame and its predecessor. If we display
> the histogram of that value, a thinner histogram will mean a better
> meassurement. The results for:
> - original hw timestamp: https://ibb.co/D1HJJ4x
> - pure software timestamp: https://ibb.co/QC9MgVK
> - modified hw timestamp: https://ibb.co/8s9dBdk
>
> This bug in the camera firmware has been confirmed by the vendor.
>
> lsusb -v
>
> Bus 001 Device 044: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 239 Miscellaneous Device
> bDeviceSubClass 2
> bDeviceProtocol 1 Interface Association
> bMaxPacketSize0 64
> idVendor 0x046d Logitech, Inc.
> idProduct 0x085c C922 Pro Stream Webcam
> bcdDevice 0.16
> iManufacturer 0
> iProduct 2 C922 Pro Stream Webcam
> iSerial 1 80B912DF
> bNumConfigurations 1
>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Laurent Pinchart <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_driver.c | 9 +++++++++
> drivers/media/usb/uvc/uvc_video.c | 11 +++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index bbd90123a4e76..723e6d5680c2e 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2574,6 +2574,15 @@ static const struct usb_device_id uvc_ids[] = {
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) },
> + /* Logitech HD Pro Webcam C922 */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x046d,
> + .idProduct = 0x085c,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_INVALID_DEVICE_SOF) },
> /* Chicony CNF7129 (Asus EEE 100HE) */
> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> | USB_DEVICE_ID_MATCH_INT_INFO,
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index b2e70fcf4eb4c..d6ca383f643e3 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -558,6 +558,17 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> stream->clock.last_sof = dev_sof;
>
> host_sof = usb_get_current_frame_number(stream->dev->udev);
> +
> + /*
> + * On some devices, like the Logitech C922, the device SOF does not run
> + * at a stable rate of 1kHz. For those devices use the host SOF instead.
> + * In the tests performed so far, this improves the timestamp precision.
> + * This is probably explained by a small packet handling jitter from the
> + * host, but the exact reason hasn't been fully determined.
Given that the counter increases at a low frequency (1 kHz), we have a
millisecond from when the frame is received to go into
uvc_video_clock_decode() and read it, which should be quite realistic in
normal conditions.
I suspect that under a relatively high interrupt load, with interrupts
of higher priority than USB host, we could end up with more jitter, but
it should be still better compared to the broken hw timestamp behavior
and not worse than sw timestamp, because that would be subjected to many
more factors introducing jitter.
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> With UVC 1.5 we get as little as one clock sample per frame. Which means
> that it takes 32 frames to move from the software timestamp to the
> hardware timestamp method.
>
> This results in abrupt changes in the timestamping after 32 frames (~1
> second), resulting in noticeable artifacts when used for encoding.
>
> With this patch we modify the update algorithm to work with whatever
> amount of values are available.
>
> Tested-by: HungNien Chen <[email protected]>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Laurent Pinchart <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index d6ca383f643e3..af25b9f1b53fe 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
>
> spin_lock_irqsave(&clock->lock, flags);
>
> - if (clock->count < clock->size)
> + if (clock->count < 2)
> goto done;
>
> - first = &clock->samples[clock->head];
> + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
>
> /* First step, PTS to SOF conversion. */
> @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> if (y2 < y1)
> y2 += 2048 << 16;
>
> + /*
> + * Have at least 1/4 of a second of timestamps before we
> + * try to do any calculation. Otherwise we do not have enough
> + * precision. This value was determined by running Android CTS
> + * on different devices.
> + *
> + * dev_sof runs at 1KHz, and we have a fixed point precision of
> + * 16 bits.
> + */
> + if ((y2 - y1) < ((1000 / 4) << 16))
> + goto done;
Not a comment for this patch directly, but...
This kind of makes me wonder if we don't want to have some documentation
that specifies what the userspace can expect from the timestamps, so
that this isn't changed randomly in the future breaking what was fixed
by this patch.
Anyway:
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
On Sat, Mar 23, 2024 at 10:48:06AM +0000, Ricardo Ribalda wrote:
> Isolate all the changes related to the clock circular buffer to its own
> function, that way we can make changes easier to the buffer logic.
>
> Also simplify the lock, by removing the circular buffer clock handling
> from uvc_video_clock_decode().
>
> And now that we are at it, unify the API of the clock functions.
>
> Tested-by: HungNien Chen <[email protected]>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Reviewed-by: Laurent Pinchart <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 83 +++++++++++++++++----------------------
> 1 file changed, 36 insertions(+), 47 deletions(-)
>
Very nice clean-up. Thanks!
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index af25b9f1b53fe..5df8f61d39cd1 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -466,19 +466,28 @@ static inline ktime_t uvc_video_get_time(void)
> return ktime_get_real();
> }
>
> +static void uvc_video_clock_add_sample(struct uvc_clock *clock,
> + const struct uvc_clock_sample *sample)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&clock->lock, flags);
> +
> + clock->samples[clock->head] = *sample;
> + clock->head = (clock->head + 1) % clock->size;
> + clock->count = min(clock->count + 1, clock->size);
> +
> + spin_unlock_irqrestore(&clock->lock, flags);
> +}
> +
> static void
> uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> const u8 *data, int len)
> {
> - struct uvc_clock_sample *sample;
> + struct uvc_clock_sample sample;
> unsigned int header_size;
> bool has_pts = false;
> bool has_scr = false;
> - unsigned long flags;
> - ktime_t time;
> - u16 host_sof;
> - u16 dev_sof;
> - u32 dev_stc;
>
> switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
> case UVC_STREAM_PTS | UVC_STREAM_SCR:
> @@ -523,11 +532,11 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> * all the data packets of the same frame contains the same SOF. In that
> * case only the first one will match the host_sof.
> */
> - dev_sof = get_unaligned_le16(&data[header_size - 2]);
> - if (dev_sof == stream->clock.last_sof)
> + sample.dev_sof = get_unaligned_le16(&data[header_size - 2]);
> + if (sample.dev_sof == stream->clock.last_sof)
> return;
>
> - dev_stc = get_unaligned_le32(&data[header_size - 6]);
> + sample.dev_stc = get_unaligned_le32(&data[header_size - 6]);
>
> /*
> * STC (Source Time Clock) is the clock used by the camera. The UVC 1.5
> @@ -552,12 +561,10 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> * suffer from this condition.
> */
> if (buf && buf->bytesused == 0 && len == header_size &&
> - dev_stc == 0 && dev_sof == 0)
> + sample.dev_stc == 0 && sample.dev_sof == 0)
> return;
>
> - stream->clock.last_sof = dev_sof;
> -
> - host_sof = usb_get_current_frame_number(stream->dev->udev);
> + sample.host_sof = usb_get_current_frame_number(stream->dev->udev);
>
> /*
> * On some devices, like the Logitech C922, the device SOF does not run
> @@ -567,9 +574,9 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> * host, but the exact reason hasn't been fully determined.
> */
> if (stream->dev->quirks & UVC_QUIRK_INVALID_DEVICE_SOF)
> - dev_sof = host_sof;
> + sample.dev_sof = sample.host_sof;
>
> - time = uvc_video_get_time();
> + sample.host_time = uvc_video_get_time();
>
> /*
> * The UVC specification allows device implementations that can't obtain
> @@ -592,46 +599,28 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
> * the 8 LSBs of the delta are kept.
> */
> if (stream->clock.sof_offset == (u16)-1) {
> - u16 delta_sof = (host_sof - dev_sof) & 255;
> + u16 delta_sof = (sample.host_sof - sample.dev_sof) & 255;
> if (delta_sof >= 10)
> stream->clock.sof_offset = delta_sof;
> else
> stream->clock.sof_offset = 0;
> }
>
> - dev_sof = (dev_sof + stream->clock.sof_offset) & 2047;
> -
> - spin_lock_irqsave(&stream->clock.lock, flags);
> -
> - sample = &stream->clock.samples[stream->clock.head];
> - sample->dev_stc = dev_stc;
> - sample->dev_sof = dev_sof;
> - sample->host_sof = host_sof;
> - sample->host_time = time;
> -
> - /* Update the sliding window head and count. */
> - stream->clock.head = (stream->clock.head + 1) % stream->clock.size;
> -
> - if (stream->clock.count < stream->clock.size)
> - stream->clock.count++;
> -
> - spin_unlock_irqrestore(&stream->clock.lock, flags);
> + sample.dev_sof = (sample.dev_sof + stream->clock.sof_offset) & 2047;
> + uvc_video_clock_add_sample(&stream->clock, &sample);
> + stream->clock.last_sof = sample.dev_sof;
> }
>
> -static void uvc_video_clock_reset(struct uvc_streaming *stream)
> +static void uvc_video_clock_reset(struct uvc_clock *clock)
> {
> - struct uvc_clock *clock = &stream->clock;
> -
> clock->head = 0;
> clock->count = 0;
> clock->last_sof = -1;
> clock->sof_offset = -1;
> }
>
> -static int uvc_video_clock_init(struct uvc_streaming *stream)
> +static int uvc_video_clock_init(struct uvc_clock *clock)
> {
> - struct uvc_clock *clock = &stream->clock;
> -
> spin_lock_init(&clock->lock);
> clock->size = 32;
>
> @@ -640,15 +629,15 @@ static int uvc_video_clock_init(struct uvc_streaming *stream)
> if (clock->samples == NULL)
> return -ENOMEM;
>
> - uvc_video_clock_reset(stream);
> + uvc_video_clock_reset(clock);
>
> return 0;
> }
>
> -static void uvc_video_clock_cleanup(struct uvc_streaming *stream)
> +static void uvc_video_clock_cleanup(struct uvc_clock *clock)
> {
> - kfree(stream->clock.samples);
> - stream->clock.samples = NULL;
> + kfree(clock->samples);
> + clock->samples = NULL;
> }
>
> /*
> @@ -2123,7 +2112,7 @@ int uvc_video_resume(struct uvc_streaming *stream, int reset)
>
> stream->frozen = 0;
>
> - uvc_video_clock_reset(stream);
> + uvc_video_clock_reset(&stream->clock);
>
> if (!uvc_queue_streaming(&stream->queue))
> return 0;
> @@ -2272,7 +2261,7 @@ int uvc_video_start_streaming(struct uvc_streaming *stream)
> {
> int ret;
>
> - ret = uvc_video_clock_init(stream);
> + ret = uvc_video_clock_init(&stream->clock);
> if (ret < 0)
> return ret;
>
> @@ -2290,7 +2279,7 @@ int uvc_video_start_streaming(struct uvc_streaming *stream)
> error_video:
> usb_set_interface(stream->dev->udev, stream->intfnum, 0);
> error_commit:
> - uvc_video_clock_cleanup(stream);
> + uvc_video_clock_cleanup(&stream->clock);
>
> return ret;
> }
> @@ -2318,5 +2307,5 @@ void uvc_video_stop_streaming(struct uvc_streaming *stream)
> usb_clear_halt(stream->dev->udev, pipe);
> }
>
> - uvc_video_clock_cleanup(stream);
> + uvc_video_clock_cleanup(&stream->clock);
> }
>
> --
> 2.44.0.396.g6e790dbe36-goog
>
>
On Sat, Mar 23, 2024 at 10:48:07AM +0000, Ricardo Ribalda wrote:
> In UVC 1.5 we get a single clock value per frame. With the current
> buffer size of 32, FPS slowers than 32 might roll-over twice.
>
> The current code cannot handle two roll-over and provide invalid
> timestamps.
>
> Remove all the samples from the circular buffer that are more than two
> rollovers old, so the algorithm always provides good timestamps.
>
> Note that we are removing values that are more than one second old,
> which means that there is enough distance between the two points that
> we use for the interpolation to provide good values.
>
> Tested-by: HungNien Chen <[email protected]>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 24 ++++++++++++++++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 5df8f61d39cd1..900b57afac93a 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -471,8 +471,31 @@ static void uvc_video_clock_add_sample(struct uvc_clock *clock,
> {
> unsigned long flags;
>
> + /*
> + * If we write new data on the position where we had the last
> + * overflow, remove the overflow pointer. There is no overflow
> + * on the whole circular buffer.
> + */
> + if (clock->head == clock->last_sof_overflow)
> + clock->last_sof_overflow = -1;
> +
> spin_lock_irqsave(&clock->lock, flags);
>
> + /* Handle overflows */
> + if (clock->count > 0 && clock->last_sof > sample->dev_sof) {
> + /*
> + * Remove data from the circular buffer that is older than the
> + * last overflow. We only support one overflow per circular
> + * buffer.
> + */
> + if (clock->last_sof_overflow != -1) {
> + clock->count = (clock->head - clock->last_sof_overflow
> + + clock->count) % clock->count;
> + }
> + clock->last_sof_overflow = clock->head;
> + }
> +
> + /* Add sample */
> clock->samples[clock->head] = *sample;
> clock->head = (clock->head + 1) % clock->size;
> clock->count = min(clock->count + 1, clock->size);
> @@ -616,6 +639,7 @@ static void uvc_video_clock_reset(struct uvc_clock *clock)
> clock->head = 0;
> clock->count = 0;
> clock->last_sof = -1;
> + clock->last_sof_overflow = -1;
> clock->sof_offset = -1;
> }
>
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index cb9dd50bba8ac..fb9f9771131ac 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -499,6 +499,7 @@ struct uvc_streaming {
> unsigned int head;
> unsigned int count;
> unsigned int size;
> + unsigned int last_sof_overflow;
>
> u16 last_sof;
> u16 sof_offset;
>
> --
> 2.44.0.396.g6e790dbe36-goog
>
>
Given that majority of cameras kind of run ~30 fps, this should improve
the timestamps for quite a lot of the users. Thanks.
Reviewed-by: Tomasz Figa <[email protected]>
Best regards,
Tomasz
Hi Ricardo,
Thank you for the patch.
On Sat, Mar 23, 2024 at 10:48:02AM +0000, Ricardo Ribalda wrote:
> The tail of the list lives at the position before the head. This is
> mathematically noted as:
> ```
> (head-1) mod size.
> ```
> Unfortunately C, does not have a modulus operator, but a remainder
> operator (%).
> The reminder operation has a different result than the modulus if
> (head -1) is a negative number and size is not a power of two.
>
> Adding size to (head-1) allows the code to run with any value of size.
>
> This does not change the current behaviour of the driver, as the size is
> always a power of two, but avoid tedious debugging if we ever change its
> size.
>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 7cbf4692bd875..659c9e9880a99 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -732,7 +732,7 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> goto done;
>
> first = &clock->samples[clock->head];
> - last = &clock->samples[(clock->head - 1) % clock->size];
> + last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
>
> /* First step, PTS to SOF conversion. */
> delta_stc = buf->pts - (1UL << 31);
>
--
Regards,
Laurent Pinchart
On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > that it takes 32 frames to move from the software timestamp to the
> > hardware timestamp method.
> >
> > This results in abrupt changes in the timestamping after 32 frames (~1
> > second), resulting in noticeable artifacts when used for encoding.
> >
> > With this patch we modify the update algorithm to work with whatever
> > amount of values are available.
> >
> > Tested-by: HungNien Chen <[email protected]>
> > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > Reviewed-by: Laurent Pinchart <[email protected]>
> > Signed-off-by: Ricardo Ribalda <[email protected]>
> > ---
> > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > index d6ca383f643e3..af25b9f1b53fe 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> >
> > spin_lock_irqsave(&clock->lock, flags);
> >
> > - if (clock->count < clock->size)
> > + if (clock->count < 2)
> > goto done;
> >
> > - first = &clock->samples[clock->head];
> > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> >
> > /* First step, PTS to SOF conversion. */
> > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > if (y2 < y1)
> > y2 += 2048 << 16;
> >
> > + /*
> > + * Have at least 1/4 of a second of timestamps before we
> > + * try to do any calculation. Otherwise we do not have enough
> > + * precision. This value was determined by running Android CTS
> > + * on different devices.
> > + *
> > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > + * 16 bits.
> > + */
> > + if ((y2 - y1) < ((1000 / 4) << 16))
> > + goto done;
>
> Not a comment for this patch directly, but...
>
> This kind of makes me wonder if we don't want to have some documentation
> that specifies what the userspace can expect from the timestamps, so
> that this isn't changed randomly in the future breaking what was fixed
> by this patch.
I think timestamp handling should really be moved to userspace. It will
be easier to handle with floating-point arithmetic there. That would
have been difficult to manage for applications a while ago, but now that
we have libcamera, we could implement it there. This isn't high on my
todo list though.
> Anyway:
>
> Reviewed-by: Tomasz Figa <[email protected]>
--
Regards,
Laurent Pinchart
Hi Ricardo,
Thank you for the patch.
On Sat, Mar 23, 2024 at 10:48:07AM +0000, Ricardo Ribalda wrote:
> In UVC 1.5 we get a single clock value per frame. With the current
> buffer size of 32, FPS slowers than 32 might roll-over twice.
>
> The current code cannot handle two roll-over and provide invalid
> timestamps.
>
> Remove all the samples from the circular buffer that are more than two
> rollovers old, so the algorithm always provides good timestamps.
>
> Note that we are removing values that are more than one second old,
> which means that there is enough distance between the two points that
> we use for the interpolation to provide good values.
>
> Tested-by: HungNien Chen <[email protected]>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
> Signed-off-by: Ricardo Ribalda <[email protected]>
> ---
> drivers/media/usb/uvc/uvc_video.c | 24 ++++++++++++++++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 5df8f61d39cd1..900b57afac93a 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -471,8 +471,31 @@ static void uvc_video_clock_add_sample(struct uvc_clock *clock,
> {
> unsigned long flags;
>
> + /*
> + * If we write new data on the position where we had the last
> + * overflow, remove the overflow pointer. There is no overflow
s/overflow/SOF overflow/
otherwise it sounds like a circular buffer overflow. Same in the other
comments below.
> + * on the whole circular buffer.
> + */
> + if (clock->head == clock->last_sof_overflow)
> + clock->last_sof_overflow = -1;
> +
> spin_lock_irqsave(&clock->lock, flags);
>
> + /* Handle overflows */
s/overflows/overflows./
> + if (clock->count > 0 && clock->last_sof > sample->dev_sof) {
> + /*
> + * Remove data from the circular buffer that is older than the
> + * last overflow. We only support one overflow per circular
> + * buffer.
> + */
> + if (clock->last_sof_overflow != -1) {
> + clock->count = (clock->head - clock->last_sof_overflow
> + + clock->count) % clock->count;
If I'm following you correctly here, you want to set count to the
distance between last_sof_overflow and head. Shouldn't it be
clock->count = (clock->head - clock->last_sof_overflow
+ clock->size) % clock->size;
> + }
No need for curly braces.
> + clock->last_sof_overflow = clock->head;
> + }
> +
> + /* Add sample */
s/sample/sample./
I still think it would be nicer to handle multiple rollovers correctly,
but that probably better handled by moving all the clock handling to
userspace. With the above issues addressed, I think this patch can go
in.
I could address all these issues when applying, but I'd like the count
-> size change to be tested first. You can submit a new version of this
patch only, I've applied the rest of the series to my tree already.
> clock->samples[clock->head] = *sample;
> clock->head = (clock->head + 1) % clock->size;
> clock->count = min(clock->count + 1, clock->size);
> @@ -616,6 +639,7 @@ static void uvc_video_clock_reset(struct uvc_clock *clock)
> clock->head = 0;
> clock->count = 0;
> clock->last_sof = -1;
> + clock->last_sof_overflow = -1;
> clock->sof_offset = -1;
> }
>
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index cb9dd50bba8ac..fb9f9771131ac 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -499,6 +499,7 @@ struct uvc_streaming {
> unsigned int head;
> unsigned int count;
> unsigned int size;
> + unsigned int last_sof_overflow;
>
> u16 last_sof;
> u16 sof_offset;
--
Regards,
Laurent Pinchart
On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart
<[email protected]> wrote:
>
> On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > that it takes 32 frames to move from the software timestamp to the
> > > hardware timestamp method.
> > >
> > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > second), resulting in noticeable artifacts when used for encoding.
> > >
> > > With this patch we modify the update algorithm to work with whatever
> > > amount of values are available.
> > >
> > > Tested-by: HungNien Chen <[email protected]>
> > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > ---
> > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > >
> > > spin_lock_irqsave(&clock->lock, flags);
> > >
> > > - if (clock->count < clock->size)
> > > + if (clock->count < 2)
> > > goto done;
> > >
> > > - first = &clock->samples[clock->head];
> > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > >
> > > /* First step, PTS to SOF conversion. */
> > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > if (y2 < y1)
> > > y2 += 2048 << 16;
> > >
> > > + /*
> > > + * Have at least 1/4 of a second of timestamps before we
> > > + * try to do any calculation. Otherwise we do not have enough
> > > + * precision. This value was determined by running Android CTS
> > > + * on different devices.
> > > + *
> > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > + * 16 bits.
> > > + */
> > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > + goto done;
> >
> > Not a comment for this patch directly, but...
> >
> > This kind of makes me wonder if we don't want to have some documentation
> > that specifies what the userspace can expect from the timestamps, so
> > that this isn't changed randomly in the future breaking what was fixed
> > by this patch.
>
> I think timestamp handling should really be moved to userspace. It will
> be easier to handle with floating-point arithmetic there. That would
> have been difficult to manage for applications a while ago, but now that
> we have libcamera, we could implement it there. This isn't high on my
> todo list though.
While indeed that would probably be a better way to handle the complex
logic if we designed the driver today, we already have userspace that
expects the timestamps to be handled correctly in the kernel. I
suspect moving it to the userspace would require some core V4L2
changes to define a new timestamp handling mode, where multiple raw
hardware timestamps are exposed to the userspace, instead of the high
level system monotonic one.
Best regards,
Tomasz
On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > that it takes 32 frames to move from the software timestamp to the
> > > > hardware timestamp method.
> > > >
> > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > second), resulting in noticeable artifacts when used for encoding.
> > > >
> > > > With this patch we modify the update algorithm to work with whatever
> > > > amount of values are available.
> > > >
> > > > Tested-by: HungNien Chen <[email protected]>
> > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > ---
> > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > >
> > > > spin_lock_irqsave(&clock->lock, flags);
> > > >
> > > > - if (clock->count < clock->size)
> > > > + if (clock->count < 2)
> > > > goto done;
> > > >
> > > > - first = &clock->samples[clock->head];
> > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > >
> > > > /* First step, PTS to SOF conversion. */
> > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > if (y2 < y1)
> > > > y2 += 2048 << 16;
> > > >
> > > > + /*
> > > > + * Have at least 1/4 of a second of timestamps before we
> > > > + * try to do any calculation. Otherwise we do not have enough
> > > > + * precision. This value was determined by running Android CTS
> > > > + * on different devices.
> > > > + *
> > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > + * 16 bits.
> > > > + */
> > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > + goto done;
> > >
> > > Not a comment for this patch directly, but...
> > >
> > > This kind of makes me wonder if we don't want to have some documentation
> > > that specifies what the userspace can expect from the timestamps, so
> > > that this isn't changed randomly in the future breaking what was fixed
> > > by this patch.
> >
> > I think timestamp handling should really be moved to userspace. It will
> > be easier to handle with floating-point arithmetic there. That would
> > have been difficult to manage for applications a while ago, but now that
> > we have libcamera, we could implement it there. This isn't high on my
> > todo list though.
>
> While indeed that would probably be a better way to handle the complex
> logic if we designed the driver today, we already have userspace that
> expects the timestamps to be handled correctly in the kernel. I
> suspect moving it to the userspace would require some core V4L2
> changes to define a new timestamp handling mode, where multiple raw
> hardware timestamps are exposed to the userspace, instead of the high
> level system monotonic one.
The uvcvideo driver already supports exposing the packet headers to
userspace through a metadata capture device, so I think we have all the
components we need. The only missing thing would be the implementation
in libcamera :-)
--
Regards,
Laurent Pinchart
On Wed, 12 Jun 2024 at 09:44, Laurent Pinchart
<[email protected]> wrote:
>
> On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> > On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > > that it takes 32 frames to move from the software timestamp to the
> > > > > hardware timestamp method.
> > > > >
> > > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > > second), resulting in noticeable artifacts when used for encoding.
> > > > >
> > > > > With this patch we modify the update algorithm to work with whatever
> > > > > amount of values are available.
> > > > >
> > > > > Tested-by: HungNien Chen <[email protected]>
> > > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > > ---
> > > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > >
> > > > > spin_lock_irqsave(&clock->lock, flags);
> > > > >
> > > > > - if (clock->count < clock->size)
> > > > > + if (clock->count < 2)
> > > > > goto done;
> > > > >
> > > > > - first = &clock->samples[clock->head];
> > > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > > >
> > > > > /* First step, PTS to SOF conversion. */
> > > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > if (y2 < y1)
> > > > > y2 += 2048 << 16;
> > > > >
> > > > > + /*
> > > > > + * Have at least 1/4 of a second of timestamps before we
> > > > > + * try to do any calculation. Otherwise we do not have enough
> > > > > + * precision. This value was determined by running Android CTS
> > > > > + * on different devices.
> > > > > + *
> > > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > > + * 16 bits.
> > > > > + */
> > > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > > + goto done;
> > > >
> > > > Not a comment for this patch directly, but...
> > > >
> > > > This kind of makes me wonder if we don't want to have some documentation
> > > > that specifies what the userspace can expect from the timestamps, so
> > > > that this isn't changed randomly in the future breaking what was fixed
> > > > by this patch.
> > >
> > > I think timestamp handling should really be moved to userspace. It will
> > > be easier to handle with floating-point arithmetic there. That would
> > > have been difficult to manage for applications a while ago, but now that
> > > we have libcamera, we could implement it there. This isn't high on my
> > > todo list though.
> >
> > While indeed that would probably be a better way to handle the complex
> > logic if we designed the driver today, we already have userspace that
> > expects the timestamps to be handled correctly in the kernel. I
> > suspect moving it to the userspace would require some core V4L2
> > changes to define a new timestamp handling mode, where multiple raw
> > hardware timestamps are exposed to the userspace, instead of the high
> > level system monotonic one.
>
> The uvcvideo driver already supports exposing the packet headers to
> userspace through a metadata capture device, so I think we have all the
> components we need. The only missing thing would be the implementation
> in libcamera :-)
We would still have to duplicate the quirk information in libcamera
and the kernel.
>
> --
> Regards,
>
> Laurent Pinchart
--
Ricardo Ribalda
On Wed, Jun 12, 2024 at 09:47:26AM +0200, Ricardo Ribalda wrote:
> On Wed, 12 Jun 2024 at 09:44, Laurent Pinchart
> <[email protected]> wrote:
> >
> > On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> > > On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > > > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > > > that it takes 32 frames to move from the software timestamp to the
> > > > > > hardware timestamp method.
> > > > > >
> > > > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > > > second), resulting in noticeable artifacts when used for encoding.
> > > > > >
> > > > > > With this patch we modify the update algorithm to work with whatever
> > > > > > amount of values are available.
> > > > > >
> > > > > > Tested-by: HungNien Chen <[email protected]>
> > > > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > > > ---
> > > > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > >
> > > > > > spin_lock_irqsave(&clock->lock, flags);
> > > > > >
> > > > > > - if (clock->count < clock->size)
> > > > > > + if (clock->count < 2)
> > > > > > goto done;
> > > > > >
> > > > > > - first = &clock->samples[clock->head];
> > > > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > > > >
> > > > > > /* First step, PTS to SOF conversion. */
> > > > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > > if (y2 < y1)
> > > > > > y2 += 2048 << 16;
> > > > > >
> > > > > > + /*
> > > > > > + * Have at least 1/4 of a second of timestamps before we
> > > > > > + * try to do any calculation. Otherwise we do not have enough
> > > > > > + * precision. This value was determined by running Android CTS
> > > > > > + * on different devices.
> > > > > > + *
> > > > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > > > + * 16 bits.
> > > > > > + */
> > > > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > > > + goto done;
> > > > >
> > > > > Not a comment for this patch directly, but...
> > > > >
> > > > > This kind of makes me wonder if we don't want to have some documentation
> > > > > that specifies what the userspace can expect from the timestamps, so
> > > > > that this isn't changed randomly in the future breaking what was fixed
> > > > > by this patch.
> > > >
> > > > I think timestamp handling should really be moved to userspace. It will
> > > > be easier to handle with floating-point arithmetic there. That would
> > > > have been difficult to manage for applications a while ago, but now that
> > > > we have libcamera, we could implement it there. This isn't high on my
> > > > todo list though.
> > >
> > > While indeed that would probably be a better way to handle the complex
> > > logic if we designed the driver today, we already have userspace that
> > > expects the timestamps to be handled correctly in the kernel. I
> > > suspect moving it to the userspace would require some core V4L2
> > > changes to define a new timestamp handling mode, where multiple raw
> > > hardware timestamps are exposed to the userspace, instead of the high
> > > level system monotonic one.
> >
> > The uvcvideo driver already supports exposing the packet headers to
> > userspace through a metadata capture device, so I think we have all the
> > components we need. The only missing thing would be the implementation
> > in libcamera :-)
>
> We would still have to duplicate the quirk information in libcamera
> and the kernel.
Sure, and there will be some level of code duplication. My point is that
I believe it can be done in userspace, and while small changes to the
clock handling on the kernel side are fine, if we wanted to change the
code significantly I think it would be better moved to userspace. I
don't have plans to work on this, and I'm not requesting anyone to do so
either at this point.
--
Regards,
Laurent Pinchart
On Wed, Jun 12, 2024 at 4:44 PM Laurent Pinchart
<[email protected]> wrote:
>
> On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> > On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > > that it takes 32 frames to move from the software timestamp to the
> > > > > hardware timestamp method.
> > > > >
> > > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > > second), resulting in noticeable artifacts when used for encoding.
> > > > >
> > > > > With this patch we modify the update algorithm to work with whatever
> > > > > amount of values are available.
> > > > >
> > > > > Tested-by: HungNien Chen <[email protected]>
> > > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > > ---
> > > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > >
> > > > > spin_lock_irqsave(&clock->lock, flags);
> > > > >
> > > > > - if (clock->count < clock->size)
> > > > > + if (clock->count < 2)
> > > > > goto done;
> > > > >
> > > > > - first = &clock->samples[clock->head];
> > > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > > >
> > > > > /* First step, PTS to SOF conversion. */
> > > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > if (y2 < y1)
> > > > > y2 += 2048 << 16;
> > > > >
> > > > > + /*
> > > > > + * Have at least 1/4 of a second of timestamps before we
> > > > > + * try to do any calculation. Otherwise we do not have enough
> > > > > + * precision. This value was determined by running Android CTS
> > > > > + * on different devices.
> > > > > + *
> > > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > > + * 16 bits.
> > > > > + */
> > > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > > + goto done;
> > > >
> > > > Not a comment for this patch directly, but...
> > > >
> > > > This kind of makes me wonder if we don't want to have some documentation
> > > > that specifies what the userspace can expect from the timestamps, so
> > > > that this isn't changed randomly in the future breaking what was fixed
> > > > by this patch.
> > >
> > > I think timestamp handling should really be moved to userspace. It will
> > > be easier to handle with floating-point arithmetic there. That would
> > > have been difficult to manage for applications a while ago, but now that
> > > we have libcamera, we could implement it there. This isn't high on my
> > > todo list though.
> >
> > While indeed that would probably be a better way to handle the complex
> > logic if we designed the driver today, we already have userspace that
> > expects the timestamps to be handled correctly in the kernel. I
> > suspect moving it to the userspace would require some core V4L2
> > changes to define a new timestamp handling mode, where multiple raw
> > hardware timestamps are exposed to the userspace, instead of the high
> > level system monotonic one.
>
> The uvcvideo driver already supports exposing the packet headers to
> userspace through a metadata capture device, so I think we have all the
> components we need. The only missing thing would be the implementation
> in libcamera :-)
Okay, I see. That would make it easier indeed. :)
That said, we still need to provide some valid timestamps in the
v4l2_buffer struct returned from DQBUF, as per the current API
contract, so we can't simply remove the timestamp handling code from
the kernel completely.
On Wed, Jun 12, 2024 at 5:21 PM Laurent Pinchart
<[email protected]> wrote:
>
> On Wed, Jun 12, 2024 at 09:47:26AM +0200, Ricardo Ribalda wrote:
> > On Wed, 12 Jun 2024 at 09:44, Laurent Pinchart
> > <[email protected]> wrote:
> > >
> > > On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> > > > On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > > > > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > > > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > > > > that it takes 32 frames to move from the software timestamp to the
> > > > > > > hardware timestamp method.
> > > > > > >
> > > > > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > > > > second), resulting in noticeable artifacts when used for encoding.
> > > > > > >
> > > > > > > With this patch we modify the update algorithm to work with whatever
> > > > > > > amount of values are available.
> > > > > > >
> > > > > > > Tested-by: HungNien Chen <[email protected]>
> > > > > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > > > > ---
> > > > > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > > >
> > > > > > > spin_lock_irqsave(&clock->lock, flags);
> > > > > > >
> > > > > > > - if (clock->count < clock->size)
> > > > > > > + if (clock->count < 2)
> > > > > > > goto done;
> > > > > > >
> > > > > > > - first = &clock->samples[clock->head];
> > > > > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > > > > >
> > > > > > > /* First step, PTS to SOF conversion. */
> > > > > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > > > if (y2 < y1)
> > > > > > > y2 += 2048 << 16;
> > > > > > >
> > > > > > > + /*
> > > > > > > + * Have at least 1/4 of a second of timestamps before we
> > > > > > > + * try to do any calculation. Otherwise we do not have enough
> > > > > > > + * precision. This value was determined by running Android CTS
> > > > > > > + * on different devices.
> > > > > > > + *
> > > > > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > > > > + * 16 bits.
> > > > > > > + */
> > > > > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > > > > + goto done;
> > > > > >
> > > > > > Not a comment for this patch directly, but...
> > > > > >
> > > > > > This kind of makes me wonder if we don't want to have some documentation
> > > > > > that specifies what the userspace can expect from the timestamps, so
> > > > > > that this isn't changed randomly in the future breaking what was fixed
> > > > > > by this patch.
> > > > >
> > > > > I think timestamp handling should really be moved to userspace. It will
> > > > > be easier to handle with floating-point arithmetic there. That would
> > > > > have been difficult to manage for applications a while ago, but now that
> > > > > we have libcamera, we could implement it there. This isn't high on my
> > > > > todo list though.
> > > >
> > > > While indeed that would probably be a better way to handle the complex
> > > > logic if we designed the driver today, we already have userspace that
> > > > expects the timestamps to be handled correctly in the kernel. I
> > > > suspect moving it to the userspace would require some core V4L2
> > > > changes to define a new timestamp handling mode, where multiple raw
> > > > hardware timestamps are exposed to the userspace, instead of the high
> > > > level system monotonic one.
> > >
> > > The uvcvideo driver already supports exposing the packet headers to
> > > userspace through a metadata capture device, so I think we have all the
> > > components we need. The only missing thing would be the implementation
> > > in libcamera :-)
> >
> > We would still have to duplicate the quirk information in libcamera
> > and the kernel.
>
> Sure, and there will be some level of code duplication. My point is that
> I believe it can be done in userspace, and while small changes to the
> clock handling on the kernel side are fine, if we wanted to change the
> code significantly I think it would be better moved to userspace.
Okay, that sounds much more reasonable. I guess I misunderstood your
original reply, sorry.
Best regards,
Tomasz
> I
> don't have plans to work on this, and I'm not requesting anyone to do so
> either at this point.
>
> --
> Regards,
>
> Laurent Pinchart
On Wed, Jun 12, 2024 at 05:35:38PM +0900, Tomasz Figa wrote:
> On Wed, Jun 12, 2024 at 4:44 PM Laurent Pinchart
> <[email protected]> wrote:
> >
> > On Wed, Jun 12, 2024 at 12:28:56PM +0900, Tomasz Figa wrote:
> > > On Mon, Jun 10, 2024 at 8:43 PM Laurent Pinchart wrote:
> > > > On Wed, May 29, 2024 at 05:03:08PM +0900, Tomasz Figa wrote:
> > > > > On Sat, Mar 23, 2024 at 10:48:05AM +0000, Ricardo Ribalda wrote:
> > > > > > With UVC 1.5 we get as little as one clock sample per frame. Which means
> > > > > > that it takes 32 frames to move from the software timestamp to the
> > > > > > hardware timestamp method.
> > > > > >
> > > > > > This results in abrupt changes in the timestamping after 32 frames (~1
> > > > > > second), resulting in noticeable artifacts when used for encoding.
> > > > > >
> > > > > > With this patch we modify the update algorithm to work with whatever
> > > > > > amount of values are available.
> > > > > >
> > > > > > Tested-by: HungNien Chen <[email protected]>
> > > > > > Reviewed-by: Sergey Senozhatsky <[email protected]>
> > > > > > Reviewed-by: Laurent Pinchart <[email protected]>
> > > > > > Signed-off-by: Ricardo Ribalda <[email protected]>
> > > > > > ---
> > > > > > drivers/media/usb/uvc/uvc_video.c | 16 ++++++++++++++--
> > > > > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > > > > index d6ca383f643e3..af25b9f1b53fe 100644
> > > > > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > > > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > > > > @@ -768,10 +768,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > >
> > > > > > spin_lock_irqsave(&clock->lock, flags);
> > > > > >
> > > > > > - if (clock->count < clock->size)
> > > > > > + if (clock->count < 2)
> > > > > > goto done;
> > > > > >
> > > > > > - first = &clock->samples[clock->head];
> > > > > > + first = &clock->samples[(clock->head - clock->count + clock->size) % clock->size];
> > > > > > last = &clock->samples[(clock->head - 1 + clock->size) % clock->size];
> > > > > >
> > > > > > /* First step, PTS to SOF conversion. */
> > > > > > @@ -786,6 +786,18 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
> > > > > > if (y2 < y1)
> > > > > > y2 += 2048 << 16;
> > > > > >
> > > > > > + /*
> > > > > > + * Have at least 1/4 of a second of timestamps before we
> > > > > > + * try to do any calculation. Otherwise we do not have enough
> > > > > > + * precision. This value was determined by running Android CTS
> > > > > > + * on different devices.
> > > > > > + *
> > > > > > + * dev_sof runs at 1KHz, and we have a fixed point precision of
> > > > > > + * 16 bits.
> > > > > > + */
> > > > > > + if ((y2 - y1) < ((1000 / 4) << 16))
> > > > > > + goto done;
> > > > >
> > > > > Not a comment for this patch directly, but...
> > > > >
> > > > > This kind of makes me wonder if we don't want to have some documentation
> > > > > that specifies what the userspace can expect from the timestamps, so
> > > > > that this isn't changed randomly in the future breaking what was fixed
> > > > > by this patch.
> > > >
> > > > I think timestamp handling should really be moved to userspace. It will
> > > > be easier to handle with floating-point arithmetic there. That would
> > > > have been difficult to manage for applications a while ago, but now that
> > > > we have libcamera, we could implement it there. This isn't high on my
> > > > todo list though.
> > >
> > > While indeed that would probably be a better way to handle the complex
> > > logic if we designed the driver today, we already have userspace that
> > > expects the timestamps to be handled correctly in the kernel. I
> > > suspect moving it to the userspace would require some core V4L2
> > > changes to define a new timestamp handling mode, where multiple raw
> > > hardware timestamps are exposed to the userspace, instead of the high
> > > level system monotonic one.
> >
> > The uvcvideo driver already supports exposing the packet headers to
> > userspace through a metadata capture device, so I think we have all the
> > components we need. The only missing thing would be the implementation
> > in libcamera :-)
>
> Okay, I see. That would make it easier indeed. :)
>
> That said, we still need to provide some valid timestamps in the
> v4l2_buffer struct returned from DQBUF, as per the current API
> contract, so we can't simply remove the timestamp handling code from
> the kernel completely.
We could pass the system timestamp, the same way the driver used to
before getting clock recovery support. That being said, I'm not calling
for this code to be dropped overnight, it can stay there.
--
Regards,
Laurent Pinchart