diff --git a/docs/source/about/guides/app_examples.rst b/docs/source/about/guides/app_examples.rst index 8bca2bd89f0..932c129a727 100644 --- a/docs/source/about/guides/app_examples.rst +++ b/docs/source/about/guides/app_examples.rst @@ -200,11 +200,11 @@ Changing Resolution and Refresh Rate .. tab:: X11 - +----------------------+------------------------------------------------------------------------------------------------------------------------------------+ - | Command Preparations | Do: ``sh -c "xrandr --output HDMI-1 --mode \"${SUNSHINE_CLIENT_WIDTH}x${SUNSHINE_CLIENT_HEIGHT}\" --rate ${SUNSHINE_CLIENT_FPS}"`` | - | +------------------------------------------------------------------------------------------------------------------------------------+ - | | Undo: ``xrandr --output HDMI-1 --mode 3840x2160 --rate 120`` | - +----------------------+------------------------------------------------------------------------------------------------------------------------------------+ + +----------------------+--------------------------------------------------------------------------------------------------------------------------------+ + | Command Preparations | Do: ``sh -c "xrandr --output HDMI-1 --mode ${SUNSHINE_CLIENT_WIDTH}x${SUNSHINE_CLIENT_HEIGHT} --rate ${SUNSHINE_CLIENT_FPS}"`` | + | +--------------------------------------------------------------------------------------------------------------------------------+ + | | Undo: ``xrandr --output HDMI-1 --mode 3840x2160 --rate 120`` | + +----------------------+--------------------------------------------------------------------------------------------------------------------------------+ .. hint:: The above only works if the xrandr mode already exists. You will need to create new modes to stream to macOS and iOS devices, since they use non standard resolutions. @@ -256,6 +256,24 @@ Changing Resolution and Refresh Rate | | Undo: ``wlr-xrandr --output HDMI-1 --mode 3840x2160@120Hz`` | +----------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + .. hint:: + + ``wlr-xrandr`` only works with wlroots-based compositors. + + .. tab:: Gnome (Wayland, X11) + + +----------------------+--------------------------------------------------------------------------------------------------------------------------------+ + | Command Preparations | Do: ``sh -c "xrandr --output HDMI-1 --mode ${SUNSHINE_CLIENT_WIDTH}x${SUNSHINE_CLIENT_HEIGHT} --rate ${SUNSHINE_CLIENT_FPS}"`` | + | +--------------------------------------------------------------------------------------------------------------------------------+ + | | Undo: ``xrandr --output HDMI-1 --mode 3840x2160 --rate 120`` | + +----------------------+--------------------------------------------------------------------------------------------------------------------------------+ + + The commands above are valid for an X11 session but won't work for + Wayland. In that case ``xrandr`` must be replaced by `gnome-randr.py + `_. This script is intended as a + drop-in replacement with the same syntax. (It can be saved in + ``/usr/local/bin`` and needs to be made executable.) + .. tab:: KDE Plasma (Wayland, X11) +----------------------+-------------------------------------------------------------------------------------------------------------------------------+ diff --git a/docs/source/troubleshooting/general.rst b/docs/source/troubleshooting/general.rst index e1602da1349..7d174787076 100644 --- a/docs/source/troubleshooting/general.rst +++ b/docs/source/troubleshooting/general.rst @@ -86,6 +86,9 @@ instead of 2.5 or 100 Mbps instead of 1 Gbps. (A technically more advanced solution would be to configure traffic shaping rules at the OS-level, so that only Sunshine's traffic is slowed down.) +Sunshine versions > 0.23.1 include improved networking code that should +alleviate or even solve this issue (without reducing the NIC speed). + Packet loss (MTU) ----------------- Albeit unlikely, some guests might work better with a lower `MTU diff --git a/docs/source/troubleshooting/linux.rst b/docs/source/troubleshooting/linux.rst index 2a4817f1374..aab32db0f1b 100644 --- a/docs/source/troubleshooting/linux.rst +++ b/docs/source/troubleshooting/linux.rst @@ -50,22 +50,26 @@ often grub is used to load the kernel and set its command line.) AMD encoding latency issues --------------------------- -If you notice unexpectedly high encoding latencies (e.g. in Moolight's +If you notice unexpectedly high encoding latencies (e.g. in Moonlight's performance overlay) or strong fluctuations thereof, this is due to `missing support `_ in Mesa/libva for AMD's low latency encoder mode. This is particularly problematic at higher resolutions (4K). -As of now this can only be fixed by recompiling Mesa with a test patch (see -url above) that unconditionally enables a low latency tuning mode for all -encoder workloads. This is for advanced users only and neither support nor -warranty are provided. Note also that this patch entails a higher power -consumption while encoding and may not be suitable for all use cases. +Only the most recent development versions of mesa include support for this +low-latency mode. It will be included in Mesa-24.2. -(A crude workaround is to *increase* the load on the de-/encoder by having it -de- or encode an additional arbitrary video stream in the background. This -ensures that the encoder's clock frequencies stay high and the latency -fluctuations disappear.) +In order to enable it, Sunshine has to be started with a special environment +variable: + +.. code-block:: bash + + AMD_DEBUG=lowlatencyenc sunshine + +To check whether low-latency mode is being used, one can watch the ``VCLK`` and +``DCLK`` frequencies in ``amdgpu_top``. Without this encoder tuning both clock +frequencies will fluctuate strongly, whereas with active low-latency encoding +they will stay high as long as the encoder is used. Gamescope compatibility ----------------------- diff --git a/packaging/linux/sunshine.service.in b/packaging/linux/sunshine.service.in index df914ebff33..1ba3a138b46 100644 --- a/packaging/linux/sunshine.service.in +++ b/packaging/linux/sunshine.service.in @@ -4,6 +4,8 @@ StartLimitIntervalSec=500 StartLimitBurst=5 [Service] +# Avoid starting Sunshine before the desktop is fully initialized. +ExecStartPre=/bin/sleep 5 @SUNSHINE_SERVICE_START_COMMAND@ @SUNSHINE_SERVICE_STOP_COMMAND@ Restart=on-failure diff --git a/src_assets/common/assets/web/public/assets/locale/en.json b/src_assets/common/assets/web/public/assets/locale/en.json index cc5a863a5e9..73418b797e2 100644 --- a/src_assets/common/assets/web/public/assets/locale/en.json +++ b/src_assets/common/assets/web/public/assets/locale/en.json @@ -252,7 +252,7 @@ "origin_web_ui_allowed_lan": "Only those in LAN may access Web UI", "origin_web_ui_allowed_pc": "Only localhost may access Web UI", "origin_web_ui_allowed_wan": "Anyone may access Web UI", - "output_name_desc_unix": "During Sunshine startup, you should see the list of detected displays. Note: You need to use the id value inside the parenthesis.", + "output_name_desc_unix": "During Sunshine startup, you should see the list of detected displays. Note: You need to use the id value inside the parenthesis. Below is an example; the actual output can be found in the Troubleshooting tab.", "output_name_desc_windows": "Manually specify a display to use for capture. If unset, the primary display is captured. Note: If you specified a GPU above, this display must be connected to that GPU. The appropriate values can be found using the following command:", "output_name_unix": "Display number", "output_name_windows": "Output Name",