All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 4/6 v5] uvcvideo: add a metadata device node
Date: Fri, 28 Jul 2017 15:03:13 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.1707281453220.16637@axis700.grange> (raw)
In-Reply-To: <ee61391f-4183-eaf3-437a-666652cd4f23@xs4all.nl>

Hi Hans,

On Fri, 28 Jul 2017, Hans Verkuil wrote:

> On 07/28/2017 02:33 PM, Guennadi Liakhovetski wrote:

[snip]

> > +/**
> > + * struct uvc_meta_buf - metadata buffer building block
> > + * @ns		- system timestamp of the payload in nanoseconds
> > + * @sof		- USB Frame Number
> > + * @length	- length of the payload header
> > + * @flags	- payload header flags
> > + * @buf		- optional device-specific header data
> > + *
> > + * UVC metadata nodes fill buffers with possibly multiple instances of this
> > + * struct. The first two fields are added by the driver, they can be used for
> > + * clock synchronisation. The rest is an exact copy of a UVC payload header.
> > + * Only complete objects with complete buffers are included. Therefore it's
> > + * always sizeof(meta->ts) + sizeof(meta->sof) + meta->length bytes large.
> > + */
> > +struct uvc_meta_buf {
> > +	__u64 ns;
> > +	__u16 sof;
> > +	__u8 length;
> > +	__u8 flags;
> 
> I think the struct layout is architecture dependent. I could be wrong, but I think
> for x64 there is a 4-byte hole here, but not for arm32/arm64.
> 
> Please double-check the struct layout.

It worked for me so far on an x86-64 system, I was able to access buffer 
data correctly, but yes, it's probably safer to use __packed.

> BTW: __u8 for length? The payload can never be longer in UVC?

No, it cannot. That's exactly how UVC defines it.

Thanks
Guennadi

> 
> Regards,
> 
> 	Hans
> 
> > +	__u8 buf[];
> > +};
> > +
> >  #endif
> > 
> 

  reply	other threads:[~2017-07-28 13:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28 12:33 [PATCH 0/6 v5] uvcvideo: metadata nodes and controls Guennadi Liakhovetski
2017-07-28 12:33 ` [PATCH 1/6 v5] UVC: fix .queue_setup() to check the number of planes Guennadi Liakhovetski
2017-07-31 13:57   ` Laurent Pinchart
2017-07-31 13:58     ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 2/6 v5] V4L: Add a UVC Metadata format Guennadi Liakhovetski
2017-07-28 12:46   ` Hans Verkuil
2017-10-30 12:10     ` Hans Verkuil
2017-11-06 14:53       ` Guennadi Liakhovetski
2017-11-07 11:14         ` Laurent Pinchart
2017-11-08 10:43           ` Guennadi Liakhovetski
2017-11-09  5:42             ` Laurent Pinchart
2017-11-09  7:37               ` Guennadi Liakhovetski
2017-10-17 12:51   ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 3/6 v5] uvcvideo: convert from using an atomic variable to a reference count Guennadi Liakhovetski
2017-07-31 14:39   ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 4/6 v5] uvcvideo: add a metadata device node Guennadi Liakhovetski
2017-07-28 12:50   ` Hans Verkuil
2017-07-28 13:03     ` Guennadi Liakhovetski [this message]
2017-10-18  7:32     ` Guennadi Liakhovetski
2017-10-18 14:00       ` Laurent Pinchart
2017-10-18  7:35   ` [PATCH 4/6 v6] " Guennadi Liakhovetski
2017-07-28 12:33 ` [PATCH 5/6 v5] uvcvideo: send a control event when a Control Change interrupt arrives Guennadi Liakhovetski
2017-07-30  6:31   ` kbuild test robot
2017-07-30  6:31   ` [PATCH] uvcvideo: fix ifnullfree.cocci warnings kbuild test robot
2017-08-08  2:18   ` [lkp-robot] [uvcvideo] c698cbbd35: Failed to query (GET_INFO) UVC control 11 on unit 1: -32 (exp. 1) kernel test robot
2017-08-08  2:18     ` kernel test robot
2017-10-17 18:18     ` Laurent Pinchart
2017-10-17 18:18       ` Laurent Pinchart
2017-10-17 18:17   ` [PATCH 5/6 v5] uvcvideo: send a control event when a Control Change interrupt arrives Laurent Pinchart
2017-07-28 12:33 ` [PATCH 6/6 v5] uvcvideo: handle control pipe protocol STALLs Guennadi Liakhovetski
2017-10-17 18:34   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.1707281453220.16637@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.