| Message ID | 20250623081922.96900-1-barnabas.pocze@ideasonboard.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series |
|
| Related | show |
Hi Barnabás, Thanks for updating this. On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze <barnabas.pocze@ideasonboard.com> wrote: > > The description of the control mentions SensorTimestamp multiple > times, but it omits that the two do not have the same units. > Clarify that. > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > --- > > Or could it easily be converted to nanoseconds? Is there an overflow issue > in the ClockRecovery class in that case? What was the motivation for making > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > across a network, etc?) > > --- > src/libcamera/control_ids_core.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > index 028919ef3..0708ec7cc 100644 > --- a/src/libcamera/control_ids_core.yaml > +++ b/src/libcamera/control_ids_core.yaml > @@ -1272,7 +1272,8 @@ controls: > description: | > This timestamp corresponds to the same moment in time as the > SensorTimestamp, but is represented as a wall clock time as measured by > - the CLOCK_REALTIME clock. > + the CLOCK_REALTIME clock. Note that this control measures time in units > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > Being a wall clock measurement, it can be used to synchronise timing > across different devices. > -- > 2.50.0
Quoting Naushir Patuck (2025-06-23 11:44:54) > Hi Barnabás, > > Thanks for updating this. > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze > <barnabas.pocze@ideasonboard.com> wrote: > > > > The description of the control mentions SensorTimestamp multiple > > times, but it omits that the two do not have the same units. > > Clarify that. > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > --- > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > in the ClockRecovery class in that case? What was the motivation for making > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > across a network, etc?) Would this be more beneficial for the accuracy of the sync algorithm? (And also keep both timestamps 'aligned' for units usage?) > > > > --- > > src/libcamera/control_ids_core.yaml | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > index 028919ef3..0708ec7cc 100644 > > --- a/src/libcamera/control_ids_core.yaml > > +++ b/src/libcamera/control_ids_core.yaml > > @@ -1272,7 +1272,8 @@ controls: > > description: | Should we maybe have some sort of explicit units field on controls when it makes sense? > > This timestamp corresponds to the same moment in time as the > > SensorTimestamp, but is represented as a wall clock time as measured by > > - the CLOCK_REALTIME clock. > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > Being a wall clock measurement, it can be used to synchronise timing > > across different devices. > > -- > > 2.50.0
On Mon, 23 Jun 2025 at 12:59, Kieran Bingham <kieran.bingham@ideasonboard.com> wrote: > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > Hi Barnabás, > > > > Thanks for updating this. > > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze > > <barnabas.pocze@ideasonboard.com> wrote: > > > > > > The description of the control mentions SensorTimestamp multiple > > > times, but it omits that the two do not have the same units. > > > Clarify that. > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > --- > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > in the ClockRecovery class in that case? What was the motivation for making > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > across a network, etc?) > > Would this be more beneficial for the accuracy of the sync algorithm? > (And also keep both timestamps 'aligned' for units usage?) No benefit wrt accuracy going from us to ns in the sync algorithm. The only benefit would be to align the units for these two controls. But, to be honest, I don't think that's such a big deal either. Naush > > > > > > > --- > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > index 028919ef3..0708ec7cc 100644 > > > --- a/src/libcamera/control_ids_core.yaml > > > +++ b/src/libcamera/control_ids_core.yaml > > > @@ -1272,7 +1272,8 @@ controls: > > > description: | > > Should we maybe have some sort of explicit units field on controls when > it makes sense? > > > > This timestamp corresponds to the same moment in time as the > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > - the CLOCK_REALTIME clock. > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > across different devices. > > > -- > > > 2.50.0
On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > Quoting Naushir Patuck (2025-06-23 11:44:54) > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > The description of the control mentions SensorTimestamp multiple > > > times, but it omits that the two do not have the same units. > > > Clarify that. > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > --- > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > in the ClockRecovery class in that case? What was the motivation for making > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > across a network, etc?) > > Would this be more beneficial for the accuracy of the sync algorithm? > (And also keep both timestamps 'aligned' for units usage?) I would really like to standardize on the same unit for all timestamps, unless there's a compeling reason not to do so. > > > > > > --- > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > index 028919ef3..0708ec7cc 100644 > > > --- a/src/libcamera/control_ids_core.yaml > > > +++ b/src/libcamera/control_ids_core.yaml > > > @@ -1272,7 +1272,8 @@ controls: > > > description: | > > Should we maybe have some sort of explicit units field on controls when > it makes sense? That could be an interesting addition, but I'm not sure yet how useful it would be in practice. > > > This timestamp corresponds to the same moment in time as the > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > - the CLOCK_REALTIME clock. > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > across different devices.
Quoting Laurent Pinchart (2025-06-23 13:38:36) > On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > > > The description of the control mentions SensorTimestamp multiple > > > > times, but it omits that the two do not have the same units. > > > > Clarify that. > > > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > > > --- > > > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > > in the ClockRecovery class in that case? What was the motivation for making > > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > > across a network, etc?) > > > > Would this be more beneficial for the accuracy of the sync algorithm? > > (And also keep both timestamps 'aligned' for units usage?) > > I would really like to standardize on the same unit for all timestamps, > unless there's a compeling reason not to do so. I'd probably be on this side of the fence too ... it seems confusing to me to have timestamps in different units in different places... I wish I'd noticed that before I merged the control ;-( -- Kieran > > > > > > > > > --- > > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > > index 028919ef3..0708ec7cc 100644 > > > > --- a/src/libcamera/control_ids_core.yaml > > > > +++ b/src/libcamera/control_ids_core.yaml > > > > @@ -1272,7 +1272,8 @@ controls: > > > > description: | > > > > Should we maybe have some sort of explicit units field on controls when > > it makes sense? > > That could be an interesting addition, but I'm not sure yet how useful > it would be in practice. > > > > > This timestamp corresponds to the same moment in time as the > > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > > - the CLOCK_REALTIME clock. > > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > > across different devices. > > -- > Regards, > > Laurent Pinchart
On Mon, 23 Jun 2025 at 15:58, Kieran Bingham <kieran.bingham@ideasonboard.com> wrote: > > Quoting Laurent Pinchart (2025-06-23 13:38:36) > > On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > > > > > The description of the control mentions SensorTimestamp multiple > > > > > times, but it omits that the two do not have the same units. > > > > > Clarify that. > > > > > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > > > > > --- > > > > > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > > > in the ClockRecovery class in that case? What was the motivation for making > > > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > > > across a network, etc?) > > > > > > Would this be more beneficial for the accuracy of the sync algorithm? > > > (And also keep both timestamps 'aligned' for units usage?) > > > > I would really like to standardize on the same unit for all timestamps, > > unless there's a compeling reason not to do so. > > I'd probably be on this side of the fence too ... it seems confusing to > me to have timestamps in different units in different places... > > I wish I'd noticed that before I merged the control ;-( So what's the plan here? I think ns might be a bit overkill, but if we prefer to use the same units throughout this can be changed. Regards, Naush > > -- > Kieran > > > > > > > > > > > > > > --- > > > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > > > index 028919ef3..0708ec7cc 100644 > > > > > --- a/src/libcamera/control_ids_core.yaml > > > > > +++ b/src/libcamera/control_ids_core.yaml > > > > > @@ -1272,7 +1272,8 @@ controls: > > > > > description: | > > > > > > Should we maybe have some sort of explicit units field on controls when > > > it makes sense? > > > > That could be an interesting addition, but I'm not sure yet how useful > > it would be in practice. > > > > > > > This timestamp corresponds to the same moment in time as the > > > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > > > - the CLOCK_REALTIME clock. > > > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > > > across different devices. > > > > -- > > Regards, > > > > Laurent Pinchart
Quoting Naushir Patuck (2025-07-07 09:25:04) > On Mon, 23 Jun 2025 at 15:58, Kieran Bingham > <kieran.bingham@ideasonboard.com> wrote: > > > > Quoting Laurent Pinchart (2025-06-23 13:38:36) > > > On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > > > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > > > > > > > The description of the control mentions SensorTimestamp multiple > > > > > > times, but it omits that the two do not have the same units. > > > > > > Clarify that. > > > > > > > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > > > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > > > > > > > --- > > > > > > > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > > > > in the ClockRecovery class in that case? What was the motivation for making > > > > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > > > > across a network, etc?) > > > > > > > > Would this be more beneficial for the accuracy of the sync algorithm? > > > > (And also keep both timestamps 'aligned' for units usage?) > > > > > > I would really like to standardize on the same unit for all timestamps, > > > unless there's a compeling reason not to do so. > > > > I'd probably be on this side of the fence too ... it seems confusing to > > me to have timestamps in different units in different places... > > > > I wish I'd noticed that before I merged the control ;-( > > So what's the plan here? I think ns might be a bit overkill, but if > we prefer to use the same units throughout this can be changed. I think https://github.com/raspberrypi/libcamera/issues/283 probably indicates users expect the units to be the same too. So ideally we need a patch to both the control documentation and the implementation, before the next release... -- Kieran > > Regards, > Naush > > > > > > -- > > Kieran > > > > > > > > > > > > > > > > > > > --- > > > > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > > > > index 028919ef3..0708ec7cc 100644 > > > > > > --- a/src/libcamera/control_ids_core.yaml > > > > > > +++ b/src/libcamera/control_ids_core.yaml > > > > > > @@ -1272,7 +1272,8 @@ controls: > > > > > > description: | > > > > > > > > Should we maybe have some sort of explicit units field on controls when > > > > it makes sense? > > > > > > That could be an interesting addition, but I'm not sure yet how useful > > > it would be in practice. > > > > > > > > > This timestamp corresponds to the same moment in time as the > > > > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > > > > - the CLOCK_REALTIME clock. > > > > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > > > > across different devices. > > > > > > -- > > > Regards, > > > > > > Laurent Pinchart
On Mon, 7 Jul 2025 at 12:00, Kieran Bingham <kieran.bingham@ideasonboard.com> wrote: > > Quoting Naushir Patuck (2025-07-07 09:25:04) > > On Mon, 23 Jun 2025 at 15:58, Kieran Bingham > > <kieran.bingham@ideasonboard.com> wrote: > > > > > > Quoting Laurent Pinchart (2025-06-23 13:38:36) > > > > On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > > > > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > > > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > > > > > > > > > The description of the control mentions SensorTimestamp multiple > > > > > > > times, but it omits that the two do not have the same units. > > > > > > > Clarify that. > > > > > > > > > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > > > > > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > > > > > > > > > --- > > > > > > > > > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > > > > > in the ClockRecovery class in that case? What was the motivation for making > > > > > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > > > > > across a network, etc?) > > > > > > > > > > Would this be more beneficial for the accuracy of the sync algorithm? > > > > > (And also keep both timestamps 'aligned' for units usage?) > > > > > > > > I would really like to standardize on the same unit for all timestamps, > > > > unless there's a compeling reason not to do so. > > > > > > I'd probably be on this side of the fence too ... it seems confusing to > > > me to have timestamps in different units in different places... > > > > > > I wish I'd noticed that before I merged the control ;-( > > > > So what's the plan here? I think ns might be a bit overkill, but if > > we prefer to use the same units throughout this can be changed. > > I think https://github.com/raspberrypi/libcamera/issues/283 probably > indicates users expect the units to be the same too. Indeed, that's what made me come back to this. > > So ideally we need a patch to both the control documentation and the > implementation, before the next release... Sure, shall I post a patch? > > -- > Kieran > > > > > > > Regards, > > Naush > > > > > > > > > > -- > > > Kieran > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > > > > > index 028919ef3..0708ec7cc 100644 > > > > > > > --- a/src/libcamera/control_ids_core.yaml > > > > > > > +++ b/src/libcamera/control_ids_core.yaml > > > > > > > @@ -1272,7 +1272,8 @@ controls: > > > > > > > description: | > > > > > > > > > > Should we maybe have some sort of explicit units field on controls when > > > > > it makes sense? > > > > > > > > That could be an interesting addition, but I'm not sure yet how useful > > > > it would be in practice. > > > > > > > > > > > This timestamp corresponds to the same moment in time as the > > > > > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > > > > > - the CLOCK_REALTIME clock. > > > > > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > > > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > > > > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > > > > > across different devices. > > > > > > > > -- > > > > Regards, > > > > > > > > Laurent Pinchart
Quoting Naushir Patuck (2025-07-07 12:36:35) > On Mon, 7 Jul 2025 at 12:00, Kieran Bingham > <kieran.bingham@ideasonboard.com> wrote: > > > > Quoting Naushir Patuck (2025-07-07 09:25:04) > > > On Mon, 23 Jun 2025 at 15:58, Kieran Bingham > > > <kieran.bingham@ideasonboard.com> wrote: > > > > > > > > Quoting Laurent Pinchart (2025-06-23 13:38:36) > > > > > On Mon, Jun 23, 2025 at 12:59:49PM +0100, Kieran Bingham wrote: > > > > > > Quoting Naushir Patuck (2025-06-23 11:44:54) > > > > > > > On Mon, 23 Jun 2025 at 09:19, Barnabás Pőcze wrote: > > > > > > > > > > > > > > > > The description of the control mentions SensorTimestamp multiple > > > > > > > > times, but it omits that the two do not have the same units. > > > > > > > > Clarify that. > > > > > > > > > > > > > > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> > > > > > > > > > > > > > > Reviewed-by: Naushir Patuck <naush@raspberrypi.com> > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > Or could it easily be converted to nanoseconds? Is there an overflow issue > > > > > > > > in the ClockRecovery class in that case? What was the motivation for making > > > > > > > > it μs? (I suppose nanosecond resolution is not that useful when synchronizing > > > > > > > > across a network, etc?) > > > > > > > > > > > > Would this be more beneficial for the accuracy of the sync algorithm? > > > > > > (And also keep both timestamps 'aligned' for units usage?) > > > > > > > > > > I would really like to standardize on the same unit for all timestamps, > > > > > unless there's a compeling reason not to do so. > > > > > > > > I'd probably be on this side of the fence too ... it seems confusing to > > > > me to have timestamps in different units in different places... > > > > > > > > I wish I'd noticed that before I merged the control ;-( > > > > > > So what's the plan here? I think ns might be a bit overkill, but if > > > we prefer to use the same units throughout this can be changed. > > > > I think https://github.com/raspberrypi/libcamera/issues/283 probably > > indicates users expect the units to be the same too. > > Indeed, that's what made me come back to this. > > > > > So ideally we need a patch to both the control documentation and the > > implementation, before the next release... > > Sure, shall I post a patch? Yes please! My hesitation on my side is that we now need to coordinate with Raspberry Pi usages! So if you can handle it then I know everything is aligned. Thanks -- Kieran > > > > > > -- > > Kieran > > > > > > > > > > > > Regards, > > > Naush > > > > > > > > > > > > > > -- > > > > Kieran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > src/libcamera/control_ids_core.yaml | 3 ++- > > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml > > > > > > > > index 028919ef3..0708ec7cc 100644 > > > > > > > > --- a/src/libcamera/control_ids_core.yaml > > > > > > > > +++ b/src/libcamera/control_ids_core.yaml > > > > > > > > @@ -1272,7 +1272,8 @@ controls: > > > > > > > > description: | > > > > > > > > > > > > Should we maybe have some sort of explicit units field on controls when > > > > > > it makes sense? > > > > > > > > > > That could be an interesting addition, but I'm not sure yet how useful > > > > > it would be in practice. > > > > > > > > > > > > > This timestamp corresponds to the same moment in time as the > > > > > > > > SensorTimestamp, but is represented as a wall clock time as measured by > > > > > > > > - the CLOCK_REALTIME clock. > > > > > > > > + the CLOCK_REALTIME clock. Note that this control measures time in units > > > > > > > > + of microseconds as opposed to nanoseconds in case of SensorTimestamp. > > > > > > > > > > > > > > > > Being a wall clock measurement, it can be used to synchronise timing > > > > > > > > across different devices. > > > > > > > > > > -- > > > > > Regards, > > > > > > > > > > Laurent Pinchart
diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml index 028919ef3..0708ec7cc 100644 --- a/src/libcamera/control_ids_core.yaml +++ b/src/libcamera/control_ids_core.yaml @@ -1272,7 +1272,8 @@ controls: description: | This timestamp corresponds to the same moment in time as the SensorTimestamp, but is represented as a wall clock time as measured by - the CLOCK_REALTIME clock. + the CLOCK_REALTIME clock. Note that this control measures time in units + of microseconds as opposed to nanoseconds in case of SensorTimestamp. Being a wall clock measurement, it can be used to synchronise timing across different devices.
The description of the control mentions SensorTimestamp multiple times, but it omits that the two do not have the same units. Clarify that. Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> --- Or could it easily be converted to nanoseconds? Is there an overflow issue in the ClockRecovery class in that case? What was the motivation for making it μs? (I suppose nanosecond resolution is not that useful when synchronizing across a network, etc?) --- src/libcamera/control_ids_core.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.50.0