| Message ID | 20230920125939.1478-1-ricardo@ribalda.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | yavta: Format type errors for non x86 arches | expand |
Hi Ricardo, Thanks for the update. On Wed, Sep 20, 2023 at 02:59:39PM +0200, Ricardo Ribalda wrote: > mipsel64el, ppc64el, ia64, ppc64, sparc64 and x32 have different lenghts > for long long ints, which result in some compilation errors. > > Lets add some castings and inttypes macros to help the compiler deal with > this. > > We have to use the castings, because kernel types (__u64 et al) does not > seem to be compatible with inttypes macros. > > Signed-off-by: Ricardo Ribalda <ricardo@ribalda.com> It'd be great to address this in the kernel. The kernel UAPI integer types have been around for a very long time so there could be issues in doing that, too. Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
@Laurent Pinchart Friendly Ping :) On Wed, Sep 20, 2023 at 10:06 PM Sakari Ailus <sakari.ailus@iki.fi> wrote: > > Hi Ricardo, > > Thanks for the update. > > On Wed, Sep 20, 2023 at 02:59:39PM +0200, Ricardo Ribalda wrote: > > mipsel64el, ppc64el, ia64, ppc64, sparc64 and x32 have different lenghts > > for long long ints, which result in some compilation errors. > > > > Lets add some castings and inttypes macros to help the compiler deal with > > this. > > > > We have to use the castings, because kernel types (__u64 et al) does not > > seem to be compatible with inttypes macros. > > > > Signed-off-by: Ricardo Ribalda <ricardo@ribalda.com> > > It'd be great to address this in the kernel. The kernel UAPI integer types > have been around for a very long time so there could be issues in doing > that, too. > > Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > -- > Kind regards, > > Sakari Ailus
Hi Laurent I can see that you updated yavta recently... Any chance that you can take a look at this? Thanks! On Fri, Oct 20, 2023 at 9:07 AM Ricardo Ribalda Delgado <ricardo@ribalda.com> wrote: > > @Laurent Pinchart > > Friendly Ping :) > > On Wed, Sep 20, 2023 at 10:06 PM Sakari Ailus <sakari.ailus@iki.fi> wrote: > > > > Hi Ricardo, > > > > Thanks for the update. > > > > On Wed, Sep 20, 2023 at 02:59:39PM +0200, Ricardo Ribalda wrote: > > > mipsel64el, ppc64el, ia64, ppc64, sparc64 and x32 have different lenghts > > > for long long ints, which result in some compilation errors. > > > > > > Lets add some castings and inttypes macros to help the compiler deal with > > > this. > > > > > > We have to use the castings, because kernel types (__u64 et al) does not > > > seem to be compatible with inttypes macros. > > > > > > Signed-off-by: Ricardo Ribalda <ricardo@ribalda.com> > > > > It'd be great to address this in the kernel. The kernel UAPI integer types > > have been around for a very long time so there could be issues in doing > > that, too. > > > > Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > -- > > Kind regards, > > > > Sakari Ailus
diff --git a/yavta.c b/yavta.c index d562863..d8c9d14 100644 --- a/yavta.c +++ b/yavta.c @@ -1313,7 +1313,8 @@ static void video_query_menu(struct device *dev, printf(" %u: %.32s%s\n", menu.index, menu.name, menu.index == value ? " (*)" : ""); else - printf(" %u: %lld%s\n", menu.index, menu.value, + printf(" %u: %" PRId64 "%s\n", menu.index, + (int64_t)menu.value, menu.index == value ? " (*)" : ""); }; } @@ -1360,7 +1361,7 @@ static void video_print_control_value(const struct v4l2_query_ext_ctrl *query, printf("0x%08x", ctrl->value); break; case V4L2_CTRL_TYPE_INTEGER64: - printf("%lld", ctrl->value64); + printf("%" PRId64, (int64_t)ctrl->value64); break; case V4L2_CTRL_TYPE_STRING: printf("%s", ctrl->string); @@ -1399,9 +1400,10 @@ static int video_get_control(struct device *dev, } if (full) { - printf("control 0x%08x `%s' min %lld max %lld step %lld default %lld ", - query->id, query->name, query->minimum, query->maximum, - query->step, query->default_value); + printf("control 0x%08x `%s' min %" PRId64 " max %" PRId64 " step %" PRIu64 " default %" PRId64 " ", + query->id, query->name, (int64_t)query->minimum, + (int64_t)query->maximum, (uint64_t)query->step, + (int64_t)query->default_value); if (query->nr_of_dims) { for (i = 0; i < query->nr_of_dims; ++i) printf("[%u]", query->dims[i]); @@ -2190,13 +2192,16 @@ static int video_do_capture(struct device *dev, unsigned int nframes, clock_gettime(CLOCK_MONOTONIC, &ts); get_ts_flags(buf.flags, &ts_type, &ts_source); - printf("%u (%u) [%c] %s %u %u B %ld.%06ld %ld.%06ld %.3f fps ts %s/%s\n", i, buf.index, - (buf.flags & V4L2_BUF_FLAG_ERROR) ? 'E' : '-', - v4l2_field_name(buf.field), - buf.sequence, video_buffer_bytes_used(dev, &buf), - buf.timestamp.tv_sec, buf.timestamp.tv_usec, - ts.tv_sec, ts.tv_nsec/1000, fps, - ts_type, ts_source); + printf("%u (%u) [%c] %s %u %u B %" PRId64 ".%06" PRId64 " %" PRId64 ".%06" PRId64 " %.3f fps ts %s/%s\n", + i, buf.index, + (buf.flags & V4L2_BUF_FLAG_ERROR) ? 'E' : '-', + v4l2_field_name(buf.field), + buf.sequence, video_buffer_bytes_used(dev, &buf), + (int64_t)buf.timestamp.tv_sec, + (int64_t)buf.timestamp.tv_usec, + (int64_t)ts.tv_sec, + (int64_t)(ts.tv_nsec / 1000), fps, + ts_type, ts_source); last = buf.timestamp; @@ -2252,8 +2257,9 @@ static int video_do_capture(struct device *dev, unsigned int nframes, bps = size/(ts.tv_nsec/1000.0+1000000.0*ts.tv_sec)*1000000.0; fps = i/(ts.tv_nsec/1000.0+1000000.0*ts.tv_sec)*1000000.0; - printf("Captured %u frames in %lu.%06lu seconds (%f fps, %f B/s).\n", - i, ts.tv_sec, ts.tv_nsec/1000, fps, bps); + printf("Captured %u frames in %" PRId64 ".%06" PRId64 " seconds (%f fps, %f B/s).\n", + i, (int64_t)ts.tv_sec, (int64_t)(ts.tv_nsec / 1000), fps, + bps); done: video_free_buffers(dev);
mipsel64el, ppc64el, ia64, ppc64, sparc64 and x32 have different lenghts for long long ints, which result in some compilation errors. Lets add some castings and inttypes macros to help the compiler deal with this. We have to use the castings, because kernel types (__u64 et al) does not seem to be compatible with inttypes macros. Signed-off-by: Ricardo Ribalda <ricardo@ribalda.com> --- yavta.c | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-)