debcrafters-packages team mailing list archive

[Alessandro Astone <2127792@xxxxxxxxxxxxxxxxxx>]

> The protocol should be RDP - Remote Desktop Protocol. Indeed in Gnome
settings panel it's called Remote Login.

Both "Desktop Sharing" and "Remote Login" use RDP. Only the latter
presents the log-in screen, which according to the upstream maintainer
is the only place where you'd see these graphical artifacts.

> there is actually another bug somewhat close that you're involved in
already (https://bugs.launchpad.net/ubuntu/+source/gnome-remote-
desktop/+bug/2077538?comments=all). Because of this one (I think) we
have to add the user we setup in the "Remote Login" to both the video
and render groups

The credentials set in "Login Details" are for an RDP user, not a linux
user. The log-in screen **in plucky and older** is always presented by
the "gdm" user, which is why I proposed `usermod -a -G render gdm`.
Alternatively, if you don't want to guess the user then chmod 666 would
achieve the same result. Whether this is necessary for triggering this
bug, I don't know.

> otherwise it crashes. What do you think?

I'm not aware of bug 2077538 causing crashes. At most, it should prevent
GNOME Shell from doing hardware accelerated rendering and fall-back to
software rendering. But that is without NVIDIA remote desktop in the
mix: does it crash remote desktop on NVIDIA?

> The monitor: actually this fix is about headless sessions. But testing
with AND without a monitor would be safer. Adding to the test plan.

The upstream maintainer commented:
"""
CUDA seems to only work, when the application or service using it, runs as a user that has physical access to a monitor. In headless sessions, there is no physical monitor. Thus CUDA and NVENC should fail to initialize, and the session falls back to software encoding.
"""

which doesn't make a whole lot of sense to me, but maybe it's true at
least in this case?

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to gnome-remote-desktop in
Ubuntu.
https://bugs.launchpad.net/bugs/2127792

Title:
  Images are corrupted on blackwell GPUs

Status in gnome-remote-desktop package in Ubuntu:
  Fix Released
Status in gnome-remote-desktop source package in Noble:
  In Progress
Status in gnome-remote-desktop source package in Plucky:
  In Progress
Status in gnome-remote-desktop source package in Questing:
  In Progress
Status in gnome-remote-desktop source package in Resolute:
  Fix Released

Bug description:
  There is image distorsion in gnome-remote-desktop when a Blackwell GPU
  is in use and NVENC is responsible for the video streaming.

  Upstream issue: https://gitlab.gnome.org/GNOME/gnome-remote-
  desktop/-/issues/263

  A fix was just released by nvidia upstream, and also backported to GNOME 48: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/344
  https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/346

  ---------------------------
  SRU Justification:

  [ Impact ]

   * This is a hardware enablement SRU.

   * gnome-remote-desktop, when used alongside NVENC for video
  streaming, simply does not work, because the image is broken.

   * With the above, the streaming is fixed.

  [ Fix ]

   * Nvidia devices never supported `NV_ENC_PARAMS_FRAME_FIELD_MODE_MBAFF`.
  Though the code worked for past, it causes interlaced line artifacts on
  Blackwell GPUs.

  * Using `NV_ENC_PARAMS_FRAME_FIELD_MODE_FRAME` and changing
  `grd-cuda-avc-utils` to produce progressive frames works on
  Blackwell and on older GPU generations.

  [ Test Plan ]

  1. Use a DUT that has a Blackwell GPU
  (https://en.wikipedia.org/wiki/Blackwell_(microarchitecture)#Blackwell_dies)

  2. Enable Remote Login from the Gnome Settings on the DUT with a
  monitor plugged in.

  3. Install Reminna from Snap. This version supports NVENC, the .deb
  does not.

  4. Test gnome-remote-desktop with and without the fix. Make sure which
  backend is in use. This can be checked by running `nvidia-smi dmon`
  and observing an encoder activity >0%. The repro only occurs when the
  NVENC path is used. CPU encoding path or non-H264 streaming is
  unaffected

  5. Run the same test without a monitor plugged in to the DUT.

  6. Run the same tests (with and without monitors) on an older GPU
  generation (Maxwell, ideally)

  [ Where problems could occur ]

   * Given the nature of the fix, it should not impact non-nvidia machines.
   * Also, the  fix comes from nvidia themsleves, and it's in GNOME 48 and 49 already, so it's pretty safe.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-remote-desktop/+bug/2127792/+subscriptions