[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311935#comment-17311935
]
Mike Jumper commented on GUACAMOLE-168:
---------------------------------------
{quote}
So I have this working, but in my GPU accelerated container the guac driver
replaces the nvidia driver for the primary X server. Do I need to run a
secondary X server and use VirtualGL to achieve acceleration now?
{quote}
I think you might be able to leverage Xinerama to mirror the
hardware-accelerated display onto the software display exposed by the guac
driver. You would then have two displays configured within your xorg.conf: the
Nvidia display and the guac display, with the latter arranged as a mirror of
the former.
{quote}
That is the current state of the XOrg driver? Is there code which can be
manually compiled and tested?
{quote}
Yes, if you'd like to test the driver, the pull request with the associated
code can be found here:
https://github.com/apache/guacamole-server/pull/316
Based on the above difficulty regarding hardware-accelerated displays, I'm
starting to wonder whether an approach like that used by x11vnc might be
better. We could then rely on the native driver for rendering, and hook into
only the parts of X11 necessary to be aware of screen changes, window position,
and take window content captures.
> 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
> Attachments: 00-guac.conf, Xorg.0.log
>
>
> 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)
