Re: X server 1.5.3-2 candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: > After doing some tracing into the server, and looking at the difference > between the successful and failing remote cases, it seems that we really > do have a direct context in the success case, whereas in the failure > case we have an indirect context. > > I think that due to your trick of linking dri_swrast.so with libGL, we > have some duplicate symbols, as libGL provides glapi_Dispatch itself, > but it's also defined in the server GLX code. > > I think maybe creating the indirect context (which occurs deep inside > swrast) isn't setting the instance of this symbol which the GLX > functions dispatch through when we have an indirect context, instead > they are dispatching through glapi_noop_table, hence the crash. > > I tried to work around this by removing the files with duplicate symbols > (glpapi.c and glthread.c) from the GLX code and linking XWin with libGL > as well, which seems to work as far as running glgears goes... No regression with my Ubumtu 8.10 VM. > (I still need to check that these files are actually functionally > identical between xserver/GLX and mesa/glapi) I checked, and they are practically identical. > Attached is a rough patch I modified the build system part of that patch, and added it and the NumLock/CapsLock sync patch to SVN. Could you please test 1.5.3-4? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkqERYACgkQpiWmPGlmQSN9AgCeP1+0ikWowKAzwM0j5dHGEfXy NjgAn3PO2/HnE1Mgf78QWFsz+54rhFEl =kxj9 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server 1.5.3-2 candidate
Yaakov (Cygwin Ports) wrote:
Of course, we only have the choice of the latter, but if swrast_dri.so
is missing, the GLX (and SGI-GLX) extension is disabled. So I prepared
mesa-7.2-2 and tried building that module, but after fixing up the build
system, I found that it wasn't so simple. The build only links the
module against libmesa.a (a convenience lib that becomes part of libGL),
leaving several undefined references:
_glapi_Context
_glapi_Dispatch
_glapi_add_dispatch
_glapi_check_multithread
_glapi_get_context
_glapi_get_dispatch_table_size
_glapi_noop_enable_warnings
_glapi_set_context
_glapi_set_dispatch
_glapi_set_warning_func
My understanding -- and I may be wrong -- is that these symbols are left
undefined on purpose, because they are meant to be resolved by whatever
loads the module. That may be a DRI-enabled libGL, an X server, etc.
But that doesn't work for us because DLLs must have all references
resolved at link time.
So what to do? All the X servers have GLX support, but if I were to
resolve these symbols against e.g. XWin, then the other servers will
crash trying to load it. (Yes, I tried it.) So while our libGL doesn't
actually use the module, the only neutral solution was to link against
all of libGL instead of just part of it, and at least on the surface it
appears to work.
After doing some tracing into the server, and looking at the difference
between the successful and failing remote cases, it seems that we really do
have a direct context in the success case, whereas in the failure case we have
an indirect context.
I think that due to your trick of linking dri_swrast.so with libGL, we have
some duplicate symbols, as libGL provides glapi_Dispatch itself, but it's also
defined in the server GLX code.
I think maybe creating the indirect context (which occurs deep inside swrast)
isn't setting the instance of this symbol which the GLX functions dispatch
through when we have an indirect context, instead they are dispatching through
glapi_noop_table, hence the crash.
I tried to work around this by removing the files with duplicate symbols
(glpapi.c and glthread.c) from the GLX code and linking XWin with libGL as
well, which seems to work as far as running glgears goes...
(I still need to check that these files are actually functionally identical
between xserver/GLX and mesa/glapi)
Attached is a rough patch
Cygwin/X: GLX crash workaround
Remove GL dispatcher symbols which are defined in libGL, and link
with libGL for them instead (as dri_swrast.so is linked with libGL)
Paper over the cracks. Avoid a crash when we have a broken context.
Turn on GLX null context debugging
---
xserver/glx/Makefile.am |2 --
xserver/glx/single2.c|3 +++
xserver/hw/vfb/Makefile.am |7 ++-
xserver/hw/xnest/Makefile.am |7 ++-
xserver/hw/xwin/InitOutput.c | 24
xserver/hw/xwin/Makefile.am |8 +++-
6 files changed, 46 insertions(+), 5 deletions(-)
Index: xorg-server-1.5.3/xserver/glx/single2.c
===
--- xorg-server-1.5.3.orig/xserver/glx/single2.c
+++ xorg-server-1.5.3/xserver/glx/single2.c
@@ -341,6 +341,9 @@ int DoGetString(__GLXclientState *cl, GL
string = (const char *) CALL_GetString( GET_DISPATCH(), (name) );
client = cl->client;
+if (string == NULL)
+ string = "";
+
/*
** Restrict extensions to those that are supported by both the
** implementation and the connection. That is, return the
Index: xorg-server-1.5.3/xserver/hw/xwin/InitOutput.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/InitOutput.c
+++ xorg-server-1.5.3/xserver/hw/xwin/InitOutput.c
@@ -134,6 +134,9 @@ const char *
winGetBaseDir(void);
#endif
+static
+void glx_debugging(void);
+
/*
* For the depth 24 pixmap we default to 32 bits per pixel, but
* we change this pixmap format later if we detect that the display
@@ -1045,6 +1048,8 @@ InitOutput (ScreenInfo *screenInfo, int
* Apply locale specified in LANG environment variable.
*/
setlocale (LC_ALL, "");
+
+ glx_debugging();
}
#endif
@@ -1127,3 +1132,22 @@ winCheckDisplayNumber ()
return TRUE;
}
+
+/* GLX debugging helpers */
+#include <../glx/glapi.h>
+
+static
+void warn_func(void * p1, const char *format, ...) {
+ va_list v;
+ va_start(v, format);
+ vfprintf(stderr, format, v);
+ va_end(v);
+ fprintf(stderr,"\n");
+}
+
+static
+void glx_debugging(void)
+{
+ _glapi_set_warning_func(warn_func);
+ _glapi_noop_enable_warnings(TRUE);
+}
Index: xorg-server-1.5.3/xserver/glx/Makefile.am
===
--- xorg-server-1.5.3.orig/xserver/glx/Makefile.am
+++ xorg-server-1.5.3/xserver/glx/Makefile.am
@@ -38,10 +38,8 @@ glapi_sources = \
dispatch.h \
Re: GLX on XWin (was Re: X server 1.5.3-2 candidate)
Yaakov (Cygwin Ports) wrote: On Thu, Nov 13, 2008 at 07:12:42PM -0600, Yaakov (Cygwin Ports) wrote: Unfortunately I don't have a linux box to experiment with... :-( There's always http://www.virtualbox.org/ if you want to get a virtual linux system. Thanks! I setup up VirtualBox, installed Ubuntu 8.10 and set up openssh-server in the VM, and configured the VirtualBox NAT port forwarding per the user manual. I then logged in with ssh -Y two different times, once from a VT running in a XWin with GLX enabled, and then from a VT in another XWin with GLX manually disabled (-extension GLX). With XWin GLX enabled, glxinfo showed all the correct information, and glxgears worked, albeit *extremely* slowly. With XWin GLX disabled, of course neither worked, giving Xlib errors that GLX extension was not available. Other X11 programs worked in both cases, but interestingly the Ubuntu GTK+ engine was used only on the server with GLX enabled. So now I'm somewhat reassured that I did the right thing with GLX, although I certainly remain open to further discussion if anyone is having different results, or if there is insight into the speed issue. Curiouser and curiouser. ssh-ing to an Ubuntu 8.10 VM, I am able to reproduce your results: $ glxinfo | grep -E "version|vendor|rendering" direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 client glx vendor string: SGI client glx version string: 1.4 GLX version: 1.2 OpenGL vendor string: Mesa Project OpenGL version string: 2.1 Mesa 7.2 OpenGL shading language version string: 1.10 and glxgears works fine. (surely direct rendering: Yes can't be right here?) ssh-ing to an Ubuntu 8.04 VM I happen to have lying around... $ glxinfo | grep -E "version|vendor|rendering" direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) server glx vendor string: SGI server glx version string: 1.2 client glx vendor string: SGI client glx version string: 1.4 GLX version: 1.2 OpenGL vendor string: OpenGL version string: (this is with my patch from [1] applied, otherwise it the server segfaults trying to read the OpenGL version string, which is occurring because the _glapi_Dispatch points to glapi_noop_table, ie. we have no GL context!) [1] http://cygwin.com/ml/cygwin-xfree/2008-11/msg00279.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: GLX on XWin (was Re: X server 1.5.3-2 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin Ports) wrote: > glxgears worked, albeit *extremely* slowly. Using SSH data compression (with the -C flag) improved this considerably. It still runs ~10% the FPS of a local instance, but it's still responsive. > the Ubuntu GTK+ engine was used only on the server with GLX enabled. - From further experimentation I now think this has nothing to do with GLX (which didn't make sense anyway); it seems to depend on whether or nor gnome-settings-daemon is running on the local display. Does anyone else have any GLX testimonials? Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkhCXIACgkQpiWmPGlmQSM5mACgpE/HgMW0qaSxnqlEt4A79q0f ZGsAoIvB5bELQPNasfk6F56mJUnG4+dO =ng4D -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
GLX on XWin (was Re: X server 1.5.3-2 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher Faylor wrote: > On Thu, Nov 13, 2008 at 07:12:42PM -0600, Yaakov (Cygwin Ports) wrote: >> Unfortunately I don't have a linux box to experiment with... :-( > > There's always http://www.virtualbox.org/ if you want to get a virtual > linux system. Thanks! I setup up VirtualBox, installed Ubuntu 8.10 and set up openssh-server in the VM, and configured the VirtualBox NAT port forwarding per the user manual. I then logged in with ssh -Y two different times, once from a VT running in a XWin with GLX enabled, and then from a VT in another XWin with GLX manually disabled (-extension GLX). With XWin GLX enabled, glxinfo showed all the correct information, and glxgears worked, albeit *extremely* slowly. With XWin GLX disabled, of course neither worked, giving Xlib errors that GLX extension was not available. Other X11 programs worked in both cases, but interestingly the Ubuntu GTK+ engine was used only on the server with GLX enabled. So now I'm somewhat reassured that I did the right thing with GLX, although I certainly remain open to further discussion if anyone is having different results, or if there is insight into the speed issue. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkdGX0ACgkQpiWmPGlmQSOiEACcDF0m/fn9xVTrxC2E4yDB5eVD ptoAnj2QXSGzcKWHCulCDXq5W2vCfIcD =36Ni -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server 1.5.3-2 candidate
On Thu, Nov 13, 2008 at 07:12:42PM -0600, Yaakov (Cygwin Ports) wrote: >Unfortunately I don't have a linux box to experiment with... :-( There's always http://www.virtualbox.org/ if you want to get a virtual linux system. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server 1.5.3-2 candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: > Actually, this seems to be more complex than I first thought. Running any of > the mesa demo programs works fine locally, but causes a server segfault when I > do it over ssh to a linux box Let me give you some background. You're aware that X.Org was previously embedding the Mesa sources into the server. With 1.5, they moved away from that model and now offer two options for GLX: 1) Use full-fledged DRI, which is Linux/*BSD specific; 2) Load the software rasterizer DRI module (/usr/lib/dri/swrast_dri.so) and skip the hardware. Of course, we only have the choice of the latter, but if swrast_dri.so is missing, the GLX (and SGI-GLX) extension is disabled. So I prepared mesa-7.2-2 and tried building that module, but after fixing up the build system, I found that it wasn't so simple. The build only links the module against libmesa.a (a convenience lib that becomes part of libGL), leaving several undefined references: _glapi_Context _glapi_Dispatch _glapi_add_dispatch _glapi_check_multithread _glapi_get_context _glapi_get_dispatch_table_size _glapi_noop_enable_warnings _glapi_set_context _glapi_set_dispatch _glapi_set_warning_func My understanding -- and I may be wrong -- is that these symbols are left undefined on purpose, because they are meant to be resolved by whatever loads the module. That may be a DRI-enabled libGL, an X server, etc. But that doesn't work for us because DLLs must have all references resolved at link time. So what to do? All the X servers have GLX support, but if I were to resolve these symbols against e.g. XWin, then the other servers will crash trying to load it. (Yes, I tried it.) So while our libGL doesn't actually use the module, the only neutral solution was to link against all of libGL instead of just part of it, and at least on the surface it appears to work. While the local mesa demos run whether or not the GLX extension is enabled, but I do see a major difference in xdpyinfo and glxinfo with and without GLX enabled. This is the only reassurance I have right now that I may have picked a working solution. Unfortunately I don't have a linux box to experiment with... :-( Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkc0IoACgkQpiWmPGlmQSMvDgCg0vbhFME215uUOCLSs17Uoq+v yz8AnA/SDBJKcaCJkZS997PA2SQALUVt =B8F8 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server 1.5.3-2 candidate
Yaakov (Cygwin Ports) wrote: > Jon TURNEY wrote: >> Works for me. > >> It doesn't seem to be possible to build Xwin using just the stuff in the >> cygwin distro: Kdrive's kxv.c requires headers from videoproto. I guess this >> is failing to honour a configure check properly somewhere. > > AFAICS that file shouldn't be need if !XV. I just committed a new patch > (1.5-kdrive-xv-conditional.patch) to SVN to fix that, if you could give > that a try. Good stuff. >> Running anything which uses GLX seems to segfault the server :-( > > Do you have a test case? Actually, this seems to be more complex than I first thought. Running any of the mesa demo programs works fine locally, but causes a server segfault when I do it over ssh to a linux box >> I notice we are now loading swrast_dri.so, and I kind of lost track of the >> magic you did to make it loadable, but I suspect something is still not quite >> right. > > It was a hack, and I wasn't sure that it would work, but I didn't have > any way of testing. I'll need to look into this further once I have a > test case. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server 1.5.3-2 candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon TURNEY wrote: > Works for me. > > It doesn't seem to be possible to build Xwin using just the stuff in the > cygwin distro: Kdrive's kxv.c requires headers from videoproto. I guess this > is failing to honour a configure check properly somewhere. AFAICS that file shouldn't be need if !XV. I just committed a new patch (1.5-kdrive-xv-conditional.patch) to SVN to fix that, if you could give that a try. > Running anything which uses GLX seems to segfault the server :-( Do you have a test case? > I notice we are now loading swrast_dri.so, and I kind of lost track of the > magic you did to make it loadable, but I suspect something is still not quite > right. It was a hack, and I wasn't sure that it would work, but I didn't have any way of testing. I'll need to look into this further once I have a test case. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkco8UACgkQpiWmPGlmQSPpTwCgzGiDMUfIHi9JsTOKVN+UF25+ QIoAniRTbcb2D2NKLm/F+Edjm6OpHx6l =ZShh -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
X server 1.5.3-2 candidate
Yaakov (Cygwin Ports) wrote: > I just checked this into SVN, hopefully merging everything correctly and > adding a couple minor patches of my own; system.XWinrc moved to /etc/X11 > and XWin.log to /var/log. Could you please svn up and test 1.5.3-2? Works for me. It doesn't seem to be possible to build Xwin using just the stuff in the cygwin distro: Kdrive's kxv.c requires headers from videoproto. I guess this is failing to honour a configure check properly somewhere. > One more thing I did notice: running "Reload .XWinrc" causes existing > windows to have their icons change to the default X icon. This only > affects the icon in the window decoration; the icon in the Windows taskbar > remains. Running anything which uses GLX seems to segfault the server :-( I notice we are now loading swrast_dri.so, and I kind of lost track of the magic you did to make it loadable, but I suspect something is still not quite right. > I would like to move X11 development to cygwin-xfree now, so let's start a > new thread there for follow-up. Done :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
