Bug 2632 - Access X sessions from RDP dumb terminals
Summary: Access X sessions from RDP dumb terminals
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-01 08:03 UTC by Duncan Innes
Modified: 2018-12-13 22:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Duncan Innes 2005-03-01 08:03:44 UTC
Is it anywhere near feasible to create an RDP layer to the X protocol?

I ask because of the sheer number of dumb terminals that run only RDP
connections.  For companies that use these terminals, the cost of migration to
Linux would have to include replacing all their RDP terminals with those that
run X11.

The correct terminology has escaped me since my Uni days, but . . .

Can an interface be constructed so that the dumb RDP terminal can connect to the
X server and be presented with the normal desktop via it's own protocols.

Perhaps it's not technically feasible.  Perhaps it's been dismissed before.  I
just thought I'd ask.

The perverse flip-side of this is that the dumb terminals we use here are
actually running Linux as their OS, but only allowing RDP connections.
Comment 1 Duncan Innes 2005-03-02 09:21:35 UTC
As an update:

I've looked into various ways to do this, but most people come back with the
answer of using VNC (or other tool to run the X session).

The downside to this is that the dumb terminals only support the RDP and ICA
protocols.

Now buying extra licenses for X11 ICA connections is exatly what you would be
trying to avoid by migrating to Linux desktops.  So RDP ends up as the only
option on terminals such as these.  It was short sighted in my opinion to go
with these terminals in the first place, but sometimes accountants get in the
way of good decisions.  The saving by using these terminals was actually quite
dramatic compared to the model that supported X11.

I know for a fact that there are multi-national companies who have rolled out
thousands of these terminals.  A native connection method for them to run X
desktops would remove a large cost from a migration to Linux.
Comment 2 Duncan Innes 2005-03-02 11:34:30 UTC
I'll postulate and hypothesise for a few lines as I've got a few minutes spare
at work.

If this were to be a "go-er", would the best method be:

1) Create an RDP listener service.  This would start up a discrete X-server on
the server for each connection.  These X-servers would be modified from the
normal to perform the translation from X11 to RDP.  Downside is a new process
for each RDP connection.  Upside is leaving the X-client completely untouched.

2) Modify the X-client to be able to talk natively to the RDP sessions. 
Downside is having to modify the X-client software.

A caveat to my musings:  I'm not convinced I've got the X-server X-client
terminology the right way round (it's been a LONG time since Uni).  The X-server
draws the display while the X-client runs on the machine and sends the "draw"
commands to the X-server?  Don't shoot me if I'm wrong.

Also, if this has been proposed and thrown out previously - sorry.  I did look
around for several weeks before I came to submit this enhancement.
Comment 3 Adam Jackson 2005-03-07 17:43:47 UTC
this wouldn't necessarily be hard, except that the RDP protocol is wonderfully
underdocumented.
Comment 4 Duncan Innes 2005-05-19 04:14:23 UTC
Is there any way I could champion this idea to bring it closer to development stage?

Understandably there are arguments to be made for and against this kind of move,
but I'd be willing to put forward the PRO case and hopefully counter any
negative issues.

I see this purely as a way of tapping into the massive installed base of RDP
dumb terminals that already exist in corporate-land.
Comment 5 Alan Coopersmith 2005-05-19 08:28:22 UTC
The biggest reason this isn't going forward right now isn't something you can
argue your way out of.   It's a lack of developers that have all the necessary
time, knowledge and desire to volunteer to work on it.
Comment 6 Duncan Innes 2005-05-19 10:08:41 UTC
Yes - true enough.  Manpower is probably the biggest factor influencing
development.  Unfortunately my development skills are pretty far removed from X
development.

I was hoping to be able to help present a case to any corporations or
benefactors that may provide funding or manpower.  I know it will not be a quick
matter as this is not really core X development.  But if this could be raised in
the right light, those who decide what goes onto the development path would be
able to look closer at it.

Perhaps it's not worth doing at all.  I just know it's something that has
frustrated me several times now when putting together cases for migrating
systems from Windows/Citrix to Linux.
Comment 7 Daniel Stone 2007-02-27 01:25:37 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 8 chemtech 2013-03-15 14:30:56 UTC
Duncan Innes
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Comment 9 Duncan Innes 2013-04-29 20:10:09 UTC
Sorry, have lost track of X developments.

Whilst I'm aware of some projects that can *add* RDP functionality to X (i.e. xrdp) I'm not aware of anything being added to X itself. I'm not up to speed with recent developments in X.Org though.
Comment 10 Alan Coopersmith 2013-04-29 20:13:36 UTC
Right, this is pretty clearly not implemented - I think the question asking
if it was still a problem was an automated script gone awry.
Comment 11 GitLab Migration User 2018-12-13 22:14:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/325.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.