Bug Tracker item #3414789, was opened at 2011-09-27 22:14 Message generated for change (Comment added) made by dcommander You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3414789&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: UN*X version Group: 1.1.X >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Hinz (bphinz) Assigned to: Adam Tkac (atkac) Summary: Window manager (GNOME) issues Initial Comment: I'm not quite sure where to start with this one... I'm guessing that maybe there is a dependency missing in the Xvnc compile that is causing problems under RHEL4/GNOME that seems to be related to specific themes. I've attached two screen shots of the gnome theme preferences dialog, both from the same machine, same account, etc. The only difference is that one session is running under TigerVNC 1.1 and the other under RealVNC 4.0. ---------------------------------------------------------------------- >Comment By: D. R. Commander (dcommander) Date: 2011-10-01 14:10 Message: New 1.1.0 Linux builds with Composite disabled have been uploaded to Sourceforge ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-10-01 13:09 Message: After further thought, I think that disabling Composite in the "official" builds is probably the best approach. Here's my logic: The official builds are supposed to be compatible with as many platforms as possible, and mainly, they're meant to allow people to run TigerVNC on older platforms that don't have a new enough Xorg code base. Those older platforms are typically also not new enough to have a compositing WM. RHEL 5, for instance, is still running Gnome 2.16.0, so it can't take advantage of compositing, even though (unlike RHEL 4) it doesn't barf if the Composite extension is available. On newer platforms, such as RHEL 6, that support compositing window managers, the recommended approach is not to use the legacy-friendly TigerVNC build but rather to build a version of TigerVNC that uses the pre-installed X11 libraries provided with the O/S. Thus, I don't think it's a big deal if the legacy-friendly build doesn't support compositing on these newer platforms. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-09-30 15:15 Message: The referenced bug was filed against SuSE, but it affects all platforms that use the "legacy-friendly" TigerVNC build. The underlying cause was a bug in xorg-server 1.5.3, which was remedied by upgrading to xorg-server 1.6.5. I'd really like to figure out a way to support RHEL 4 using the official binaries without having to release separate binaries for just that platform and without having to rely on contributed packages. Plus, this issue will likely affect other platforms of a similar vintage to RHEL 4, such as Ubuntu 6.06 perhaps. It's hard for me to believe that there is no mechanism to disable Gnome's use of the Composite extension, but I have yet to find one after searching the web for an hour. It would seem like there should be a gconf setting, at least. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-30 15:08 Message: It is much worse than a cosmetic issue, but the actual effects appear to be theme dependent and it just happens that Bluecurve is relatively unaffected (which is why it went unnoticed for so long). Under other themes it's basically unusable, windows can't be resized, titlebars disappear, etc. I agree that disabling composite should only be done for RHEL4 (and RHEL5?). I'll take a crack at making an RPM over the weekend. That way it's specific to those distros and can be segregated out from the official release as "contributed" packages. With regards to the version of Xorg, I'm only running RHEL4 because I have legacy apps that require it, so I want to compile the xserver with the same extensions as the default console xserver (Xorg 6.8.2). That being said, I have not seen any incompatibilities with the 1.6.5 version. That bug you referenced was against SUSE linux, did you mean to reference a different bug ID? ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-09-30 13:37 Message: I have confirmed this issue, and on my system at least, it's worse than just a cosmetic issue. In addition to the theme manager problem, when opening the console, attempting to click on the new console window to make it active causes the window to jump down the screen and never activate. Both problems go away simply by adding --disable-composite to the XORGCFGFLAGS environment variable prior to running 'build-xorg build'. The quandary here is that disabling Composite eliminates the ability of more modern WM's to do desktop effects, etc, but I'm also keen on supporting RHEL 4, at least for the near term. The regular life cycle for it ends at the end of next February, so maybe companies will finally make the switch to RHEL 5 after that point. The reason why we upgraded the X server to 1.6.5 is because of another bug https://sourceforge.net/tracker/?func=detail&aid=3290864&group_id=254363&atid=1126848 so I definitely would not recommend downgrading back to 1.5.3. It would be nice if there were an environment variable or some other mechanism to disable Gnome's use of the Composite extension. I don't relish the thought of releasing two sets of binaries, one with and one without. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-30 12:03 Message: OK, it Looks like the problem is caused by having the composite extension enabled in the xserver. I rebuilt against Xorg 1.5.3 with an array of different options, the most recent change '--disable-composite --disable-xgl --disable-xglx' appears to be the one that resolves the issue. I believe that xgl and xglx are off by default. I haven't tested the current released build on RHEL5, but if it exhibits a similar problem then I suggest adding this flag to the legacy build script. Unless it makes sense to rebuild the existing 1.1 release binaries this way, I think it's safe to close this ticket and if people need to run on RHEL4 it's simple enough to run the build-xorg script to build a more RHEL4 friendly binary. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-28 11:28 Message: Rebuilt 1.1 branch against xorg-server-1.5.3 with additional XORGCFGFLAGS "--enable-xcsecurity --enable-xf86bigfont --enable-evi --enable-appgroup" so that the extensions are almost the same (only DEC-XTRAP, LBX, & RECORD are missing) but the problem persists. I googled on some of the error messages produced by gnome-theme-manager and it looks like maybe the problem is related to xauth, so I'm going to follow up on that. BTW, the issue is more than just the decorations in the gnome theme manager. If a theme such as "Glider" is chosen the whole window manager basically starts going nuts - titlebars disappear, windows can't be resized and eventually become unresponsive, etc. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-28 08:41 Message: If this message indicates that RHEL4/GNOME depends on some of those extensions (in this case, most likely eviext), then maybe Xvnc should not be built against Xorg 1.6 as they were all removed: http://cgit.freedesktop.org/xorg/xserver/commit/?id=f6617b4127125516583f321c961d70f762f728be Ugh! If only I could off RHEL4 and onto 5... ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-28 06:47 Message: Yes, it does spit out some errors from the command line (only under tigervnc): [bphinz@buildhost-epel4 ~]$ gnome-theme-manager (gnome-theme-manager:20507): Gdk-CRITICAL **: file gdkdraw.c: line 265 (gdk_drawable_set_colormap): assertion `cmap == NULL || gdk_drawable_get_depth (drawable) == cmap->visual->depth' failed (gnome-theme-manager:20507): Gdk-WARNING **: The gdk_draw_*_image require the drawable argument to have a specified colormap. All windows have a colormap, however, pixmaps only have colormap by default if they were created with a non-NULL window argument. Otherwise a colormap must be set on them with gdk_drawable_set_colormap (gnome-theme-manager:20507): GLib-GObject-CRITICAL **: file gobject.c: line 1597 (g_object_get_qdata): assertion `G_IS_OBJECT (object)' failed (gnome-theme-manager:20507): Gdk-CRITICAL **: file gdkcolor.c: line 72 (gdk_colormap_get_visual): assertion `GDK_IS_COLORMAP (colormap)' failed (gnome-theme-manager:20507): Gdk-CRITICAL **: file gdkvisual-x11.c: line 663 (gdk_visual_get_screen): assertion `GDK_IS_VISUAL (visual)' failed (gnome-theme-manager:20506): capplet-common-WARNING **: Received EOF while reading thumbnail for gtk: 'Bluecurve', metacity 'Bluecurve', icon: 'Bluecurve', font: 'Sans 10' ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2011-09-28 01:52 Message: Have you tried running gnome-theme-manager from the command line? Perhaps it prints some error to the console. ---------------------------------------------------------------------- Comment By: Brian Hinz (bphinz) Date: 2011-09-27 23:39 Message: Both sessions are started via "-query localhost" so the WM environment should be correct. Also, this doesn't happen when logging in from the console, only with xdmcp sessions running under tiger. You're right though, there are some differences between the X11 extensions present in Tiger's Xvnc and Real's Xvnc: [root@buildhost-epel4 bphinz]# diff xdpyinfo.tigervnc1.1 xdpyinfo.realvnc4.0 4,5c4,5 < vendor release number: 10605000 < X.Org version: 1.6.5 --- > vendor release number: 60801000 > X.Org version: 6.8.1 10c10 < number of supported pixmap formats: 6 --- > number of supported pixmap formats: 2 13,15d12 < depth 4, bits_per_pixel 8, scanline_pad 32 < depth 8, bits_per_pixel 8, scanline_pad 32 < depth 16, bits_per_pixel 16, scanline_pad 32 17d13 < depth 32, bits_per_pixel 32, scanline_pad 32 20c16 < number of extensions: 20 --- > number of extensions: 22 22d17 < Composite 23a19 > DEC-XTRAP 25,26c21,22 < GLX < Generic Event Extension --- > Extended-Visual-Information > LBX 29,31c25,27 < RANDR < RENDER < SGI-GLX --- > MIT-SUNDRY-NONSTANDARD > RECORD > SECURITY 33a30 > TOG-CUP 35a33 > XC-APPGROUP 38c36 < XInputExtension --- > XFree86-Bigfont I'll try rebuilding tomorrow to see if I can see if that's the case and if so, which one it is. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2011-09-27 22:30 Message: Maybe something in the ~/.vnc/xstartup file is affecting it? Or perhaps it requires an X11 extension that is present in RealVNC and missing in TigerVNC (unlikely, but I can't think of anything else.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3414789&group_id=254363 ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
