Package: libdrm-dev
Version: 2.4.123-1
Severity: minor
Tags: patch
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' -e '\\~$' <file>" to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome of this action?
an.tmac:<stdin>:30: style: .TH missing fourth argument; consider
package/project name and version (e.g., "groff 1.23.0")
an.tmac:<stdin>:336: style: 1 leading space(s) on input line
troff:<stdin>:336: warning: trailing space in the line
* What outcome did you expect instead?
No output (no warnings).
-.-
General remarks and further material, if a diff-file exist, are in the
attachments.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libdrm-dev depends on:
ii libdrm-amdgpu1 2.4.123-1
ii libdrm-intel1 2.4.123-1
ii libdrm-nouveau2 2.4.123-1
ii libdrm-radeon1 2.4.123-1
ii libdrm2 2.4.123-1
ii libpciaccess-dev 0.17-3+b3
libdrm-dev recommends no packages.
libdrm-dev suggests no packages.
-- no debconf information
Input file is drm-memory.7
Output from "mandoc -T lint drm-memory.7": (shortened list)
1 input text line longer than 80 bytes: Almost all in\-kerne...
1 input text line longer than 80 bytes: GPU features, you sh...
1 input text line longer than 80 bytes: I/O and more. The ne...
1 input text line longer than 80 bytes: The fields \fIheight...
1 input text line longer than 80 bytes: You have to fill in ...
1 input text line longer than 80 bytes: You only need to put...
1 input text line longer than 80 bytes: by the kernel. \fIha...
1 input text line longer than 80 bytes: created. \fIbpp\fP i...
1 input text line longer than 80 bytes: driver\-independent ...
1 input text line longer than 80 bytes: drivers use 32\-bit ...
1 input text line longer than 80 bytes: into the driver\-man...
1 input text line longer than 80 bytes: or access the GEM\-o...
1 input text line longer than 80 bytes: want to open. The ke...
5 skipping paragraph macro: sp after SH
4 skipping paragraph macro: sp after SS
1 whitespace at end of input line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Output from "test-groff -mandoc -t -ww -z drm-memory.7": (shortened list)
1 trailing space in the line
Remove trailing space with: sed -e 's/ *$//'
-.-.
Show if generated from reStructuredText
Who is actually generating this man page? Debian or upstream?
Is the generating software out of date?
1:.\" Man page generated from reStructuredText.
-.-.
Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
Number of lines affected is
1
-.-.
Remove space in the first column, if not indented.
Use ".in +<number>n" and ".in" to end it; ".nf" and ".fi" to end
it, for an extra indention.
drm-memory.7:336: <https://gitlab.freedesktop.org/mesa/drm/\-/issues>
-.-.
Wrong distance between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
Mark a final abbreviation point as such by suffixing it with "\&".
Some sentences (etc.) do not begin on a new line.
Split (sometimes) lines after a punctuation mark; before a conjunction.
N.B.
The number of lines affected can be too large to be in a patch.
Lines with only one (or two) space(s) between sentences are split,
so latter sentences begin on a new line.
[List of affected lines removed]
-.-
Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.
Add "\:" to split the string for the output, "\<newline>" in the source.
Line 50, length 87
Almost all in\-kernel DRM hardware drivers support an API called
\fIDumb\-Buffers\fP\&.
Line 85, length 90
The fields \fIheight\fP, \fIwidth\fP, \fIbpp\fP and \fIflags\fP have to be
provided by the
Line 87, length 81
\fIheight\fP and \fIwidth\fP are the dimensions of the rectangular buffer that
is
Line 88, length 85
created. \fIbpp\fP is the number of bits\-per\-pixel and must be a multiple of
8. You
Line 92, length 84
by the kernel. \fIhandle\fP is a 32\-bit gem handle that identifies the buffer.
This
Line 95, length 82
drivers use 32\-bit or 64\-bit aligned stride\-values. The size field contains
the
Line 117, length 84
\fBDRM_IOCTL_MODE_CREATE_DUMB\fP into the \fIhandle\fP field. The \fIpad\fP
field is
Line 123, length 84
\fBDRM_IOCTL_MODE_DESTROY_DUMB\fP\&. If you close the DRM file\-descriptor, all
open
Line 137, length 82
You only need to put your handle into the \fIhandle\fP field. After this call,
the
Line 141, length 85
\fITTM\fP stands for \fITranslation Table Manager\fP and is a generic
memory\-manager
Line 189, length 81
driver\-independent API to create GBM buffers and retrieve a GBM\-handle to
them.
Line 205, length 83
\fBdrmAuthMagic\fP(3) to the current DRM\-Master, can \fIguess\fP the name and
open
Line 206, length 81
or access the GEM\-object. If you want more fine\-grained access control, you
can
Line 242, length 82
You have to fill in the \fIname\fP field with the name of the GEM\-object that
you
Line 243, length 85
want to open. The kernel will fill in the \fIhandle\fP and \fIsize\fP fields
with the
Line 250, length 86
I/O and more. The next higher\-level API is \fIOpenGL\fP\&. So if you want to
use more
Line 251, length 82
GPU features, you should use the \fImesa3D\fP library to create OpenGL contexts
on
Line 261, length 82
into the driver\-manpages, including \fBdrm\-intel\fP(7), \fBdrm\-radeon\fP(7)
and
Line 340, length 82
\fBdrmOpen\fP(3), \fBdrm\-intel\fP(7), \fBdrm\-radeon\fP(7),
\fBdrm\-nouveau\fP(7)
-.-.
Put a parenthetical sentence, phrase on a separate line,
if not part of a code.
See man-pages(7), item "semantic newline".
Not considered in a patch, too many lines.
drm-memory.7:94:argument. The \fIpitch\fP field is the pitch (or stride) of the
new buffer. Most
drm-memory.7:161:the semantics (and if it applies, the syntax) that is shared
between all
drm-memory.7:192:or look at the driver\-dependent man\-pages (for example
\fBdrm\-intel\fP(7) or
drm-memory.7:255:libEGL. 2D software\-rendering (rendering with the CPU) can be
achieved with the
drm-memory.7:274:This is driver\-independent (as long as the driver supports
dumb\-buffers)
drm-memory.7:278:can be used for scanout with the KMS API (see
\fBdrm\-kms\fP(7)).
-.-.
No need for "\&" to be in front of a period (.),
if there is a character in front of it
50:Almost all in\-kernel DRM hardware drivers support an API called
\fIDumb\-Buffers\fP\&.
97:\fB(height * pitch + width) * bpp / 4\fP\&.
123:\fBDRM_IOCTL_MODE_DESTROY_DUMB\fP\&. If you close the DRM file\-descriptor,
all open
168:\fBEINVAL\fP and invalid object names return \fBENOENT\fP\&.
186:\fBDRM_NOUVEAU_GEM_NEW\fP or \fBDRM_RADEON_GEM_CREATE\fP\&. Each of these
ioctls
250:I/O and more. The next higher\-level API is \fIOpenGL\fP\&. So if you want
to use more
-.-.
Remove quotes when there is a printable
but no space character between them
and the quotes are not for emphasis (markup),
for example as an argument to a macro.
30:.TH "DRM-MEMORY" "7" "September 2012" "" "Direct Rendering Manager"
-.-.
Remove excessive "\&" when it has no functional purpose.
50:Almost all in\-kernel DRM hardware drivers support an API called
\fIDumb\-Buffers\fP\&.
97:\fB(height * pitch + width) * bpp / 4\fP\&.
123:\fBDRM_IOCTL_MODE_DESTROY_DUMB\fP\&. If you close the DRM file\-descriptor,
all open
168:\fBEINVAL\fP and invalid object names return \fBENOENT\fP\&.
186:\fBDRM_NOUVEAU_GEM_NEW\fP or \fBDRM_RADEON_GEM_CREATE\fP\&. Each of these
ioctls
250:I/O and more. The next higher\-level API is \fIOpenGL\fP\&. So if you want
to use more
-.-.
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z
":
an.tmac:<stdin>:30: style: .TH missing fourth argument; consider
package/project name and version (e.g., "groff 1.23.0")
an.tmac:<stdin>:336: style: 1 leading space(s) on input line
troff:<stdin>:336: warning: trailing space in the line
-.-.
Generally:
Split (sometimes) lines after a punctuation mark; before a conjunction.
--- drm-memory.7 2025-02-20 21:52:10.282144885 +0000
+++ drm-memory.7.new 2025-02-20 22:20:13.915742424 +0000
@@ -27,14 +27,12 @@ level margin: \\n[rst2man-indent\\n[rst2
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
-.TH "DRM-MEMORY" "7" "September 2012" "" "Direct Rendering Manager"
+.TH DRM-MEMORY 7 "September 2012" "" "Direct Rendering Manager"
.SH NAME
drm-memory \- DRM Memory Management
.SH SYNOPSIS
-.sp
\fB#include <xf86drm.h>\fP
.SH DESCRIPTION
-.sp
Many modern high\-end GPUs come with their own memory managers. They even
include several different caches that need to be synchronized during access.
Textures, framebuffers, command buffers and more need to be stored in memory
@@ -46,8 +44,8 @@ one driver. These can be used for trivia
driver\-dependent code. But for hardware\-accelerated rendering you need to
read
the manual pages for the driver you want to work with.
.SS Dumb\-Buffers
-.sp
-Almost all in\-kernel DRM hardware drivers support an API called
\fIDumb\-Buffers\fP\&.
+Almost all in\-kernel DRM hardware drivers support an API called
+\fIDumb\-Buffers\fP.
This API allows to create buffers of arbitrary size that can be used for
scanout. These buffers can be memory mapped via \fBmmap\fP(2) so you can render
into them on the CPU. However, GPU access to these buffers is often not
@@ -82,19 +80,25 @@ struct drm_mode_create_dumb {
.UNINDENT
.UNINDENT
.sp
-The fields \fIheight\fP, \fIwidth\fP, \fIbpp\fP and \fIflags\fP have to be
provided by the
-caller. The other fields are filled by the kernel with the return values.
-\fIheight\fP and \fIwidth\fP are the dimensions of the rectangular buffer that
is
-created. \fIbpp\fP is the number of bits\-per\-pixel and must be a multiple of
8. You
+The fields \fIheight\fP, \fIwidth\fP, \fIbpp\fP
+and \fIflags\fP have to be provided by the caller.
+The other fields are filled by the kernel with the return values.
+\fIheight\fP and \fIwidth\fP are the dimensions of the rectangular buffer
+that is created.
+\fIbpp\fP is the number of bits\-per\-pixel and must be a multiple of 8. You
most commonly want to pass 32 here. The flags field is currently unused and
must be zeroed. Different flags to modify the behavior may be added in the
future. After calling the ioctl, the handle, pitch and size fields are filled
-by the kernel. \fIhandle\fP is a 32\-bit gem handle that identifies the
buffer. This
+by the kernel.
+\fIhandle\fP is a 32\-bit gem handle that identifies the buffer. This
is used by several other calls that take a gem\-handle or memory\-buffer as
-argument. The \fIpitch\fP field is the pitch (or stride) of the new buffer.
Most
-drivers use 32\-bit or 64\-bit aligned stride\-values. The size field contains
the
+argument. The \fIpitch\fP field is the pitch
+(or stride)
+of the new buffer. Most
+drivers use 32\-bit or 64\-bit aligned stride\-values.
+The size field contains the
absolute size in bytes of the buffer. This can normally also be computed with
-\fB(height * pitch + width) * bpp / 4\fP\&.
+\fB(height * pitch + width) * bpp / 4\fP.
.sp
To prepare the buffer for \fBmmap\fP(2) you need to use the
\fBDRM_IOCTL_MODE_MAP_DUMB\fP ioctl. It takes as argument a structure of type
@@ -114,13 +118,15 @@ struct drm_mode_map_dumb {
.UNINDENT
.sp
You need to put the gem\-handle that was previously retrieved via
-\fBDRM_IOCTL_MODE_CREATE_DUMB\fP into the \fIhandle\fP field. The \fIpad\fP
field is
-unused padding and must be zeroed. After completion, the \fIoffset\fP field
will
+\fBDRM_IOCTL_MODE_CREATE_DUMB\fP into the \fIhandle\fP field.
+The \fIpad\fP field is unused padding and must be zeroed.
+After completion, the \fIoffset\fP field will
contain an offset that can be used with \fBmmap\fP(2) on the DRM
file\-descriptor.
.sp
If you don\(aqt need your dumb\-buffer, anymore, you have to destroy it with
-\fBDRM_IOCTL_MODE_DESTROY_DUMB\fP\&. If you close the DRM file\-descriptor,
all open
+\fBDRM_IOCTL_MODE_DESTROY_DUMB\fP.
+If you close the DRM file\-descriptor, all open
dumb\-buffers are automatically destroyed. This ioctl takes as argument a
structure of type \fBstruct drm_mode_destroy_dumb\fP:
.INDENT 0.0
@@ -134,16 +140,16 @@ struct drm_mode_destroy_dumb {
.UNINDENT
.UNINDENT
.sp
-You only need to put your handle into the \fIhandle\fP field. After this call,
the
-handle is invalid and may be reused for new buffers by the dumb\-API.
+You only need to put your handle into the \fIhandle\fP field.
+After this call, the handle is invalid
+and may be reused for new buffers by the dumb\-API.
.SS TTM
-.sp
-\fITTM\fP stands for \fITranslation Table Manager\fP and is a generic
memory\-manager
-provided by the kernel. It does not provide a common user\-space API so you
need
+\fITTM\fP stands for \fITranslation Table Manager\fP
+and is a generic memory\-manager provided by the kernel.
+It does not provide a common user\-space API so you need
to look at each driver interface if you want to use it. See for instance the
radeon man pages for more information on memory\-management with radeon and
TTM.
.SS GEM
-.sp
\fIGEM\fP stands for \fIGraphics Execution Manager\fP and is a generic DRM
memory\-management framework in the kernel, that is used by many different
drivers. GEM is designed to manage graphics memory, control access to the
@@ -158,14 +164,15 @@ flow within the linux DRM subsystem. How
that is fully driver independent. Instead, if provides many functions that are
shared between many drivers, but each driver has to implement most of
memory\-management with driver\-dependent ioctls. This manpage tries to
describe
-the semantics (and if it applies, the syntax) that is shared between all
-drivers that use GEM.
+the semantics
+(and if it applies, the syntax)
+that is shared between all drivers that use GEM.
.sp
All GEM APIs are defined as \fBioctl\fP(2) on the DRM file descriptor. An
application must be authorized via \fBdrmAuthMagic\fP(3) to the current
DRM\-Master to access the GEM subsystem. A driver that does not support GEM
will
return \fBENODEV\fP for all these ioctls. Invalid object handles return
-\fBEINVAL\fP and invalid object names return \fBENOENT\fP\&.
+\fBEINVAL\fP and invalid object names return \fBENOENT\fP.
.sp
Gem provides explicit memory management primitives. System pages are allocated
when the object is created, either as the fundamental storage for hardware
@@ -183,14 +190,15 @@ when all handles from user\-space were c
.sp
GEM\-buffers cannot be created with a generic API. Each driver provides its own
API to create GEM\-buffers. See for example \fBDRM_I915_GEM_CREATE\fP,
-\fBDRM_NOUVEAU_GEM_NEW\fP or \fBDRM_RADEON_GEM_CREATE\fP\&. Each of these
ioctls
+\fBDRM_NOUVEAU_GEM_NEW\fP or \fBDRM_RADEON_GEM_CREATE\fP. Each of these ioctls
returns a GEM\-handle that can be passed to different generic ioctls. The
\fIlibgbm\fP library from the \fImesa3D\fP distribution tries to provide a
-driver\-independent API to create GBM buffers and retrieve a GBM\-handle to
them.
+driver\-independent API to create GBM buffers
+and retrieve a GBM\-handle to them.
It allows to create buffers for different use\-cases including scanout,
rendering, cursors and CPU\-access. See the libgbm library for more information
-or look at the driver\-dependent man\-pages (for example \fBdrm\-intel\fP(7) or
-\fBdrm\-radeon\fP(7)).
+or look at the driver\-dependent man\-pages
+(for example \fBdrm\-intel\fP(7) or \fBdrm\-radeon\fP(7)).
.sp
GEM\-buffers can be closed with \fBdrmCloseBufferHandle\fP(3). It takes as
argument the GEM\-handle to be closed. After this call the GEM handle cannot be
@@ -202,8 +210,9 @@ name for them and pass this name to othe
GEM\-object. Names are currently 32\-bit integer IDs and have no special
protection. That is, if you put a name on your GEM\-object, every other client
that has access to the DRM device and is authenticated via
-\fBdrmAuthMagic\fP(3) to the current DRM\-Master, can \fIguess\fP the name and
open
-or access the GEM\-object. If you want more fine\-grained access control, you
can
+\fBdrmAuthMagic\fP(3) to the current DRM\-Master,
+can \fIguess\fP the name and open or access the GEM\-object.
+If you want more fine\-grained access control, you can
use the new \fBdrm\-prime\fP(7) API to retrieve file\-descriptors for
GEM\-handles. To create a name for a GEM\-handle, you use the
\fBDRM_IOCTL_GEM_FLINK\fP ioctl. It takes as argument a structure of type
@@ -239,26 +248,32 @@ struct drm_gem_open {
.UNINDENT
.UNINDENT
.sp
-You have to fill in the \fIname\fP field with the name of the GEM\-object that
you
-want to open. The kernel will fill in the \fIhandle\fP and \fIsize\fP fields
with the
+You have to fill in the \fIname\fP field with the name of the GEM\-object
+that you want to open.
+The kernel will fill in the \fIhandle\fP and \fIsize\fP fields with the
new handle and size of the GEM\-object. You can now access the GEM\-object via
the handle as if you created it with the GEM API.
.sp
Besides generic buffer management, the GEM API does not provide any generic
access. Each driver implements its own functionality on top of this API. This
includes execution\-buffers, GTT management, context creation, CPU access, GPU
-I/O and more. The next higher\-level API is \fIOpenGL\fP\&. So if you want to
use more
-GPU features, you should use the \fImesa3D\fP library to create OpenGL
contexts on
+I/O and more.
+The next higher\-level API is \fIOpenGL\fP. So if you want to use more
+GPU features,
+you should use the \fImesa3D\fP library to create OpenGL contexts on
DRM devices. This does \fInot\fP require any windowing\-system like X11, but
can
also be done on raw DRM devices. However, this is beyond the scope of this
man\-page. You may have a look at other mesa3D man pages, including libgbm and
-libEGL. 2D software\-rendering (rendering with the CPU) can be achieved with
the
+libEGL. 2D software\-rendering
+(rendering with the CPU)
+can be achieved with the
dumb\-buffer\-API in a driver\-independent fashion, however, for
hardware\-accelerated 2D or 3D rendering you must use OpenGL. Any other API
that
tries to abstract the driver\-internals to access GEM\-execution\-buffers and
other GPU internals, would simply reinvent OpenGL so it is not provided. But if
you need more detailed information for a specific driver, you may have a look
-into the driver\-manpages, including \fBdrm\-intel\fP(7), \fBdrm\-radeon\fP(7)
and
+into the driver\-manpages, including \fBdrm\-intel\fP(7),
+\fBdrm\-radeon\fP(7) and
\fBdrm\-nouveau\fP(7). However, the \fBdrm\-prime\fP(7) infrastructure and the
generic GEM API as described here allow display\-managers to handle
graphics\-buffers and render\-clients without any deeper knowledge of the GPU
@@ -266,16 +281,16 @@ that is used. Moreover, it allows to mov
complex display\-servers that don\(aqt do any rendering on their own. See its
man\-page for more information.
.SH EXAMPLES
-.sp
This section includes examples for basic memory\-management tasks.
.SS Dumb\-Buffers
-.sp
This examples shows how to create a dumb\-buffer via the generic DRM API.
-This is driver\-independent (as long as the driver supports dumb\-buffers)
+This is driver\-independent
+(as long as the driver supports dumb\-buffers)
and provides memory\-mapped buffers that can be used for scanout. This
example creates a full\-HD 1920x1080 buffer with 32 bits\-per\-pixel and a
color\-depth of 24 bits. The buffer is then bound to a framebuffer which
-can be used for scanout with the KMS API (see \fBdrm\-kms\fP(7)).
+can be used for scanout with the KMS API
+(see \fBdrm\-kms\fP(7)).
.INDENT 0.0
.INDENT 3.5
.sp
@@ -331,12 +346,12 @@ memset(map, 0, creq.size);
.UNINDENT
.UNINDENT
.SH REPORTING BUGS
-.sp
Bugs in this manual should be reported to
- <https://gitlab.freedesktop.org/mesa/drm/\-/issues>
+.ti \n(INu+2m
+<https://gitlab.freedesktop.org/mesa/drm/\-/issues>
.SH SEE ALSO
-.sp
-\fBdrm\fP(7), \fBdrm\-kms\fP(7), \fBdrm\-prime\fP(7), \fBdrmAvailable\fP(3),
-\fBdrmOpen\fP(3), \fBdrm\-intel\fP(7), \fBdrm\-radeon\fP(7),
\fBdrm\-nouveau\fP(7)
+\fBdrm\fP(7), \fBdrm\-kms\fP(7), \fBdrm\-prime\fP(7),
+\fBdrmAvailable\fP(3), \fBdrmOpen\fP(3), \fBdrm\-intel\fP(7),
+\fBdrm\-radeon\fP(7), \fBdrm\-nouveau\fP(7)
.\" Generated by docutils manpage writer.
.
Any program (person), that produces man pages, should check the output
for defects by using (both groff and nroff)
[gn]roff -mandoc -t -ww -b -z -K utf8 <man page>
The same goes for man pages that are used as an input.
For a style guide use
mandoc -T lint
-.-
Any "autogenerator" should check its products with the above mentioned
'groff', 'mandoc', and additionally with 'nroff ...'.
It should also check its input files for too long (> 80) lines.
This is just a simple quality control measure.
The "autogenerator" may have to be corrected to get a better man page,
the source file may, and any additional file may.
Common defects:
Not removing trailing spaces (in in- and output).
The reason for these trailing spaces should be found and eliminated.
"git" has a "tool" to point out whitespace,
see for example "git-apply(1)" and git-config(1)")
Not beginning each input sentence on a new line.
Line length and patch size should thus be reduced.
The script "reportbug" uses 'quoted-printable' encoding when a line is
longer than 1024 characters in an 'ascii' file.
See man-pages(7), item "semantic newline".
-.-
The difference between the formatted output of the original and patched file
can be seen with:
nroff -mandoc <file1> > <out1>
nroff -mandoc <file2> > <out2>
diff -d -u <out1> <out2>
and for groff, using
\"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - \"
instead of 'nroff -mandoc'
Add the option '-t', if the file contains a table.
Read the output from 'diff -d -u ...' with 'less -R' or similar.
-.-.
If 'man' (man-db) is used to check the manual for warnings,
the following must be set:
The option \"-warnings=w\"
The environmental variable:
export MAN_KEEP_STDERR=yes (or any non-empty value)
or
(produce only warnings):
export MANROFFOPT=\"-ww -b -z\"
export MAN_KEEP_STDERR=yes (or any non-empty value)
-.-
