Re: RemoteFX & Session Sharing

[Jonathan Swift <ga...@deepdia.com>]

I'm a little confused. Isn't remotefx a strictly (or mainly) server side
solution, so that so long as we enable remotefx on the WinServer 2016
server, all we need is a "plain old" rdp client (eg normal guacamole) and it
should work? That is, does remotefx not work just like vnc-like solutions
and transmit the computed bitmap image back to the rdp client, so the rdp
client need not have any code changes? The reason I ask this is twofold:
one, there doesn't appear to be any specific requirement for the rdp client
to support remotefx, though the documentation is a touch confusing on this
regard. And two, thinrdp seemed to support remotefx years ago, and I have a
hunch they never recoded anything. (Note: In our  use case, we are only
using remoteFx to use the 3d accelerated NVidia graphics card that is on the
winserver 2016 vm running on the google cloud; we don't care about USB
redirection etc.)

If the rdp client (eg guacamole in this case) really must change in order to
"view" remoteFx enabled screens, then what about simply installing a vnc
server (such as TightVNCServer or RealVNC Server or UltimateVNC Server on
the Win Server 2016 VM) and then using guacamole to connect to the win
machine via vnc? (I believe that vnc will still allow the WinServer machine
to use the NVidia graphics card, and I believe that guacamole shouldn't have
any trouble at that point, since presumably vnc is just sending bitmap
images back?)

Lastly, if none of the above ideas work (or work well), would there be
interest in all the people on this thread and any others that have desired
remoteFx support in guacamole to maybe band together and sponsor this
feature (so it's done sooner rather than later)? We're a tiny company (1
founder + 5 part-time developers, but I'm sure we can help.)



--
View this message in context: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/RemoteFX-Session-Sharing-tp1080p1277.html
Sent from the Apache Guacamole (incubating) - Users mailing list archive at Nabble.com.

Re: RemoteFX & Session Sharing

[Mike Jumper <mi...@guac-dev.org>]

On Fri, Jul 21, 2017 at 6:01 AM, Herzog <he...@phil.to> wrote:
> I would be more than interested, too!
>
> Mike, is the MIT licensed "poorly implemented" version publicly available?
> Could you publicize it otherwise?
>

No, this is incorrect.

If it were MIT-licensed, yes, we could indeed do as you suggest. The
main reason the code cannot be used is because its license status is
unknown. The author made his changes to MIT-licensed code, yes, but
that does not mean his changes are under the same license. Without the
explicit permission of the author, and without a license giving us
permission, we cannot legally include his code.

> Maybe we could use that as a starting point (regarding the lack of
> documentation, some could would surely help).
>

The only legal route is to start from scratch, without referencing his
code in any way whatsoever. Doing otherwise risks creating a
derivative work and running afoul of copyright law.

It would be safe to consult the FreeRDP source itself, particularly
the X11 client implementation. In fact, since FreeRDP has no API
documentation, walking through the code is very often the only way to
determine what the various functions/parameters/structures actually
do. It's fairly painful, but it is doable, and in this case it's
simply the only option.

Thanks,

- Mike

Re: RemoteFX & Session Sharing

[Herzog <he...@phil.to>]

I would be more than interested, too!

Mike, is the MIT licensed "poorly implemented" version publicly available?
Could you publicize it otherwise?

Maybe we could use that as a starting point (regarding the lack of
documentation, some could would surely help).



--
View this message in context: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/RemoteFX-Session-Sharing-tp1080p1358.html
Sent from the Apache Guacamole (incubating) - Users mailing list archive at Nabble.com.

Re: RemoteFX & Session Sharing

[Mike Jumper <mi...@guac-dev.org>]

On Tue, Jul 11, 2017 at 9:52 AM, Jonathan Swift <ga...@deepdia.com>
wrote:

> I'm a little confused. Isn't remotefx a strictly (or mainly) server side
> solution, so that so long as we enable remotefx on the WinServer 2016
> server, all we need is a "plain old" rdp client (eg normal guacamole) and
> it
> should work? That is, does remotefx not work just like vnc-like solutions
> and transmit the computed bitmap image back to the rdp client, so the rdp
> client need not have any code changes?


Nope. RemoteFX uses entirely different codecs to transmit the image. Though
FreeRDP supports those formats, Guacamole would need to be modified to
implement and call the appropriate functions to shuttle the RemoteFX data
back and forth, updating its own internal surface with the received data.

The main barrier here is the total lack of API docs on the FreeRDP side,
but it's doable.

The reason I ask this is twofold:
> one, there doesn't appear to be any specific requirement for the rdp client
> to support remotefx, though the documentation is a touch confusing on this
> regard. And two, thinrdp seemed to support remotefx years ago, and I have a
> hunch they never recoded anything.
>

They would need to explicitly handle the RemoteFX data. There is no other
way.


> If the rdp client (eg guacamole in this case) really must change in order
> to
> "view" remoteFx enabled screens, then what about simply installing a vnc
> server (such as TightVNCServer or RealVNC Server or UltimateVNC Server on
> the Win Server 2016 VM) and then using guacamole to connect to the win
> machine via vnc? (I believe that vnc will still allow the WinServer machine
> to use the NVidia graphics card, and I believe that guacamole shouldn't
> have
> any trouble at that point, since presumably vnc is just sending bitmap
> images back?)
>
>
Yes, you can do this.


> Lastly, if none of the above ideas work (or work well), would there be
> interest in all the people on this thread and any others that have desired
> remoteFx support in guacamole to maybe band together and sponsor this
> feature (so it's done sooner rather than later)? We're a tiny company (1
> founder + 5 part-time developers, but I'm sure we can help.)
>
>
You can't directly sponsor development here - we're strictly volunteers.
You can donate to the ASF - it will not influence project decisions or what
features get developed, but don't let that stop you. ;)

Development is supported through contributions of code, which are always
made by individuals. You can definitely contribute if you have the
development bandwidth to do so, or even hire a third party to contribute,
but you cannot hire the project. As long as it's an individual contributing
the changes, and as long as that individual can legally do so, there's no
problem, since it's still that group of volunteers that ultimately decides
how/if that contribution is accepted, independent of corporate influence.

- Mike