All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Daniel Scally <dan.scally@ideasonboard.com>, linux-usb@vger.kernel.org
Cc: laurent.pinchart@ideasonboard.com, gregkh@linuxfoundation.org,
	w36195@motorola.com, m.grzeschik@pengutronix.de,
	torleiv@huddly.com, Daniel Scally <dan.scally@ideasonboard.com>
Subject: Re: [PATCH 5/6] usb: gadget: uvc: Make color matching attributes read/write
Date: Thu, 15 Dec 2022 11:51:12 +0000	[thread overview]
Message-ID: <167110507266.9133.9781573969949845356@Monstersaurus> (raw)
In-Reply-To: <20221213083736.2284536-6-dan.scally@ideasonboard.com>

Quoting Daniel Scally (2022-12-13 08:37:35)
> In preparation for allowing more than the default color matching
> descriptor, make the color matching attributes writeable.
> 
> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
> ---
>  .../ABI/testing/configfs-usb-gadget-uvc       |  2 +-
>  drivers/usb/gadget/function/uvc_configfs.c    | 32 ++++++++++++++++++-
>  2 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> index 611b23e6488d..3512f4899fe3 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -165,7 +165,7 @@ Date:               Dec 2014
>  KernelVersion: 4.0
>  Description:   Default color matching descriptors
>  
> -               All attributes read only:
> +               All attributes read/write:

Do we need to specify here what acceptable values can now be written at
all?

>  
>                 ========================  ======================================
>                 bMatrixCoefficients       matrix used to compute luma and
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
> index 6f5932c9f09c..4fbc42d738a4 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -1845,7 +1845,37 @@ static ssize_t uvcg_color_matching_##cname##_show(                       \
>         return result;                                                  \
>  }                                                                      \
>                                                                         \
> -UVC_ATTR_RO(uvcg_color_matching_, cname, aname)
> +static ssize_t uvcg_color_matching_##cname##_store(                    \
> +       struct config_item *item, const char *page, size_t len)         \
> +{                                                                      \
> +       struct config_group *group = to_config_group(item);             \
> +       struct mutex *su_mutex = &group->cg_subsys->su_mutex;           \
> +       struct uvcg_cmd *cmd = to_uvcg_cmd(group);                      \
> +       struct f_uvc_opts *opts;                                        \
> +       struct config_item *opts_item;                                  \
> +       int ret;                                                        \
> +       u##bits num;                                                    \
> +                                                                       \
> +       ret = kstrtou##bits(page, 0, &num);                             \
> +       if (ret)                                                        \
> +               return ret;                                             \

I don't know how horrible it would be - or if there's any other
precendence, but I'm weary that setting '1', or '4' in here from
userspace is fairly meaningless.

Of course - the user doing so would have to know from the spec perhaps
what they are configuring - but it makes me wonder if we should support
string matching in here to also convert say "BT.709" to the appropriate
integer value (if a non-integer was set).

It may depend on how 'most' other configfs entries that would be similar
to this would expect to operate.

> +                                                                       \
> +       mutex_lock(su_mutex); /* for navigating configfs hierarchy */   \
> +                                                                       \
> +       opts_item = group->cg_item.ci_parent->ci_parent->ci_parent;     \
> +       opts = to_f_uvc_opts(opts_item);                                \
> +                                                                       \
> +       mutex_lock(&opts->lock);                                        \
> +                                                                       \
> +       cmd->desc.aname = num;                                          \
> +       ret = len;                                                      \
> +                                                                       \
> +       mutex_unlock(&opts->lock);                                      \
> +       mutex_unlock(su_mutex);                                         \
> +                                                                       \
> +       return ret;                                                     \
> +}                                                                      \
> +UVC_ATTR(uvcg_color_matching_, cname, aname)
>  
>  UVCG_COLOR_MATCHING_ATTR(b_color_primaries, bColorPrimaries, 8);
>  UVCG_COLOR_MATCHING_ATTR(b_transfer_characteristics, bTransferCharacteristics, 8);
> -- 
> 2.34.1
>

  reply	other threads:[~2022-12-15 11:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13  8:37 [PATCH 0/6] UVC Gadget: Extend color matching support Daniel Scally
2022-12-13  8:37 ` [PATCH 1/6] usb: gadget: usb: Remove "default" from color matching attributes Daniel Scally
2022-12-18 23:29   ` Laurent Pinchart
2022-12-19  9:53     ` Kieran Bingham
2022-12-13  8:37 ` [PATCH 2/6] usb: gadget: uvc: Add struct for color matching in configs Daniel Scally
2022-12-15 11:45   ` Kieran Bingham
2022-12-16 14:06     ` Dan Scally
2022-12-18 23:28       ` Laurent Pinchart
2022-12-13  8:37 ` [PATCH 3/6] usb: gadget: uvc: Copy color matching descriptor for each frame Daniel Scally
2022-12-18 23:28   ` Laurent Pinchart
2022-12-19 10:33     ` Dan Scally
2022-12-19 15:52       ` Laurent Pinchart
2022-12-13  8:37 ` [PATCH 4/6] usb: gadget: uvc: Remove the hardcoded default color matching Daniel Scally
2022-12-15 11:48   ` Kieran Bingham
2022-12-16 15:32     ` Dan Scally
2022-12-18 22:52   ` Laurent Pinchart
2022-12-13  8:37 ` [PATCH 5/6] usb: gadget: uvc: Make color matching attributes read/write Daniel Scally
2022-12-15 11:51   ` Kieran Bingham [this message]
2022-12-16 15:53     ` Dan Scally
2022-12-18 23:04       ` Laurent Pinchart
2022-12-19  9:21         ` Dan Scally
2022-12-13  8:37 ` [PATCH 6/6] usb: gadget: uvc: Allow creating new color matching descriptors Daniel Scally
2022-12-15 12:00   ` Kieran Bingham
2022-12-15 12:03     ` Dan Scally
2022-12-18 23:17       ` Laurent Pinchart
2022-12-19  9:44         ` Dan Scally
2022-12-19 16:05           ` Laurent Pinchart
2022-12-18 18:12 ` [PATCH 0/6] UVC Gadget: Extend color matching support Laurent Pinchart
2022-12-19  7:30   ` Dan Scally

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=167110507266.9133.9781573969949845356@Monstersaurus \
    --to=kieran.bingham@ideasonboard.com \
    --cc=dan.scally@ideasonboard.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=torleiv@huddly.com \
    --cc=w36195@motorola.com \
    /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.