SUMMARY The full screen from the remote computer is not shown on in the VNC client - it appears to be stuck at a lower resolution STEPS TO REPRODUCE 1. Run KRFB on host Kubuntu 2. Run VNC client on Windows (tried TightVNC and RealVNC to confirm issue) 3. Connect to KRFB Kubuntu host OBSERVED RESULT Full screen is not displayed - it is at 1440x960, top-left of host screen EXPECTED RESULT Full 2160 x 1440 screen should be displayed on the client SOFTWARE/OS VERSIONS Windows: 10 macOS: no thanks Linux/KDE Plasma: Kubuntu 19.10 installed (available in About System) KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.67.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION Surface Pro 3 *not* in VM/hypervisor This has been observed by other users, but I cannot find anywhere in krfb to configure it; nor in rfb; is it an fb issue/limitation? Wouldn't have expected it - the screen looks good locally...
connecting from KRDC to KRFB on the came computer has a similar outcome, even though I set the host resolution in KRDC...
I discovered the cause - it is because the display is scaled. I.e., if I scale it to 200%, then only a quarter of the screen can be seen in VNC client. In this age of high-resolution laptops, this is a deal-breaker...
might be fixed by https://invent.kde.org/network/krfb/-/merge_requests/7
thanks @alexey
Git commit 933169b4c0e3ea9796783f70eca2f0aae29dea2f by Stefan Brüns. Committed on 28/08/2020 at 02:08. Pushed by bruns into branch 'master'. Compensate for global scale factor when using xcb fb plugin The screen geometry is reported in device independent pixels, so it has to be multiplied by the devicePixelRatio to get the size of the underlying framebuffer. Otherwise, only the top left of the screen will be captured. This matches the behavior of QScreen::grabWindow(...), which also returns a QPixmap of the given size scaled by devicePixelRatio. M +5 -1 framebuffers/xcb/xcb_framebuffer.cpp https://invent.kde.org/network/krfb/commit/933169b4c0e3ea9796783f70eca2f0aae29dea2f
Git commit 024ce87b3af0c7b8cffbf2065c3f083a057edb70 by Alexey Min, on behalf of Stefan Brüns. Committed on 15/09/2020 at 00:03. Pushed by alexeymin into branch 'release/20.08'. Compensate for global scale factor when using xcb fb plugin The screen geometry is reported in device independent pixels, so it has to be multiplied by the devicePixelRatio to get the size of the underlying framebuffer. Otherwise, only the top left of the screen will be captured. This matches the behavior of QScreen::grabWindow(...), which also returns a QPixmap of the given size scaled by devicePixelRatio. M +5 -2 framebuffers/xcb/xcb_framebuffer.cpp https://invent.kde.org/network/krfb/commit/024ce87b3af0c7b8cffbf2065c3f083a057edb70
thank you!
The exact same problem happens when the remote computer is running a Wayland session. I don't know if it would be better to open a new ticket or reopen this one but since it's the exact same problem I preferred the latter. When the display of the remote computer is scaled only the upper left computer is shown on the client and scaling the output on the client seems not possible. Just right the original report. The solution provided seems to only cover Xorg and indeed all works flawlessly on Xorg remote sessions. We need a solution for Plasma Wayland too, also considering at this moment there is no other native way to remote controlling a graphic session on Plasma Wayland (The RDP server seems not being ready yet) and still Wayland is to be becoming default on Plasma 6 (and the only choice on Fedora)
(In reply to nope1000000 from comment #8) > The exact same problem happens when the remote computer is running a Wayland > session. I don't know if it would be better to open a new ticket or reopen > this one but since it's the exact same problem I preferred the latter. > > When the display of the remote computer is scaled only the upper left > computer is shown on the client and scaling the output on the client seems > not possible. Just right the original report. The solution provided seems to > only cover Xorg and indeed all works flawlessly on Xorg remote sessions. We > need a solution for Plasma Wayland too, also considering at this moment > there is no other native way to remote controlling a graphic session on > Plasma Wayland (The RDP server seems not being ready yet) and still Wayland > is to be becoming default on Plasma 6 (and the only choice on Fedora) Just some corrections on my previous message: The upper left OF THE SCREEN* Just LIKE* the original report