Docs: Fix typos and touch up grammar

Collected some typo and grammar bug fixes into this patch.

Fixes: QTBUG-106682
Fixes: QTBUG-111271
Fixes: QTBUG-111279
Change-Id: Iec758c2fa7f0f3a9ba2af954391bd8af01710bd1
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
(cherry picked from commit 9423c67c767656403014b2eb72b56fe21da90234)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

3 files changed, 37 insertions, 37 deletions

diff --git a/doc/src/platforms/android/android-building-user-projects.qdoc b/doc/src/platforms/android/android-building-user-projects.qdoc
index 4250f6d0..66be77af 100644
--- a/doc/src/platforms/android/android-building-user-projects.qdoc
+++ b/doc/src/platforms/android/android-building-user-projects.qdoc
@@ -114,8 +114,8 @@
     property that specifies a list of ABIs that the single executable target is
     built for. For example:
 
-    \badcode
     \dots 0
+    \badcode
     qt_add_executable(MyApp main.cpp)
 
     set_target_properties(MyApp PROPERTIES QT_ANDROID_ABIS "arm64-v8a;x86")
diff --git a/doc/src/platforms/android/android-openssl-support.qdoc b/doc/src/platforms/android/android-openssl-support.qdoc
index 3361c8cd..96b5124b 100644
--- a/doc/src/platforms/android/android-openssl-support.qdoc
+++ b/doc/src/platforms/android/android-openssl-support.qdoc
@@ -84,7 +84,7 @@ The following instructions guide you to build the OpenSSL libraries manually:
         make -j$(nproc) SHLIB_VERSION_NUMBER= SHLIB_EXT=<custom_suffix>.so build_libs
         \endcode
 
-        Then set the environment variable in your main.ccp file:
+        Then set the environment variable in your main.cpp file:
 
         \code
         qputenv("ANDROID_OPENSSL_SUFFIX", "<custom_suffix>");
diff --git a/doc/src/platforms/emb-linux.qdoc b/doc/src/platforms/emb-linux.qdoc
index 89457363..44586101 100644
--- a/doc/src/platforms/emb-linux.qdoc
+++ b/doc/src/platforms/emb-linux.qdoc
@@ -58,11 +58,11 @@
   with EGLFS there is always exactly one native window and one EGL window
   surface; these belong to the widget or window that is created first. This
   approach works well when there is a main window that exists for the
-  application's lifetime and all other widgets are either non top-levels or are
-  created afterwards, once the main window is shown.
+  application's lifetime and all other widgets are either not top-levels or are
+  created afterward, once the main window is shown.
 
   There are further restrictions for OpenGL-based windows. EGLFS supports a
-  single single fullscreen GL window (as of Qt 5.3), like OpenGL-based QWindow,
+  single fullscreen GL window (as of Qt 5.3), like OpenGL-based QWindow,
   a QQuickView, or a QOpenGLWidget. Opening additional OpenGL windows or mixing
   such windows with QWidget-based content isn't supported; Qt terminates the
   application with an error message.
@@ -87,13 +87,13 @@
           This is only an option when no static or compiled-in hooks were
           specified in the device makespecs. In practice, the traditional
           compiled-in hooks are rarely used, almost all backends are now
-          migrated to plugins. The device makespecs still contain a relevant
-          \c EGLFS_DEVICE_INTEGRATION entry: the name of the preferred backend
-          for that particular device. This is optional, but very useful to
-          avoid the need to set this environment variable if there are more
-          than one plugin present in the target system. In a desktop
-          environment the KMS or X11 backends are prioritized, depending on
-          the presence of the \c DISPLAY environment variable.
+          migrated to plugins. The device makespecs still contain a relevant,
+          though optional,  \c EGLFS_DEVICE_INTEGRATION entry: the name of
+          the preferred backend for that particular device. Avoid setting
+          this environment variable if there is more than one plugin present
+          on the target system. In a desktop environment, the KMS or X11 backends
+          are prioritized, depending on the presence of the \c DISPLAY environment
+          variable.
           \note On some boards a special value of \c none is used instead
           of an actual plugin. This indicates that no special integration is
           necessary to use EGL with the framebuffer; no plugins must be loaded.
@@ -293,7 +293,7 @@
           isn't set.
   \endtable
 
-  As of Qt 5.9, the behavior of EGLFS and LinuxFB have been synchronized, with
+  As of Qt 5.9, the behavior of EGLFS and LinuxFB has been synchronized, with
   regards to the window sizing policy: the first top-level window is forced to
   cover the entire screen, with both platform plugins. If this is not desired,
   set the \c{QT_QPA_FB_FORCE_FULLSCREEN} environment variable to \c 0 to
@@ -301,9 +301,9 @@
 
   \section1 Display output
 
-  When you have multiple displays connected, the level of support to target one
-  or more of these displays from one single Qt application, varies between the
-  platform plugins and often depends on the device and its graphics stack.
+  The level of support to target one or more displays from one single Qt application
+  varies between the platform plugins. Support often depends on the device and its
+  graphics stack.
 
   \section2 EGLFS with the eglfs_kms backend
 
@@ -377,7 +377,7 @@
   \c QT_QPA_EGLFS_ALWAYS_SET_MODE environment variable), this value is useful to
   preserve the current mode and any content in the planes not touched by Qt.
 
-  \c skip causes the connector for the output to be ignored, as if it were
+  \c skip causes the connector for the output to be ignored as if it were
   disconnected. \c off is similar, but it changes the mode and turns off the
   display.
 
@@ -393,7 +393,7 @@
   value starting from 0.
 
   For example, the following configuration uses the preferred resolution but ensures
-  that the left side in the virtual desktop is the screen connected to the HDMI port;
+  that the left side of the virtual desktop is the screen connected to the HDMI port;
   while the right side is the screen connected to the DisplayPort:
 
   \badcode
@@ -444,14 +444,14 @@
 
   \note Avoid such configurations when mouse support is desired. The mouse
   cursor's behavior may be unexpected with non-linear layouts. Touch should
-  present no issues however.
+  present no issues.
 
   \section3 Automatic physic screen size querying
 
-  In some cases the automatic querying of the physical screen size via DRM may
+  In some cases, the automatic querying of the physical screen size via DRM may
   fail. Normally the \c QT_QPA_EGLFS_PHYSICAL_WIDTH and
   \c QT_QPA_EGLFS_PHYSICAL_HEIGHT environment variable would be used to provide the
-  missing values, however this is not suitable anymore when multiple screens are
+  missing values. This is not suitable anymore when multiple screens are
   present. Instead, use the \c physicalWidth and \c physicalHeight properties
   in the \c outputs list to specify the sizes in millimeters.
 
@@ -483,7 +483,7 @@
     }
   \endcode
 
-  For troubleshooting it might be useful to enable debug logs from the KMS/DRM
+  For troubleshooting, it might be useful to enable debug logs from the KMS/DRM
   backend. To do this, enable the \c qt.qpa.eglfs.kms categorized logging rule.
 
   \note In an embedded environment, virtual desktops are more limited compared to
@@ -498,7 +498,7 @@
   \c threaded render loop of the Qt Quick scenegraph, each of these windows will
   get its own dedicated render thread. This is good because the threads can be
   throttled independently based on vsync, and will not interfere with each
-  other. With the \c basic loop this can get problematic, causing animations to
+  other. With the \c basic loop, this can get problematic, causing animations to
   degrade.
 
   For example, discovering all connected screens and creating a QQuickView for
@@ -612,7 +612,7 @@
   within the same renderloop, whereas legacy API would require one plane update
   per vsync.
 
-  Atomic API is useful when you application needs to blend content into overlays
+  Atomic API is useful when your application needs to blend content into overlays
   keeping all the updates within the same vsync. Still not all devices
   support this API and it could be unavailable on some older devices.
   KMS backend will by default use the legacy API, but you can enable the DRM
@@ -645,7 +645,7 @@
   configuration via \c QT_QPA_EGLFS_KMS_CONFIG are supported. Some settings,
   such as \c hwcursor and \c pbuffers are not applicable however.
 
-  By default the backend will automatically choose the correct EGL layer for the
+  By default, the backend will automatically choose the correct EGL layer for the
   default plane of each output. When necessary, this can be overridden by
   setting the \c QT_QPA_EGLFS_LAYER_INDEX environment variable to the index of
   the desired layer. This approach does not currently support multiple outputs,
@@ -653,7 +653,7 @@
   layers are available, and to debug potential startup issues, enable the
   logging category \c qt.qpa.eglfs.kms.
 
-  In some cases it may be necessary to perform a video mode set on application
+  In some cases, it may be necessary to perform a video mode set on application
   startup even when the screen reports that the desired resolution is already
   set. This is normally optimized away, but if the screen stays powered down,
   try setting the environment variable \c QT_QPA_EGLFS_ALWAYS_SET_MODE to a
@@ -661,7 +661,7 @@
 
   To configure the behavior of the EGLStream object used by the backend, use the
   \c QT_QPA_EGLFS_STREAM_FIFO_LENGTH environment variable. This assumes that
-  \c KHR_stream_fifo is supported by the target system. By default the stream
+  \c KHR_stream_fifo is supported by the target system. By default, the stream
   operates in mailbox mode. To switch to FIFO mode, set a value of 1 or
   greater. The value specifies the maximum number of frames the stream can hold.
 
@@ -673,7 +673,7 @@
   environment variables. When these are set, only the specified connector and
   plane will be in use, all other outputs will get ignored. The backend will
   take care of picking the EGL layer that corresponds to the desired plane, and
-  the configuring of the plane.
+  configuring the plane.
 
   \section2 Touch input in systems with multiple screens on KMS/DRM
 
@@ -712,7 +712,7 @@
   \note When in doubt, enable logging from both the graphics and input
   subsystems by setting the environment variable
   \c{QT_LOGGING_RULES=qt.qpa.*=true} before launching the application. This will
-  help identifying the correct input device nodes and may uncover output
+  help identify the correct input device nodes and may uncover output
   configuration issues that can be difficult to debug otherwise.
 
   \note As of Qt 5.8, the above is only supported for the evdevtouch input
@@ -723,7 +723,7 @@
 
   \section2 EGLFS with other backends
 
-  Other backends, that are typically based on targeting the framebuffer or a
+  Other backends, which are typically based on targeting the framebuffer or a
   composition API directly via the vendor's EGL implementation, usually provide
   limited or no support for multiple displays. On i.MX6-based boards with
   Vivante GPUs the \c{QT_QPA_EGLFS_FB} environment variable can be used to
@@ -731,7 +731,7 @@
   the \c{QT_QPA_EGLFS_DISPMANX_ID} environment variable can be used to specify
   the screen to output to. The value corresponds to one of the \c{DISPMANX_ID_}
   constants, refer to the Dispmanx documentation. Note that these approaches,
-  unlike KMS/DRM, will not typically allow to output to multiple screens from
+  unlike KMS/DRM, will not typically allow output to multiple screens from
   the same application. Alternatively, driver-specific environment variables or
   kernel parameters may also be available as well to control the used
   framebuffer. Refer to the embedded board's documentation.
@@ -739,13 +739,13 @@
   \section1 Video memory
 
   Systems with a fixed amount of dedicated video memory may need extra care
-  before running Qt application based on Qt Quick or classes like
+  before running Qt applications based on Qt Quick or classes like
   QOpenGLWidget. The default setting may be insufficient for such applications,
   especially when they are displayed on a high resolution (for example, full HD)
   screen. In this case, they may start failing in unexpected ways. It is
   recommended to ensure that there is at least 128 MB of GPU memory available.
   For systems that do not have a fixed amount of memory reserved for
-  the GPU this is not an issue.
+  the GPU, this is not an issue.
 
   \section2 linuxfb
 
@@ -762,7 +762,7 @@
   possible when \c{QT_QPA_ENABLE_TERMINAL_KEYBOARD} is set, as outlined above in
   the Input section). However, in some cases capturing \c SIGINT can be
   undesirable as it may conflict with remote debugging for instance. Therefore,
-  the environment variable \c{QT_QPA_NO_SIGNAL_HANDLER} is provided to opt out
+  the environment variable \c{QT_QPA_NO_SIGNAL_HANDLER} is provided to opt-out
   from all built-in signal handling.
 
   \section1 Fonts
@@ -792,12 +792,12 @@
   \note On some devices there is no EGL and OpenGL support available under X
   because the EGL implementation is not compatible with Xlib. In this case the
   XCB plugin is built without EGL support, meaning that Qt Quick 2 or other
-  OpenGL-based applications does not work with this platform plugin. It can
-  still be used however to run software-rendered applications (based on QWidget
+  OpenGL-based applications do not work with this platform plugin. It can
+  still be used, however, to run software-rendered applications (based on QWidget
   for example).
 
   As a general rule, the usage of XCB on embedded devices is not
-  advisable. Plugins like eglfs are likely to provide better performance, and
+  advisable. Plugins like eglfs are likely to provide better performance and
   hardware acceleration.
 
   \section2 Wayland