any chance of a screenshot demonstrating this? :)

Created attachment 24905 [details]
screenshot demonstrating the problem

The xv windows are not part of the intended content...

Note, although the window title mentions localhost, the server is
remote and is accessed through an ssh tunnel...

Created attachment 24907 [details]
another screen shot

This is another screen shot.  Note: I am not using ssh, this is a direct
connection.  Note in addition to blurring/doubling imaging of text, there are
also some strange color rectangles appearing.

Same problem here, garbled screen, with all sorts of strange color rectangles.

OpenSuSE 11, KDE3, with KRFB-4. ATI fxglrx video drivers.
Using SSH tunnel using putty and UltraVNC on Windows.
Tried several protocol configurations on client, with no avail.

Display is momentarily fixed when requested a full refresh of screen, then the first regions that seem to display the Due to this fact, I'd say it seems to be something related to XDamage extension, since the strange rectangles appear on places of the screen that require a refresh (in my case, places like gkrellm and small animations are the first ones to show the problem).

Same problem here.  openSUSE 11.0 x86-64.  TightVNC client on Windows XP.  Screen shot and other detail available at https://bugzilla.novell.com/show_bug.cgi?id=405229
openSUSE 10.3 allowed a VNC server to be configured through SAX2 and that one worked correctly.

*** This bug has been confirmed by popular vote. ***

The same problem here since openSUSE 10.3 that already shipped the kde4 version of krfb 8 months ago.

confirmed on kde-4.1/kubuntu-8.04.

I don't know if this is the exact same bug I'm experiencing, but when I connect krfb takes a garbled "screenshot" and then only displays that, although the mouse rendering still seems to work, because I can move the cursor around and see it move.

I have what sounds like the same bug on Fedora 9. kdenetwork-4.1.0-2-fc9 I can authenticate and the screen displays and then shifts a little to the right and blurs. After that no screen updates occur. All the input is being seen on the server. I get the same mouse behavior as Stephen.

I just wanted to add that the KRFB doesn't stop working if compositing is turned off, but I still get weird visual effects (red, green, blue, and yellow boxes over things.)

*** Bug 172134 has been marked as a duplicate of this bug. ***

Created attachment 28104 [details]
Screnshot of problem - jantman

Confirmed on OpenSuSE 11.0 x86_64, kde4-krfb-4.0.4-19.1 from SuSE RPMs, client is KRDC from identical install OpenSuSE 11.0 x86.

In addition to the garbled screen in the screenshot, the pointer also does not update on the remote client - it constantly stays in the top left corner, but does update on the server desktop.

Confirmed on Gentoo with multiple clients (UltraVNC on Windows XP, integrated VNC viewer on OSX 10.5):
Qt: 4.4.2
KDE: 4.1.2 (KDE 4.1.2)
Desktop Sharing: 1.0

Still broken in 4.1.3

I confirm this bug on 4.1.3

I confirm this bug on a kubuntu 8.04 machine with kde4.1
the mouse pointer does not appear to move on the client screen, but does work on the server.
desktop effects on the server machine are active, but reports before this one said, this makes no difference.

I confirm this on the openSUSE versions 10.3, 11.0 and 11.1-Beta5 (with KDE 4.1.3)
KDE3's krfb is also broken but we don't look back ;)

I confirm this bug on Fedora 10 (i386).

I confirm this bug on openmamba devel. Tried both with libvncserver 0.9.1 and the backport of the library from x11vnc 0.9.5, which works fine with krdc.

Bug confirmed in Fedora 10 as well.  I have a raft of equipment here i can provide to the cause of getting this bug fixed, if a dev needs a fedora 10 station, or anything else you feel a non-programmer sysadmin could do to help.  This is the *last item* preventing us from replacing Windows on the desktop at my organisation, so you can imagine it's a big bug over here.  

From our experience not only does the display get garbled, with the "coloured boxes" mentionned, but krfb also noms 100% CPU on the server-side system.  (Is KRFB not implementing XDamage?)  Willing to provide any testing or resources I can to get this bug dealt with.  Thank you.

This is the only thing preventing me from using Linux too. Since I can't use it at all with this bug.

Does anyone know if anyone is working on this at all?

Also, are there any alternatives or temporary fixes that can help me get some kind of VNC working on my Kubuntu machine?

this bug still exists in 4.2beta1

I confirm this bug (and 100% CPU load) on Fedora 10 x86_64.

(In reply to comment #24)
> This is the only thing preventing me from using Linux too. Since I can't use it
> at all with this bug.
> 
> Does anyone know if anyone is working on this at all?
> 
> Also, are there any alternatives or temporary fixes that can help me get some
> kind of VNC working on my Kubuntu machine?
> 

Try using "vncviewer" instead.  Last time I tried vncviewer, it worked normally.

Bill

Using vncviewer helps a bit, I don't see funky colors anymore. But the display is still garbled (seeing "double" as you can see in the screenshots).

try using x11vnc standalone as workaround (e.g. invoked in an ssh session as the correct user). it gives you a fully working vnc server on your primary desktop.

I comfirm this bug in Archlinux with kde 4.1.3

I get arround this problem configuring in xorg.conf Depth 16 instead of 24 in both client and server machines.

Sadly with Depth 16 compositing doesn't work.

The only way I can get around this annoying bug is to install Xrdp on top of the same host I want to connect to, and then use KRDC to establish an RDP (Microsoft) connection to the *ix host which forwards it to TightVNC.   

Only that displays correctly.

The problem is easy to see if you turn on the Java HTTP clients in xinetd... open a web browser and connect to the HTTP VNC service (:5801); it's garbled as hell.

> The only way I can get around this annoying bug is to install Xrdp on top of 
> the same host I want to connect to, and then use KRDC to establish an RDP 
> (Microsoft) connection to the *ix host which forwards it to TightVNC.

x11vnc (mentioned above) seems to be simpler than Xrdp, since Xrdp uses x11vnc in turn. Or am I wrong?

To tell the truth, I haven't seen a working version of krfb so far. Please, dear developers, fix this bug!

Same here with fresh KDE 4.2.0 on Slackware 12.2 using Krdc 3.5 as a client on LAN

I confirm this bug too, with KDE 4.1.4 on Fedora and Kubuntu.

I confirm this bug running krfb KDE 4.2 on Kubuntu 8.10, connecting with Windows using TightVNC. I can only see one garbled screen on client after logging in, no further screen updates. Mouse cursor moves on client and server machine, but no screen updates sent to client.

It worked perfectly with the kfrb version from KDE 3.5. Anyone knows how to reinstall this version ?

I can confirm on KDE 4.1.3 (Kubuntu 8.10) on both server and client. Both use nvidia FX5200 with binary X.org nvidia driver - version 173.

Same here with OpenSuse 11.1 and KDE 4.1.3. I'm using the nvidia X server on the VNC server.
When the screen is configured with a depth of 24 bits the display on the client is a complete mess. If I reduce the depth to 16 bits everything works.
From the colors I see when the display is garbled, it looks like krfb is confused and thinks that the frame buffer is in 32 bits. When I slowly move a rectangle on the screen, pixel by pixel, I see the colors changing as if there where a rotation between the R, G and B values. On every third move the colors are ok again. I don't know if my explanation is clear enough...

I'm switching to x11vnc for now, it works fine.

I gave up on seeing RFB working again.

x11vnc doesn't compress that well anyway, even over broadband so I switched to NoMachine (NX) nxserver which offers better X11 compression and works through SSH tunneling.

I upgraded today from Kubuntu 8.04 to 8.10 and got this error as well. 
Double drawn display and strange color rectangles all over. Mouseclicks seems to do nothing, and the mouse pointer moves on the client but not always on the server. 

This thread is getting rather old to not have a fix, no?

Bug confirmed for me as well.

KDE 4.1.4
Kubuntu 8.10, 2.6.27-9-generic; x86_64 
ATI proprietary Driver - FGLRX

confirm in 4.1.2, kubuntu 8.10

Created attachment 32717 [details]
Comparison of my real desktop (above) and the image broadcasted by krfb (below)

It's still an issue in KDE 4.2.2. See the krfb image, there are not only variously coluured rectangles (which are flickering in addition), buth the whole image is chopped vertically, slices are repeated, and thus the whole image is lengthened horizontally, so that the rightmost part of the desktop is missing (missing battery monitor, clock and logout buttons on the KDE panel)!

krfb 3.5.9 worked well herer in connection with krdc 3.5.10, 4.1.4., 4.2.1

However after both maschines are updated to KDE4.2.2 I have the same problem on GENTOO (two up to date maschines, krfb on x86 krdc on amd_64

Same problem here with Fedora 10 (KDE 4.2.2)

This is getting to be a bit ridiculous.  Perhaps if krfb is going to be broken for all who would try to use it, then the answer is to kill it off.  That's often a tough decision, but there are limited resources, and a project is far better off choosing its priorities and focusing on them rather than shipping unmaintained code.  If KDE is not going to support it, then it should not be a part of KDE.

In one month we'll be celebrating the 1-year anniversary of nobody doing anything with this bug.   I vote that krfb be removed from KDE and some other replacement found for it.

It's sad that nobody fixes this bug, but at the moment Krfb is pretty unmaintained. So do not expect an fix for this bug very soon. Anybody is free to help on fixing this. KDE lives from everyones help. ;)

(In reply to comment #47)
> It's sad that nobody fixes this bug, but at the moment Krfb is pretty
> unmaintained. So do not expect an fix for this bug very soon. Anybody is free
> to help on fixing this. KDE lives from everyones help. ;)

I've tried SLES 11 (with KDE4), and krfb works there! So, some solution may already exist but not widely published yet.

Sorry, I've tried VirtualBox also with the new openSUSE 11.1 reloaded live CD,
and it also works. It means for me, that I was wron when I said that SLES contains an extra solution. Now I suspect that this problem is driver dependent, or something like that
(I'm using intel).

OK, finally I realized that it works with a 16 bit colour depth, but not at 24 bit. So, if you want to make a workaround, just decrease the colour depth from 24 bit to 16 bit. I've tried it with two different drivers, and it behaved the same way on both graphic cards. However, krfb has some more issues:


-It's screen refresh capabilities are insufficient. It's too slow, some areas of the screen are randomly delayed when drawing, so it's nearly unusable (at least very uncomfortable).

-It constantly consumes 100% CPU time with some graphic cards.

-It cannot follow the changes of screen resolution, moreover, it's not enough to log out and back in after a resolution change, but the whole krfb process has to be restarted.

-It cannot be shut down remotely, because if one clicks on its systray icon by the right mouse button and then starts the exit process, it immediately stops the VNC communication towards the client, despite that clicking OK on a confirmation dialog is necessary for complete shutdown (and this dialog remains invisible for the remote user, of course).

(In reply to comment #50)

> -It constantly consumes 100% CPU time with some graphic cards.

Sorry, this one was a mistake. I cannot reproduce the 100% CPU consumption anymore, krfb consumes considerably low CPU time now. I suspect that I was looking at a different bar of the graph (memory usage) instead of the CPU load. So sorry it's a false alarm from me. (Altought some are complaining about this.)

Any solution in sight? i think i would vote to remove krfb from kde until fixed, the application simply does not work and puts a bad light on kde.

Still the same with KDE 4.3.0 on Sidux. The problem does not seem to be driver dependent at all as I get the garbled non-updating display on both my netbook (Intel graphics) and laptop (ATI graphics) when I connect to the respective other machine.

The problem with the non-updating mouse cursor can be worked around by activating "show local mouse cursor" (or whatever it is called in English KDE) from the toolbar in fullscreen mode, but you still have the colored rectangles everywhere, it lags like crazy (this is over a local LAN connection by router) and the mouse cursor sometimes behaves funny on the remote machine after the connection has been closed.

It's kind of funny that this application in its non-working state is preinstalled in several distributions...

Same problem here with Mandriva 2009.1 (both KDE 4.2.2 and KDE 4.2.4).

I can confirm this on Kubuntu 9.04. This bug has also been reported on launchpad:

https://bugs.launchpad.net/ubuntu/+source/kdenetwork/+bug/340702

This is in the top 10 most hated bugs (https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&votes=700&order=bugs.votes) and has been opened for well over a year.  It would really be great if someone could take a look at it.  Perhaps krfb could be replaced with neatx (http://code.google.com/p/neatx/)

I agree that this is a really annoying issue.

I hope everybody of you know that we KDE-developers work on KDE in our free time. That means that we decide by ourself what we want to work on. At the moment nobody is actively maintaining Krfb unfortunately. *Anybody* of you is free to step up and start looking into this issue. ;) If you need any hints or help, contact me in a private conversation.

*** Bug 204833 has been marked as a duplicate of this bug. ***

> I hope everybody of you know that we KDE-developers work on KDE in our free
> time. That means that we decide by ourself what we want to work on. At the
> moment nobody is actively maintaining Krfb unfortunately. *Anybody* of you is
> free to step up and start looking into this issue. ;) If you need any hints or
> help, contact me in a private conversation.

I hope all the developers know that we KDE-bug-reporters mostly report bugs in our free time.  That means we get to decide if we're going to continue to report bugs and help the KDE project or not.

If the bug voting system is going to be ignored, then it makes little sense to keep it around.  Similarly, if bug reports are going to fall on deaf ears, then there's little incentive to continue to report them.

I know you guys are looking for a KRFB maintainer, but your post came off as a little crass.  I don't think any bug reporter wants to read, "Report all the bugs, we don't care."

(In reply to comment #59)
> I hope all the developers know that we KDE-bug-reporters mostly report bugs in
> our free time.  That means we get to decide if we're going to continue to
> report bugs and help the KDE project or not.

Sure, reporting bugs is *very* valuable for us. I really appreciate your reports.

> If the bug voting system is going to be ignored, then it makes little sense to
> keep it around.  Similarly, if bug reports are going to fall on deaf ears, then
> there's little incentive to continue to report them.

To be honest, I'm not sure if the voting system makes that much sense... I for me read bugreports (or better, get notified) for apps which I maintain or I develop. (I get notified for this report because it was reported for KRDC before...) I do not have the time to read all reports for all KDE components. So in the worst case nobody does read (or better, care) about a bug reported for a component if nobody does actively maintain the app. You can simply not force anybody to work on something he is not interested. But do not get it wrong: a bugreport is still valuable since often somebody steps up at some point and starts working on an unmaintained app. Then these reports help him at that point. So please do not stop reporting bugs! ;) I hope these words make the unfortunate situation a bit more clear.

> I know you guys are looking for a KRFB maintainer, but your post came off as a
> little crass.  I don't think any bug reporter wants to read, "Report all the
> bugs, we don't care."

I'm sorry for that. It was not meant to sound crass at all. I just wanted to give a clear statement for the state of this bugreport.

Having worked on many open source projects myself, I completely understand why this isn't being fixed.  That's why I'm suggesting krfb be removed from KDE.  There's no real reason to have it when it duplicates the functionality of VNC/NX.  Why not remove it from KDE or replace it with one of those better maintained alternatives?  It's a bad user experience to have it there when it is knowingly broken.

(In reply to comment #61)
> Why not remove it from KDE or replace it with one of those better
> maintained alternatives?

Do you know such alternatives? I'm not aware of any. (of course not talking about command line tools)

What about Vino?  Gnome uses it, so someone is obviously maintinaing it.  It works fine, and a little commonality between the two projects on some items, (like remote control apps) couldn't hurt.

I've been working a bit on krfb, trying to get it usable again. It seems to me (although I could be incorrect) that this problem is caused by the XDamage based framebuffer which was partially added in krfb for KDE 4.0. However, it has fallen unmaintained since then, and the XDamage framebuffer was never completed, hence many people experiencing this bug. I've tried locally disabling the XDamage framebuffer and using the Qt one instead. The result: this bug is fixed. However, the performance of the Qt framebuffer is much worse, so it lags more.

I'm just finishing porting the framebuffers to be plugins. The result of this will be that those people experiencing this bug can configure krfb to use the Qt framebuffer for now. This should land in KDE 4.4 (I can't do it any sooner since it is probably too intrusive a change for KDE 4.3.x).

Once that is done, I'll take a look at the XDamage framebuffer and see if I can actually fix this bug. However, I'm no X11 expert, so I'm not making any promises :).

The workaround for now: compile krfb without the XDamage and XShm support.

finally a hero was found.

great to hear that. where do we send presents? ;-)
any chances to get this into 4.4? 4.4 might end up in long term releases, so it would be nice if it was fixed by then.

again, thank you very much for your work, i think you make many people happy

Great news, George! Keep up your work.

Since I consider this as an important bugfix, I think we can even put these change into the 4.3 branch when you have finished it.

Hi all! I'm just starting out in the kde-devel world. From what I can see, there might be a bug in the VNC server setup. I'll try and attach a patch.

Created attachment 36731 [details]
Altered VNC server setup patch

Comment on attachment 36731 [details]
Altered VNC server setup patch

Tested on 16 and 24 bit displays

Hi Shane, Thanks for the patch. I'll take a look at it soon when I can get my hands on two linux boxes to test it with :). It would also be great if some of the other people experiencing this bug could give it a try to ;).

Shane, welcome to KDE-development! :)

Can you reproduce this bug without your patch and verify that it is fixed with this patch?

I can reproduce this bug without the patch and can verify it is fixed with the patch on my setup.

Based on the libvnc documentation you create a server using rfbGetScreen. One of the parameters is for bytes per pixel, where byte per pixel should be 1, 2 or 4. In krfb this is found by dividing the current depth by 8.

Given a depth of 24, this gives us 3 bytes per pixel.

Also note that a depth of 16 does work with the current krfb code as 16 / 8 = 2 which is valid. I have confirmed this. Also Comment #30 From Alfonso confirms this.

Libvnc relevant info:

To make a server, you just have to initialise a server structure using the
function rfbDefaultScreenInit, like
  rfbScreenInfoPtr rfbScreen =
    rfbGetScreen(argc,argv,width,height,8,3,bpp);
where byte per pixel should be 1, 2 or 4. If performance doesn't matter,
you may try bpp=3 (internally one cannot use native data types in this
case; if you want to use this, look at pnmshow24).

I didn't test the patch, but your explanation of the first part seems to be correct. I just wonder why you also removed the screen->newClientHook?

anybody with actual commit rights around? (just want to make a 100% sure that the fix gets in svn, i can commit if really needed to, but if somebody can that actually can test this, it would be better)

Ah, your right, that is not part of this bug. I was confused as to why it was done twice. It can be removed from this patch.

Created attachment 36737 [details]
Altered VNC server setup patch 2

Removed:

screen->newClientHook = newClientHook;

from patch.

@ comment #75: If Shane doesn't have an svn account, I'll commit this later, once I've had a chance to test it for myself :)

Thanks George! I don't have an svn account. However I am curious as to what the process is for getting one?

Great, don't forget to backport it, so it can get into 4.3.3, so there is a certain chance it ends up in the next ubuntu release, which would be nice.

@Shane: Normally, you would first submit a few patches that get committed by other developers. Once it seems that you are doing a good job, and if you are intending to stay involved in KDE for the longer term, then you can apply to get an svn account.

The official document on this is located here:
http://techbase.kde.org/Contribute/Get_a_SVN_Account#Who_Can_Apply_For_a_KDE_SVN_Account.3F

@Beat Wolf: Yeah, I'll definitely backport this to 4.3. Krfb should finally be usable for the first time in KDE 4!

SVN commit 1022261 by gberg:

Fix calculation of bpp to use libvncserver friendly values. Thanks to Shane for the patch.

BUG: 162493

 M  +6 -1      krfbserver.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022261

SVN commit 1022262 by gberg:

Backport r1022261.

BUG: 162493

 M  +6 -1      krfbserver.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022262

*** Bug 183776 has been marked as a duplicate of this bug. ***

Will this fix be backported to 9.04?

@Bruce Edge: I'm assuming your talking about Kubuntu 9.04? In that case you will need to ask the Kubuntu developers.