On Sat, Feb 08, 2025 at 04:36:47PM +0100, Thorsten Leemhuis wrote:
> On 07.02.25 10:05, Laurent Pinchart wrote:
> > Thank you for the patch.
>
> Thx for saying that!
>
> > On Thu, Feb 06, 2025 at 03:30:10PM +0100, Thorsten Leemhuis wrote:
> >> Point out that expl
he latter is not a theoretical issue, as one maintainer mentioned that
> his employer received a EU GDPR (general data protection regulation)
> complaint after exposing a email address used in bugzilla through a tag
> in a patch description.
>
> Cc: Laurent Pinchart
> Cc: Simona
29 Kory Maincent (Dent Project)
34 Alexis Lothoré (eBPF Foundation)
The other cases correctly refer to companeis, for contributors using
other email addresses:
14 linux.dev
41 zytor.com
47 joelfernandes.org
176 alien8.de
243 gmail.com
333 goodmis.org
454 armlinux.org.uk
918 infradead.org
1007 kernel.org
Do we want to only document existing practices, or also tell which
one(s) should be favoured ?
--
Regards,
Laurent Pinchart
at it is expected
> by committers, in order to start with the model. My view is that it works
> fine for such purpose. I also feel that we're close to the final document.
>
> I'm sending today a v4 addressing the comments since last review.
>
> Once we get people that are a
Hi Mauro,
On Fri, Nov 29, 2024 at 11:29:52AM +0100, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Nov 2024 21:07:07 +0200 Laurent Pinchart escreveu:
>
> > > With that in mind, every committer has duties of reviewing other
> > > developer's patches submitted for the d
On Thu, Nov 28, 2024 at 07:28:42PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 15:48:10 +0100 Simona Vetter escreveu:
>
> > Jumping in the middle here with some clarifications.
> >
> > On Wed, 27 Nov 2024 at 12:19, Laurent Pinchart wrote:
> > > O
On Thu, Nov 28, 2024 at 07:15:43PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 15:25:15 +0200 Laurent Pinchart escreveu:
>
> > > > I think this goes a bit backward, and mixes things up a bit. On the
> > > > mixing side, the expectation of timely
to the next version.
I don't mind much either way, but as we're using gitlab for the shared
tree, we could also do the same as drm-misc and handle this through a
gitlab issue instead of an e-mail. That advantage is that we'll ensure
the person has a gitlab account.
--
Regards,
Laurent Pinchart
On Wed, Nov 27, 2024 at 04:09:23PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 15:39:38 +0200 Laurent Pinchart escreveu:
> > On Wed, Nov 27, 2024 at 12:54:15PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Wed, 27 Nov 2024 10:39:48 +0100 Mauro Carval
rge them using the committers workflow (where you would
handle both steps of merging in the shared tree and giving the
maintainer approval), it's true that the normal workflow would be one of
the two above.
Looking at the pull requests sent to the list over the past twelve
months, we have
oints you raised are also discussed in the other part of
the mail thread. I'll elaborate here on the ones that are unique, and
just mention for the other ones that we can discuss them in my reply to
Mauro to avoid splitting the discussion.
> On 26/11/2024 16:19, Laurent Pinchart wrote:
>
On Wed, Nov 27, 2024 at 10:39:48AM +0100, Mauro Carvalho Chehab wrote:
> Em Tue, 26 Nov 2024 17:19:30 +0200 Laurent Pinchart escreveu:
> > On Mon, Nov 25, 2024 at 02:28:58PM +0100, Mauro Carvalho Chehab wrote:
> > > As the media subsystem will experiment with a multi-committers m
server is busy, so it may take up to a few hours
s/is busy/may be busy/
> + for a patch to be handled by the mail server and by the patchwork
> + instance.
"for a patch to be recorded by patchwork."
> +
> +.. [3] If your email contains HTML, the mailing list
On Wed, Nov 13, 2024 at 11:59:39AM +0100, Simona Vetter wrote:
> On Wed, 13 Nov 2024 at 11:55, Thorsten Leemhuis wrote:
> >
> > On 13.11.24 11:26, Laurent Pinchart wrote:
> > > On Wed, Nov 13, 2024 at 09:35:03AM +0100, Thorsten Leemhuis wrote:
> > >> Remind de
ayed to logged out users'.
> +
> +Furthermore note that only Cc: is appropriate for addition without the
> +explicit permission of the person named; using Reported-by: is fine most of
> +the time as well given the above constraints, but ask for permission for bugs
> +reported in private.
> +
> .. _the_canonical_patch_format:
>
> The canonical patch format
>
> base-commit: 623e5747c680d3854b6b9882d9907096bc63580d
--
Regards,
Laurent Pinchart
ing lists, and patches are then of
course reviewed and further discussed in public. Is this a behaviour you
want to discourage, or is this considered fine ?
> +
> Selecting the maintainer
>
>
--
Regards,
Laurent Pinchart
evelopers are often
better than patches originating from within a company. External
contributors are more used to follow proper upstream review processes.
> That not to mention that company will almost always prioritize new
> product support over maintaining existing products.
>
> No do/don't kind of document will change that.
>
> A change like that should come top/down, so it has to be addressed
> via other strategies, like documents underlining the benefits of
> upstream first, and tutorials/speeches aimed at companies management
> staff.
--
Regards,
Laurent Pinchart
On Mon, Apr 15, 2024 at 10:33:42AM +0200, Greg KH wrote:
> On Mon, Apr 15, 2024 at 11:25:29AM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2024 at 07:21:37AM +0200, Greg KH wrote:
> > > On Sun, Apr 14, 2024 at 10:48:35PM +0300, Laurent Pinchart wrote:
> > > >
Hi Greg,
On Mon, Apr 15, 2024 at 07:21:37AM +0200, Greg KH wrote:
> On Sun, Apr 14, 2024 at 10:48:35PM +0300, Laurent Pinchart wrote:
> > On Sun, Apr 14, 2024 at 12:08:50PM -0500, Alex Elder wrote:
> > > Several times recently Greg KH has admonished that variants of WARN()
&
g-deprecated APIs that we were getting close to
removing for instance. dev_warn() wouldn't have had the same effect.
>
> Use BUILD_BUG_ON() for compile-time assertions
> **
--
Regards,
Laurent Pinchart
On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> wrote:
> >
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinch
On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote:
> On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote:
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > Hi Si
On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > Hi Simon,
> >
> > Thank you for the patch.
> >
> > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > >
ompatible', bytes(compat))
> +
> +with open(fname, 'rb') as inf:
> +compressed = compress_data(inf, compress)
> +fsw.property('data', compressed)
> +return model, compat
> +
> +
> +def build_fit(args):
> +"""Build the FIT from the provided files and arguments
> +
> +Args:
> +args (Namespace): Program arguments
> +
> +Returns:
> +tuple:
> +bytes: FIT data
> +int: Number of configurations generated
> +size: Total uncompressed size of data
> +"""
> +fsw = libfdt.FdtSw()
> +setup_fit(fsw, args.name)
> +seq = 0
> +size = 0
> +entries = []
> +
> +# Handle the kernel
> +with open(args.kernel, 'rb') as inf:
> +comp_data = compress_data(inf, args.compress)
> +size += os.path.getsize(args.kernel)
> +write_kernel(fsw, comp_data, args)
> +
> +for path in args.srcdir:
> +# Handle devicetree files
> +if os.path.isdir(path):
> +for dirpath, _, fnames in os.walk(path):
> +for fname in fnames:
> +if os.path.splitext(fname)[1] != '.dtb':
> +continue
> +pathname = os.path.join(dirpath, fname)
> +seq += 1
> +size += os.path.getsize(pathname)
> +model, compat = output_dtb(fsw, seq, pathname,
> + args.arch, args.compress)
> +entries.append([model, compat])
> +
> +finish_fit(fsw, entries)
> +
> +# Include the kernel itself in the returned file count
> +return fsw.as_fdt().as_bytearray(), seq + 1, size
> +
> +
> +def run_make_fit():
> +"""Run the tool's main logic"""
> +args = parse_args()
> +
> +out_data, count, size = build_fit(args)
> +with open(args.fit, 'wb') as outf:
> +outf.write(out_data)
> +
> +ext_fit_size = None
> +if args.external:
> +mkimage = os.environ.get('MKIMAGE', 'mkimage')
> +subprocess.check_call([mkimage, '-E', '-F', args.fit],
> + stdout=subprocess.DEVNULL)
> +
> +with open(args.fit, 'rb') as inf:
> +data = inf.read()
> +ext_fit = libfdt.FdtRo(data)
> +ext_fit_size = ext_fit.totalsize()
> +
> +comp_size = len(out_data)
> +print(f'FIT size {comp_size:#x}/{comp_size / 1024 / 1024:.1f} MB',
> end='')
> +if ext_fit_size:
> +print(f', header {ext_fit_size:#x}/{ext_fit_size / 1024:.1f} KB',
> end='')
> +print(f', {count} files, uncompressed {size / 1024 / 1024:.1f} MB')
> +
> +
> +if __name__ == "__main__":
> +sys.exit(run_make_fit())
--
Regards,
Laurent Pinchart
Hi Krzysztof,
On Sun, Nov 26, 2023 at 11:32:17AM +0100, Krzysztof Kozlowski wrote:
> On 25/11/2023 20:37, Laurent Pinchart wrote:
> > On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> >> Document preferred coding style for Devicetree sources (DTS and DT
"qcom,tsens-v2";
> + reg = <0x0 0x0c271000 0x0 0x1000>,
> + <0x0 0x0c222000 0x0 0x1000>;
> + };
> +
> +Organizing DTSI and DTS
> +---
> +
> +The DTSI and DTS files shall be organized in a way repres
letter, and the submitter should push
and provide a link to a branch that contains the series on top of the
appropriate base (or just a link to the base). This won't help the bots
much though, if they just look at the base tag. Is there a way, or can
we standardize on a way, to indicate where the base can be found ?
> Reviewed-by: Kees Cook
--
Regards,
Laurent Pinchart
read for previous versions ?
--
Regards,
Laurent Pinchart
Hi Mauro,
On Monday, 18 December 2017 17:13:26 EET Mauro Carvalho Chehab wrote:
> Em Fri, 13 Oct 2017 15:38:11 +0300 Laurent Pinchart escreveu:
> > On Thursday, 28 September 2017 00:46:51 EEST Mauro Carvalho Chehab wrote:
> >> Currently, there's no way to document #defin
+ * @cur.val: The control's current value, if the @type is represented via
> + * a u32 integer (see &enum v4l2_ctrl_type).
> * @val: The control's new s32 value.
> * @priv:The control's private pointer. For use by the driver. It is
> *
> + * probed, to a notifier->waiting list.
> + * Not to be used by drivers.
> */
> struct v4l2_async_subdev {
> enum v4l2_async_match_type match_type;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
f the bus is Mobile Industry Processor
> + * Interface's Camera Serial Interface version 2
> + * (MIPI CSI2).
These are not pointers.
> * @link_frequencies: array of supported link frequencies
> * @nr_of_link_frequencies: number of elements in link_frequencc
ll syscalls.
> + */
> +enum v4l2_debug_flags {
> + V4L2_DEV_DEBUG_IOCTL= 0x01,
> + V4L2_DEV_DEBUG_IOCTL_ARG= 0x02,
> + V4L2_DEV_DEBUG_FOP = 0x04,
> + V4L2_DEV_DEBUG_STREAMING= 0x08,
> + V4L2_DEV_DEBUG_POLL = 0x10,
> +};
>
2 (vsync == 8) is true.
> + * - For CEA861 timings: if %V4L2_DV_FL_CAN_REDUCE_FPS flag is true.
> */
> static inline bool can_reduce_fps(struct v4l2_bt_timings *bt)
> {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Each element there groups a set of callbacks functions.
> + * @f: callback function that will be called if @cond matches.
> + * The callback functions are defined in groups, according to
> + * each element at &struct v4l2_subdev_ops.
> */
> #define v4l2_device_has_op(v4l2_dev, grpid, o, f)\
> ({ \
> @@ -331,9 +492,18 @@ static inline void v4l2_subdev_notify(struct
> v4l2_subdev *sd, __result;
> \
> })
>
> -/*
> - * Does any subdev with matching grpmsk (or all if grpmsk == 0) has the
> given
> - * op?
> +/**
> + * v4l2_device_mask_has_op - checks if any subdev with matching group
> + * mask has a given ops.
> + *
> + * @v4l2_dev: pointer to &struct v4l2_device
> + * @grpmsk: bitmask to be checked against &struct v4l2_subdev->grp_id
> + * group ID to be matched. Use 0 to match them all.
> + * @o: name of the element at &struct v4l2_subdev_ops that contains @f.
> + * Each element there groups a set of callbacks functions.
> + * @f: callback function that will be called if @cond matches.
> + * The callback functions are defined in groups, according to
> + * each element at &struct v4l2_subdev_ops.
> */
> #define v4l2_device_mask_has_op(v4l2_dev, grpmsk, o, f)
> \
> ({ \
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
handle userspace sizes, I
wouldn't mention userspace here.
> + */
> const struct v4l2_frmsize_discrete
> *v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
> const size_t num_sizes,
> s32 width, s32 height);
>
> +/**
> + * v4l2_get_timestamp - ancillary routine to get a timestamp to be used
> when
> + * filling streaming metadata. Internally, it uses ktime_get_ts(), +
> * with is the recommended way to get it.
s/with/which/
> + *
> + * @tv: pointer to &stuct timeval to be filled.
> + */
> void v4l2_get_timestamp(struct timeval *tv);
>
> #endif /* V4L2_COMMON_H_ */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ struct v4l2_priv_tun_config {
>
> #define VIDIOC_INT_RESET _IOW ('d', 102, u32)
>
> -struct v4l2_routing {
> - u32 input;
> - u32 output;
> -};
> -
> /*
> ---------
> */
>
const struct v4l2_discrete_probe *probe,
> - s32 width, s32 height);
> +const struct v4l2_frmsize_discrete
> +*v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
> + const size_t num_sizes,
No need for a const keyword.
> + s32 width, s32 height);
>
> void v4l2_get_timestamp(struct timeval *tv);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mauro,
On Friday, 25 August 2017 16:38:23 EEST Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 16:11:15 +0300 Laurent Pinchart escreveu:
> > On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
> >> From: "mche...@s-opensource.com"
> >>
>> * - ``V4L2_CAP_DEVICE_CAPS``
> >>- 0x8000
> >>- The driver fills the ``device_caps`` field. This capability can
> >>
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index 45cf7359822
green light to such implementations
until we have to, and I also prefer discussing this topic separately. It will
require a fair amount of work to document (and thus first agree on), and
there's no need to block the rest of this patch until we complete that work.
For those reasons I woul
devices that together make a larger user-facing functional
device (for instance the SoC ISP IP cores and external camera sensors together
make a camera device)
We need different terms for those different concepts, and we need to be very
consistent in our usage of those terms. I believe we shou
e related to, say, a video node is a pain
> >> without MC.
> >
> > I disagree with the above sentence: just video nodes are enough for
> > almost all non-embedded hardware. We implemented MC there only in order to
>
> How would you find a sub-device node somehow related to a video node
> without MC?
>
> > solve a conflict when certain sub-devices are busy because they're used by
> > a DVB pipeline while someone tries to stream V4L2 on.
>
> This matter certainly was as you say, but nowadays e.g. some Intel Core
> SoCs do have IPUs (ISPs) and CSI-2 receivers in them. These chips could be
> used on a regular PC. From software point of view they're not different
> from typical embedded systems.
>
> If this doesn't mean that there will be universally more need for MC, it
> does still mean that the need for MC is no longer related to embedded
> systems only.
>
> >> Less variance in interface availability is better for the user
> >> space, and unlike between video node centric vs. MC-centric, there are
> >> hardly technical reasons (or at least I can't remember one) for doing
> >> this.
> >>
> >> I remember we had a few of these drivers and the agreement was to add MC
> >> interface to those.
> >
> > Sorry, I'm completely lost what you meant here, as it seems that you're
> > contradicting yourself :-)
> >
> > Do you want to allow non-mc-centric devices to expose subdev API or not?
> >
> > If not, we need to add a notice forbidding it (but noticing that it
> > might change in the future, if we ever need it for whatever reason).
>
> I meant to say that we should constrain ourselves to providing as little
> variance in user space interfaces between different drivers as possible,
> still without limiting ourselves to supporting only a subset of hardware
> features.
>
> In this case there is no technical reason I'm aware of for providing
> sub-device nodes without Media controller.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s own operations.
>
> Reviewed-by: Jose Abreu
> Reviewed-by: Archit Taneja
> Signed-off-by: Neil Armstrong
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 +++
> include/drm/bridge/dw_hdmi.h |
Hi Neil,
Thank you for the patch.
On Monday 03 Apr 2017 16:42:37 Neil Armstrong wrote:
> This patch adds a new DRM documentation entry and links to the input
> format table added in the dw_hdmi header.
>
> Reviewed-by: Archit Taneja
> Signed-off-by: Neil Armstrong
Acked-by: L
;
> +/**
> + * DOC: Supported input formats and encodings
> + *
> + * Depending on the Hardware configuration of the Controller IP, it
> supports
> + * a subset of the following input formats and encodings on it's internal
> + * 48bit bus.
> + *
s/it's/its/
[s
> + - b\ :sub:`3`
> + - b\ :sub:`2`
> + - b\ :sub:`1`
> + - b\ :sub:`0`
> +
> +.. raw:: latex
> +
> +\endgroup
> +
> +
> +The following table list existing packed 36bit wide RGB formats.
s/list/lists/
Same comment for the other tables. Apar
ding a 16-bits word (0x5678),
> > it will actually read 32 bits, with 16-bits with some random value,
> >
> > causing a buffer overflow. E. g. buffer content will now be:
> > buf = { 0x12, x34, 0xde, 0xad }
> >
> > In other words, the second transfer c
Hi Mauro,
On Thursday 30 Mar 2017 07:28:00 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 12:34:32 +0300 Laurent Pinchart escreveu:
> > On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> >> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
> >&
Hi Mauro,
On Wednesday 29 Mar 2017 22:06:33 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 01:15:27 +0300 Laurent Pinchart escreveu:
> > On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:
> > > Several host controllers, commonly found on ARM, like dwc2,
> >
Hi Oliver,
On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
> > > + may also override PAD bytes at the end of the ``transfer_buffer``,
> > > up to the
> > > + size of the CPU word.
>
ord alignment condition is normally ensured if the buffer is
> + * allocated with kmalloc(), but this may not be the case if the driver
> + * allocates a bigger buffer and point to a random place inside it.
> + *
Couldn't we avoid three copies of the same text ? The chance they will get
out-of-sync is quite high.
> * Initialization:
> *
> * All URBs submitted must initialize the dev, pipe, transfer_flags (may be
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Daniel,
Thank you for the patch.
On Wednesday 01 Mar 2017 09:27:14 Daniel Vetter wrote:
> Resulted in confusion a few times in the past.
>
> v2: Spelling fix (Eric).
>
> Cc: Eric Anholt
> Acked-by: Eric Anholt
> Cc: Laurent Pinchart
> Cc: Manasi Navare
> S
Hi Daniel and Markus,
On Thursday 02 Mar 2017 16:11:08 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 03:58:36PM +0100, Markus Heiser wrote:
> > Am 02.03.2017 um 15:14 schrieb Laurent Pinchart:
> > > On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:
> > >>
rt, otherwise debugging issues with
> the diagrams is impossible.
>
> v3: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
&g
Hi Daniel,
Thank you for the patch.
On Tuesday 28 Feb 2017 18:13:16 Daniel Vetter wrote:
> Oh, the shiny and pretties!
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Overall this looks good to me, please see below for a few minor issues.
> ---
> Documen
a ok-ish start for
> better atomic overview.
>
> v2: Spelling and clarifications (Eric).
>
> v3: Implement suggestion from Gabriel to fix the graph.
>
> Cc: Gabriel Krisman Bertazi
> Acked-by: Eric Anholt
> Cc: Eric Anholt
> Cc: Laurent Pinchart
> Cc: Harr
Hi Daniel,
On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:
> On Thu, Mar 2, 2017 at 1:26 PM, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > With this applied, I get
> >
> > make[1]: Entering dir
c-guide/sphinx.rst| 90 ++-
> Documentation/doc-guide/svg_image.svg | 10 +
> Documentation/process/changes.rst | 7 +-
> Documentation/sphinx/kfigure.py | 442 ++
> 6 files changed, 548 insertions(+), 6 deletions(-)
> create mode 100
e way Sphinx works, the PDF images should be
> generated inside the Kernel source tree, as otherwise Sphinx
> won't find it, not obeying what's specified by "O=" makefile
> parameter.
Can't we fix that ?
> Signed-off-by: Mauro Carvalho Chehab
--
Regards,
L
Hi Mauro,
Thank you for the patch.
On Thursday 08 Sep 2016 09:03:44 Mauro Carvalho Chehab wrote:
> The "struct" were inside the reference, causing it to break.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
> ---
> Documentation/media/kapi/v4l2
Hi Mauro,
On Wednesday 13 Jul 2016 11:11:43 Mauro Carvalho Chehab wrote:
> Em Sat, 09 Jul 2016 20:10:21 +0300 Laurent Pinchart escreveu:
> > The other one is related, the table of contents in the main page of each
> > section
> > (https://mchehab.fedorapeople.org/media_API_bo
information
we need without requiring many clicks (or actually any click at all). How can
we keep that feature ?
By the way, the "Video for Linux API" section (and the other sibling sections)
are child nodes of the "Introduction" section. That feels quite odd.
63 matches
Mail list logo
