[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268252#comment-17268252
]
Christopher Speck commented on GUACAMOLE-168:
---------------------------------------------
[~Ghost_Knight] I don't yet have a public repository with the things I've been
experimenting with however I did upload my Dockerfile I use for building the
guacamole-server/xf86-video-guac branch on a CentOS 7 container.
[https://github.com/apache/guacamole-server/pull/316#issuecomment-758321806]
Which pieces are you having difficulty with? I have been running an application
along with Xorg within a container and so far there are only a few things which
I have not gotten working properly:
# PulseAudio - I think this is due to not having any actual sound device, it
causes Xorg to crash. I don't have any interest in audio at the moment so I've
simply ensured the library for pulseaudio is not installed so it won't get
compiled in as an option.
# Running Xorg in a container with only guacd driver requires that running the
container enables device passthrough, so that the container can access a tty. I
have a patch for the guacd driver to address this which I intend to submit once
this is upstream.
# The X server's RENDER extension - I think the xf86-video-guac branch is
meant to support this however I was not able to get Java applications to render
properly (which by default use xrender). This manifests as an application with
mostly gray blocks instead of any UI, and was rather challenging to uncover the
issue. In a simple non-Java test I tried running xeyes which by default also
uses xrender and it does not appear to work properly, but does when disabling
xrender. I think there's a bug related to xrender which likely only occurs when
running within a minimally configured container. I haven't had time to dig
deeper into this yet but I planned to file an issue with my findings once this
lands upstream then continue experimenting/investigating for a fix. For Java
applications this can be worked around by passing a specific flag to not use
xrender though I think the flag is deprecated/invalid past Java 11. Not using
xrender I think results in performance degradation but I don't yet have
anything to make valid comparisons against, just my understanding of what
xrender is.
> Add support for X.Org
> ---------------------
>
> Key: GUACAMOLE-168
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-168
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client, guacamole-server
> Reporter: Mike Jumper
> Assignee: Mike Jumper
> Priority: Major
>
> It's been frequently requested that we add support for a more efficient
> protocol like NX or X2Go. Though that sounds nice on the surface, and
> theoretically would allow us to leverage some of Guacamole's nicer
> protocol-level features, investigating deeper reveals:
> # X2Go *is* NX - it uses the same protocol behind the scenes.
> # NX isn't really a protocol - it is essentially a compressor for X11, and
> depends on the client having a local X11 server to handle the decompressed
> result.
> Implementing support for either of these would thus involve implementing
> support for X11, which is crazy. *However:*
> What about implementing a driver for the X.Org X11 server?
> The X.Org server provides a driver abstraction layer which exposes access to
> windows (including their hierarchy) and pixmaps, much in the same way the
> Guacamole protocol provides nestable layers and buffers. If we were to
> implement a Guacamole driver for X.Org, we would be able to make much greater
> use Guacamole protocol features like client-side compositing. Operations
> which are typically expensive in VNC or RDP like window movement suddenly
> become simple, as they only involve updating the properties of a layer.
> I have an experimental implementation of all this, built upon several other
> improvements which ended up being required. Work started several years ago,
> even before Guacamole was accepted into the Apache Incubator, but I think
> it's finally ready to move forward. I've been using it myself for roughly a
> month now, and so far so good.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
