From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87D02210F59 for ; Sun, 18 May 2025 08:08:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.79.88.28 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747555697; cv=none; b=YHLPdjy+esM6F8O2hJUQe+B7qfo3R+8xwb816IFdomE8SSPLID3FlplTwGODhR368x/+6+n3IV6ExmvWHdp96fA8tcy79dfLXFscc7+EcJJIcvujhKVZmEUcfXby0Ftt0ZIRkKsecIF+IeGwUMfTXby/TXPQTkfDzxik3HVBaKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747555697; c=relaxed/simple; bh=K0mD+exufhKozeZsdWFJfbcoRT8wJYBxrZTXm3HI6iw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ThDzWQDBt+3C9yNnBkCdHDvaS4ODhmuJ2+ZOcgge/TeKT/DWQJQfyLUmsWjt0XBM/o17jR4fwbK43LPHwVnph13Zj7yVa0V2NQpiLyhXuttU5aIBDJqYO4bXAitwSlm6DuIbh1InW2kNOhzo1X5KjfZT4PFpRlHe4J/t7NsOBqc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net; spf=pass smtp.mailfrom=lwn.net; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b=neNrmWTS; arc=none smtp.client-ip=45.79.88.28 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="neNrmWTS" DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 89F6241086 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1747555688; bh=vmujWYBKx4CX1NBzrB8MtJnhhIUjsMYZ7XHQeYwWuSY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=neNrmWTSmRNYDG3cu/UFSD1rpH+UyTaqyQ/XkVfh3sZVe/xYk3saKMXGsCLG2FsWX dthvOc/uNamX/hfwiYszJymf1LeRAYAVHjIGYmt/uxTze99dx5PFge919G8ZxZovr8 mfkv7Os89omQ0SpbxH0C3rb6mYOFjwbV4UbKa7yBjmXruqbv8L0wP2tZo4Dt/ucPeL DQ29m7TdBEmYprrAehSy8+zSHLTCS2fgLNpJWldSMcRXRJPK7NQVYmTnQZsvPtjmaq TlIH8ZJXm617fcHQhkpSkjaN4QaAI/bF41vbBtBSy9GoKW9En5yKIg0ll38JzTXXTs RJC2bRbhFYD2w== Received: from localhost (mdns.lwn.net [45.79.72.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 89F6241086; Sun, 18 May 2025 08:08:07 +0000 (UTC) From: Jonathan Corbet To: Hanne-Lotta =?utf-8?B?TcOkZW5ww6TDpA==?= , mchehab@kernel.org, ribalda@chromium.org, hverkuil@xs4all.nl, hljunggr@cisco.com, dave.jiang@intel.com, jgg@ziepe.ca, saeedm@nvidia.com, Jonathan.Cameron@huawei.com, ilpo.jarvinen@linux.intel.com, mario.limonciello@amd.com, W_Armin@gmx.de, mpearson-lenovo@squebb.ca Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev, Hanne-Lotta =?utf-8?B?TcOkZW5ww6Q=?= =?utf-8?B?w6Q=?= Subject: Re: [PATCH 2/4] docs: Improve grammar, formatting in Video4Linux In-Reply-To: <20250517132711.117618-2-hannelotta@gmail.com> References: <20250517132711.117618-1-hannelotta@gmail.com> <20250517132711.117618-2-hannelotta@gmail.com> Date: Sun, 18 May 2025 02:08:04 -0600 Message-ID: <871psml4t7.fsf@trenco.lwn.net> Precedence: bulk X-Mailing-List: linux-kernel-mentees@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for working to improve our documentation! Hanne-Lotta M=C3=A4enp=C3=A4=C3=A4 writes: > Fix typos, punctuation and improve grammar and formatting > in documentation for Video4Linux (V4L). > > Signed-off-by: Hanne-Lotta M=C3=A4enp=C3=A4=C3=A4 > --- > .../userspace-api/media/v4l/biblio.rst | 8 ++--- > .../media/v4l/dev-sliced-vbi.rst | 4 +-- > .../media/v4l/ext-ctrls-fm-rx.rst | 15 ++++------ > .../media/v4l/ext-ctrls-fm-tx.rst | 29 +++++++------------ > .../media/v4l/pixfmt-srggb12p.rst | 4 +-- > .../media/v4l/pixfmt-srggb14p.rst | 2 +- > 6 files changed, 25 insertions(+), 37 deletions(-) > > diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documenta= tion/userspace-api/media/v4l/biblio.rst > index 35674eeae20d..c3f7c466e287 100644 > --- a/Documentation/userspace-api/media/v4l/biblio.rst > +++ b/Documentation/userspace-api/media/v4l/biblio.rst > @@ -53,7 +53,7 @@ ISO 13818-1 >=20=20 > :title: ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology= --- Generic coding of moving pictures and associated audio information: Sy= stems" >=20=20 > -:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organisation for Standardisation (http://www.iso.ch) > +:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organization for Standardization (http://www.iso.ch) Please do not "fix" the use of either British or American spellings; both are explicitly just fine for kernel docs. > .. _mpeg2part2: >=20=20 > @@ -63,7 +63,7 @@ ISO 13818-2 >=20=20 > :title: ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology -= -- Generic coding of moving pictures and associated audio information: Vide= o" >=20=20 > -:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organisation for Standardisation (http://www.iso.ch) > +:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organization for Standardization (http://www.iso.ch) >=20=20 > .. _itu470: >=20=20 > @@ -131,7 +131,7 @@ ITU H.265/HEVC >=20=20 > :title: ITU-T Rec. H.265 | ISO/IEC 23008-2 "High Efficiency Video Co= ding" >=20=20 > -:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organisation for Standardisation (http://www.iso.ch) > +:author: International Telecommunication Union (http://www.itu.ch), I= nternational Organization for Standardization (http://www.iso.ch) >=20=20 > .. _jfif: >=20=20 > @@ -150,7 +150,7 @@ ITU-T.81 > =3D=3D=3D=3D=3D=3D=3D=3D >=20=20 >=20=20 > -:title: ITU-T Recommendation T.81 "Information Technology --- Digita= l Compression and Coding of Continous-Tone Still Images --- Requirements an= d Guidelines" > +:title: ITU-T Recommendation T.81 "Information Technology --- Digita= l Compression and Coding of Continuous-Tone Still Images --- Requirements a= nd Guidelines" >=20=20 > :author: International Telecommunication Union (http://www.itu.int) >=20=20 > diff --git a/Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst b/D= ocumentation/userspace-api/media/v4l/dev-sliced-vbi.rst > index 42cdb0a9f786..96e0e85a822c 100644 > --- a/Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst > +++ b/Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst > @@ -48,7 +48,7 @@ capabilities, and they may support :ref:`control` ioctl= s. > The :ref:`video standard ` ioctls provide information vital > to program a sliced VBI device, therefore must be supported. >=20=20 > -.. _sliced-vbi-format-negotitation: > +.. _sliced-vbi-format-negotiation: >=20=20 > Sliced VBI Format Negotiation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > @@ -377,7 +377,7 @@ Sliced VBI Data in MPEG Streams >=20=20 > If a device can produce an MPEG output stream, it may be capable of > providing > -:ref:`negotiated sliced VBI services ` > +:ref:`negotiated sliced VBI services ` > as data embedded in the MPEG stream. Users or applications control this > sliced VBI data insertion with the > :ref:`V4L2_CID_MPEG_STREAM_VBI_FMT ` > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-fm-rx.rst b/= Documentation/userspace-api/media/v4l/ext-ctrls-fm-rx.rst > index b6cfc0e823d2..565157709911 100644 > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-fm-rx.rst > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-fm-rx.rst > @@ -35,7 +35,7 @@ FM_RX Control IDs > description of the correct character encoding for Programme Service > name strings. Also from RDS specification, PS is usually a single > eight character text. However, it is also possible to find receivers > - which can scroll strings sized as 8 x N characters. So, this control > + which can scroll strings sized as 8 x N characters. Therefore this c= ontrol This kind of change just seems like churn that isn't really improving the content? > must be configured with steps of 8 characters. The result is it must > always contain a string with size multiple of 8. >=20=20 > @@ -49,7 +49,7 @@ FM_RX Control IDs > Radio Text strings depends on which RDS Block is being used to > transmit it, either 32 (2A block) or 64 (2B block). However, it is > also possible to find receivers which can scroll strings sized as 32 > - x N or 64 x N characters. So, this control must be configured with > + x N or 64 x N characters. Therefore this control must be configured = with > steps of 32 or 64 characters. The result is it must always contain a > string with size multiple of 32 or 64. >=20=20 > @@ -64,17 +64,12 @@ FM_RX Control IDs > broadcasts speech. If the transmitter doesn't make this distinction, > then it will be set. >=20=20 > -``V4L2_CID_TUNE_DEEMPHASIS`` > - (enum) > - > -enum v4l2_deemphasis - > +``V4L2_CID_TUNE_DEEMPHASIS (enum)`` > Configures the de-emphasis value for reception. A de-emphasis filter > is applied to the broadcast to accentuate the high audio > frequencies. Depending on the region, a time constant of either 50 > - or 75 useconds is used. The enum v4l2_deemphasis defines possible > - values for de-emphasis. Here they are: > - > - > + or 75 microseconds is used. The enum v4l2_deemphasis defines possible > + values for de-emphasis. They are: >=20=20 > .. flat-table:: > :header-rows: 0 > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-fm-tx.rst b/= Documentation/userspace-api/media/v4l/ext-ctrls-fm-tx.rst > index 04c997c9a4c3..aa509039bd27 100644 > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-fm-tx.rst > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-fm-tx.rst > @@ -41,7 +41,7 @@ FM_TX Control IDs > description of the correct character encoding for Programme Service > name strings. Also from RDS specification, PS is usually a single > eight character text. However, it is also possible to find receivers > - which can scroll strings sized as 8 x N characters. So, this control > + which can scroll strings sized as 8 x N characters. Therefore this c= ontrol > must be configured with steps of 8 characters. The result is it must > always contain a string with size multiple of 8. >=20=20 > @@ -55,7 +55,7 @@ FM_TX Control IDs > E of :ref:`iec62106`. The length of Radio Text strings depends on > which RDS Block is being used to transmit it, either 32 (2A block) > or 64 (2B block). However, it is also possible to find receivers > - which can scroll strings sized as 32 x N or 64 x N characters. So, > + which can scroll strings sized as 32 x N or 64 x N characters. There= fore > this control must be configured with steps of 32 or 64 characters. > The result is it must always contain a string with size multiple of > 32 or 64. > @@ -94,8 +94,8 @@ FM_TX Control IDs >=20=20 > ``V4L2_CID_RDS_TX_ALT_FREQS (__u32 array)`` > The alternate frequencies in kHz units. The RDS standard allows for > - up to 25 frequencies to be defined. Drivers may support fewer > - frequencies so check the array size. > + up to 25 frequencies to be defined. Because drivers may support fewer > + frequencies, check the array size. Here too, I'm not sure I see the value in this kind of change. Thanks, jon