[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683892#comment-16683892
]
Fabio Corsi commented on GUACAMOLE-168:
---
{quote}{{I'm trying to compile Guacamole with the X11 plugin on Ubuntu 18.04
LTS. }}
{{Whenever I run }}
{{ ._/configure --with-xorg-module-dir=/usr/lib/xorg/modules/_ }}
{{It returns }}
{{ checking for XORG... no }}
{{In the config.log I find }}
{{ Package xorg-server was not found in the pkg-config search path. }}
{{ Perhaps you should add the directory containing `xorg-server.pc' }}
{{ to the PKG_CONFIG_PATH environment variable }}
{{ No package 'xorg-server' found }}
{{However I don't seem to be able to find the required package in the Ubuntu
repositories. }}
{{Is there a list of all the dependencies needed to compile guacamole with the
X.Org driver on Ubuntu 18.04? }}
{{Many thanks}}
{quote}
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493950#comment-16493950 ] Kodiak Firesmith commented on GUACAMOLE-168: This is fantastic news. I would love to set this up on RHEL 7 as a replacement for TigerVNC on RHEL 6. I'm going to test this as soon as a beta is available. > 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: Michael Jumper >Assignee: Michael 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 (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397320#comment-16397320 ] Rick Leir commented on GUACAMOLE-168: - My experience is with NoMachine NX client, connecting to a server across town. Response was snappy! Better than what I have seen of RDP. So I will be happy if we can get NX communications into Guac. cheers – Rick > 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: Michael Jumper >Assignee: Michael 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 (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378617#comment-16378617 ] Tom commented on GUACAMOLE-168: --- This is a great idea. I'd love nothing but to get a rid of xRDP to access my systems, it's historically been really unstable and has no 2FA ability or fail2ban. So thank you for your work. I got this to build but I am definitely missing something. I'm running a "headless" linux (CentOS/RHEL) container and I can't figure out how to start up X with this driver. How does that happen? "init 5" or whatever its systemd equiv. doesn't work. I am assuming that needs to be running before you connect to the web gateway. Am I correct? > 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: Michael Jumper >Assignee: Michael 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 (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347956#comment-16347956
]
Michael Jumper commented on GUACAMOLE-168:
--
{quote}
Could you give the link to its sources?
{quote}
Your best resource at the moment would be the mailing list thread which
discusses testing the driver, the build process, etc.:
https://lists.apache.org/thread.html/5f4a5afa46dfcc974f254cc7bcf962d08e29b7af7459e3030b6f6448@%3Cuser.guacamole.apache.org%3E
The source, not being ready for merge/review yet, is on the "xf86-video-guac"
branches of my forks on GitHub.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347936#comment-16347936
]
Berserker Troll commented on GUACAMOLE-168:
---
{quote}Won't a compositing WM provide the same features?{quote}
I think I can answer my own question.
The X Composite Extension allows one to redirect window rendering to off-screen
storage.
The X DAMAGE Extension allows one to get information about DAMAGEd (by
painting) regions.
Compositing managers use either the X Rendering Extension (slow) or OpenGL
(fast) to (re)draw the windows, add shadows, add transparency etc.
The off-screen window pixmaps are stored on the server and XRENDER/OpenGL has
no problem accessing them. But the compositing manager doesn't have direct
access to these pixmaps. One may think about using MIT-SHM extension, but, if I
understand it correctly, a driver has to support this extension and the dummy
driver (what else would you use with remote rendering?) doesn't support MIT-SHM.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345700#comment-16345700
]
Berserker Troll commented on GUACAMOLE-168:
---
{quote}Within X.Org, the only compositors _are_ compositing window
managers.{quote}
Ehm... I fell like there is some misunderstanding here. Not sure where exactly.
You wrote
{quote}This would sacrifice the user's ability to use their desktop environment
of choice.{quote}
so I understood it as that you're thinking that user will have to replace her
favourite DE/WM (i3wm, awesome etc.) by Guacamole compositing WM and she may be
unhappy about that. But I'm looking at ArchLinux wiki page about
[Xcompmgr|https://wiki.archlinux.org/index.php/Xcompmgr] and
[Compton|https://wiki.archlinux.org/index.php/Compton] and if I understood
their description correctly, you can run them with any other WM.
Anyway, a driver is indeed looks like a natural solution, so o'k.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345659#comment-16345659 ] Michael Jumper commented on GUACAMOLE-168: -- Within X.Org, the only compositors _are_ compositing window managers. If you're referring to Wayland, it's the reverse: window managers are compositors, there is no such thing as a window manager from the perspective of Wayland, and desktop environments typically provide their own compositors. Writing a similar solution for Wayland, assuming compositors can be nested without losing direct access to the surfaces within the innermost compositor, would not necessarily be a bad idea in itself ... however we have an X.Org driver already written. It doesn't make sense to dump the driver when it's already working as well as it is, even if you think that Wayland might work, too. > 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: Michael Jumper >Assignee: Michael 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 (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344879#comment-16344879
]
Berserker Troll commented on GUACAMOLE-168:
---
{quote}Unless compositing window managers can be nested, no.
{quote}
Well, probably I shouldn't have written "compositing WM", but a "compositor".
Compositors doesn't need to replace running WM.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344251#comment-16344251
]
Michael Jumper commented on GUACAMOLE-168:
--
{quote}
Pardon my ignorant question: isn't a X.Org driver an overkill?
{quote}
It seems a perfect fit, actually. Considering Guacamole as a display mechanism,
it makes sense to have a driver for a network display (Guacamole) just as you
would have a driver for a hardware display (graphics card).
{quote}
Won't a compositing WM provide the same features?
{quote}
Unless compositing window managers can be nested, no. This would sacrifice the
user's ability to use their desktop environment of choice.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344230#comment-16344230
]
Berserker Troll commented on GUACAMOLE-168:
---
{quote}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.
{quote}
Pardon my ignorant question: isn't a X.Org driver an overkill? Won't a
compositing WM provide the same features?
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343943#comment-16343943
]
Michael Jumper commented on GUACAMOLE-168:
--
{quote}
Would it be (at least in principle) possible to translate OpenGL (GLX) to WebGL?
{quote}
In principle, sure, however:
* For the initial implementation of X.Org support, no. We need to keep scope
minimal. It's already a huge change.
* The more low-level each individual forwarded call gets, and the more
frequently those calls occur, the less performant Guacamole will be. Passing
through OpenGL as part of the protocol stream may not actually be as fast as
you might think.
* With the continuing shift toward relying on cloud-based computing resources,
offloading the heavy rendering to the client seems a step backwards. It would
be nice to continue relying on the server to handle the main load with respect
to rendering, such that applications that make heavy use of OpenGL can be
usable even on platforms which otherwise could not hope to run such
applications.
> 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: Michael Jumper
>Assignee: Michael 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
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343916#comment-16343916 ] Berserker Troll commented on GUACAMOLE-168: --- Would it be (at least in principle) possible to translate OpenGL (GLX) to WebGL? > 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: Michael Jumper >Assignee: Michael 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 (v7.6.3#76005)
