Version: unspecified (using KDE 4.5.0) OS: Linux Freerdp is a fork of rdesktop and fixes some bugs still in rdeskop. Eg. mouse cursors are displayed correct when using freerdp. Reproducible: Always Steps to Reproduce: New feature
This is the first time I hear of freeRDP; it sounds like an interesting project.
*** Bug 250979 has been marked as a duplicate of this bug. ***
Very keen to get my hands on the new plug-in. This is quite crutial, for using RDP to Win 2008 R2.
freerdp is rdesktop fork with backward compatibility, so, i think, it would be not so difficult
*** Bug 263566 has been marked as a duplicate of this bug. ***
I think, just replace "rdesktop" to "xfreerdp" entries in the krdc's sources is enough
Joker-jar, not really, xfreerdp does not accept the parameters in any order like rdesktop. Moreover it uses plugins for extra functionality, and it also comes in the form of a lib, some maybe it's time to rewrite the RDP plugin a bit. I actually thought of doing it myself but I am not familiar with gui programming at all. So it not worth trying :(
It's much more than just replacing some strings... I think it needs an major rewrite of the RDP plugin. I would be happy to support anybody who volunteers to work on such a rewrite.
promise to answer noob questions, and you can count me in!
(In reply to comment #9) > promise to answer noob questions, and you can count me in! Sure, just drop me a mail! :) Thanks for your offer.
There is a GTK+ UI which is based on FreeRDP: http://remmina.sourceforge.net/
Perhaps both rdesktop and freerdp can be supported? Eg: two separate plugins.
(In reply to comment #12) > Perhaps both rdesktop and freerdp can be supported? Eg: two separate plugins. Sure, there would be no problem to do so. I would even suggest to do this at least while development. You can enable / disable the plugins in KRDC configuration dialog. By default, of course, we should enable freerdp once it is fully implemented. This task is still open and anybody who feels like doing a nice programming task could work on it :)
I'm searching for the client as well and found this bug. And I spent a little time to modify the rdp plugin to freerdp plugin and it works well. I'll submit the patch once the UI is done.
Hello AceLan, May I ask if there is any progress on your side? freerdp is so much better than rdesktop and a kde integration would be very very cool. Regards, Jens (Actually I can't use rdesktop anymore since I need network level authentication for rdp on Windows 2008 R2 :) )
Any news ? It seems that there is an existing patch need to be reviewed : https://svn.reviewboard.kde.org/r/6978/ Regards
Yes, there is a patch for freerdp. It looks good, but I have not found time to test it yet... :( I hope I can do it soon.
I've been using the patch on the reviewboard since krdc 4.8.4 to 4.9.4 successfully on a daily basis at work, connecting to various machines running Windows Server 2000/2003(R2)/2008(R2) and WindowsXP. I've spotted no problems in the krdc integration so far. I'd love to see this merged for KDE SC 4.11.
@Timo Gurr: Thanks for your feedback. I will try to get it done for 4.11.
It would be very cool to get freerdp support. Considering the patch, in my opinion the patch should replace the old rdp backend instead of introducing a new protocol name.
Sorry, I didn't followup this thread until it pops up in front of me today. I have some problems with my email filter. It's great to hear that the patch works and helps others and it will go into KDE 4.11. That's really a cool news to me.
Created attachment 75979 [details] Patch which replaces rdesktop with freerdp Good news! I have prepared a patch for 4.11 which replaces the rdesktop plugin with the freerdp one. The work is based on the patch done by AceLan Kao (thanks a lot for this work!). One issue at the moment is, that freerdp 1.0.1 has a bug, which prevents KRDC from embedding the xfreerdp window into the KRDC one. This is fixed already in Git and will be included in the next freerdp release (1.0.2-rc2 has already been released). I will commit this work soon into trunk, which is the base for KDE SC 4.11. Feel free to try the patch before and tell me your comments.
SVN commit 1330138 by uwolfer: Port KRDC RDP plugin to Freerdp (xfreerdp). - freerdp is a fork of rdesktop which fixes many bugs and adds support for newer OS (e.g. Windows 2008 R2) - requires Freerdp 1.0.2 (RC2 is out already; final will be out for sure at KDE SC 4.11 release) because of a bug in 1.0.1 (window embedding) Work is based on a patch by AceLan Kao. M +7 -1 CMakeLists.txt M +10 -1 core/krdc.kcfg M +3 -3 rdp/CMakeLists.txt M +40 -1 rdp/rdphostpreferences.cpp M +8 -1 rdp/rdphostpreferences.h M +96 -6 rdp/rdppreferences.ui M +101 -24 rdp/rdpview.cpp M +8 -7 rdp/rdpview.h M +4 -4 rdp/rdpviewfactory.cpp M +1 -1 rdp/rdpviewfactory.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1330138
Hi, a couple of doc changes that might have been missed: $ grep -R rdesktop doc/krdc/index.docbook:<para><acronym>RDP</acronym> support in &krdc; depends on rdesktop. Make sure that you have installed krdc/rdp/rdppreferences.ui: <string>Here you can enter additional rdesktop options.</string>
SVN commit 1330203 by uwolfer: Fix some missed strings. Thanks to Michael for noticing it. M +1 -1 doc/krdc/index.docbook M +1 -1 krdc/rdp/rdppreferences.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=1330203
Hi, sorry for commenting on a closed bug/feature. But I am questioning the whole bug entry. This change, which went into Ubuntu 13.10 also, caused a lot of trouble. Folder sharing is not working, some connections to some windows systems are not possible at all in specific configurations etc. etc. So why the hell is a major component in KDE so quickly replaced with any notice nor the availability to choose? Only because one is reporting that there is a fork of something which is much (!?) better than the original one because it fixes a couple of bugs but introduces a whole lot of new ones?? I am questioning this procedure. KDE is a mature platform and heavily used and should not be treated like a small little program which can be changed at will. I would have expected that at least there would have been planned a migration period where the user can choose from both engines rdesktop and xfreerdp which would also be like a testing/fixing period for this new integration. Does KDE not have some guidelines on how to integrate new functionality respectively check the test coverage of the new component? Some sort of staging for it? So probably I will make a new request to revert from this decision and integrate it (maybe also as default) as an option, such that one can easily switch, which engine (rdesktop/xfreerdp) will be used for which connection. Maybe a hint to test the new component would also help to get more feedback.
(In reply to comment #26) > But I am questioning the whole bug entry. > This change, which went into Ubuntu 13.10 also, > caused a lot of trouble. Folder sharing is not working, > some connections to some windows systems are not > possible at all in specific configurations etc. etc. That might be true for your case, but others want to be able to connect with krdc to non-ancient Windows machines, which rdesktop can't. I would suggest to report your problems to the freerdp project instead.
(In reply to comment #27) > (In reply to comment #26) > > But I am questioning the whole bug entry. > > This change, which went into Ubuntu 13.10 also, > > caused a lot of trouble. Folder sharing is not working, > > some connections to some windows systems are not > > possible at all in specific configurations etc. etc. > > That might be true for your case, but others want to be able to connect with > krdc to non-ancient Windows machines, which rdesktop can't. > > I would suggest to report your problems to the freerdp project instead. this exactly is the problem I want to discuss. Both components do support a specific range of configurations and functionality. And this exactly is the reason why one should not make such hard decisions in KDE which is so widely used. There should be a migration phase and an option to switch between both. The end of the story is that a lot of business users have to use rdesktop via command line until all this bugs are fixed. And it is not like the bug creator making us believe that everything is fine because it is a fork of rdesktop.
(In reply to comment #26) > Hi, > > sorry for commenting on a closed bug/feature. > But I am questioning the whole bug entry. > This change, which went into Ubuntu 13.10 also, > caused a lot of trouble. > Folder sharing is not working, I was not aware of this issue. Can you please tell me the bugs.kde.org issue number? > some connections to some windows systems are not > possible at all in specific configurations etc. etc. b.k.o #? > So why the hell is a major component in KDE so quickly > replaced with any notice nor the availability to choose? This issue has been open for more than two years before it got changed. You can see that many people have requested / supported the migration. > Only because one is reporting that there is a fork of something > which is much (!?) better than the original one because it > fixes a couple of bugs but introduces a whole lot of new ones?? rdesktop is an almost discontinued project. It does not support recent server setups which are more and more spread in the wild (also in professional environments). FreeRDP is quite active and supports these updated setups. > I am questioning this procedure. KDE is a mature platform and heavily > used and should not be treated like a small little program which can > be changed at will. I am aware of this. In my opinion, this move is not just a one-day-decision. It has been discussed and the work has been tested and reviewed by some people. I, as the maintainer and main developer of KRDC, have supported this change. > I would have expected that at least there would have been planned > a migration period where the user can choose from both engines > rdesktop and xfreerdp which would also be like a testing/fixing period > for this new integration. Does KDE not have some guidelines on how > to integrate new functionality respectively check the test coverage of > the new component? Some sort of staging for it? This change has been introduced with KDE SC 4.11. KDE policy allows introducing new dependencies at such an update because it is released after many beta and RC releases. In that period distributions and users have the possibility to test things and report issues with such new features. I understand that a period where both rdesktop and FreeRDP could be switched at runtime would have been great - but we simply had not the manpower to that. > So probably I will make a new request to revert from this decision > and integrate it (maybe also as default) as an option, such that one > can easily switch, which engine (rdesktop/xfreerdp) will be used for > which connection. Maybe a hint to test the new component would > also help to get more feedback. Feel free to work such a functionality where both rdesktop and FreeRDP can be switched. As I have written above, we do simply not have the manpower to do it at the moment. Even when you cannot write code (or don't like to), you can support this project by reporting issues. I was not aware of the issues you have written above. We have not received many bug report for this specific rdesktop to FreeRDP move (I thing there were only 2 to max. 5 reports). This is my very personal opinion about this topic - it may not reflect the opinion everyone in the KDE community.
(In reply to comment #29) > (In reply to comment #26) > > Hi, > > > > sorry for commenting on a closed bug/feature. > > But I am questioning the whole bug entry. > > This change, which went into Ubuntu 13.10 also, > > caused a lot of trouble. > > Folder sharing is not working, > > I was not aware of this issue. Can you please tell me the bugs.kde.org issue > number? Got me. Did not yet post a bug entry. Just created an account for commenting here. Will try to put a bug report. > > > some connections to some windows systems are not > > possible at all in specific configurations etc. etc. > > b.k.o #? > > > So why the hell is a major component in KDE so quickly > > replaced with any notice nor the availability to choose? > > This issue has been open for more than two years before it got changed. You > can see that many people have requested / supported the migration. Was not aware of this as I just was shocked when I upgraded to 13.10 and no connection was possible via RDP. First problem was, that I had the options -r disk:disk=/path for rdesktop in krdc. With this options nothing works. I removed this option and could connect. So far so good. But putting any path into the "share media" will display the media on the remove desktop as usual under \\tsclient. But there is no access. Clicking on it gives "drive not available" or "access denied" etc. Connecting to the same system wir rdesktop and the -r disk: options works perfectly. This has been observed on Windows XP and Windows 7 x64. > > > Only because one is reporting that there is a fork of something > > which is much (!?) better than the original one because it > > fixes a couple of bugs but introduces a whole lot of new ones?? > > rdesktop is an almost discontinued project. It does not support recent > server setups which are more and more spread in the wild (also in > professional environments). FreeRDP is quite active and supports these > updated setups. > > > I am questioning this procedure. KDE is a mature platform and heavily > > used and should not be treated like a small little program which can > > be changed at will. > > I am aware of this. In my opinion, this move is not just a one-day-decision. > It has been discussed and the work has been tested and reviewed by some > people. I, as the maintainer and main developer of KRDC, have supported this > change. > > > I would have expected that at least there would have been planned > > a migration period where the user can choose from both engines > > rdesktop and xfreerdp which would also be like a testing/fixing period > > for this new integration. Does KDE not have some guidelines on how > > to integrate new functionality respectively check the test coverage of > > the new component? Some sort of staging for it? > > This change has been introduced with KDE SC 4.11. KDE policy allows > introducing new dependencies at such an update because it is released after > many beta and RC releases. In that period distributions and users have the > possibility to test things and report issues with such new features. > I understand that a period where both rdesktop and FreeRDP could be switched > at runtime would have been great - but we simply had not the manpower to > that. Ok, understand. Thanks for the info. > > > So probably I will make a new request to revert from this decision > > and integrate it (maybe also as default) as an option, such that one > > can easily switch, which engine (rdesktop/xfreerdp) will be used for > > which connection. Maybe a hint to test the new component would > > also help to get more feedback. > > Feel free to work such a functionality where both rdesktop and FreeRDP can > be switched. As I have written above, we do simply not have the manpower to > do it at the moment. Even when you cannot write code (or don't like to), you > can support this project by reporting issues. I was not aware of the issues > you have written above. We have not received many bug report for this > specific rdesktop to FreeRDP move (I thing there were only 2 to max. 5 > reports). > > This is my very personal opinion about this topic - it may not reflect the > opinion everyone in the KDE community. Thanks for explanation. It was just so suprised that krdc did not behave like expected after the updates and then I saw the headline of the bug and could not believe that a change has been done only because one said "yeah, lets switch it". Ok, then, if the decision phase was over 2 years, then it should be mature. You are right, if it is not, this can happen. I really wonder if an engine option had been considered seriously and if it really would have been so much more effort than using xfreerdp.
Please report the bug, I'm willing to verify and fix the issue if this is a bug in krdc framework, not from freerdp.
(In reply to comment #30) > Was not aware of this as I just was shocked when I upgraded to 13.10 and no > connection was possible via RDP. First problem was, that I had the options > -r disk:disk=/path for rdesktop in krdc. With this options nothing works. > I removed this option and could connect. This issue is already reported: #324585 @AceLan Kao: If you like, you can look into this issue. Probably we could use a KConfig update script here: http://techbase.kde.org/Development/Tutorials/Updating_KConfig_Files What do you think?
Thanks for the info.
Regarding the folder mapping I could nail down that it does not work in Windows XP and sometimes also happens in Windows7. The folders are shown and its content can be listed (1st level). When changeing into a folder the error message "access denied" is given. A second trial gives "folder not available" and from there on the whole mapping does not work anymore.
@Buddy Butterfly: If you run xfreerdp from a terminal, can you reproduce this issue also?
I will try to reproduce from terminal. Please be patient as I am running short in time at the moment. Just experienced the next problem. I tried to connect with krdc and rdp protocol. It is not connecting and just shows a blue empty screen. But I figured out, what could be the problem. When connecting I am presented with 2 dialogs. One for the user and one for the password. Quite often, I do not use them and press cancel on the dialogs to get into the standard Windows logon screen. This does not work with krdc and xfreerdp! When I give the user and the password in the dialogs, it workds! With rdesktop I am able to immediately see the logon screen.