From 11411655453f91ad77397780c685ae386d34e13a Mon Sep 17 00:00:00 2001 From: Nicholas Bennett Date: Wed, 22 Feb 2023 15:22:20 +0200 Subject: 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 (cherry picked from commit 9423c67c767656403014b2eb72b56fe21da90234) Reviewed-by: Qt Cherry-pick Bot --- .../android/android-building-user-projects.qdoc | 2 +- .../platforms/android/android-openssl-support.qdoc | 2 +- doc/src/platforms/emb-linux.qdoc | 70 +++++++++++----------- 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=.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", ""); diff --git a/doc/src/platforms/emb-linux.qdoc b/doc/src/platforms/emb-linux.qdoc index 74e28200..93487c53 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 -- cgit v1.2.1