Remote Desktop software (RDP, RDM, terminals, TeamViewer)

[joten]

[ Bug #18382 ] Remote Desktop windows do not resize/position correctly

Import from berliOS:

Date: 2011-Oct-04 17:41
Submitted By: djsumdog
Assigned To: fuhsjr00
Category: application compatibility
Priority: 5
Bug Group: None
Resolution: Later
Summary: Remote Desktop windows do not resize/position correctly

Original Submission:

I've had some trouble with bug.n and Remote Desktop. If remote desktop
starts as full screen, I realize that is a problem. But even if I tell
it to start in a scaled window, bug.n seems to incorrectly determine the
window size and either give it a really small area or have it overlay
all the other windows.

I've tried using other remote desktop tools like Remote Desktop Manager
and Terminals, but they all use the standard windows libraries for RDP
and render to the screen the same way.

Also, when I open sessions in a window, over half the time the remote
machine will not receive mouse or keyboard events. Occasionally the
mouse cursor I see is 100 or so pixels off from where the event
registers on the remote machine. There is no way to send events to the
machine without first quitting bug.n

Operating System: Windows 7 64 Ultimate
Resolution: 2x 1920x180 monitors

Followups

2012-Nov-24 15:47 fuhsjr00
You can configure RDP to capture hotkeys when not in full-screen mode.
When I do this, I'm completely unable to interact with bug.n until I
change focus to another window with the mouse.

I've not seen any rendering problems with RDP, but I usually use RDP in
mono mode.

---

2012-Mar-27 19:36 tammeri
Hello,

I was experiencing the same problem, until I discovered the Window Rule
feature. I included this rule in my Config.ini:

Config_rule=TscShellContainerClass;*;;1;1;0;1;1;0

Now the remote desktop app (mstc.exe) works as expected! If fullscreen,
the remote desktop takes over the keyboard and mouse. If windowed, the
window works as a managed floating window. Has saved me a lot of
headaches!

---

2011-Oct-06 13:31 joten
I am not sure I can build a test environment for this; but I will see.

Regarding the second problem, I can imagine, that there might be a
conflict, which will be difficult to solve, since, as far as I know,
both applications (bug.n and Remote Desktop) monitor the keyboard and
mouse input.

[ Bug #18808 ] bug.n does not handle display changes well

Import from berliOS:

Date: 2012-Nov-26 01:28
Submitted By: fuhsjr00
Assigned To: fuhsjr00
Category: None
Priority: 5
Bug Group: None
Resolution: None
Summary: bug.n does not handle display changes well

Original Submission:

To start, the configuration that I'm immediately interested in is a
dual-monitor (1680x1050) system connecting to another dual-monitor
(1920x1080) system via RDP.

If I attempt this forcing the local RDP resolution to 3840x1080 it
works, though somewhat awkwardly. If I accidentally do something that
causes bug.n to re-measure monitor 1 (#Space), then monitor 1 takes up
the entire 3840x1080 RDP session, and monitor 2 (of the original setup)
is near impossible to use.

If I use the /multimon switch ("Use all my monitors for the remote
session"), monitor 1 will resize correctly (to match my local monitor)
when I do something to indirectly resize it. However, monitor 2 is still
stuck at its original position and resolution.

When I connect a single-monitor (less than 1680x1050) station to the
same dual-monitor bug.n setup via RDP, the experience is awful. Setting
the resolution to 3840x1080 makes everything usable, but extremely
awkward (and suffers from the same resize problem above). If I just use
the full screen single-monitor settings, the second bug.n monitor is
completely unavailable. I think this use case calls into question the
one-to-one "Monitor" to physical display relationship that bug.n
currently enforces.

[joten]

I moved parts from issue #7 to this issue. They seem to be related, whereas the bug report from issue #7 regarding RDP did not seem to be related to the handling of display changes.

I am still not able to work on this one; I do not have the "infrastructure" to reproduce the problem.

[joten]

Although it is a long time ago ... is this issue related to running bug.n on a machine, to which you connect over RDP, or are you running bug.n on the local machine on which RDP clients are running?

[fuhsjr00]

When I had filed this I was using bug.n on the remote multi-monitor machine and optionally on the local multi-monitor machine.

The first issue was that bug.n simply didn't handle the change in "display". I had (2) remote displays, but the RDP viewport only appeared as 1 large display (I believe). I also confirmed that bug.n didn't handle physical display changes well either. I think these problems shared the same root cause.

Another issue with RDP or VNC is/was the handling of keyboard events.

My daily development is almost exclusively Mac and Linux now, so this hasn't been a problem for me.