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: Open
Resolution: None
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 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

Reply via email to