Re: where is /usr/X11R6/lib/libGLw.a on cygwin?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Phan, Linh H wrote:
> I went to setup-1.7.exe to get the libGLw-devel. setup put libGLw.dll in
> /usr/lib/libGLw.dll.a but it also put all these files:
> in /usr/bin and removed it from my /usr/X11R6/bin. It also removed alot of
> other
> files from /usr/X11R6/bin (eg glxgears) and /usr/X11R6/lib. Luckily I had
> another
> working cygwin system and copied the glxgears from there to the updated cygwin
> system but then the glxgears didn't work. I finally had to copy all files
> from
> /usr/X11R6/{bin,lib} on my working cygwin to my updated cygwin and then things
> work again. The last mirror I used to update cygwin was
> http://mirrors.xmission.com.
> Why are the mirrors not consistent in that some put files in /usr/bin and
> some in
> /usr/X11R6/bin? What is a good mirror that you usually use?
Please read the upgrade announcement:
http://cygwin.com/ml/cygwin-xfree-announce/2008-11/msg0.html
Yaakov
Cygwin/X
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkkqXIkACgkQpiWmPGlmQSN5aQCcCzGaIs6kTasq66XUkEruoDvE
YvkAn1JQLIy3hIrpEeuJ89C1xdTpVvk0
=oQuQ
-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: where is /usr/X11R6/lib/libGLw.a on cygwin?
Hi Marco,
I went to setup-1.7.exe to get the libGLw-devel. setup put libGLw.dll in
/usr/lib/libGLw.dll.a but it also put all these files:
XWin.exe cygSM-6.dll cygXaw3d-7.dllcygXi-6.dll cygXrender-1.dll
cygGL-1.dll cygUil-2.dll cygXcursor-1.dll cygXm-2.dll cygXt-6.dll
cygGLU-1.dll cygX11-6.dll cygXdmcp-6.dllcygXmu-6.dll cygXtst-6.dll
cygGLw-1.dll cygXau-6.dll cygXext-6.dll cygXmuu-1.dllcygfontenc-1.dll
cygICE-6.dll cygXaw-7.dll cygXfixes-3.dll cygXpm-4.dll cygxkbfile-1.dll
cygMrm-2.dll cygXaw-8.dll cygXft-2.dll cygXrandr-2.dll
in /usr/bin and removed it from my /usr/X11R6/bin. It also removed alot of
other
files from /usr/X11R6/bin (eg glxgears) and /usr/X11R6/lib. Luckily I had
another
working cygwin system and copied the glxgears from there to the updated cygwin
system but then the glxgears didn't work. I finally had to copy all files from
/usr/X11R6/{bin,lib} on my working cygwin to my updated cygwin and then things
work again. The last mirror I used to update cygwin was
http://mirrors.xmission.com.
Why are the mirrors not consistent in that some put files in /usr/bin and some
in
/usr/X11R6/bin? What is a good mirror that you usually use?
Thank you Marco,
Linh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Atzeri
Sent: Saturday, November 22, 2008 2:14 PM
To: cygwin-xfree@cygwin.com
Subject: Re: where is /usr/X11R6/lib/libGLw.a on cygwin?
--- "Phan, Linh H" ha scritto:
> Hi,
>
> I am getting this undefined reference to
> `_glwM2DrawingAreaWidgetClass' error:
>
> $ g++ componentTest.o libInventorWidget.a
> -lInventorXt -lInventor -lstdc++ -L/usr/X11R6/lib
> -L/usr/local/lib -limage -ljpeg -liconv -lFL
> -lfreetype -lGL -lGLU -lXm -lXt -lXext -lXi -lX11
> -lm -o componentTest
>
libInventorWidget.a(MyTextureEd.o):MyTextureEd.c++:(.text+0x6b3a):
> undefined reference to
> `_glwM2DrawingAreaWidgetClass'
>
> and it is due to this line in MyTextureEd.c++:
>
> Widget glx = XtCreateWidget("paletteGLX",
> glwMDrawingAreaWidgetClass, parent, args, n);
>
> glwMDrawingAreaWidgetClass is defined in:
> /usr/X11R6/include/GL/GLwDrawA.h:# define
> glwMDrawingAreaWidgetClass
> glwM2DrawingAreaWidgetClass
>
> I know on linux "glwM2DrawingAreaWidgetClass" is
> defined in /usr/X11R6/lib/libGLw.a.
> Does any one know where /usr/X11R6/lib/libGLw.a is
> on cygwin-1.7?
>
For this question
http://cygwin.com/packages/
is your friend.
I presume replaced by libGLw.dll.a
http://cygwin.com/cgi-bin2/package-cat.cgi?file=libGLw-devel%2FlibGLw-devel-7.2-2&grep=libGLw
libGLw-devel: X11 OpenGL libraries
(widgets libdevel)
(installed binaries and support files)
usr/include/GL/GLwDrawA.h
usr/include/GL/GLwMDrawA.h
usr/lib/libGLw.dll.a
usr/lib/pkgconfig/glw.pc
> Thank you,
>
> Linh
>
Regards
Marco
--
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/
--
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: Cygwin X-Win scripting help
Jon, Of course I did that :) :) :) It doesn't work and I am lost, that's all the opening of several windows at least they pop up confuses me until there is only one.. and it's like an empty Cygwin window... and the X session is dead,, who knows like we haven't heard Vista is full of bugs :( :( :( any more ideas please let me know.. Tom Jon TURNEY wrote: > > tbishop wrote: >> I have used XP and have used this script for a long time as a bat file to >> get >> to my UNIX box: >> === >> @echo off >> >> >> C: >> chdir C:\cygwin\bin >> >> bash --login -c "\XWin.exe -query 128.49.000.44 -from 128.23.77.149" >> >> for some reason on Vista it seems NOT to work the same, way, it opens up >> 3 >> command >> tools, the 3rd one blank and a blank Xsession... nothing on the screen >> but >> an X >> in the middle does anyone have any ideas??? > > If this is a new computer with Vista on it you'll need to change the > "-from" > IP address to match. > > > -- > 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/ > > > -- View this message in context: http://www.nabble.com/Cygwin-X-Win-scripting-help-tp20614082p20655494.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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: > 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/
[ANNOUNCEMENT] Updated: {aalib/libaa1/aalib-devel}-1.4rc5-3: An ascii art library
Hi New versions of 'aalib/libaa1/aalib-devel' have been uploaded to a server near you. Cygwin NEWS: o Recompiled against latest X11R7.4 DESCRIPTION: AA-lib is a low level gfx library just as many other libraries are. The main difference is that AA-lib does not require graphics device. In fact, there is no graphical output possible. AA-lib replaces those old-fashioned output methods with powerful ascii-art renderer. UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'aalib' from the 'Libs' category (it should already be selected). DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Dr. Volker Zell volunteer cygwin aalib maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Xinerama
Yaakov (Cygwin Ports) wrote: Looking further into Xinerama, I think I brushed it off too early. It is *very* widely supported[1], and while XRandR is supposed to replace it, actual implementation and usage may be some time off. I also think that there may be some potential flaws in windowed multiplemonitor mode that Xinerama support would fix. While the current behaviour makes sense in multiwindow mode, I'm not sure that it does in windowed mode. Since X window managers have no sense of what is really happening in that case, placing a dialog in the centre of the X display could easily land on the seam between two monitors. (I know, I tried it.) With Xinerama support, however, they would have the necessary information to DTRT. Actually, -multiwindow mode is equally deficient. If we presented the the monitors as separate screens to X (rather than one large screen which spans the entire Windows virtual desktop), X apps could do sensible placement with their windows also) I think that the implementation may be simpler than we thought. To see the situation as it stands: 1) Build and install xineramaproto; 2) Remove the --disable-xinerama flag from xorg-server and rebuild; 3) Build and install libXinerama; 4) Remove --without-xinerama from xdpyinfo and rebuild. This part is fine with me For this example, on my single-head system I launched XWin with: X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0 This gives :0.0 and :0.1 side-by-side. If you have a multihead system, you could just as easily run: X +xinerama -nodecoration -screen 0 @1 -screen 1 @2 Now, let's see what xdpyinfo has to say: $ xdpyinfo -ext XINERAMA | tail [snip] XINERAMA version 1.1 opcode: 128 head #0: 640x480 @ 0,0 head #1: 640x480 @ 0,0 AFAICS that implies that the X geometry overlaps. Indeed, if you run an X client, both screens show exactly the same thing, but only screen 0 accepts input. Compare this to -xinerama, where each screen is completely independent from the other, as if you were running :0 and :1. Yes, I think what I was trying to say back here [1], is that there isn't much value in enabling Xinerama until there is code in the server to set the monitor layout somehow. On Linux, after defining the Screens, you must define their relationship in ServerLayout, e.g.[2]: Section "ServerLayout" Identifier "Simple Layout" Screen "Screen 2" Screen "Screen 1" RightOf "Screen 2" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection So if we were to add additional parameters to the -screen flag, e.g.: X +xinerama -nodecoration -screen 0 640x480 -screen 1 640x480+640+0 - -rightof 0 The problem is that these native windows containing server screens are movable! Xinerama can't deal with dynamic changes to the layout (whereas I think XRandR will be able to) I'm not sure there's a need for any additional command line parameters. We can imply that screen 1 (in your example) is to the right of screen 0 from the co-ordinates it's given. In "-fullscreen -multimonitor" or "-multiwindow" mode, we could use the Windows GetMonitorInfo() API to discover the monitor geometry (it's perhaps an acceptable limitation that the server will need to be restarted to notice any changes to this) [1] http://sourceforge.net/mailarchive/forum.php?thread_name=48F0B732.2040100%40dronecode.org.uk&forum_name=cygwin-ports-general -- 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: [ANNOUNCEMENT] Updated: xorg-cf-files-1.0.2-7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dr. Volker Zell wrote: > Actually only FONTDIR and ENCODINGSDIR are fixed. My true feelings about imake are simply not printable. What other package this size would take 8 releases to (maybe) get right? At least cygport takes care of /usr/man -> /usr/share/man, which perhaps is why I didn't notice this when building nas. Thanks again for the report, Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkp8NAACgkQpiWmPGlmQSOttQCgjG9PQob6xy/x6gR/vQRWijUa MLcAoNGsnXp+rkSuTn9ITAfLVYYj8jmq =88++ -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: pmconfig from proxymngr-1.0.1-1 references to deprecated /usr/X11R6 hirarchy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dr. Volker Zell wrote: > 09:40 PM [531]> cat /usr/lib/X11/proxymngr/pmconfig | grep /X11 > lbx managed /usr/X11R6/bin/lbxproxy lbxproxy is obsolete and long gone, so this is harmless. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkp8MUACgkQpiWmPGlmQSOdUACfeptU0Wd9hLYgBPlt9MO4Useu fDoAn3oC5aLM0RbMj/sf6359BsIb6W+Q =ZUwj -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/
PATCH: Fix Numlock/Capslock synchronization
xorg-server-1.5.3-3 temporary disabled the NumLock/CapsLock synchronization
between X and windows as it was badly broken. (In 1.5.3-2, if NumLock or
Capslock was on, it would toggle everytime an X window gained focus)
This patch repairs that synchronization, so the X server's idea about these
locking keyboard modes is updated correctly when an X window regains focus
Cygwin: Fix the keyboard mode key synchronization
Fix the code which generates fake keypresses when an X window gains focus to
bring the X servers idea of the state of these mode keys in to sync with any
changes which might have taken place whilst unfocused.
With MPX changes, the place the server stores the current mode key state has
changed, appears they are now only held on the virtual core keyboard.
---
xserver/hw/xwin/winkeybd.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
Index: xorg-server-1.5.3/xserver/hw/xwin/winkeybd.c
===
--- xorg-server-1.5.3.orig/xserver/hw/xwin/winkeybd.c
+++ xorg-server-1.5.3/xserver/hw/xwin/winkeybd.c
@@ -49,10 +49,6 @@
static Bool g_winKeyState[NUM_KEYCODES];
-/* Stored to get internal mode key states. Must be read-only. */
-static unsigned short const *g_winInternalModeKeyStatesPtr = NULL;
-
-
/*
* Local prototypes
*/
@@ -209,7 +205,6 @@ winKeybdBell (int iPercent, DeviceIntPtr
static void
winKeybdCtrl (DeviceIntPtr pDevice, KeybdCtrl *pCtrl)
{
- g_winInternalModeKeyStatesPtr = &(pDevice->key->state);
}
@@ -295,19 +290,15 @@ winKeybdProc (DeviceIntPtr pDeviceInt, i
}
}
#endif
-
- g_winInternalModeKeyStatesPtr = &(pDeviceInt->key->state);
break;
case DEVICE_ON:
pDevice->on = TRUE;
- g_winInternalModeKeyStatesPtr = &(pDeviceInt->key->state);
break;
case DEVICE_CLOSE:
case DEVICE_OFF:
pDevice->on = FALSE;
- g_winInternalModeKeyStatesPtr = NULL;
break;
}
@@ -369,7 +360,7 @@ winRestoreModeKeyStates ()
unsigned short internalKeyStates;
/* X server is being initialized */
- if (!g_winInternalModeKeyStatesPtr)
+ if (!inputInfo.keyboard)
return;
/* Only process events if the rootwindow is mapped. The keyboard events
@@ -382,7 +373,9 @@ winRestoreModeKeyStates ()
mieqProcessInputEvents ();
/* Read the mode key states of our X server */
- internalKeyStates = *g_winInternalModeKeyStatesPtr;
+ /* (stored in the virtual core keyboard) */
+ internalKeyStates = inputInfo.keyboard->key->state;
+ winDebug("winRestoreModeKeyStates: state %d\n", internalKeyStates);
/*
* NOTE: The C XOR operator, ^, will not work here because it is
--
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/
pmconfig from proxymngr-1.0.1-1 references to deprecated /usr/X11R6 hirarchy
Hi See subject: 09:40 PM [531]> cat /usr/lib/X11/proxymngr/pmconfig | grep /X11 lbx managed /usr/X11R6/bin/lbxproxy Ciao Volker -- 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: [ANNOUNCEMENT] Updated: xorg-cf-files-1.0.2-7
> Yaakov writes: > The following packages have been updated in the Cygwin net distribution: > *** xorg-cf-files-1.0.2-7 > This release fixes the definitions of MANPATH, FONTDIR, and ENCODINGSDIR. Actually only FONTDIR and ENCODINGSDIR.are fixed. The line with MANPATH comes from Imake.tmpl and is still MANPATH = /usr/man in the generated Makefiles. This is from Imake.tmpl: #ifdef ProjectRoot #define ManDirectoryRoot Concat(ProjectRoot,/man) #else #define ManDirectoryRoot SystemManDirectory #endif #endif #ifndef ManPath #define ManPath ManDirectoryRoot #endif : : MANPATH = ManPath /* top of manual page tree */ and ProjectRoot seems to be set in site.def: #ifndef ProjectRoot #define ProjectRoot /usr #endif > Yaakov > Cygwin/X Ciao Volker -- 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: xmkmf creates wrong MANPATH entry in Makefiles
> Yaakov writes: > Dr. Volker Zell wrote: >> When generating Makefiles with latest xmkmf the resulting Makefiles have >> some bogus entries. > Fixed in xorg-cf-files-1.0.2-7. But I'm curious, what are you building > that still uses imake so extensively? I had a couple of old x11 binaries lying around and tried recompiling with latest X11R7.4 e.g.: xkeycaps Ciao Volker -- 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: Upgrade woes.
* Eric Roode (Thu, 20 Nov 2008 06:21:37 -0500) > I do check www.cygwin.com before doing (what I think is going to be) a > routine upgrade. If there's nothing in the news there, I assume that > what I'm getting is just an upgrade of existing packages that I > already have installed. Is that such a foolish assumption? The real problem is deeper: setup.exe is completely broken by design in respect to upgrading. If you choose "Install from Internet" it will silently choose to upgrade all your "outdated" packages without telling you or presenting you the automatically chosen packages. You have to click on View > Partial to be able to see that on the last screen. But who knows about that option - or who thinks of that? You might simply want to install wget - and you end up with an update of and a completely broken X. Yaakov did a hell of a job[1], but I think he knew that - and I think this is not exaggerated - probably more than fifty percent of all existing Cygwin X installations would be more or less broken after the update. Thorsten [1] "hell of a job" meaning something positive -- 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/
