-
Notifications
You must be signed in to change notification settings - Fork 713
GUACAMOLE-288: Add support for multi-monitor connections. #560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
GUACAMOLE-288: Add support for multi-monitor connections. #560
Conversation
78954b5
to
d829739
Compare
8374544
to
683800f
Compare
683800f
to
62c8b1e
Compare
62c8b1e
to
4ee5e1b
Compare
4ee5e1b
to
ac08c95
Compare
it will be great if we bring that to main |
Yes, that is the plan, once the code is finalized and has been fully reviewed. |
f4716ce
to
1fa8ce3
Compare
afbaa06
to
d44d527
Compare
9fb030d
to
7a8e74a
Compare
…hen adding a new monitor.
eda5067
to
5294c1b
Compare
Frequently resizing a monitor window, e.g. by using Maximize and Restore down of the window in quick succession, can cause a RDP disconnect with the following message in the guacd logs:
Is it possible to wait for the flush or just discard the affected window instead of crashing the connection? |
Which version of freerdp are you using? |
I'm using the Dockerfile from the repository which defaults to FreeRDP 2. The exact version is |
This is potentially a bug in FreeRDP. This assertion is mandatory in version 2. |
This comment was marked as resolved.
This comment was marked as resolved.
I was able to reproduce it with one monitor with the FreeRDP 2 build. EDIT: It does not reproduce with FreeRDP 3, independent of the number of monitors. |
guac_rdp_client* rdp_client = (guac_rdp_client*) client->data; | ||
|
||
pthread_mutex_lock(&(rdp_client->message_lock)); | ||
disp->disp->SendMonitorLayout(disp->disp, monitors_count, monitors); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may not understand the API, but naively I feel like when a pointer (monitors) is sent via a signal that memory must either be given to the receiver (eg it is now responsible for freeing monitors) or it would have to signal it is "done" with the memory somehow (which I cannot see happening). I believe from line 422 that there is a possible segmentation violation with the receiver of SendMonitorLayout reading free'ed memory.
/* Send current max allowed secondary monitors */ | ||
guac_client_stream_argv(client, broadcast_socket, "text/plain", | ||
"secondary-monitors", max_monitors); | ||
guac_mem_free(max_monitors); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same concern as above, who "owns" the char* max_monitors? does guac_client_stream_argv copy from max_monitors?
/* Make json string containing monitor information */ | ||
char json[JSON_BUFFER_SIZE]; | ||
int pos = 0; | ||
pos += snprintf(json + pos, JSON_BUFFER_SIZE - pos, "{"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: While there may be concerns about grabbing an external dependency, when it comes to "never re-invent the wheel" any manual string manipulation to do json generation/parsing is king. Libraries like
https://github.com/nlohmann/json
will allow "C++ like" json parsing and generation that covers all the corner cases that JSON hides from the average user.
} | ||
|
||
/* Append monitor information to JSON string */ | ||
pos += snprintf(json + pos, JSON_BUFFER_SIZE - pos, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small piece of my soul is severed and sent to the depths of Hades every time I see sprintf generating json.
@necouchman @corentin-soriano |
I still have some things to finalize before we can merge. |
Allows as is to add multiple monitors of the same dimensions in RDP protocol if the server supports it.
I haven't looked at the VNC part yet.
Client side PR : apache/guacamole-client#1061
POC:
