Skip to content

Conversation

corentin-soriano
Copy link
Member

@corentin-soriano corentin-soriano commented Oct 20, 2024

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:
image

@corentin-soriano corentin-soriano force-pushed the GUACAMOLE-288_multi_monitors branch from 4ee5e1b to ac08c95 Compare February 22, 2025 15:41
@Pierre-Gronau-ndaal
Copy link

it will be great if we bring that to main

@necouchman
Copy link
Contributor

necouchman commented Apr 15, 2025

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.

@corentin-soriano corentin-soriano force-pushed the GUACAMOLE-288_multi_monitors branch 2 times, most recently from f4716ce to 1fa8ce3 Compare May 23, 2025 14:58
@corentin-soriano corentin-soriano force-pushed the GUACAMOLE-288_multi_monitors branch 2 times, most recently from afbaa06 to d44d527 Compare May 30, 2025 13:23
@corentin-soriano corentin-soriano force-pushed the GUACAMOLE-288_multi_monitors branch 4 times, most recently from 9fb030d to 7a8e74a Compare June 8, 2025 13:43
@corentin-soriano corentin-soriano force-pushed the GUACAMOLE-288_multi_monitors branch from eda5067 to 5294c1b Compare June 17, 2025 15:49
@Vertganti
Copy link

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:

GUAC_ASSERT in guac_rdp_gdi_desktop_resize() failed at gdi.c:172.

Assertion code

Is it possible to wait for the flush or just discard the affected window instead of crashing the connection?

@corentin-soriano
Copy link
Member Author

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:

GUAC_ASSERT in guac_rdp_gdi_desktop_resize() failed at gdi.c:172.

Assertion code

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?
If you are on v3, can you update it to at least version 3.8.0?

@Vertganti
Copy link

Vertganti commented Jul 7, 2025

I'm using the Dockerfile from the repository which defaults to FreeRDP 2. The exact version is 2.11.7. I can try using FreeRDP 3 to see if that improves anything.

@corentin-soriano
Copy link
Member Author

I'm using the Dockerfile form the repository which defaults to FreeRDP 2. The exact version is 2.11.7. I can try using FreeRDP 3 to see if that improves anything.

This is potentially a bug in FreeRDP. This assertion is mandatory in version 2.
Are you sure you can't reproduce this with a single monitor?

@Vertganti

This comment was marked as resolved.

@Vertganti
Copy link

Vertganti commented Jul 7, 2025

I'm using the Dockerfile form the repository which defaults to FreeRDP 2. The exact version is 2.11.7. I can try using FreeRDP 3 to see if that improves anything.

This is potentially a bug in FreeRDP. This assertion is mandatory in version 2. Are you sure you can't reproduce this with a single monitor?

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);
Copy link

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);
Copy link

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, "{");
Copy link

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,
Copy link

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.

@lirannisani
Copy link

lirannisani commented Sep 4, 2025

@necouchman @corentin-soriano
Thanks for adding this feature!
Do you plan to merge it into the main branch?

@corentin-soriano
Copy link
Member Author

@necouchman @corentin-soriano Thanks for adding this feature! Do you plan to merge it into the main branch?

I still have some things to finalize before we can merge.
I haven't had time to continue lately but the subject has not been forgotten!

@necouchman necouchman mentioned this pull request Sep 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants