RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1765448 - remote session shows black screen when starting
Summary: remote session shows black screen when starting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gnome-remote-desktop
Version: 8.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: 8.0
Assignee: Jonas Ådahl
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1739559 1745633
Blocks: 1748331
TreeView+ depends on / blocked
 
Reported: 2019-10-25 06:46 UTC by Martin Krajnak
Modified: 2020-04-28 16:10 UTC (History)
4 users (show)

Fixed In Version: gnome-remote-desktop-0.1.6-6.el8 libvncserver-0.9.11-10.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:09:57 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1766 0 None None None 2020-04-28 16:10:18 UTC

Description Martin Krajnak 2019-10-25 06:46:09 UTC
Description of problem:
There are several concerns with screen sharing experience revealed after rebase to a new version pipewire-0.2.7-1.el8.x86_64

Environment: RHEL-8.2.0-20191020.n.0, both VM and bare metal + updated pipewire

1. Reproducer (gating test which we used in past a quick verification in our CI)
a) enable screen sharing, set password
b) connect from the shared session from the very same machine -> vinagre localhost:0, fill password

Result; There was a nested sessions shown on the screen so we were able to verify that screen is shared

After rebase: Session is loaded but some click actions are ignored with following messages in journal shown later:
Oct 23 14:15:06 localhost.localdomain org.gnome.Shell.desktop[3547]: libinput error: client bug: timer event2 debounce short: offset negative (-8ms)
Oct 23 14:15:14 localhost.localdomain org.gnome.Shell.desktop[3547]: libinput error: client bug: timer event2 debounce: offset negative (-7ms)
Oct 23 14:15:15 localhost.localdomain org.gnome.Shell.desktop[3547]: libinput error: client bug: timer event2 debounce short: offset negative (-0ms)
Oct 23 14:15:16 localhost.localdomain org.gnome.Shell.desktop[3547]: libinput error: client bug: timer event2 debounce short: offset negative (-10ms)
Oct 23 14:15:18 localhost.localdomain org.gnome.Shell.desktop[3547]: libinput error: client bug: timer event2 debounce short: offset negative (-5ms)


I know that this is not a very good use case but it was working quite good in the previous version of pipewire (pipewire-0.2.5-1.el)
we were able to control the session and for a while than close the connection without the problems. After update, it is very hard to close the nested mess and it takes a while to force the event to close the remote viewer. Not to mention that if I kill the vinagre sometimes I completely loose the input for the session and I have to restart the gdm to bring it back.

Question:

Opinion on these errors from Peter Hutterer
"""
in short: mutter doesn't call libinput_dispatch() quickly enough because
it's stuck doing something else. There's some more info here:
https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#what-causes-the-timer-offset-negative-warning

There isn't anything we can fix in libinput though because we rely on
the caller to provide the mainloop and in this case it's too slow.

Cheers,
   Peter
"""

2.Reproducer
Enabling sharing, connection from the different machine

Result: Connection is made, but the screen is black for as long as 60 seconds before it is shown to the user, the problem here is, remote-viewer screen is black, until I randomly do one of the following:
a) keep clicking on a blank black screen in vinagre
b) I click or press a key on a machine I am connected to I am getting the screen instantly after pressing the key

Sometimes I have to do just one of the above cases, sometimes I have to do both to get it working

3. Problem How long should password be saved ? Most of the time the password option in control-center only lasts for 1 connection,
then it clears the password and leave the form blank until it is updated by the user again. Sometimes it resets itself to:
"New connections must ask for access", it looks very inconsistent to me, I would expect that the remote access is configured once and worked until it
is turned off.

Comment 2 Wim Taymans 2019-11-13 12:24:06 UTC
I tried with latest nightly build RHEL-8.2.0-20191113.n.0 on a bare laptop. Here are some observations:

Running vinagre results in very high cpu load on some components (vinagre 100%, gnome-remote-desktop 100%, gnome-shell 47%).
I guess this can explain the input event errors. The experience is not smooth, there is considerable lag between the screen
and vinagre (measured in seconds).

Running vinagre with jpeg compression improves things a lot. CPU load is still quite high but the system can keep up
(vinagre 66%, gnome-remote-desktop 46%, gnome-shell 35%). Latency is now maybe around 100ms and stable.

I can't really move into the vinagre window, I get moved to the corresponding coordinate in the real screen.

This was with version 0.2.7 of PipeWire.

I forcibly downgraded to 0.2.5 of PipeWire and can't see any difference in the above observations.

Remote connection did not work yet (firewall issues probably..)

Comment 3 Wim Taymans 2019-11-13 14:26:48 UTC
I tried over a WiFi network between 2 computers.

This uses much less CPU usage and is quite usable with or without jpeg compression (gnome-remote-desktop 2%, gnome-shell 2%).
CPU peaks when moving windows around, which is quite expected.

I can't see a difference between 0.2.5 and 0.2.7 PipeWire.

Comment 4 Wim Taymans 2019-11-13 14:45:35 UTC
I can reproduce the black screen when starting. It goes away as soon as I move the mouse on the receiver. No action
on the sender can seem to unlock the black screen.

I get the same behaviour with 0.2.5 as with 0.2.7.

Comment 5 Martin Krajnak 2019-11-19 12:48:01 UTC
(In reply to Wim Taymans from comment #3)
> I tried over a WiFi network between 2 computers.
> 
> This uses much less CPU usage and is quite usable with or without jpeg
> compression (gnome-remote-desktop 2%, gnome-shell 2%).
> CPU peaks when moving windows around, which is quite expected.
> 
> I can't see a difference between 0.2.5 and 0.2.7 PipeWire.

True this works fine for me as well.

(In reply to Wim Taymans from comment #4)
> I can reproduce the black screen when starting. It goes away as soon as I
> move the mouse on the receiver. No action
> on the sender can seem to unlock the black screen.
> 
> I get the same behaviour with 0.2.5 as with 0.2.7.

I am not sure about this, but would it be somehow possible to force rendering
of the very first frame as soon as the connection is made ? I had the experience
of clicking on black screen around 10 seconds before I got rid of it. Or would it be
possible to have some indicator (red, orange, green light or a simple message) that user 
should wait as connection is still being made ?

Comment 7 Martin Krajnak 2019-11-28 12:11:27 UTC
gnome-remote-desktop-0.1.6-6.el8.x86_64
libvncserver-0.9.11-10.el8.x86_64

Tested on 2 machines over wifi ( with temporarilly disabled firewalld) + vm, much better experience, thanks a lot!

Comment 9 errata-xmlrpc 2020-04-28 16:09:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1766


Note You need to log in before you can comment on or make changes to this bug.