MGA fixes don't compile
260. Disabled mode writeback to client program from MGA driver (Egbert
Eich).
This doesn't compile on RedHat 6.2 / egcs-2.91.66
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c: In function `MGASwitchMode':
mga_driver.c:3503: undefined or invalid # directive
mga_driver.c:3505: undefined or invalid # directive
mga_driver.c:3507: undefined or invalid # directive
mga_driver.c:3509: undefined or invalid # directive
mga_driver.c:3523: undefined or invalid # directive
mga_driver.c:3527: undefined or invalid # directive
mga_driver.c: In function `MGAAdjustFrame':
mga_driver.c:3609: warning: implicit declaration of function `HALSetDisplayStart'
make: *** [mga_driver.o] Error 1
This patch expands the macro MGA_HAL() thus allowing the code to compile.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
Index: mga_driver.c
===
RCS file: /home/CVS/XFree86/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c,v
retrieving revision 1.234
diff -u -r1.234 mga_driver.c
--- mga_driver.c2003/06/30 16:52:56 1.234
+++ mga_driver.c2003/07/01 07:32:12
@@ -3490,15 +3490,18 @@
char sCmdIn[256];
char sCmdOut[256];
FILE* fdIn;
+#ifdef MATROX_WRITEBACK
FILE* fdOut;
#endif
+#endif
MGAPtr pMga;
ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
pMga = MGAPTR(pScrn);
if (mode-Flags 0x8000) {
#ifdef USEMGAHAL
- MGA_HAL(
+ MGAPtr pMga = MGAPTR(pScrn);
+ if (pMga-HALLoaded HAL_CHIPSETS) {
fdIn = fopen(/tmp/mgaDriverIn, rt);
#ifdef MATROX_WRITEBACK
fdOut = fopen(/tmp/mgaDriverOut, wt);
@@ -3539,7 +3542,7 @@
mode-Flags = 0x7FFF;
return FALSE;
}
- )
+ }
#endif
return FALSE;
} else
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Ian Romanick writes: I looked into the code, and I now understand what's going on. Alexis made a good catch of a very subtle bug! The main problem that I had was that it wasn't 100% clear at first glance how bufSize / buf / pc were used. Some form of - 8 should be applied to bufSize. I have attached the patch that I plan to apply to the DRI tree. I suspect that it has only cosmetic and / or commentary differences from your patch. Some things have moved around in the DRI tree, so this patch probably won't apply to the XFree86 tree. We can wait until the DRI stuff is merged back again. The patch indeed is very similar to what has been proposed in #439. I've also looked at the GLX code. At line 671 in glxext.c there is : maxSize = ctx-bufSize - sizeof(xGLXRenderLargeReq); Wouldn't we have to add sz_xGLXRenderReq there again? I suppose if the size is to small it is saver as if it is too big. Would you mind taking bug #439 and close it when the code is scheduled for merger with XFree86? Thanks a lot! Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Remove redundant SharedLibObjCompile
Hi, I'm playing with the X build infrastructure and I noticed that SharedLibObjCompile is redundant. Attached is a patch to remove it. Nick ps. see http://mail-index.netbsd.org/tech-x11/2003/06/02/0001.html for what I'm trying to achieve. Index: config/cf/Imake.rules === RCS file: /cvs/xc/config/cf/Imake.rules,v retrieving revision 3.119 diff -c -r3.119 Imake.rules *** config/cf/Imake.rules 2003/05/29 15:31:23 3.119 --- config/cf/Imake.rules 2003/06/09 19:49:22 *** *** 123,129 * LibObjCompile (dir,options) * DebuggedLibObjCompile (options) * ProfiledLibObjCompile (options) - * SharedLibObjCompile (options) * NormalLibraryObjectRule () * NormalFortranObjectRule () * ObjectFromSpecialSource (dst,src,flags) --- 123,128 *** *** 2277,2289 #ifndef UnsharedLibObjCplusplusCompile #define UnsharedLibObjCplusplusCompile(options) LibObjCplusplusCompile(unshared,$(CXXDEBUGFLAGS) $(CXXLIBDEBUGFLAGS) options) - #endif - - /* - * SharedLibObjCompile - compile fragment for shared objects - */ - #ifndef SharedLibObjCompile - #define SharedLibObjCompile(options) LibObjCompile(shared,options $(SHLIBDEF) $(SHAREDCODEDEF) $(PICFLAGS) $(CDEBUGFLAGS) $(CLIBDEBUGFLAGS)) #endif /* --- 2276,2281 Index: config/cf/necLib.rules === RCS file: /cvs/xc/config/cf/necLib.rules,v retrieving revision 1.3 diff -c -r1.3 necLib.rules *** config/cf/necLib.rules 2001/01/17 16:22:32 1.3 --- config/cf/necLib.rules 2003/06/09 19:49:22 *** *** 33,40 #define SeparateSharedCompile NO #endif - #define SharedLibObjCompile(options) $(_NULLCMD_) - /* * InstallSharedLibrary - generate rules to install the shared library. */ --- 33,38 Index: config/cf/sv3Lib.rules === RCS file: /cvs/xc/config/cf/sv3Lib.rules,v retrieving revision 3.6 diff -c -r3.6 sv3Lib.rules *** config/cf/sv3Lib.rules 2003/04/14 20:35:50 3.6 --- config/cf/sv3Lib.rules 2003/06/09 19:49:22 *** *** 103,121 #endif /* - * SharedLibObjCompile - compile fragment for shared objects - */ - #ifndef SharedLibObjCompile - #define SharedLibObjCompile(options) $(RM) shared/$@ @@\ - cat import.h $*.c _$*.c @@\ - $(CC) -c $(ANSICCOPTIONS) $(CCOPTIONS) $(ALLDEFINES) options \ @@\ - $(SHLIBDEF) $(SHAREDCODEDEF) $(PICFLAGS) $(CDEBUGFLAGS) $(CLIBDEBUGFLAGS) \@@\ - _$*.c @@\ - $(MV) _$*.o shared/$@ @@\ - $(RM) _$*.c - #endif - - /* * NormalSharedLibObjCompile - compile fragment for shared object when * a normal library is not being built */ --- 103,108
Re: 2003_06_30 mkfontscale creates encodings.dir in wrong order
Thanks!
I've commited this.
Egbert.
Roland Mainz writes:
Hi!
Xfree86 source tree, pulled at 2003-06-30 this morning. It seems that
mkfontscale is generating the encodings.dir files in the wrong order.
The fontenc code expects the name filename order but mkfontscale
uses now filename name (which means that most encodings are not
recognised anymore when fonts.scale should be build).
I've attached a patch to fix the issue...
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ [EMAIL PROTECTED]
/O /==\ O\ MPEG specialist, CJAVASunUnix programmer
(;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359Index: mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.7
diff -u -r1.7 mkfontscale.c
--- mkfontscale.c2003/06/20 15:49:52 1.7
+++ mkfontscale.c2003/06/30 23:03:37
@@ -1210,7 +1210,7 @@
free(fullname);
fullname = n;
}
-encodingsToDo = listConsF(encodingsToDo, %s %s, fullname, *name);
+encodingsToDo = listConsF(encodingsToDo, %s %s, *name, fullname);
if(encodingsToDo == NULL) {
fprintf(stderr, Couldn't allocate encodings\n);
closedir(dirp);
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
On Tue, 1 Jul 2003, Egbert Eich wrote: Dr Andrew C Aitchison writes: 260. Disabled mode writeback to client program from MGA driver (Egbert Eich). This doesn't compile on RedHat 6.2 / egcs-2.91.66 Hi Andrew, Yes, thanks! Mattieu already told me. It builds with gcc 3.3 (however issues warnings). I'll commit a little different fix later. I have been thinking to remove the Matrox HAL stuff completely and tell Matrox to ship this stuff in their binary only driver. I had to program around so many things in the HALlib. Furthermore using our driver with this lib is quite rediculous. This lib does allmost all initialization. Only the hw cursor, dri and accel functions are taken from our driver. I'd be very unhappy to lose the HAL; it helps a lot when getting a G550 to work with DVI monitors. Some monitors work without it, but others just don't seem to work unless I use mga_hal_drv.o I believe that the /tmp/mgaDriverIn/Out stuff is only used by the MGA PowerDesktop, and I can live without that, but please don't remove the HAL. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
it's also needed for mergedfb support on mga, although it could probably be rewritten to not use HAL. Alex --- Dr Andrew C Aitchison [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2003, Egbert Eich wrote: Dr Andrew C Aitchison writes: 260. Disabled mode writeback to client program from MGA driver (Egbert Eich). This doesn't compile on RedHat 6.2 / egcs-2.91.66 Hi Andrew, Yes, thanks! Mattieu already told me. It builds with gcc 3.3 (however issues warnings). I'll commit a little different fix later. I have been thinking to remove the Matrox HAL stuff completely and tell Matrox to ship this stuff in their binary only driver. I had to program around so many things in the HALlib. Furthermore using our driver with this lib is quite rediculous. This lib does allmost all initialization. Only the hw cursor, dri and accel functions are taken from our driver. I'd be very unhappy to lose the HAL; it helps a lot when getting a G550 to work with DVI monitors. Some monitors work without it, but others just don't seem to work unless I use mga_hal_drv.o I believe that the /tmp/mgaDriverIn/Out stuff is only used by the MGA PowerDesktop, and I can live without that, but please don't remove the HAL. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
AA What sort of checking was done before replaceing mkfontdir with AA mkfontscale ? None; there's been a problem of assignment of responsibility. Please see bug 388, where I'm assuming somebody will do the testing before committing (or decide not to commit until there's testing), and Egbert assumes I did the testing. AA Is there a realistic prospect of testing and fixing this AA properly within say a week ? I've scheduled Wednesday evening (CEST) for that. Might have some time tonight, no promises though. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
imakemdep.h ... is this really correct?
All, At or about line 315 or a top-of-tree config/imake/imakemdep.h there is code that looks like this: #if defined(__GNUC__) !defined(USE_CC_E) #define USE_CC_E ... #endif I dont know when this was added, or even particularly why, but it seems wrong to me. Just because you are using GCC does NOT mean you want to use gcc -E as your CPP. In fact, I have just encountered a case where it even breaks things in unexpected ways. Here's the problem. I wanted to add the -mcpu=i686 -march=i586 lines to my .cf file. But gcc defines symbols like -D__i586__, -Di586, -D__i586 etc, which means that the generated Makefiles end up with -march=1 -mcpu=i686. This of course causes gcc to fail. Does anyone have any idea why this was deemed necessary, and would anyone be heartbroken if I removed that block of code? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Dell C400 fix applied to 855GM?
Sottek, Matthew J writes: The Windows driver does full mode programming including all the external digital components from many 3rd party companies. The open source XFree This is pretty much what the SiS driver does after Thomas got his hands on it. It programms the SiS and it knows about several video bridges attached to it. driver sets modes by using the video bios. That way it does not have to have full programming capabilities for 3rd party components. The XFree driver is therefore limited to what the vbios can do while the Windows driver is not. It is nice to know that - yet it doesn't solve our problem. The users want to use their systems at resolutions and depths that are common these days and they care very little about it what the capablilities of the BIOS are. I know that the BIOS offers a rather easy way to get over the very difficult task of getting the video modes right. In fact I was the one who started the int10 and VESA BIOS stuff - mainly to get the secondary graphics boards posted. However we realize over and over again that the implementation of the VESA BIOS functions is done sloppy and that we are seeing more problems (which we cannot fix) as if we had gone the hard route. Anyway, the solution in this case however should be much simpler: the BIOS knows about the other modes as they get listed. It just refuses to set them them it doesn't see more than 892 kB of video memory. The BIOS just needs to be convinced of that. We had two ways of doing that. One was by setting some BIOS flags, the other was using a VESA BIOS interface. For whatever reason there is at least one more way. Now it is the BIOS vendors' term to provide us with the necessary information. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: imake template to install files from a third directory
Alexander Pohoyda writes: Hi list, I am unable to find a template to create a rule to install files from a directory which does not have a makefile itself. I need to process some files matching a mask (e.g. somedir/*.xpm) without having to list them all in a makefile. There is an InstallMultiple(list,dest) macro, but it takes a file list as an argument, so that's exactly what I want to avoid. I believe that this is quite a general task, so I dare to propose a new template. Please see the attached patch. I would appreciate any ideas about this patch or maybe there are good reasons not to have such a template? Better ways to do this? I've looked all over the X sources and I was not able to find a case where we don't supply a list. However have you tried to use somedir/*.xpm in InstallMultiple()? InstallMultiple() does a for i in $LIST; do... if $LIST gets replaced by somedir/*.xpm it should do what you have in mind. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
Egbert Eich wrote: Sottek, Matthew J writes: The Windows driver does full mode programming including all the external digital components from many 3rd party companies. The open source XFree This is pretty much what the SiS driver does after Thomas got his hands on it. It programms the SiS and it knows about several video bridges attached to it. OT, but for the record: With SiS, it is actuall the other way round. SiS' Windows drivers do mode changes _exclusively_ by calling the BIOS. That's why they never need to update their Windows driver... and produce zillions of different BIOSes instead :( Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
Dr Andrew C Aitchison writes: On Tue, 1 Jul 2003, Egbert Eich wrote: I'd be very unhappy to lose the HAL; it helps a lot when getting a G550 to work with DVI monitors. Some monitors work without it, but others just don't seem to work unless I use mga_hal_drv.o I believe that the /tmp/mgaDriverIn/Out stuff is only used by the MGA PowerDesktop, and I can live without that, but please don't remove the HAL. OK, you have to know - as you are the MGA maintainer. I just think it makes the code very ugly. It hasn't helped me getting two G450 running in one system, either. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Dr Andrew C Aitchison writes:
With Roland's fix, mkfontscale generates encodings.dir files
containing the string (null), ie with lines like:
big5-0 (null)(null)large/big5.eten-0.enc
big5.eten-0 (null)large/big5.eten-0.enc
viscii1.1-1 (null)./viscii1.1-1.enc.gz
adobe-symbol (null)./adobe-symbol.enc.gz
The following diff seems to remove the nulls;
any idea whether this is the right solution ?
Juliusz?
diff -u -r1.8 mkfontscale.c
--- mkfontscale.c 2003/06/30 16:52:57 1.8
+++ mkfontscale.c 2003/07/01 11:58:19
@@ -1203,7 +1203,7 @@
continue;
for(name = names; *name; name++) {
-if(fullname[0] != '/') {
+if(encodingPrefix fullname[0] != '/') {
char *n;
n = dsprintf(%s%s, encodingPrefix, fullname);
if(n == NULL) {
What sort of checking was done before replaceing mkfontdir with
mkfontscale ?
I had the impression that this had been tested to some extend.
Otherwise I wouldn't have committed the fixes.
Appearantly is had not been tested thoroughly.
Is there a realistic prospect of testing and fixing this
properly within say a week ?
If not, I'd like to revert to building the real mkfontdir app and
having a build option to use one or the other when making XFree86.
Yes, if we don't have an improved version by the end of the week
I will revert this.
Having build options for all kinds of experimental stuff doesn't
sound like a realistic solution. Better to have some sandbox
separate from the main tree.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
What sort of checking was done before replaceing mkfontdir with mkfontscale ? EE I had the impression that this had been tested to some extend. Egbert, I am sorry if I misled you. I had tested the mkfontdir replacement on the font directories I hold on my laptop. I did not test this on a tree build, as building a tree on my laptop takes a long time and I was busy. It was my impression that I had been clear on this subject in bugzilla #388. http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=388 I'll try to be even more cautious in the future. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
On Tue, 1 Jul 2003, Egbert Eich wrote: Having build options for all kinds of experimental stuff doesn't sound like a realistic solution. Better to have some sandbox separate from the main tree. True. If we had known that this was experimental, a branch of the CVS tree would have made sense. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
AA any idea whether this is the right solution ?
Please try the attached instead.
Juliusz
Index: xc/programs/mkfontscale/mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.9
diff -u -r1.9 mkfontscale.c
--- xc/programs/mkfontscale/mkfontscale.c 2003/07/01 13:05:34 1.9
+++ xc/programs/mkfontscale/mkfontscale.c 2003/07/01 19:19:32
@@ -117,6 +117,7 @@
}
if(prefix[strlen(prefix) - 1] != '/')
strcat(prefix, /);
+encodingPrefix = dsprintf(%s, prefix);
outfilename = NULL;
@@ -154,7 +155,8 @@
usage();
exit(1);
}
-strcpy(prefix, argv[argn + 1]);
+free(encodingPrefix);
+encodingPrefix = dsprintf(%s, argv[argn + 1]);
argn += 2;
} else if(strcmp(argv[argn], -e) == 0) {
if(argn = argc - 1) {
@@ -199,8 +201,6 @@
}
}
-encodingPrefix = dsprintf(%s, prefix);
-
if(outfilename == NULL) {
if(doBitmaps)
outfilename = fonts.dir;
@@ -1211,10 +1211,12 @@
closedir(dirp);
return -1;
}
-free(fullname);
-fullname = n;
+encodingsToDo = listConsF(encodingsToDo, %s %s, *name, n);
+free(n);
+} else {
+encodingsToDo =
+listConsF(encodingsToDo, %s %s, *name, fullname);
}
-encodingsToDo = listConsF(encodingsToDo, %s %s, *name ,fullname);
if(encodingsToDo == NULL) {
fprintf(stderr, Couldn't allocate encodings\n);
closedir(dirp);
Re: imakemdep.h ... is this really correct?
I dont know when this was added, or even particularly why, but it seems wrong to me. Just because you are using GCC does NOT mean you want to use gcc -E as your CPP. Yes, it does. Why? This is defining the CPP to use for porcessing Imakefile's. Many many UNIXes provide /lib/cpp as a general preprocessing tool. GCC or any other compiler is an extension package. Imake is used in environments outside of X11, albeit infrequently. IMHO, imake should be biased to using tools that are as generic as possible, not as specific as possible. Linux, and others, also provide /lib/cpp or /usr/bin/cpp or some equivalent, there is no need to use gcc -E. By forcing USE_CC_E in imakemdep.h, you completely eliminate the ability for a platform's .cf file to set the desired cpp with CppCmd. Look at how it is used in imahe.c, circa line 314. USE_CC_E is designed, as I remember and as I read the code, for systems that do NOT provide a suitable /lib/cpp or other preprocessor. I stand by that assertion I made earlier ... setting USE_CC_E just because of the compiler I chose is wrong. You are making global system decisions based on a compiler setting. Thats just plain wrong. Beef up SCO's section in Imake.cf to more closely match Linux's. Perhaps this should be more globally done for any platform using GCC. That looks like you are fixing a bug created by a bug, not a bug created by a problem. You do realize that all of that trickery for Linux would not be needed if those lines in imakemdep.h were removed? s/ deemed//. Builds break on platforms where gcc is not the default compiler. I dont understand how. If gcc is not the default compiler the .cf defines CppCmd. Thats the right place to fix it. SCO doesnt have gcc as its default compiler, and it works quite fine with those lines removed from imakemdep.h. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: imakemdep.h ... is this really correct?
On Tue, 1 Jul 2003, Kean Johnston wrote: I dont know when this was added, or even particularly why, but it seems wrong to me. Just because you are using GCC does NOT mean you want to use gcc -E as your CPP. Yes, it does. Why? This is defining the CPP to use for porcessing Imakefile's. Many many UNIXes provide /lib/cpp as a general preprocessing tool. GCC or any other compiler is an extension package. Imake is used in environments outside of X11, albeit infrequently. IMHO, imake should be biased to using tools that are as generic as possible, not as specific as possible. Linux, and others, also provide /lib/cpp or /usr/bin/cpp or some equivalent, there is no need to use gcc -E. By forcing USE_CC_E in imakemdep.h, you completely eliminate the ability for a platform's .cf file to set the desired cpp with CppCmd. Look at how it is used in imahe.c, circa line 314. USE_CC_E is designed, as I remember and as I read the code, for systems that do NOT provide a suitable /lib/cpp or other preprocessor. I stand by that assertion I made earlier ... setting USE_CC_E just because of the compiler I chose is wrong. You are making global system decisions based on a compiler setting. Thats just plain wrong. Beef up SCO's section in Imake.cf to more closely match Linux's. Perhaps this should be more globally done for any platform using GCC. That looks like you are fixing a bug created by a bug, not a bug created by a problem. You do realize that all of that trickery for Linux would not be needed if those lines in imakemdep.h were removed? s/ deemed//. Builds break on platforms where gcc is not the default compiler. I dont understand how. If gcc is not the default compiler the .cf defines CppCmd. Thats the right place to fix it. SCO doesnt have gcc as its default compiler, and it works quite fine with those lines removed from imakemdep.h. Different pre-processors have, in general, different pre-defines. Using a different pre-processor to generate Makefiles than that used to pre-process the C source is asking for trouble (and getting it). While that might not be the case for SCO by some happenstance, it definitely is on Solaris and IRIX, to name two. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Please test http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=425 Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fonts/FreeType builds even when HasFreetype2=YES
All, fonts/FreeType is built even if HasFreetype2 is set to YES. lib/freetype2 correctly doesn't build if HasFreetype2 is set to YES. Is this difference by design or accident? If by accident, can I adjust xfree86.cf to #define BuildFreetype !HasFreetype2? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fonts/FreeType builds even when HasFreetype2=YES
On Tue, Jul 01, 2003 at 03:29:45PM -0700, Kean Johnston wrote: All, fonts/FreeType is built even if HasFreetype2 is set to YES. lib/freetype2 correctly doesn't build if HasFreetype2 is set to YES. Is this difference by design or accident? If by accident, can I adjust xfree86.cf to #define BuildFreetype !HasFreetype2? The two are independent, so the difference is by design. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
On Tue, Jul 01, 2003 at 02:55:19PM +0100, Dr Andrew C Aitchison wrote: On Tue, 1 Jul 2003, Egbert Eich wrote: Dr Andrew C Aitchison writes: 260. Disabled mode writeback to client program from MGA driver (Egbert Eich). This doesn't compile on RedHat 6.2 / egcs-2.91.66 Hi Andrew, Yes, thanks! Mattieu already told me. It builds with gcc 3.3 (however issues warnings). I'll commit a little different fix later. I have been thinking to remove the Matrox HAL stuff completely and tell Matrox to ship this stuff in their binary only driver. I had to program around so many things in the HALlib. Furthermore using our driver with this lib is quite rediculous. This lib does allmost all initialization. Only the hw cursor, dri and accel functions are taken from our driver. I'd be very unhappy to lose the HAL; it helps a lot when getting a G550 to work with DVI monitors. Some monitors work without it, but others just don't seem to work unless I use mga_hal_drv.o Maybe the situation would be better if the mga_hal module was limited to doing just those initialisations that can't, for whatever reasons, be done in open source. If I recall correctly, the original reason for not having this in open source was that enabling the second display on the G400 couldn't be done without exposing how macrovision could be disabled (or something like that). I get the impression that the mga_hal module went beyond what was originally intended, and it definitely makes a mess of the mga driver, as Egbert noted. I believe that the /tmp/mgaDriverIn/Out stuff is only used by the MGA PowerDesktop, and I can live without that, but please don't remove the HAL. When the PowerDesktop stuff was originally discussed a while back, it was recommended that it be implemented via a server extension. That recommendation was obviously ignored. What Matrox puts in their own driver is their business, but it definitely doesn't belong in XFree86 in its current state. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Autônomo com Internet
Empresa procura Autônomos para trabalho utilizando a Internet, em tempo parcial ou integral e com altos ganhos. Não requer experiência. Detalhes no site ou na Apresentação em São Paulo. Visite: www.hipernegocio.com Elmer NGTCorp - Dúvidas pelo email [EMAIL PROTECTED] Para ser removido de futuros correios, por favor, envie email para [EMAIL PROTECTED], com o assunto REMOVER. Obrigado. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Juliusz Chroboczek wrote: Please test http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=425 This fixes the -n -r problems for me, and compiles OK. However, are you trying to emulate the exact semantic behavious of mkfontdir? If so then the way you implement doEncodings is incorrect. In mkfontdir, it first does the unlink (removing the file) and then creates it if there are encodings to output. It does this regardless of whether or nor you specify -e. If there are no encodings there is no file, not a file with just a 0 (which is what will currently be produced). Its ordering is also different, which may or may not have an impact. The function that produces encodings.dir is only run *after* the font tables are written, and only if that work didnt produce an error. If these semantics are unimportant then ignore the above. Please also note that the -x option conflicts with the usage in mkfontdir. In mkfontscale it means add an encoding. In mkfontdir it means ignore the following suffix. This is part of the reason why the fonts.dir file created during the build is a little more than double the size it needs to be, because -x isn't working. If the -x option is really entrenched in mkfontscale, then the mkfontdir wrapper is going to have to parse all arguments and convert a -x to some other option that does the same thing in mkfontscale. If you dont want to do that work let me know I'll happily add both the argument to mkfontscale and the mods to the mkfontdir script to cope with it. It would be much easier if we can just change the current -x option to be something else though. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fonts/FreeType builds even when HasFreetype2=YES
David Dawes wrote: On Tue, Jul 01, 2003 at 03:29:45PM -0700, Kean Johnston wrote: All, fonts/FreeType is built even if HasFreetype2 is set to YES. lib/freetype2 correctly doesn't build if HasFreetype2 is set to YES. Is this difference by design or accident? If by accident, can I adjust xfree86.cf to #define BuildFreetype !HasFreetype2? The two are independent, so the difference is by design. Ah. But since they both link files out of the same source directory, and they appear to both be compiled the same way, would a system-provided FreeType 2.1.4 not suffice for both? Could I bother you to explain how they are independant? Thanks :) If a system-provided FreeType 2.1.4 does indeed provide for both cases, is it then not appropriate to make BuildFreetype !HasFreetype2 as I suggested above? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
On Mon, Jun 30, 2003 at 09:01:31AM -0700, Hope Merritt wrote: All, The patches will not work do to a limitation in the Dell system BIOS and Intel VBIOS. Dell locks their pre-allocated (once called stolen) memory at 1MB and therefore you will be limited in modes on Linux since the VBIOS limits its modes to the amount of pre-allocated memory. Intel has implemented a workaround, but it would require Dell to implement one of Intels latest VBIOS drops in there systems BIOS and then update the system BIOS. I would expect any 855 release of system BIOS from Dell in the next 2 months to have the VBIOS that allows the Xserver to report memory it allocated to the VBIOS and the modes could be adjusted. Another problem I get a lot of reports about is that the VBIOS doesn't support video modes like 1400x1050, the panel resolution used by a number of laptops. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fonts/FreeType builds even when HasFreetype2=YES
On Tue, Jul 01, 2003 at 07:14:03PM -0700, Kean Johnston wrote: David Dawes wrote: On Tue, Jul 01, 2003 at 03:29:45PM -0700, Kean Johnston wrote: All, fonts/FreeType is built even if HasFreetype2 is set to YES. lib/freetype2 correctly doesn't build if HasFreetype2 is set to YES. Is this difference by design or accident? If by accident, can I adjust xfree86.cf to #define BuildFreetype !HasFreetype2? The two are independent, so the difference is by design. Ah. But since they both link files out of the same source directory, and they appear to both be compiled the same way, would a system-provided FreeType 2.1.4 not suffice for both? Could I bother you to explain how they are independant? Thanks :) They are independent for two reasons. The first is that the system-provided FreeType library isn't (yet) used by the freetype XFree86 server module. The second is that lib/font/FreeType is an X server font backend that contains more than just the FreeType library. It is a goal to resolve the first reason (making the lib/font/FreeType build smaller), but the second will remain. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: imakemdep.h ... is this really correct?
On Tue, 1 Jul 2003, Kean Johnston wrote: At or about line 315 or a top-of-tree config/imake/imakemdep.h there is code that looks like this: #if defined(__GNUC__) !defined(USE_CC_E) #define USE_CC_E ... #endif I dont know when this was added, or even particularly why, but it seems wrong to me. Just because you are using GCC does NOT mean you want to use gcc -E as your CPP. Yes, it does. In fact, I have just encountered a case where it even breaks things in unexpected ways. Here's the problem. I wanted to add the -mcpu=i686 -march=i586 lines to my .cf file. But gcc defines symbols like -D__i586__, -Di586, -D__i586 etc, which means that the generated Makefiles end up with -march=1 -mcpu=i686. This of course causes gcc to fail. Beef up SCO's section in Imake.cf to more closely match Linux's. Perhaps this should be more globally done for any platform using GCC. Does anyone have any idea why this was deemed necessary, s/ deemed//. Builds break on platforms where gcc is not the default compiler. and would anyone be heartbroken if I removed that block of code? Such a patch would be rejected. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
