Red Hat Bugzilla – Bug 213215
Extension GLX is broken
Last modified: 2013-04-30 19:34:04 EDT
Steps to Reproduce:
1. Open a vnc session
2. Start a program using extension GLX
The program stops because GLX is not supported
There is already a patch included in the source to enable "BuildGlxExt", but
the makefiles ignore this token.
In other words, GLX seems completely broken in vnc!
Could you please give me link for glx application that doesn't run??
I tried with googleearth (http://dl.google.com/earth/GE4/GoogleEarthLinux.bin),
that revealed the problem (start it from a terminal to see its error messages).
Blender should do it too, but i did not check.
hmm, I have 2 machines - m1 & m2
m2$ ssh -X m1
m1$ vncviewer :0
and in vncviewer I've started googleearth program and all works fine. Could you
please specify more your reproduction??
I do not understand quiet well your test conditions. Where is the vnc server ?
Which graphic environment is displayed by m1's vnc window.
IMHO, I think the problem is that GLX support is not compiled into the vnc
SERVER (/usr/bin/Xvnc). The client is of little importance, since it only deals
with the RFB protocol. Rendering is done in the SERVER.
The conditions in wich the problem occurs:
Machine m1: FC6 dynamic vnc server. Configuration info:
socket_type = stream
wait = no
user = root
log_on_failure += USERID
server = /usr/bin/Xvnc
server_args = -inetd -once -query localhost -geometry 1600x1200 -dpi
100 -depth 24 -fp unix/:7100 -securitytypes=none
disable = no
3) Restart xinetd
4) Enable local XDMCP, restart display manager.
machine m2 is an FC4 workstation: in a terminal window, submit command
... but again, I do not think the viewer version/os/etc. is involved in the problem.
The command on m2 above tells m1's xinetd to launch a new vnc server and start a
session with the login screen.
Once logged-in (in m1), open a terminal (on m1 via the m2 vnc window) and launch
Does it really make sense to have accelerated Vnc X server? That would require
bunch of opengl libraries to be added and I don't see any revenue for this.
It does make sense, of course: Although the animations are "jumpy", it allows
to remotely run programs optimized for accelerated graphics that would'nt
otherwise accept to run at all !
By the way, I applied the "BuildGlxExt" (opengl) patch on the FC4 version of
VNC (4.1.1-11.fc4): the resulting vnc-server package supports successfully GLX
applications under FC4 via any vnc client...
I've fixed glx extensions. Could you try to reproduce with vnc-4.1.2-6.fc7,
Tested vnc-4.1.2-6.fc7 server with blender on FC6: it works great !
FYI: GLX is a catastrophe with vnc-4.1.2-7.fc7 ...
Starting blender from the menu makes a white window with a very large gray
frame to blink(i.e: appear and disappear quickly), then it stays steady with a
black window (without window manager items). It is possible to stop blender via
Starting blender from a terminal blackens the whole screen immediately. It is
possible to recover via Alt+Q.
By adding option -render to Xvnc, it works OK!
Many thanks for your work
Looks like big conflict between render & glx extensions. In next release I'm
going turn off both of these extensions by default and you could start glx
extensions with +glx