Attempting to get VNC working with Vino AND XRDP ... no luck

I’ve been trying to get Remote Desktop working with my newly flashed TX2. I’m on Ubuntu 18.04 and Jetpack 4.5.1.
This seems like a common problem.
I followed the “get Vino working” instructions found in the L4T-README file.
The “Desktop Sharing” options crash … in fact, Desktop Sharing just crashes with an internal error. I attempted to follow these instructions for getting that bit working but Desktop Sharing still doesn’t open.

I also tried getting remote access using XRDP. Link
It seems like I’m able to connect, but the remote session just sits there for a loooong time … almost like there’s a laggy connection.

Do you have any suggestions?
The eventual goal is to have this run headless and stream results of image classification from a webcam.

Thank you.

Other notes: I do have a monitor connected. I’m able to log in via the attached monitor and keyboard and mouse … things are otherwise working, I suppose.

helped me alot

I have hdmi, mouse and keyboard, use “Activities” search for remote, one result will be settings, and you will get to the Screen Sharing “active” set things up here.

it is dependent on the network,

I then first used linux Remmina and it connected and worked great.

The on a microsoft box I use Realvnc viewer and got into the can’t connect stuff. I found I had to use dconf to set the encription false, and then vnc viewer from microsoft and android would work. the web link give you the command line way of doing a bunch of things to get vino to work.

I might of had to do a sudo apt-get install vino

But the Sharing stuff is critical.

I used vnc and it worked and not xrdp…

Good luck.

You will find that vnc and remote sharing is very slow/laggy/bad.


but even if it’s laggy … I should be able to still log in … which doesn’t seem to be happening here.
My RDP session just … doesn’t get past the login prompt.

I know vnc and realvnc viewer on microsoft and android work, I believe vino only supports vnc, not xrdp.

try vnc ipaddress:5900 as the address and see what happens.


I changed the default port in Remote Desktop on Windows (regedit, changed to port 5900).
That didn’t seem to have an effect.
I did add port 5900 to the firewall … ‘sudo ufw allow 5900’ on the TX2 and rebooted the TX2.

I know real vnc viewer works on my window 10 machine, sorry I will not be any help with Remote Desktop

Look at vino on the web and I know it supports vnc, no clue if it supports xrdp.


ok … downloaded Real VNC.

Checking the logs after a failed connection shows:

vncviewer[11080]: Child: 22516: CConnection: close: [RefuseUnencrypted] Refusing unencrypted connection.

Any idea how to change that setting? Either on my TX2 (allowing unencrypted connections) or in Real VNC (to encrypt connections)

And again … I’m still not able to open up the Desktop Sharing app to perform those parts of the setup steps … ideas?

gsettings set org.gnome.Vino require-encryption false
dconf dump /org/gnome/desktop/remote-access/
dconf dump /org/gnome/settings-daemon/plugins/sharing/vino-server/
gsettings list-recursively org.gnome.settings-daemon.plugins.sharing.service

on my system: the dump commands show
dconf dump /org/gnome/desktop/remote-access/

dconf dump /org/gnome/settings-daemon/plugins/sharing/vino-server/

nmcli c
ATTIKkS5H3 8c5e42da-4280-4643-9bd0-3b7b1f899927 wifi wlan0
ATTIKkS5H3_RPT e3e4aa04-4c39-4459-af2a-4f3ebf636b36 wifi –
Blade T2 Lite Network 36d52975-0b64-4940-8470-c3b7615bf7b2 bluetooth –
Seattle_Test_5G 83b0810b-7771-43ae-a778-642b4d4b6a5c wifi –
Wired connection 1 dbf9df2e-a2b8-3878-a74b-1cd964759830 ethernet –
butterfly 11790a07-31fd-47c2-846c-de00c31bda41 wifi –
butterfly_RPT 2 c07f974e-22fe-40bc-b6e4-d6baf8f88baa wifi –
butterfly_RPT 3 87ce6bc7-757a-4555-b150-583b66ca5a23 wifi –
butterfly_RPT 4 5fd048f3-4532-4251-8c7c-a1e5b3394bcc wifi –
butterfly_RPT 5 a485e30d-279a-4cf6-9296-96c5a1995711 wifi –

do at least the BOLDED command and try again



I used the bolded command and rebooted the TX2.
Ah ha!
That did it … as long as I’m logged in it seems to work.

The bit that doesn’t work is if I’m logged out and I want to run this head-less.
This should be possible …

Good, I knew it would work, it worked for me, how about setting it up to autologin on boot? then the remote will work.


that’s what I ended up doing.
thank you!