Version: (using KDE KDE 3.2.1) Compiler: gcc (GCC) 3.3.1 20030927 (Gentoo Linux 3.3.1-r5, propolice) OS: Linux No matter what client I connect with (Krdc, TightVNC, original VNC, etc), both Krfb and X eat CPU while I am connected. Processor is an 800 MHz Pentium 3, so it shouldn't use that much... TightVNC's X server works fine without eating CPU.
This is a X11-problem, there is currently no other way to get the content of a running X11 server without polling for changes all the time. Future X11 servers will solve it with the DAMAGE extension. TightVNC and other 'traditional' VNC systems don't have the problem because they come with their own, modified X11 server. The TightVNC server is not much more than XFree 3.x with a VNC driver instead of the regular video driver.
Any way to at least provide some configuration for this? The CPU eating is such that without any restriction, it might as well not exist... (in particular, events are repeated liiiikkkke thiiiiis a lot)
I don't know what to do against it, beside limiting the refresh rate even more but then it's not very useful. The only real solution is to wait for the XDamage extension. I don't think that the key rate problem is related, i guess that's a side-effect of using the XTest-Extension for the keypresses. That's the price for using X11 in ways it was never intended to be used, but it's currently the only way to do it. BTW I would recommend Desktop Sharing only for helping other people. If you want to access your own desktop, use vncserver, X11 over ssh or NX.
Is XDamage supported by Krfb yet? If not, can it be added to the KDE 3.4 feature list? Even if there's no server to test it with, at least a should-work implementation would be nice so it might when they exist. If it doesn't work, then it would become a bugfix and not a new feature, thus getting in 3.4.1 or whatever is next. As a side note, the 'gemsvnc' server (which works similar to krfb, but w/o a GUI) works *much* better for displaying the screen. The only problem with it is that for some reason (perhaps x86-64 arch), it ignores all remote events. As far as your suggestions to access my own desktop: 1. vncserver doesn't share a local X server 2. X11 over SSH is completely useless for accessing an existing session 3. FreeNX does not seem to support x86-64 arch (note: I've done very limited research on this, since I prefer VNC anyway) If XDamage cannot even be hopefully-implemented, I suggest fixing this by seeing how gemsvnc handles things...
Concerning XDamage: we need a volunteer :) gemsvncserver: I just looked at the description, and it uses the same scanning algorithm as krfb, it's even based on the same code (x0rfbserver). It also uses livncserver as backend. Maybe it has some optimizations, but beside that there are very few differences.
gemsvnc: Perhaps it polls less insanely and as a result has better performance xdamage: what would it involve? I see other things on the 3.4 feature list w/o someone assigned to them
xdamage: writing it. It does not make any sense to list features if no one it committed to implementing them.
Looks like someone already did... Just needs to handle the absense of Damage, preferably at runtime, though to do so might mean including the XDamage header with KDE. http://freedesktop.org/~mallum/xdamagevnc.c
I just added my 20 votes for this bug. XDamage support in krfb is definitely needed. Since Luke-Jr has linked to a hacked up xdamagevnc.c, what's the likelihood of this making the next release?
*** This bug has been confirmed by popular vote. ***
Request: 1. Change summary to "XDamage Support for Krdc" 2. Prefix summary with "JJ:" if Tim won't implement it
http://bugs.kde.org/show_bug.cgi?id=68637 seems to be a duplicate of this bug (though 68637 was closed, and this one isn't, as it's surely not fixed).
Any update on this? Is Damage support included in the krfb packaged with KDE 3.4.0 or 3.4.1?
Nope. Krfb hasn't been changed since before 3.3, as far as I can tell. The sole developer just officially resigned a week or so ago.
*** Bug 124778 has been marked as a duplicate of this bug. ***
*** Bug 117911 has been marked as a duplicate of this bug. ***
*** Bug 110075 has been marked as a duplicate of this bug. ***
it isnt true that this is an X server problem.. well atleast not the latest bug that was marked as duplicate of this, cause this is a bug that started appearing AFTER 3.4.0 as my bug says, 3.4.0 is okay and very fast.
It *can be* an X server problem... to fix this requires the X server to support the DAMAGE extension. A workaround for non-supporting X servers might be to poll less often (or to have a separate polling process nice'd to the max). Krfb does not, AFAIK, support DAMAGE yet, and thus the problem will occur whether or not the X server has DAMAGE or not. I don't think Krfb changed since 3.3, so 3.4.0 shouldn't work any better.
all i can say is, that for me, 3.4.0 worked alot better, and that this problem first appeared for me in 3.4.1, where krfb became virtually useless for me, and still is. i think its worth looking into changes done in 3.4.1
KRFB has been completely unmaintained for a year and half, and this issue was opened 2 years ago. I think it is safe to say that no one is interested in working on KRFB anymore. :) With KDE4 coming up, I don't think it is realistic that existing maintainers will want to pick up a new project, and it is unlikely we will find a new volunteer (crazy enough) to take care of things the way they are. The bug cleanup I've been doing is in preparation for a petition for the deprecation of KRFB (and KRDC) to extragear at least, or complete removal of the projects at most.
If krfb/krdc are removed, how will it be possible to connect to a KDE desktop? Well, I personally use Vino from Gnome, which doesn't have the bugs KRFB has. Perhaps it could be merged :)
There are numerous connectivity options for *nix systems. Judging from the state of KRFB I would guess most people have moved to them by now.
To Jason Lee from #23: you're wrong, for *nix there is only one possibility to connect to an existing session (i.e., your desktop session running at home, to which you want to connect from work, or vice versa): VNC. krfb/krdc have an advantage that they were nicely integrated into KDE, and thus, easy to use for the end user.
> krfb/krdc have an advantage that they were nicely integrated into KDE, and >thus, easy to use for the end user. I don't disagree. I'd love to keep them both. But they are broken and no one is fixing them and I doubt anyone will step up to do the work required to get them working with Qt4/KDE4. They can't use Qt3Support forever. And having completely unmaintained apps in the core distro only leads to long conversations like this one. extragear is the best place for them to live out the rest of their lives, which I imagine will be short and uneventful. If you feel strongly about this just help me to find a maintainer. But please keep further discussion here confined to the bug specifics.
It's a shame. I use FreeNX primarily, but local display sharing has its uses for sure. I don't know of anyone who could maintain, but I am willing to help contribute financially if some sort of effort developes. --Dave M
Perhaps KDE project could do something that would do some good publicity: try to cooperate some more with Gnome (why duplicate work for most basic functionality)? Gnome has already a good VNC server, called Vino. It's developed, the last changelog entry comes from the middle of January. It has damage extensions, and works OK - so all the core technology that is needed for a VNC server is there. It even uses some parts of krfb/krdc (from AUTHORS file): ##### Mark McLoughlin <mark at skynet dot ie> Calum Benson <calum dot benson at sun dot com> This is just another re-incarnation of many other similar projects: + libvncserver by Johannes E. Schindelin which in turn is based on: - OSXvnc by Dan McGuirk - The original Xvnc by AT&T Laboratories, Cambridge - TightVNC by Const Kaplinsky - RealVNC by James "Wez" Weatherall + krfb, KDE's desktop sharing server, by Tim Jansen + x11vnc.c (from libvncserver) by Karl J. Runge + x0rfbserver, the original native X vnc server, by Jens Wagner Much code and ideas from each of those projects is re-used here. ##### All that would be needed is to add KDE look and feel. Maybe if someone from KDE team contacted Mark McLoughlin, who seems to be the current maintainer of Vino?
kino is just slow compared to what krfb was in 3.4.0.. i really dont understand why nobody wants to work on krfb anymore, its a great tool, loosing it in kde will be a real loss.
vino*, sorry
sorry for posting again.. i figured that if nobody else would do anything about the problem (well my problem actually), i'd have to, so i did a checkout of 3.4.0 to 3.5.2, and realized that no changes in the code was made since 3.5.1 to 3.5.2, which is just a change in some output, no matter.. i am completely dazzled, cause when i upgraded to 3.4.1 from 3.4.0, i got problems, but i can see that there is absolutely no difference, so it must be something else.. guess i should have done this along time ago :|
Kasper, you probably has some other problems. krfb was always slow, at least CPU-intensive. And as it's VNC, it could never be fast, even on LAN (all flavours of VNC are dead slow when you compare them to FreeNX for example).
what i can say, is that when i got 3.4.0 loaded, it felt like "WOW", it was really really awesomely good, but it stopped being that at 3.4.1, and obviously it wasnt the kde upgrade itself that did it, so it must have been something else.
Another useful solution (if nobody wants to integrate vino) is X11vnc: http://www.karlrunge.com/x11vnc/. It also shares you local display, uses the XDAMAGE extension and is in active development. So maybe it is an alternative too.
Implementation of XDamage extension has been added to krfb in KDE4.0. If XDamage is not available, krfb will still eat a lot of CPU.
CPU throttling might be a good idea in the latter case.