Windows RDP achieves its speed by the fact that both server and client are created
by Microsoft, which allows it to be heavily optimized.
For example: RDP uses compression to speed up the screen casting,
and especially video codecs.
To support larger screens than full HD, it will use the
AVC/H.264 video codec. This allows it to use the video GPU
to speed ...
When the RDP session is lost cause various causes like network contention, you are only disconnected. You session is not closed, you are only disconnected. Then when you'll reconnect to the session (same user of course) and you'll retreive all informations, treatments and so on in your current session. You was just idle.
Often, i'm launching script file on ...
Basically this is a modification of @jooguan answer above.
The trick of pressing Windows key and type keyboard, didn't work for me remotely.
So I used literally the same suggestion of Ray Rajko Bogdanovic's to use the On-Screen Keyboard, following these steps:
Connect to the remote machine
In the remote Windows system, click the Start button, located in ...
In Windows 10, right click on the shortcut to launch your viewer. Go to properties, click the compatibility tab, click "Change high DPI settings", under High DPI scaling override, check "Override high DPI scaling behavior" and set the drop down to "Application".
What solved the problem for me was fixing this registry key.
Your path to the viewer may be different. The trick for me was adding the -optionsfile.
It needs to be "C:\Program Files\TightVNC\tvnviewer.exe" "-optionsfile=%1"
I have found this link which explains that there have been some changes to systemd, so this is more than likely where the issue is coming from.
I have removed the line referring to the pid from my vncserver@:x file and no longer get an error reporting, although the pid is still reporting an error. Hopefully there ...
I finally got it working by changing the --session type to gnome-classic. So my working startup file is now as shown below:
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
I've found this project (is not with MIT Licensed but it's pretty cool).
The principle is :
Create a virtual screen and start x11 (this is done by VirtScreen)
from the slave laptop connect via viewer (i'm using vncViewer)
VirtScreen : https://github.com/kbumsik/VirtScreen/releases
Synergy is a $30-$40 commercial supported open source app (you can download the source code to compile and build it yourself) which does this.
Free? There's a free fork of Synergy, named Barrier (review) with a package for 18.04 and now 20.04.
x2vnc is also available and requires x2x or x11vnc on the subordinate PC, but unlike Barrier, it's out of ...
It is not a solution for the above error but it realizes the VNC connection
At the end, I downloaded Real VNC Viewer from here and it did the job. There, I had to put the Domain (the raspberry IP and not the "IP-like thing"), the username and the user password.
The installation was done using sudo dpkg -i VNC-Viewer-6.20.113-Linux-x64.deb (Ubuntu 18.04)
It seems like you have tried using many different Windows clients, but did you ever think that the problem might be the server?
Apple has a tendency to make their own [everything], which can be either good or bad. I am not an Apple user, but my wild guess is that they made their own protocols for remote management (similar but different from VNC).
I will say you use rdesktop command but it seems that this project will not have a mantainer. Very light software to connect via RDP over Linux shell.
I suggest you use Remmina if rdesktop cannot be find at Ubuntu 18, give a try:
I have used these two ones at work when I have to access Windows Servers at my Ubuntu desktop and I always have a good ...
So I found 2 solutions for me - if anyone stumble over the same question.
with Tigervnc or Tightvnc
The difference between both is that 1. starts its own x11 server and 2. connects to the existing desktop. With 1. I can setup any screen resolution that I want and start as many as the hardware can handle - didn't red about any limitations.
Assuming RealVNC is not supported on the platform you are using (which is my case with arm64 Arch) I found the following solution.
As root, edit the config file in /root/.vnc/config.d/vncserver-x11
Insert the following at the bottom of the file
Restart RealVNC (or just reboot)
As user rodrunner suggested in the comments, one way to get the VNC connection going is by using RealVNC's vncviewer.
Make sure to uninstall TigerVNC or any other VNC implementations before proceeding.
The package of RealVNC viewer is currently in AUR, you can install it via aura:
sudo aura -A realvnc-vnc-viewer
Assuming your Raspberry Pi'...
A bit late to the party but x11vnc will allow you to scale the footage before streaming it to you (saving bandwidth and yet still providing the larger resolution to applications).
Check out the -scale option.
With TigerVNC Windows VNC client (viewer) auto resolution works out of the box. No need to set anything anywhere, on the client or on the server. When you first connect to your server, the resolution is set to whatever is preset on the server side but you can easily change it just by resizing the client window; to any resolution, any crazy, non-standard, ad-...