Re: Darwin extern/static fix
At 3:42 PM -0400 4/13/05, David Dawes wrote: On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote: Bugzilla #1576 and the fix committed for it is only partially right. The patch applewmExt.h is right, but patching the imported Mesa code in extras/Mesa/include/GL/internal/dri_interface.h is the wrong thing to do and likely has unintended side effects on other platforms. The correct fix is just to rename __driConfigOptions in lib/GL/apple/dri_glx.c. Thanks for pointing out the issue. I didn't find anything that requires the external declaration of __driConfigOptions, which is why I applied the patch as submitted. Perhaps something should in the BUILT_IN_DRI_DRIVER case. There are also likely other issues with the BUILT_IN_DRI_DRIVER case. Yes, I don't know of a specific issue, but it seems like bad practice to change an imported header file when we don't need to. The names I came up with in apple/dri_glx.c are completely arbitrary. Now that in gcc 4.0 we can't rely on static to avoid namespace collisions, those static variables should be named something more unique. In the X.Org tree I'm going to change the name of the static variables in apple/dri_glx.c. Of course there's nothing wrong with doing both this and the submitted patch. --Torrey ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Darwin extern/static fix
At 2:41 PM -0700 4/13/05, Ian Romanick wrote: Torrey Lyons wrote: At 3:42 PM -0400 4/13/05, David Dawes wrote: On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote: Bugzilla #1576 and the fix committed for it is only partially right. The patch applewmExt.h is right, but patching the imported Mesa code in extras/Mesa/include/GL/internal/dri_interface.h is the wrong thing to do and likely has unintended side effects on other platforms. The correct fix is just to rename __driConfigOptions in lib/GL/apple/dri_glx.c. Thanks for pointing out the issue. I didn't find anything that requires the external declaration of __driConfigOptions, which is why I applied the patch as submitted. Perhaps something should in the BUILT_IN_DRI_DRIVER case. There are also likely other issues with the BUILT_IN_DRI_DRIVER case. Yes, I don't know of a specific issue, but it seems like bad practice to change an imported header file when we don't need to. The names I came up with in apple/dri_glx.c are completely arbitrary. Now that in gcc 4.0 we can't rely on static to avoid namespace collisions, those static variables should be named something more unique. In the X.Org tree I'm going to change the name of the static variables in apple/dri_glx.c. Of course there's nothing wrong with doing both this and the submitted patch. __driConfigOptions is supposed to be exported by the DRI driver. The idea is that a configuration utility would open libGL and use glXGetDriverConfig to get the configuration options supported by the driver. If the libGL doesn't support loading DRI drivers, as I suspect is the case with the Darwin libGL, there is no reason for glXGetDriverConfig to ever return *anything* other than NULL. Interesting. Currently glXGetScreenDriver() returns apple and glXGetDriverConfig() returns an empty string, but I can see that NULL is more appropriate. The idea was to make porting application code easier by making libGL look like it can load a single apple driver, which might some day support some configuration options. Of course, it will probably never make sense on Mac OS X to have a real loadable driver --Torrey ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Rootless documentation
At 10:58 AM + 7/13/04, Jeremy Wilkins wrote: Hi Torrey, Where did the documentation for the rootless code land - I'd be interested in reading it but can't find it in cvs. I haven't checked it in yet. I got sidetracked trying to decide on a format to use and ended up doing nothing. (Better is the enemy of good enough.) I'll go ahead and just check it in as a text README file for now under Xserver/miext/rootless. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rootless documentation
I've written up some documentation on the generic rootless layer in Xserver/miext/rootless. What is the appropriate place and format for this kind of documentation in the tree? --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Alternate Approach For nVidia PPC Drivers
At 7:17 PM -0800 2/28/04, Matthew Bogosian wrote: Howdy all, Sorry for the cross post, but in retrospect, I thought [EMAIL PROTECTED] was a better place to ask this question than [EMAIL PROTECTED] It is, so I'll stick with devel. As a user, I'm not really concerned whether or not [nVidia PPC Linux] drivers are Open Source or not (although I would certainly commend nVidia for such a bold step). I just want them to be available. I'd like to ask a question, though: is it even conceivably possible to use the binary code distributed with OS X 10.x in Linux? What I mean is, is it possible that one could (in theory) write a wrapper for the Mach-0 based code for the video drivers? Kind of like what these guys have done to allow x86 Linux to use Windows wireless drivers: On the face of it, this is an interesting idea. I had toyed with the idea of going the other way at one time: writing an IOKit wrapper for Mac OS X that would allow one to use XFree86 drivers. Unfortunately, there are a lot of issues you have not considered. http://www.linuxant.com/driverloader/?PHPSESSID=c500d3092e9954138998fb5a8bac0713 http://ndiswrapper.sourceforge.net/ I don't even know which .dylib(s) hold(s) the appropriate code, but I'm imagining something like the following: 1. Identify the appropriate .dylib files (and their dependencies?) in OS X (perhaps otool -L /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLSystem.dylib?) You'll actually want to be looked at KEXT's in /System/Library/Extensions. Dylibs are dynamic shared libraries in user land. All the drivers you want to wrap run in kernel space. 2. Find/write a Mach-0 object loader for Linux (is this necessary? Linux uses ELF, and OS X uses Mach-0, right?) Right. Note the NetBSD guys have done this. Check out http://hcpnet.free.fr/applebsd.html. 3. Identify the approprate nVidia-specific symbols in the .dylib files (this probably requires some heavy reverse engineering/experimentation and a lot of patience) 4. Write the wrapper/glue code to abstract the Mach-O loader/nVidia symbol calls as an XFree86 driver This is not really right. In fact: 1. You'd have to provide an emulation of the environment IOKit video drivers expect to see when they are linked into the Darwin kernel. This would allow the driver to talk to the hardware. This is harder then it might first appear because the IOKit is C++ based and drivers rely on inheriting much of their functionality from other objects. (This is part of the elegance of the IOKit.) You would likely end up having to provide the functionality of a big chunk of the IOKit. Since the Darwin kernel is open source you can see and use all the IOKit kernel code. The Apple Public Source License (2.0) is both open and free http://www.gnu.org/philosophy/apsl.html. Unfortunately, you may run into license compatibility issues depending on how and where you wanted to deploy this code. The APSL is not GPL compatible for example. 2. You would also need to write your XFree86 shim-driver that translated the standard calls from XFree86 ddx into calls appropriate for an IOKit driver. Unfortunately when you were done you might not see the performance you hoped for. The 2-D graphics model on Mac OS X and X11 are very different. An IOKit video driver will provide no hooks to accelerate many X11 graphics primitives. For 3-D you are at least targeting the same API with X11 and Mac OS X (OpenGL), so performance could be closer to ideal. Is there anything wrong with my thinking here? If there are any nVidia developers reading this list, is this something nVidia would be willing to do? It seems like this might be a decent compromise (nVidia doesn't have to release its IP, and Linux users get updates with OS X). Alternatively, are there any bright independents out there who are capable/willing to tackle such a daunting task? The biggest problem is that you are talking about a huge amount of work without a very large payoff. There are very few people who understand both the low level details of the X server and IOKit driver development well enough to attempt it. Not to be too glib, but the obvious question would always be, Why not just run Mac OS X, if you are willing to use binary drivers anyway? XFree86 is included with every computer shipped by Apple these days and in every retail version of the latest version of Mac OS X. With XFree86 4.4.0 on Mac OS X, OpenGL for local X11 applications is exactly as fast as it is for applications written with native Mac OS X API's. Not only that, but XFree86 inherits for free any improvements NVidia or others put into their graphics drivers and automatically supports any new hardware that NVidia supports on the Mac. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Latest fixes from DRI Project
At 9:12 AM + 2/11/04, Alan Hourihane wrote: On Tue, Feb 10, 2004 at 06:20:25PM -0800, Torrey Lyons wrote: At 10:11 AM -0800 1/28/04, Alan Hourihane wrote: Log message: 778. Fix Multitexture problems with vertex arrays and indirect rendering (Bugzilla #1092, DRI Project). 777. Fix SecondaryColor FogColor when indirect rendering (Bugzilla #1091, DRI Project). These fixes have the side effect of breaking GLX on Mac OS X. The problem is the addition of new server side dependencies on glPointParameteri, glPointParameteriv, glSampleMaskSGIS, glSamplePatternSGIS. Mac OS X instead uses glPointParameteriNV and glPointParameterivNV and GL_SGIS_multisample is not supported. I can fix these by substituting the glPointParameter*NV calls and removing the calls to the glSample*SGIS functions as shown in the patch below. Note the server still says it supports the glx extension GLX_SGIS_multisample. Should I add an #ifdef to glxscreens.c as well to remove claiming this extension? Any other comments? Your changes seem reasonable Torrey, go ahead. So I committed a similar patch that incorporates Ian Romanick's suggestions and fixes building on Mac OS X 10.1 and newer. All the changes are conditioned on MISSING_GL_EXTS and/or __DARWIN__. Let me know if it looks like I missed anything. Thanks, Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
GL_VERSION string fix
At 3:46 PM -0800 2/9/04, Alan Hourihane wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/09 15:46:31
Log message:
797. Fix GL_VERSION string for indirect rendering (Bugzilla
#1147, DRI Project)
Modified files:
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
xc/lib/GL/glx/:
glxclient.h glxcmds.c single2.c
xc/programs/Xserver/GL/glx/:
glxext.h glxscreens.c single2.c single2swap.c
This fix breaks the build when the module loader is not used because
it introduced dependence on xf86atof() in single2.c:
--- single2.c 6 Jun 2001 19:00:15 - 1.6
+++ single2.c 9 Feb 2004 23:46:31 - 1.7
@@ -331,18 +340,43 @@
}
string = buf;
}
+else if ( name == GL_VERSION ) {
+ if ( xf86atof( string ) xf86atof( GLServerVersion ) ) {
+ buf = __glXMalloc( __glXStrlen( string )
...
Should this be #ifdef'ed for IN_MODULE, or is there a more elegant
way to handle this.
--Torrey
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Latest fixes from DRI Project
At 10:11 AM -0800 1/28/04, Alan Hourihane wrote:
Log message:
778. Fix Multitexture problems with vertex arrays and indirect rendering
(Bugzilla #1092, DRI Project).
777. Fix SecondaryColor FogColor when indirect rendering (Bugzilla #1091,
DRI Project).
These fixes have the side effect of breaking GLX on Mac OS X. The
problem is the addition of new server side dependencies on
glPointParameteri, glPointParameteriv, glSampleMaskSGIS,
glSamplePatternSGIS. Mac OS X instead uses glPointParameteriNV and
glPointParameterivNV and GL_SGIS_multisample is not supported. I can
fix these by substituting the glPointParameter*NV calls and removing
the calls to the glSample*SGIS functions as shown in the patch below.
Note the server still says it supports the glx extension
GLX_SGIS_multisample. Should I add an #ifdef to glxscreens.c as well
to remove claiming this extension? Any other comments?
--Torrey
Index: g_disptab_EXT.h
===
RCS file: /home/x-cvs/xc/programs/Xserver/GL/glx/g_disptab_EXT.h,v
retrieving revision 1.5
diff -u -d -b -w -r1.5 g_disptab_EXT.h
--- g_disptab_EXT.h 28 Jan 2004 18:11:50 - 1.5
+++ g_disptab_EXT.h 11 Feb 2004 02:17:15 -
@@ -31,6 +31,16 @@
** version 1.2.1 Specification.
*/
+#ifdef __DARWIN__
+#define glPointParameteri glPointParameteriNV
+#define glPointParameteriv glPointParameterivNV
+#define __glXDisp_PointParameteri __glXDisp_PointParameteriNV
+#define __glXDisp_PointParameteriv __glXDisp_PointParameterivNV
+#define __glXDispSwap_PointParameteri __glXDispSwap_PointParameteriNV
+#define __glXDispSwap_PointParameteriv __glXDispSwap_PointParameterivNV
+#define __glPointParameterivNV_size __glPointParameteriv_size
+#endif
+
extern int __glXDisp_AreTexturesResidentEXT(__GLXclientState*, GLbyte*);
extern int __glXDisp_DeleteTexturesEXT(__GLXclientState*, GLbyte*);
extern int __glXDisp_GenTexturesEXT(__GLXclientState*, GLbyte*);
Index: glxcmds.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/GL/glx/glxcmds.c,v
retrieving revision 1.12
diff -u -d -b -w -r1.12 glxcmds.c
--- glxcmds.c 28 Jan 2004 18:11:50 - 1.12
+++ glxcmds.c 11 Feb 2004 02:17:15 -
@@ -1554,6 +1554,7 @@
req = (xGLXVendorPrivateReq *) pc;
vendorcode = req-vendorCode;
+#ifndef __DARWIN__
switch( vendorcode ) {
case X_GLvop_SampleMaskSGIS:
glSampleMaskSGIS(*(GLfloat *)(pc + 4),
@@ -1563,7 +1564,7 @@
glSamplePatternSGIS( *(GLenum *)(pc + 4));
return Success;
}
-
+#endif
if ((vendorcode = __GLX_MIN_VENDPRIV_OPCODE_EXT)
(vendorcode = __GLX_MAX_VENDPRIV_OPCODE_EXT)) {
Index: glxcmdsswap.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/GL/glx/glxcmdsswap.c,v
retrieving revision 1.10
diff -u -d -b -w -r1.10 glxcmdsswap.c
--- glxcmdsswap.c 28 Jan 2004 18:11:50 - 1.10
+++ glxcmdsswap.c 11 Feb 2004 02:17:15 -
@@ -791,6 +791,7 @@
vendorcode = req-vendorCode;
+#ifndef __DARWIN__
switch( vendorcode ) {
case X_GLvop_SampleMaskSGIS:
__GLX_SWAP_FLOAT(pc + 4);
@@ -803,7 +804,7 @@
glSamplePatternSGIS( *(GLenum *)(pc + 4));
return Success;
}
-
+#endif
if ((vendorcode = __GLX_MIN_VENDPRIV_OPCODE_EXT)
(vendorcode = __GLX_MAX_VENDPRIV_OPCODE_EXT)) {
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Latest fixes from DRI Project
At 7:11 PM -0800 2/10/04, Ian Romanick wrote: Torrey Lyons wrote: These fixes have the side effect of breaking GLX on Mac OS X. The problem is the addition of new server side dependencies on glPointParameteri, glPointParameteriv, glSampleMaskSGIS, glSamplePatternSGIS. Mac OS X instead uses glPointParameteriNV and glPointParameterivNV and GL_SGIS_multisample is not supported. I can fix these by substituting the glPointParameter*NV calls and removing the I think it would be better to put the '#ifdef __DARWIN__' in the dispatch code. I'm not terribly fond of using #defines like that. Sounds fine. Since NV_point_sprite isn't supported in all versions of OS X, is something more needed? Yes, I was first trying to get it building again on Panther but I have also been working on Mac OS X 10.1.x issues in the background. There a number of other changes that are needed for anything earlier then Mac OS X 10.2.3 when they added OpenGL 1.4. I can fold them all together as one patch. http://developer.apple.com/opengl/extensions.html#GL_NV_point_sprite calls to the glSample*SGIS functions as shown in the patch below. Note the server still says it supports the glx extension GLX_SGIS_multisample. Should I add an #ifdef to glxscreens.c as well to remove claiming this extension? Any other comments? Absolutely. If it's in the extension string, some application could try to use that functionality and get a nasty surprise. Sounds good. I'll do the same for the Mac OS X 10.2.2 and earlier changes which require removing other extensions. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
weaning off X_LOCALE
Previous versions of Mac OS X did not have proper locale support so
our StandardDefines included -DX_LOCALE. Mac OS X 10.3.x now has
proper locale support, so we want to remove -DX_LOCALE. This will
cause a problem for binaries compiled against the old versions of
libX11 that call _Xsetlocale(). To enable a smooth transition the
patch below has been suggested. I would think this problem has
occurred before. Is there a better way to deal with this?
--Torrey
--- lib/X11/SetLocale.c.origFri Nov 21 14:57:29 2003
+++ lib/X11/SetLocale.c Fri Jan 23 17:13:30 2004
@@ -116,6 +116,16 @@
}
#else /* X_LOCALE */
+#ifdef __DARWIN__
+char *
+_Xsetlocale(
+int category,
+_Xconst char *name
+)
+{
+return setlocale(category, name);
+}
+#endif /* __DARWIN__ */
/*
* _XlcMapOSLocaleName is an implementation dependent routine that derives
--- lib/X11/XlcPubI.h.orig Fri Nov 21 14:57:32 2003
+++ lib/X11/XlcPubI.h Fri Jan 23 17:15:38 2004
@@ -234,6 +234,12 @@
int category,
_Xconst char *name);
#else
+#ifdef __DARWIN__
+extern char *
+_Xsetlocale(
+int category,
+_Xconst char *name);
+#endif
extern char *_XlcMapOSLocaleName(
char *osname,
char *siname);
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Disbandment
I think David's explanation below is very good. It would help stem the tide of confused emails to add almost exactly this wording to the notice on the front page of XFree86.Org. --Torrey At 1:59 PM -0500 1/14/04, David Dawes wrote: On Tue, Jan 13, 2004 at 09:11:14PM -0500, Ruth A. Kramer wrote: Sven Luther wrote: That said, i perfectly understand that these issues are quite puzzling for outside people, who mostly know XFree86 only from using it, but nothing of the internal quarrels we had in the past. Sven, Or outsiders who knew (or thought they knew) a little about past internal quarrels but don't know what this signifies in terms of those quarrels. It is part of a restructuring that has moved XFree86 technical and development discussions into a more open environment. That started early in 2003 when this list was made into a public list. The core team was the only remaining closed technical/development group. With its disbanding, all of the technical/development discussions happen here or on one of the other public XFree86 lists. In the future, as the need arises, we may use a taskforce model to bring together concentrated groups of developers to drive specific tasks forward. The old technical core team model, with its fairly static composition, did not work well for this sort of thing. A good example is that what was effectively the taskforce for the design phase of XFree86 4.0 in 1997-1999 had quite a different makeup from the then core team. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xserver/GL/glx/g_render.c changes?
In building the top of the tree on Mac OS X 10.2 I have run into troubles linking the GLX support in Xserver/GL. The problem is that native OpenGL in Mac OS X 10.2 does not include glActiveStencilFaceEXT() and glWindowPos3fARB(), which have been added to g_render.c and g_renderswap.c since 4.3.0. On Mac OS X 10.3 things build fine since these calls are available. g_render.c includes the comment: /* DO NOT EDIT - THIS FILE IS AUTOMATICALLY GENERATED */ I can build server side GLX successfully if I just #ifdef the offending calls out on Mac OS X 10.2. or #define them to no-ops. Is this likely to cause problems? How is g_render.c automatically generated? What is the best way to conditionally remove support for these two functions? --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fix manual page building on Mac OS X
At 10:21 AM +0100 12/29/03, Matthieu Herrb wrote: Hi, The process that builds XFree86 manual pages needs cpp -traditional when GNU cpp is used. Although the man pages build correctly I suppose you are trying to avoid the multi-line string literals are deprecated warning. Good idea. I'd propose to apply the following patch do darwin.cf. Index: darwin.cf === RCS file: /cvs/xf86/xc/config/cf/darwin.cf,v retrieving revision 1.46 diff -u -r1.46 darwin.cf --- darwin.cf 18 Nov 2003 19:00:14 - 1.46 +++ darwin.cf 29 Dec 2003 09:15:28 - @@ -153,6 +153,7 @@ */ #if OSMajorVersion = 7 # define CppCmd /usr/bin/cpp3 +# define StandardCppOptions-traditional #else # define CppCmd /usr/bin/cpp #endif This fixes the manpage warnings, but this makes __GNUC__ become undefined. Probably using: #define StandardCppOptions -traditional -D__GNUC__ is the safest bet although this has the side effect that __GNUC__ is always defined even with RawCppCmd. To make the Panther case identical to previous versions you'd have to make special case for RawCppCmd as well, which is likely not worth the complexity. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
At 10:01 AM -0800 11/10/03, Ian Romanick wrote: Frank Gießler wrote: with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Can you give any details to help reproduce this error? There is a reported bug in this area, but I thought that it was fixed. Your XF86Config would also be useful. http://bugs.xfree86.org/show_bug.cgi?id=439 I'll put this on Bugzilla as well, but it is quite easy on XDarwin to reproduce this error. GLX fails consistently with indirect rendering and worked properly in 4.3.0. Only direct rendering works now. [65:~] torrey% glxgears 2006 frames in 5.0 seconds = 401.200 FPS ^C [65:~] torrey% setenv LIBGL_ALWAYS_INDIRECT 1 [65:~] torrey% glxgears X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This bug is still present in the top of the tree. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Freetype binary incompatibility
It appears that the Freetype library shipped with XFree86 4.2 is binary incompatible with what shipped with 4.3 and the top of tree. The problem is a bunch of renamed symbols, as described in xc/extras/freetype2/ChangeLog: 2002-02-24 David Turner [EMAIL PROTECTED] * Renaming stream functions to the FT_Subject_Action scheme: FT_Seek_Stream= FT_Stream_Seek FT_Skip_Stream= FT_Stream_Skip FT_Read_Stream= FT_Stream_Read FT_Read_Stream_At = FT_Stream_Read_At FT_Access_Frame = FT_Stream_Enter_Frame FT_Forget_Frame = FT_Stream_Exit_Frame FT_Extract_Frame = FT_Stream_Extract_Frame FT_Release_Frame = FT_Stream_Release_Frame FT_Get_ = FT_Stream_Get_ FT_Read_ = FT_Stream_Read_ Freetype includes a compatibility API in xc/extras/freetype2/src/base/ftapi.c but this is not included in the XFree86 build of Freetype. I'm not sure why this has not reared its head earlier but on Mac OS X qt3 linked against XFree86 4.2.1's Freetype fails with XFree86 4.3.0: dyld: kdeinit Undefined symbols: /sw/lib/libqt-mt.3.dylib undefined reference to _FT_Access_Frame expected to be defined in /usr/X11R6/lib/libfreetype.6.dylib Mac OS X is perhaps different in that XFree86's version of Freetype is the de facto standard and other versions of Freetype are often not present. In any case, we should probably fix this for XFree86 4.4. Any reason not to include ftapi.c? We should probably also push this change back to the 4.3 branch. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 specific patch to freetype-config.in
The following revision to xc/extras/freetype2/builds/unix/freetype-config.in is XFree86 specific and not in the Freetype tree: revision 1.2 date: 2003/05/05 16:12:27; author: dawes; state: Exp; lines: +29 -15 159. Make freetype-config more useful on NetBSD (#5693, Thomas Klausner). cvs diff -r xf-4_3-branch -r 1.2 freetype-config.in Index: freetype-config.in === RCS file: /home/x-cvs/xc/extras/freetype2/builds/unix/freetype-config.in,v retrieving revision 1.1.1.4 retrieving revision 1.2 diff -u -d -b -w -r1.1.1.4 -r1.2 --- freetype-config.in 15 Feb 2002 00:33:20 - 1.1.1.4 +++ freetype-config.in 5 May 2003 16:12:27 - 1.2 @@ -90,7 +90,7 @@ if test $echo_libs = yes ; then libs=-lfreetype if test @libdir@ != /usr/lib ; then - echo [EMAIL PROTECTED]@ $libs + echo -Wl,[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ $libs else echo $libs fi Unfortunately, -R is not a recognized option to ld on Darwin and perhaps other platforms as well. This should be conditionalized in some way. My configure-foo is fairly weak, but it appears that the hardcode_libdir_flag_spec is the configure option that should be used here, rather then a hardwired ELF loader specific option. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
The issue on Mac OS X is that most shared libraries want to be built as two-level namespace images. Two-level namespace images have significant advantages in loading speed, but they require that they have no unresolved symbols when linking the library. This is why the darwinLib.tmpl contains a complete list of every library's dependencies. Unfortunately this causes a problem with two shared libraries, Xt and Xfont. The problem is that these libraries are designed to have certain symbols undefined and to have theses references resolved at application link time by one of various other library choices. In the case of Xt, SM and ICE provide the default resolution of these symbols in darwinLib.tmpl (and cygwin.tmpl), but symbols with the same names from lesstif should be used instead when the application is linked with it. Two-level namespace libraries don't allow you to do that since all symbols get resolved at library link time, not application link time. Thus we fixed this problem by building libXt and libXfont as flat namespace images, which have the same linking semantics that most people on other *nixes are used to. In your case, I suspect that including $(SMLIB) and $(ICELIB) in the following line from cygwin.tmpl is causing your problem: #define SharedXtReqs $(LDPRELIB) $(SMLIB) $(ICELIB) $(XLIBONLY) If Cygwin's linker does not complain when you removed these two, you should be fine. As it is all of the references which are supposed to remain undefined are likely being satisfied at library link time so nothing from lesstif is being included at application link time. --Torrey At 2:43 AM -0400 10/25/03, Harold L Hunt II wrote: Torrey, Looks like you may have had the same sort of trouble that we are now having with regards to building a shared version of the lesstif libraries that link to a shared version of the Xt library. The particular error message, when starting a lesstif app is: XmManager ClassInitialize: XmeTraitSet failed Nicholas Wourms has been looking into this problem (his notes are below) and he seems to think that an OS/X-specific fix may have been made to one of the XFree86 libs to alleviate this problem with lesstif. Do you recall anything related to this problem? If so, could you describe the fix or point us to a message describing the fix? Thanks in advance, Harold *SIGH* I spoke too soon, after building nedit and trying some other tests, I'm experiencing the XmManager ClassInitialize: XmeTraitSet failed problem. Apparently the MacOSX people went through this ordeal last year, but unfortunately that doesn't help us. They had two solutions: 1) Pass -force_flat_namespace which is part of OSX's proprietary linker. 2) Downgrade to XFree86-4.1 libs of some sort or upgrade to latest cvs. Of course, in-depth information on why this is happening is nonexistant, all I could find were: http://oroborosx.sourceforge.net/faq.html#q5p1 http://www.geocrawler.com/mail/msg.php3?msg_id=8230372list=8629 Given that information, I'm willing to bet that an OSX-only fix was checked in sometime after July of last year to resolve this. Finding out what it is will be difficult I'm willing to bet. Of course it could just be Xt misbehaving or an auto-import/psuedo-ops failure. Heh, oh well, I'm going to further investigate this tommorrow... Sorry that it isn't working properly :-(. One last thought, perhaps we should CC Brian Ford in on this since another fresh perspective might be good. Cheers, Nicholas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Generic rootless code bug
At 1:17 AM +0900 10/25/03, Kensuke Matsuzaki wrote:
Rootless code in Xserver/miext/rootless has a small bug.
Kensuke Matsuzaki
diff -u -r1.6 rootlessWindow.c
--- rootlessWindow.c23 Jul 2003 00:48:58 - 1.6
+++ rootlessWindow.c24 Oct 2003 13:02:02 -
@@ -889,9 +889,9 @@
gResizeDeathBits = xalloc(copy_rowbytes
* copy_rect_height);
-if (rootless_CopyWindow_threshold
+if (rootless_CopyBytes_threshold
copy_rect_width * copy_rect_height
-rootless_CopyWindow_threshold)
+rootless_CopyBytes_threshold)
{
SCREENREC(pScreen)-imp-CopyBytes(
copy_rect_width * Bpp, copy_rect_height,
Thanks for catching that. I'll apply your patch.
A side note about the rootless acceleration functions: In the top of
the tree (since yesterday) we have added lots more use of these
optional functions. They are also tested for existence directly
instead of using the corresponding threshold. For example we would
test here for SCREENREC(pScreen)-imp-CopyBytes to not be NULL
instead of rootless_CopyBytes_threshold != 0. This seems safer and is
no slower if the test is true. Please let me know if you have any
comments or questions.
--Torrey
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Fwd: XWaitForReadable timeout
Rob Braun observed the following issue with XCloseDisplay() hanging
indefinitely. Any comments?
--Torrey
At 12:11 AM -0700 9/20/03, Rob Braun wrote:
From: Rob Braun [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: XWaitForReadable timeout
Howdy. While running osx2x, I came across an interesting timeout issue
in libX11's XWaitForReadable() function. The background on the issue
is that osx2x is essentially x2x, but with the source side being OS X.
I fired this up at home, and have been using it quite successfully.
However, I noticed that if the target X11 machine went offline, or
otherwise uncleanly left the network (in this case, it got a different
DHCP address on renew), I couldn't disconnect from that machine, and
osx2x would hang forever.
On inspection, osx2x was trying to disconnect from the remote display
by doing an XCloseDisplay(), which would eventually call down to
XWaitForReadable(). There, libX11 was looping on select. So, I
added a timeout to the select() call, and if the select() timed out,
then something bad has happened, and XWaitForReadable() errors out.
This appears to be the correct behavior under such conditions.
The alternative is to wait for the TCP socket to timeout, which will
take roughly 90 seconds. This is wy too long for an interactive
app, in my opinion. The timeout I used in the call to select() was
5 seconds, which I'm sure people can argue over, but it seemed a
reasonable value to pick.
Anyway, I thought I'd alert you to the issue, and I've attached the
patch I used to fix the problem. It seems like XCloseDisplay(),
and XSync() should be able to take timeouts as arguments...
Rob
Index: XlibInt.c
===
RCS file: /cvs/xc/lib/X11/XlibInt.c,v
retrieving revision 3.37
diff -u -d -r3.37 XlibInt.c
--- XlibInt.c 23 May 2003 14:38:27 - 3.37
+++ XlibInt.c 20 Sep 2003 06:58:20 -
@@ -476,7 +476,10 @@
#endif
for (;;) {
#ifndef USE_POLL
+ struct timeval tv;
FD_SET(fd, r_mask);
+ tv.tv_sec = 5;
+ tv.tv_usec = 0;
if (!(dpy-flags XlibDisplayProcConni))
for (ilist=dpy-im_fd_info; ilist; ilist=ilist-next) {
FD_SET(ilist-fd, r_mask);
@@ -490,12 +493,16 @@
(dpy-flags XlibDisplayProcConni) ? 1 :
1+dpy-im_fd_length,
-1);
#else
- result = Select(highest_fd + 1, r_mask, NULL, NULL, NULL);
+ result = Select(highest_fd + 1, r_mask, NULL, NULL, tv);
#endif
InternalLockDisplay(dpy, dpy-flags XlibDisplayReply);
if (result == -1 !ECHECK(EINTR)) _XIOError(dpy);
- if (result = 0)
+ if (result 0)
+ continue;
+ if (result == 0 ECHECK(EINTR))
continue;
+ if (result == 0)
+ _XIOError(dpy);
#ifdef USE_POLL
if (filedes[0].revents (POLLIN|POLLHUP|POLLERR))
#else
xlib.timeout.diff
Description: Mac BinHex archive
Re: XDarwin build error
Matthieu Herrb [EMAIL PROTECTED] wrote: Hi, when building the latest XFree86 on Mac OS 10.2.4, I get link errors. A first one is easily fixed by the attached patch, but XDarwinApp also fails to link with the following error for which I can't find the missing code... Yes, I have this issue fixed on my laptop. Unfortunately for the next week or so I can't commit the changes as I am away on vacation with only slow web mail access. Unfortunately this error crept shortly before I left. Here's the backstory: XDarwin is going to support two rootless implementations using different API's. On Panther (and hopefully 10.2.x) XDarwin can use Apple's new Xplugin library which was developed specifically for it. Earlier versions will have to use the mixture of Cocoa and Carbon that we used in XFree86 4.3.0. The missing xp_* symbols that you see are from libXplugin. Here's the way I have fixed this: applewm.c will be built into XDarwin as you did with your Imakefile patch. However, applewm.c is being improved to work with either the Xplugin or Cocoa implementations. The XDarwin build is also being modified so that it always builds both implementations (if possible) and dynamically loads the appropriate one in at runtime. This should make testing both implementations much easier. (This bug slipped through because I only tested it when building for Xplugin.) In the short term you can do one of the following to fix the problem: 1. Build the Xplugin implementation. To do this download Apple's X11 public beta and install it. (Actually you only need to install libXplugin, which has its own installer buried in the X11 installer bundle.) Then add the following line to your host.def file: #define XpLibDir /usr/lib Rebuild and everything should build correctly. You will also find that GLX is now exactly as fast as Mac OS X's native OpenGL. 2. Comment out the AppleWMSendEvent() call in Xserver/hw/darwin/quartz/quartz.c. You should be able to rebuild without applewm.c. --Torrey making all in programs/Xserver/miext/rootless... make[4]: Nothing to be done for `all'. /usr/bin/cc -o XDarwinApp -Os -Wall -Wpointer-arith -no-cpp-precomp -L../../exports/lib dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/darwin/libdarwin.a hw/darwin/quartz/libXQuartz.a hw/darwin/quartz/cr/libcr.a miext/rootless/librootless.a hw/darwin/quartz/aquaWindow.o hw/darwin/quartz/aquaPicture.o miext/shadow/libshadow.a fb/libfb.a Xext/libext.a xkb/libxkb.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a -L/usr/X11R6/lib../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -framework IOKit -framework ApplicationServices -framework Cocoa ! -framework CoreAudio -framework Carbon -ObjC ld: Undefined symbols: _xp_configure_window _xp_disable_update _xp_frame_draw _xp_frame_get_rect _xp_frame_hit_test _xp_reenable_update make[3]: *** [XDarwinApp] Error 1 Here's the patch to build applewm.o: Index: Imakefile === RCS file: /cvs/xf86/xc/programs/Xserver/hw/darwin/quartz/Imakefile,v retrieving revision 1.9 diff -u -r1.9 Imakefile --- Imakefile 12 Aug 2003 23:47:10 - 1.9 +++ Imakefile 1 Sep 2003 21:15:30 - @@ -18,6 +18,7 @@ quartzPasteboard.c \ quartzStartup.c \ pseudoramiX.c \ + applewm.c \ aquaPicture.c \ aquaWindow.c \ $(APPLEWMSRC) @@ -32,6 +33,7 @@ quartzPasteboard.o \ quartzStartup.o \ pseudoramiX.o \ + applewm.o \ aquaPicture.o \ aquaWindow.o \ $(APPLEWMOBJ) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
At 10:05 PM +0200 8/11/03, Michel Dänzer wrote: On Mon, 2003-08-11 at 05:29, Alex Deucher wrote: well, yeah... I only mention if in case anyone out there feels like adding basic transparency support to a driver. the driver could then register it's own version of the Xtransparency extension so that apps that were aware could make use of it. I'm not sure this is possible without the driver replacing significant parts of the core server code. I've thought about toying with it on radeon, but I don't know how to tickle the hardware to make it do that... It looks like the 3D engine would have to be used, the 2D engine doesn't seem to do any blending (or scaling, for that matter). One place that we could add this support rather easily is with Mac OS X's rootless mode. There are people writing Mac OS X-specific variants of X window managers that would like to use this kind of feature. In the past they've had to use custom hacks to the X server. If XTransparency/XOpacity became something closer to a defacto standard I would be interested in adopting it. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 to ship in Mac OS X
As some of you may have heard Apple has announced that XFree86 will be included in its next major Mac OS X release, code named Panther. http://www.apple.com/macosx/panther/ This is a major milestone following Apple's previous announcement that they would be supporting XFree86 on the platform. In the future, every Mac and Mac OS X boxed set will include XFree86, which represents a great increase in XFree86's distribution and hopefully visibility. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
At 11:14 AM + 2/19/03, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Indirect GLX acceleration for the MacOS X Xserver. Some other Mac OS X Xserver improvements (summarize as you see fit): - Smaller memory footprint and faster 2-D drawing in rootless mode - Full screen mode uses shadowfb for much faster 2-D drawing At 6:12 PM +0100 2/19/03, Juliusz Chroboczek wrote: Partial rewrite of the ``freetype'' backend. The new version is based on FreeType 2, and handles TrueType (including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old ``type1'' font backend is deprecated, and only used for CIDFonts by default. And - Ability to use native fonts on Mac OS X --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
