Bug Tracker item #3415308, was opened at 2011-09-29 03:41 Message generated for change (Comment added) made by bphinz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3415308&group_id=254363
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ptamlx (ptamlx) Assigned to: Nobody/Anonymous (nobody) Summary: Screen update issues Initial Comment: In some cases, the tigervnc server on Linux does not update the screen correctly. One case that I can always reproduce is with the Cadence IC design software. When a property dialog is opened, there are often thin lines around some boxes which are not updated, but where I can still see what was present before the dialog opened. A screen redraw fixes the problem. This happens with versions 1.1.0 and 1.0.90, independent from the viewer (checked with tigervnc viewer and realvnc viewer on Windows XP clients). Please check the attached example screenshot. Interestingly, the regions which are not redrawn are always just one-pixel wide lines. ---------------------------------------------------------------------- >Comment By: Brian Hinz (bphinz) Date: 2012-09-25 20:10 Message: I'm trying to get these RPMS into the EPEL5 repo, but in the meantime you can download them from here and use the rpm2cpio command to extract the cpio archives from the rpms: http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-license-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-server-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-server-applet-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-server-minimal-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/RPMS/x86_64/tigervnc-server-module-1.2.0-6.20120915svn4999.el5.x86_64.rpm http://dl.dropbox.com/u/3409323/TigerVNC/epel5/SRPMS/tigervnc-1.2.0-6.20120915svn4999.el5.src.rpm ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2012-09-24 05:27 Message: I do not have the possibility to build tigervnc with the patches by myself, nor the ability to install a rpm. Is it possible for somebody to make a version built with the patches available as .tar.gz for testing? ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2012-07-17 15:22 Message: I just attached a spec file to build the latest trunk code. The tracker doesn't allow files larger than 256kB or I would have posted the srpm. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2012-07-17 09:33 Message: Pierre posted a patch to the devel list that seems to fix this issue. Please test & confirm. Thanks. ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2012-07-02 01:06 Message: Sorry, ignore my last comment: I just confused 1.0 and 1.1 ... ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2012-07-02 01:04 Message: Are you sure that this is the same issue? The RedHat bugzilla #734424 states that the bug was introduced between tigervnc-server-minimal-1.0.90-0.25.20100813svn4123.fc14.x86_64.rpm and tigervnc-server-minimal-1.0.90-3.fc15.x86_64.rpm. Now when I read my old posts below, I see that the problem did already exist in tigervnc-Linux-x86_64-1.1.80.tar.gz. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2012-06-29 07:09 Message: Please see RedHat bugzilla #734424 for additional info. https://bugzilla.redhat.com/show_bug.cgi?id=734424 Pierre has already responded on the devel list that the patch is not the right way to fix the issue, but at least it's a start in the right direction. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2012-06-06 10:58 Message: I don't see this on RHEL5 with gnome, but I do see it with fluxbox, and only when running under Xvnc (not on the local console). Are you using the 1.2.0 binary from sourceforge downloads page? I don't see a 1.2 available on f16 via yum. ---------------------------------------------------------------------- Comment By: Andrew J. Schorr (ajschorr) Date: 2012-06-06 09:38 Message: FYI, I just tested version 1.2.0, and it has the same problem. Is there any hope for getting this fixed? Thanks, Andy ---------------------------------------------------------------------- Comment By: Andrew J. Schorr (ajschorr) Date: 2012-06-05 09:24 Message: FYI, I tried with GNOME and Xfce, and all exhibit the same window border corruption problem. Is there any fix for this? Or do you think this is a different bug? ---------------------------------------------------------------------- Comment By: Andrew J. Schorr (ajschorr) Date: 2012-06-05 08:36 Message: I think we are having the same problem with fvwm using tigervnc 1.1.0 in Fedora 16. Is there any fix for this? Any time a window is temporarily obscured, the window borders are left in a corrupted state. A refresh is required to fix it. Does using a different window manager fix the problem? ---------------------------------------------------------------------- Comment By: joemck85 (joemck85) Date: 2012-03-25 18:13 Message: I'm having this issue as well, but with WindowMaker. I can verify that it is indeed the window border issue cendossm mentioned, since that's how WindowMaker draws the borders on its windows. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-08 17:50 Message: I can't export the binary off of our intranet at work, but I just stood up a couple of RHEL4/5 VM's at home and will rebuild & post the tarballs. ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-07 00:35 Message: bphinz - would you mind sharing your private build to check if it shows the same problems on my side? ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-07 00:32 Message: bphinz - I am using the "KDE2" window decorations and the "KDE classic" style, I am probably a bit conservative... But the problem persists if I switch to "Bluecurve". ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-06 13:07 Message: Xorg 1.5.3 has a lot of bugs, which is why we can't use it, and I strongly advise against you using it as well, as it would lead to your binaries having those same bugs (key repeat issues, etc.) I'm afraid I need more specific diagnosis on this, because I want to understand exactly what it is that is fixing this bug. Making such broad-sweeping changes to the official builds is pretty scary, but I definitely want to make whatever minimal changes are necessary to fix this. Reproduction steps would also be greatly appreciated. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-06 12:39 Message: Sorry, I was in a hurry and was just trying to make a quick note. What I meant was that I build with the intent of ending up with the same extensions as those that are present in the 6.8.2 Xorg that ships with EL4 (aiming for compatibility). That requires additional libraries to be built as well. Like we discussed previously, it also implies using Xorg 1.5.3 rather than 1.6.5. I'm not sure how or if you want to address that part of it, personally I don't really mind rolling my own binaries because the build-xorg script makes it almost trivial... In either case, the additional "modules" (as they are referred to in the build-xorg script that I added were: xf86bigfontproto evieext trapproto libXpm libXaw libXcomposite (note that this was probably unnecessary once composite was disabled in the xserver build) libXfontcache libXft libXinerama libXrandr libXrender libXres recordproto libXtst libXv xf8fdgaproto libXxf86dga xf86miscproto libXxf86misc libXxf86vm libXvMC When building pixman I changed "--disable-gtk" to "--enable-gtk". My XORGCFGFLAGS were "--with-dri-driver-path=/usr/lib/dri \ --with-fontdir=/usr/lib/X11/fonts \ --disable-ipv6 \ --enable-setuid-install \ --enable-xcsecurity \ --enable-xf86bigfont \ --enable-evi \ --enable-appgroup \ --enable-freetype \ --with-freetype-config=`pwd`/xorg.build/bin/freetype-config \ --enable-xdm-auth-1 \ --enable-xdmcp \ --disable-composite \ --enable-dri \ --disable-xgl \ --disable-xglx \ --disable-dpms \ --disable-screensaver \ --disable-xtrap \ --enable-record \ --enable-glx" Please excuse any typos in the above, I had to retype it all. Using this build on RHEL4 and several different releases of IC5141, I cannot reproduce the bug using any of the default themes (including crux or whatever the name of the one in the screenshot is). ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-06 11:46 Message: Not sure what you mean. Xpm is an X11 client library, not a server extension. The client libraries I build as part of the Xvnc build are used only to statically link Xvnc itself. They are not shipped with the application. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-06 06:04 Message: ptamix - I noticed from your screenshots that you are not using the default "Bluecurve" theme. Can you tell me which one you are using so that I can try to reproduce the problem? DRC - I build a bunch of extra extensions into my local build (in an attempt to match the extensions used by the default xserver shipped with RHEL4). One of those was Xpm. I noticed that the fluxbox spec (from dries at least) requires libXpm, which isn't built into the current 1.10 binaries I think. I'll try some other themes and if I can't reproduce the issue I'll send the complete set of build options that I used. ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-06 00:54 Message: I have just tested the new downloaded 1.1.0 on RHEL 5.3, and the issue is still present. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-06 00:48 Message: Testing on RHEL 5 would be an interesting data point and might help us narrow down what's happening. I guess it's not the Composite extension, but it may be a similar issue in the sense that we're using a newer X server but the applications are still using the older X11 client libraries. ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-06 00:44 Message: I am running on RHEL 4.7, I could also try it on 5.3 if that can help. I just downloaded 1.1.0 again, and I am still having the issue. ---------------------------------------------------------------------- Comment By: https://me.yahoo.com/a/56BmNR9g () Date: 2011-10-06 00:35 Message: Still having the issue with fresh downloaded 1.1.0 ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-05 15:32 Message: The 1.1.80 pre-release build doesn't yet have Composite disabled. Please try the "official" 1.1.0 build from SourceForge. If, in fact, this is due to an issue with Composite, then the SourceForge 1.1.0 build should fix it. Note that the 1.1.0 build now has Composite disabled, whereas prior to 10/01, it didn't. I respun the build, since it was possible to disable that extension without modifying the source code. ---------------------------------------------------------------------- Comment By: https://me.yahoo.com/a/56BmNR9g () Date: 2011-10-05 15:16 Message: I am running RHEL5 (without admin rights ... just in case). I've downloaded the 1.1.80 version from virtualGL today (8 hours ago). ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-05 14:41 Message: No, I suspect that ptamix at least is running RHEL4, RHEL5, or possibly an older version of SUSE, since those are the only platforms IC51 supports. I think it's fine to enable composite going forward. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-05 14:05 Message: OK, I need more details. I thought the Composite issue only affected old platforms. Are you now saying that the presence of Composite will cause these problems on newer platforms as well? If so, then that's a concern, because obviously when TigerVNC is built on modern platforms like Fedora, it has Composite enabled. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-05 14:00 Message: Scratch that, this is almost certainly related to bug #3414789. DRC replaced the existing binaries on 2011-10-01, can you please install those and see if the issue is resolved? FWIW, I just started IC5141 and cannot reproduce the problem (using a local build with the same fix as the official 10/1 binaries). ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-10-05 13:45 Message: Can you both report back what linux distro and release version you're running Xvnc on? ---------------------------------------------------------------------- Comment By: https://me.yahoo.com/a/56BmNR9g () Date: 2011-10-05 13:40 Message: I'm having the same issue with 1.1.0 and 1.1.80 versions of tigerVNC, when running latest Fluxbox. Windows borders are no more refreshed when another Windows XP window got the focus on top of the viewer. The viewer "Refresh Screen" action renders everything back. ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-05 01:29 Message: I tried tigervnc-Linux-x86_64-1.1.80.tar.gz which I downloaded on 2011-09-29 and it is not fixed there. I assume the archive did not change since then, since it still has the same version number. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-05 01:15 Message: Have you tried the latest build from trunk (http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases), on the off chance that this has already been fixed? ---------------------------------------------------------------------- Comment By: ptamlx (ptamlx) Date: 2011-10-05 01:11 Message: In case it is the problem mentioned by cendossm, would it be easy to fix? It is really annoying. ---------------------------------------------------------------------- Comment By: Pierre Ossman (cendossm) Date: 2011-09-29 04:01 Message: I seem to recall we had a problem with not tracking window border changes, but that we ignored it because basically all that used that feature was twm. Maybe this is the same issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3415308&group_id=254363 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
