Arch Linux

Cannot reproduce. Client and server are x86_64.

Can reproduce using a windows client (realvnc/ultravnc 64-bit). Nothing has changed client side, downgrading to 1.3.1-2 solves the issue.
Everything involving a large screen content update hangs the image client side.

More info: https://bbs.archlinux.org/viewtopic.php?id=185057

Yes it has to do with resizing the window, after that it hangs.

Same here (1.3.1-3), i686 server, x86_64 client. Downgrade server to 1.3.1-2 works fine again, keeping 1.3.1-3 as client.

Works fine here.

There are two differences between -2 and -3: the latter is compiled against xorg-server 1.16 instead of 1.15 and has dri3 and present extensions enabled. dri3 was disabled in the Intel driver because some people had issues (not me though), maybe it causes issues for Xvnc too. So that's the first thing I'd try, compile -3 with dri3 disabled. Another thing to try is tigervnc-git from AUR.

Oh, another thing I just thought of: I don't have any Qt apps installed, I tested with GTK2 apps (specifically Geany and Firefox), maybe that has something to do with it too.

It does not depend on QT or gtk2, I just launch the session and resize the xfce window and all hangs.
Git version also doesn't work. Disabled dri3 and present options. No change so it's messed up and unusable.
Staying with 1.3.1-2 for now.

I've built -4 without dri3, please try it.

Just tried 1.3.1-4 as server and client and it still hangs. As I have noted in [1] the server side seems to continue receiving events and working, but on the client side the screen stops being updated. I have to do ctrl+c on the terminal where i launched the vncviewer to kill it, clicking the close window button does nothing after things hang.

As I have also noted in [1], if I tunnel the vnc connection over ssh, things seems to work just fine (both with -3 and -4), I have no clue why. When tunneling the vnc connection over ssh this is what I do (I have my ssh public key in the server, so there are no ssh password prompts):
ssh -f -L localport:localhost:serverport [username@]serverip sleep 10 && vncviewer localhost:localport

[1] https://bbs.archlinux.org/viewtopic.php?pid=1442474#p1442474

Ah, I was only testing through a ssh tunnel, vnc ports aren't opened in my firewall. Disabling the firewall and doing a straight connection, I can now reproduce the issue. Sometimes just right-clicking to make the openbox menu appear hangs the viewer, other times this works but then opening an application causes a hang.

So, going back to building Tigervnc against xorg-server-1.15 is in order? But that means the libvnc.so X module won't work. I guess more people use Xvnc than the X module, so a working Xvnc has higher priority. What I don't get though, how can a ssh tunnel magically fix things??

I have no idea why a ssh tunnel fixes things, I'm as surprised by this as you are. My only guess is that it may be connected with latency.

If I try connecting over lan directly from my laptop (client) to a desktop machine (server) things hang, if instead I connect to a raspberry pi(1) I have in the same lan it is harder to trigger the hang and I can close the window normally (the raspberry is quite ram/cpu speed limited so things tend to take a while to get done). If I connect over ssh or vpn to the raspberry things seem to work smoothly.

(1) Using arch linux arm, same tigervnc version as x86 arch.

I got it! The xserver116.patch was missing a hunk. Using the attached one, md5sum 948218a19eac135484267d9990502bf6, I can't reproduce the hangs anymore.

Sergej, create a new build using the new xserver116.patch, and you can enable dri3 again.

thank you, should be fixed in 5th pkgrel

Can't trigger the problem with -5, the problem seems solved.