[
https://issues.apache.org/jira/browse/GUACAMOLE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978114#comment-15978114
]
Michael Jumper commented on GUACAMOLE-125:
------------------------------------------
No update as such, though I'm skeptical about this being a bug in Guacamole
from the nature of the bug itself. Guacamole is actually relatively passive
with respect to screen resolution and RDP; it dictates nothing, and can only
make requests to the RDP server when it would like the screen to be a
particular width/height. For Guacamole+RDP, the process is as follows:
# The JavaScript client calculates what it believes to be the optimal width,
height, and DPI for the session (the dimensions of the browser window).
# That information is sent to the Guacamole tunnel, which forwards that
information to guacd on your behalf, along with the connection parameters.
# guacd sends that information and the connection parameters to the RDP plugin.
# The RDP plugin checks whether the connection parameters explicitly state the
width, height, or DPI. If they don't, the optimal width, height, and DPI
(browser window dimensions) are used. *NOTE:* At this point, the dimensions
have not actually been used for anything - they're just stored internally for
reference later.
# Those dimensions are passed to FreeRDP, which sends them along to the RDP
server while connecting, requesting that screen size. It is completely up to
the RDP server to honor (or ignore) that request.
# The RDP server sets the dimensions of the session and informs the RDP client.
*These may or may not be the requested dimensions.*
# Guacamole's RDP plugin receives those dimensions from FreeRDP and initializes
its display.
Given the above, there really isn't much space within Guacamole for this issue
to arise, especially given that Guacamole's display is the correct size
(regardless of whether everything within the display is rendering as expected),
and things are being drawn to those regions of the display (again, regardless
of whether that is correct).
My best guess would be that this is either a bug in FreeRDP's handling of
remoteapp, or a bug in Windows itself, but the nature of the problem definitely
seems to place it outside the scope of the Guacamole parts of the chain.
> Sometimes session is not initialised on Full screen
> ----------------------------------------------------
>
> Key: GUACAMOLE-125
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-125
> Project: Guacamole
> Issue Type: Bug
> Affects Versions: 0.9.9, 0.9.10-incubating
> Environment: Guacamole running on Debian 8.6
> Forwarding a windows 2012 R2 session
> Reporter: Frank Giroud
> Priority: Minor
> Attachments: notepad_size_limit_detail.jpg, notepad_size_limit.jpg
>
>
> Sometimes after logging in (which happens to be Full scren) the windows
> session or the RemoteApp is not launched in full screen.
> In fact it behaves like there were a pseudo-resolution smaller than the
> required one.
> The browser (Chrome is open in a 1920*1200) but the screen displayed is
> locked to something like 1024*768 or so.
> When you click on the Fullscreen button. It open and let a black screen all
> around in the web browser. .
> -The behavior is the same if you start a windows session , the windows
> desktop displayed in the web browser is in a 'smaller display' and what
> remains is black.- Haven't succeed to reproduce after all
> I have succeeded to find a way to reproduce the behavior "kind of" more often.
> In my example i configure notepad++ to be a remoteapp (launch by ||notepad in
> guacamole )
> # Launch a session through Guacamole => No probleme guacamole can be set in
> fullscreen (on all the browser window)
> # Unmaximized the application
> # Ctrl-Shift-Alt menu => Disconnect
> # On the guacamole option menu (3 choices) => Reconnect
> # The result => my screenshot
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
