Re: Bug: mailing list woes
Do you know if the messages are making it to the list (check mail-archive.com to see if they're there), or just not making it back to you? They didn't make it to the list at all. I thought I may be running afould of moderation but the messages were short. The only way I got this message though was to include the word 'bug' in the title :) Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
VT switching / XKB problem
In 4.3.0 days I made a change to the native keyboard driver that would differentiate between Alt+Ctrl+SPECIAL and Alt+Ctrl+Shift+SPECIAL, where SPECIAL is one of the VT screen switch, zap, or mode change keys. I submitted a small patch (Bugzilla #1298) that cathes a new case where this was being missed, but that code is only ever used if XKB is disabled. When using XKB mode, the problem still exists (that is, holding down shift while using one of the special key sequences still acts on that sequence). I am XKB-impaired, and don't know if this is a problem in the keyboard definition or in XKB itself. I have several applications that want to use Alt+Ctrl+Shift+Fx, and the only way I can currently do that is to disable XKB. Can anyone who 'gets' XKB take a look at this? Many thanks in advance. PS I filed this as bug #1297. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bug: mailing list woes
Hi, I am having a lot of trouble posting to this list. Only a subset of the messages I sent are making it back to me. I tried mailing postmaster, to no avail. Can someone look into what may be going wrong? Thank you. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bug in xdm/auth.c?
Claas Spengler wrote: Dear Kean, I have just one question : Are there other functions that use _XGetHostname ? There are a few in libX11, but they're allowed to :) Currently there arent any others outsode that do, but there are some files that include Xlibint.h so presumably they are using other internal functions from libX11. However I did notice that lib/Xmu/GetHost.c has yet another version of the same code, but called XmuGetHostname, and it has now a third, different set of pre-processor conditionals that set NEED_UTSNAME. This is messy. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bug in xdm/auth.c?
This sounds like a good idea to me. Ok I filed Bugzilla #1302 and attached a patch to address this. As the patch description says, I preserve the HP-UX uname() stuff as the comments seem to indicate its required. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
My point all along has been that the XFree86 licensing policy has not changed. If it is bad now, it was bad before. Why wasn't anyone complaining before? I hope my FQDN does not negatively impact my remarks but ... if no-one was complaining before why are you so determined to change the license? I remember the vague details of the mail thread that I think lead up to this. People were contributing code and were not being correctly attributed for their work. The way I see it, there are two ways to fix that problem. The first way (and one I would have personally chosen) is to be more diligent in producing release notes and in including the correct attributions. The second way, the one you seem to have opted for, is to change the license. I respect your opinions considerably. You have always struck me as being very reasonable and fair. However, if I may be so bold as to point something out, you seem to be a bit blinded on this issue, or at the very least,a more fervent proponent of it than the original problem warrants. I am assuming that for someone who has devoted as much time and energy to a project as you have that a change that would place its future adoption in jeopardy would be something you would fight against, not for. I dont belong to any Debian or other Linux lists so information I have on this is second-hand based on postings to this list, but if the license change is so unpallettable to people that major free software distributions are no longer willing to distribute XFree86, then regardless of any merits of the new license change, regardless of whether the objections are because of FUD or misinterpretation or even plain malevolence, it would seem that the prudent course of action would be to not change the license for the 4.4 release and take more time either fixing people's opinions or fixing the wording of the license. One final point to consider (it may already have been considered, I confess I dont read absolutely every piece of mail on this subject). Suppose there is a file foo.c in the distribution. It is currently licensed under version 1.0 of the XFree license. The people who contributed the code or made changes to it did so with the assumption that that was the license that would be applied to the code. If that license is now simply changed to 1.1, would you not need the permission of every single contributor to do so? Even if you can legally prove that no rights or priveliges granted under the old license are taken away by the new, perhaps the new restrictions placed by the 1.1 license would be unacceptable to the original contributors. I realize that the original license does not require that, but I think good faith does. Since some of the contributors of that old code have very clearly spoken up here and objected to the new license (and the reasons for their objectsions are really not germaine) I think if you proceed with the license change that you do so knowing that you are doing so against the contributors wishes, and you are likely to scare off very valued developers. Kean PS. If the term 'you' here is inappropriately specific to you David, and more appropriately interpreted as a royal 'you' that means the XFree86 board, then please interpret it that way. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiS driver
Thomas Winischhofer wrote: I am, and the current SiS driver (well, more or less) is in CVS (since I have write access). Ok I will try a get. This was with RC2 that I had the problems, and your driver dated 2004-02-11 from your website fixed the problem (with one small Imake change). Would you like more details or are you on top of this? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
SiS driver
All, Is there any reason why the SiS driver isnt the one Thomas Winischofer provides on his site? I recently had very negative experiences with the stock SiS driver on a 661FX that his driver solved immediately. Now I realized it may have solved just this one problem but it seems as the one on his site gets more attention. I know Thomas has submitted other fixes into the tree, and may even be the SiS maintainer. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. I can do that but there's not much prior art of using u_int32_t either. In fact, just one file: loader/xf86sym.c, and a few header files, most of which seem BSD related. And equally small number use uint32_t. I didnt run into problems before your checking at revision 3.18. Perhaps the best way to avoid this is to use neither ... simply use unsigned int? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
We use them in lots of places that require known size data types. If
the C99 types had been globally available say 10 years earlier, this
likely wouldn't have been the case. As it is now, we either need to
find a mechanism for providing the C99 types on platforms that don't
have them, or continue using the CARD{8,16,32} and INT{8,16,32} types,
and also provide CARD64 and INT64 on more platforms than we currently
do.
Using either CARD32 or INT32 give 4 extra warnings (I know they're
completely benign but still, I dont like warnings) whereas using
unsigned int doesn't. There may be 64-bit issues with unsigned int, so I
dont know how safe that would be either.
Definitely something to follow up soon after the 4.4.0 release.
I agree. Making X more type-consistent would be a Good Thing, even
though its likely to be pretty invasive.
Kean
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
We settled down for using CARD32 for now. Mmmm ok. I just finished taking a closer look at where the variable was being used and it is more appropriate to use unsigned int. The two functions that it is calling above are both prototyped to take unsigned int's. CARD32 will work too but it generates 4 extra warnings whereas unsigned int doesn't. But I'm not emotionally attached to either solution :) Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Two new patches: #994 and #995
Hi, I created two bugs, #994, which updates the SCO port, which I would appreciate someone checking in, and #995, which updates pci.ids so that modern nVidia cards are recognized (card names taken from the driver). #995 sure isnt critical for 4.4 but it is simple and useful. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Some warnings cleanup ...
Hi all, I've just created bug #996, which includes some warnings cleanup and some extra stuff for the SCO port. Actually, the SCO port stuff is all related to cleaning up warnings. Some of these may have been specific to the port but some are generic. If someone with commit access would be so kind as to peruse and commit I'd be very grateful. Thanks for the quick turn around on the last two David. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
4.4.0RC1 compile failure in glx
Hi, I am getting a compile failure in glxect.h, using the data type int64_t. I see that if __UNIXOS2__ is defined then it defines them, but nowhere can I find an attempt to include stdint.h, which is where these types are defined, according to POSIX. In fact, the only palces where stdint.h is mentioned in the entire tree is in expat, freetype2 and in teh darwin/quartz/xpr/Xplugin.h file. There are a few places in the tree where int64_t is used, the majority of which are in Mesa. There are a few occurences of it in the xfree86 server as well. It looks as if code expects these types to be defined if some header file other than stdint.h is included - perhaps they expect it from sys/types.h, I dont know, but that is wrong. Any thoughts on how to go about fixing this? I can of course put in a hack specific to sco to include stdint.h but that seems wrong. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Setting up a runtime-only package?
Hello everyone, I am trying to get together the packaging requires for XFree86 so that I can provide it to our users. Ideally, I would like to split the packaging into at least two pieaces, possibly three. At the very least I would like to provide a runtime component that has all of the required shared libraries, data files and header files, so that customers can run other precompiled stuff, or develop X applications. The shared libs and include stuff is easy, I know what to include there, but what else is needed for a pure runtime environment (no server, no standard clients) such that, for example, I can compile Mozilla against the XFree86 libs and have it run. Does anyone have an idea of what else is required? I am guessing the fonts will be required, but how many other bits and pieces in usr/X11R6/lib are required? The second piece would be all the clients, the server itself and anything not in the runtime package, as well as all of the man pages. A possible third piece would be to have all of the fonts in their own package, or perhaps all of the doc in its own package too. If anyone can point me at any docs, or help shed some light on this, I would be extremely grateful. Regards, Kean. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Wraphelp.c
All, With the relaxing of US export restrictions is there any reason why Wraphelp.c isn't provided by default? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Shared library inter-dependencies
The most current exemple is -lc_r vs -lc (or -lXThrstubs vs -lpthreads) on some systems for threaded vs non-threaded applications. I'm talking about inter-X11 dependencies. Xext *always* depends on X11. SM *always* depends on ICE. That kind of thing. Its a simple matter of ELF shared object inter-dependencies. Dont forget, any RTLD worth its salts wont even load the symbols from the dependent library until it needs to, unless the user has explicitly told it to bind all symbols. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Shared library inter-dependencies
Hi, I asked this once before but unfortunately I lost the reply when I moved to Mozilla for my mail reader, so I'd like to ask the question again, or open up the debate. I would very VERY much like to see the XFree86 build correctly set up its dependencies for shared libraries. For example, make sure that Xext always has X11.so.6 as a dependency. This makes life a lot easier for folks, and obviates the need for linking with the same library many times (not all systems are thus flawed, but many are). Ideally, each library should be build with -z text, so that it has no unresolved relocations. I believe that Darwin actually requires this (if I remember the previous reply to this question correctly), so there is at least some precedent in the build for handling this. If this is true, and these inter-dependencies are already addressed for Darwin, then it will most probably be a simple matter of adjusting the required *Lib.rules files to link against the dependent libraries. Comments? Suggestions? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Egbert Eich wrote: This is really difficult. I have compared Julisz's and Kean's patches. Juliusz doesn't implement the -r option while Kean's code doesn't fix the '(null)' problem, Kean doesn't generate an encodings file if no encodings are to be processed while Juliusz generates one containing a 0. I could mix both fixes and we may get closer to the truth. Sorry about that. I made my fix against one that had the NULL problem in it. I think we're getting closer though ... From the code I don't see a difference in order between you version and Juliusz's either, am I wrong? No you're not. I didnt know if those semantics were important so I didn't change them. I am not sure they are important, but since this is a replacement for mkfontdir, I think it is prudent to err on the side of caution. You never know what odd behaviour people depend on. Please also note that the -x option conflicts with the usage in mkfontdir. In mkfontscale it means add an encoding. In mkfontdir it This should definitely be fixed. Do you want to do it or would you like some help? If the latter, tell me what you want to do. Change -x in mkfontscale to be ignore a suffix or keep its add an encoding meaning. I am in favour (personally) of making -x mean eXclude a suffix and perhaps changing the current mkfontscale's -x to -a, for (a)dd an encoding. There is a fair amount of momentum in other programs for -x being an exlusion list and -a being an append list, so this would retain consistancy, at least from an intuitive point of view. But it is also possible there are lots of peoples scripts depending on the current mkfontscale -x. You know better than I, its your call. Kean ___ 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: 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
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: 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: Someone has re-implemented ucs2any.pl in C
I'd be more than happy to finish off the final touches, test it on all bdf fonts I've got available, and compare the output against ucs2any.pl if it would be useful to XFree86 project or anyone else. My C version can process all fonts in one pass and spit out multiple encodings all at once, instead of being invoked hundreds of times. I wrote it like that as I figured it might give an additional speedup not having to fork and exec from a shell script constantly. I did much the same thing about the same time and dropped it for the same reason :) But I would LOVE to see this done in C. Right now, on my dual P3/500 at least, it takes almost as much time to go through the zillions of ucs2any invocations as it does to build the hw/xfree86 directory. It certainly is a considerable part of the build time and part of the problem is perl and part of it is the huge number of invocations. I for one would be VERY glad to see this fixed. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X11.tmpl wrong for mkfontscale/dir ?
Kean Johnston wrote: All, I just pulled from the cvs head (well yesterday afternoon, or about 12 hours ago) and the build is failing becuase X11.tmpl. at about line 3675, has: RunProgram(MKFONTDIR, -n -r -p inst/ $$E .)) But MKFONTDIR is expanding to mkfontscale, which doesn't support these options. Thats becuase up at around line 1507 MKFONTDIR is being se to mkfontscale. Is that wrong? Was that a typo? Should it really be refering to mkfontdir there? Ok I see from the changelong that it shouldn't, that mkfontscale is now the Tool To Use. So just removing the -n -r from that line causes the build to succeed, but the server doesn't start after doing a make install. It fails saying it cant fine the font fixed. If I do to fonts/misc and run mkfontdir (which is now the wrapper script) then the server starts, but twm doesn't. Do I have to go to 75dpi/ and 100dpi/ and run mkfontdir and then it works. Strange thing is, the resulting fonts.dir is MUCH smaller in 75dpi than what comes out of the build. Same in misc/. Looks as if there is still some missing glue from the replace mkfontdir with mkfontscale work? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X11.tmpl wrong for mkfontscale/dir ?
-n -r -p are documented in man mkfontdir, but -n and -r aren't
implemented in mkfontscale. Thus bug #387 is not complete yet.
Attached is a patch that implements these options in mkfontscale, as
well as improving slightly the semantics of mkfontdir. Also fix two
pre-processor bugs in X11.tmpl that cause imake warnings.
Kean
Index: config/cf/X11.tmpl
===
RCS file: /cvs/xc/config/cf/X11.tmpl,v
retrieving revision 1.208
diff -u -r1.208 X11.tmpl
--- config/cf/X11.tmpl 2003/06/27 14:53:08 1.208
+++ config/cf/X11.tmpl 2003/06/30 14:52:33
@@ -3823,7 +3823,7 @@
#endif
#endif
-#ifndef MakeTblHtmlDoc(file,srcs)
+#ifndef MakeTblHtmlDoc
#ifdef HTMLroffCmd
#define MakeTblHtmlDoc(file,srcs) @@\
file.html: srcs@@\
@@ -3835,7 +3835,7 @@
#endif
#endif
-#ifndef MakeEqnHtmlDoc(file,srcs)
+#ifndef MakeEqnHtmlDoc
#ifdef HTMLroffCmd
#define MakeEqnHtmlDoc(file,srcs) @@\
file.html: srcs@@\
Index: programs/mkfontscale/mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.7
diff -u -r1.7 mkfontscale.c
--- programs/mkfontscale/mkfontscale.c 2003/06/20 15:49:52 1.7
+++ programs/mkfontscale/mkfontscale.c 2003/06/30 14:52:35
@@ -74,21 +74,24 @@
#define countof(_a) (sizeof(_a)/sizeof((_a)[0]))
-int doDirectory(char*, int, ListPtr);
+static int doDirectory(char*, int, ListPtr);
static int checkEncoding(FT_Face face, char *encoding_name);
static int checkExtraEncoding(FT_Face face, char *encoding_name, int found);
static int find_cmap(int type, int pid, int eid, FT_Face face);
static char* notice_foundry(char *notice);
static char* vendor_foundry(signed char *vendor);
-int readFontScale(HashTablePtr entries, char *dirname);
+static int readFontScale(HashTablePtr entries, char *dname);
ListPtr makeXLFD(char *filename, FT_Face face, int);
+static int readEncodings(ListPtr encodings, char *dname);
static FT_Library ft_library;
static float bigEncodingFuzz = 0.02;
+static int relative;
static int doScalable;
static int doBitmaps;
-static int doEncodings;
+static int onlyEncodings;
+static int onlyEncodings;
static ListPtr encodingsToDo;
static int reencodeLegacy;
char *encodingPrefix = NULL;
@@ -99,7 +102,7 @@
fprintf(stderr,
mkfontscale [ -b ] [ -s ] [ -o filename ] \n
[ -x encoding ] [ -f fuzz ] [ -l ]
-[ -e directory ] [ -p prefix ]\n
+[ -e directory ] [ -p prefix ] [ -n ] [ -r] \n
[ directory ]...\n);
}
@@ -108,7 +111,7 @@
{
int argn;
FT_Error ftrc;
-int rc;
+int rc, ll = 0;
char prefix[NPREFIX];
if(getcwd(prefix, NPREFIX - 1) == NULL) {
@@ -127,8 +130,9 @@
NULL, 0);
doBitmaps = 0;
doScalable = 1;
+onlyEncodings = 0;
+relative = 0;
reencodeLegacy = 1;
-doEncodings = 0;
encodingsToDo = NULL;
argn = 1;
@@ -161,7 +165,6 @@
usage();
exit(1);
}
-doEncodings = 1;
rc = readEncodings(encodingsToDo, argv[argn + 1]);
if(rc 0)
exit(1);
@@ -172,6 +175,12 @@
} else if(strcmp(argv[argn], -s) == 0) {
doScalable = 0;
argn++;
+} else if(strcmp(argv[argn], -n) == 0) {
+onlyEncodings = 1;
+argn++;
+} else if(strcmp(argv[argn], -r) == 0) {
+relative = 1;
+argn++;
} else if(strcmp(argv[argn], -l) == 0) {
reencodeLegacy = !reencodeLegacy;
argn++;
@@ -209,13 +218,14 @@
fprintf(stderr, Could not initialise FreeType library: %d\n, ftrc);
exit(1);
}
-
+ll = listLength(encodingsToDo);
+
if (argn == argc)
-doDirectory(., doEncodings, encodingsToDo);
+doDirectory(., ll, encodingsToDo);
else
while(argn argc) {
-doDirectory(argv[argn], doEncodings, encodingsToDo);
+doDirectory(argv[argn], ll, encodingsToDo);
argn++;
}
return 0;
@@ -625,10 +635,10 @@
return xlfd;
}
-int
-readFontScale(HashTablePtr entries, char *dirname)
+static int
+readFontScale(HashTablePtr entries, char *dname)
{
-int n = strlen(dirname);
+int n = strlen(dname);
char *filename;
FILE *in;
int rc, count, i;
@@ -638,10 +648,10 @@
snprintf(format, 100, %%%ds %%%d[^\n]\n,
MAXFONTFILENAMELEN, MAXFONTNAMELEN);
-if(dirname[n - 1] == '/')
-filename = dsprintf(%sfonts.scale, dirname);
+if(dname[n - 1] == '/')
+filename = dsprintf(%sfonts.scale, dname);
else
-
Re: X11.tmpl wrong for mkfontscale/dir ?
Kean Johnston wrote: Attached is a patch that implements these options in mkfontscale, as well as improving slightly the semantics of mkfontdir. Also fix two pre-processor bugs in X11.tmpl that cause imake warnings. By the way this patch changes (as you can see) the variable dirname to dname, as some systems define a function called dirname, and this produces extra warnings if you use -Wshadow. Also, I dont think this addresses the issue of fonts.alias not being read. Seems like mkfontdir uses the FontFile library, which handles this. mkfontscasle doesn't (at least at a cursory glance). I think I'll move onto other things now and let the font experts take over on this ... Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Keybaord handled differently under xdm - why?
This gets even weirder. If I use xdm I cant even use setxkbmap blah | xkbcomp blah - $DISPLAY ... even that doesn't work. There is something fundamentally funky about xdm and keyboard maps. Is no-one else experiencing this? I am sitting at a shell prompt, typing xdm, and logging in. Whether as root or non-root makes no difference. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Keybaord handled differently under xdm - why?
My guess is that xkbcomp is failing in one case and not the other. How can I tell? There's nothing in the log file, and I replaced xkbcomp with a shell script that invoked the real binary and it seems to be getting the right arguments. But no matter what, the X server that xdm is invoking is setuid root, so not matter what tricks xdm pulls, the server should still be able to start up correctly, or am I missing something fundamental here? One thing of interest I did note in the log files when running under xdm versus using startx. I get warnings from the transport layer saying it doesn't know how to handle protocol family 0. I am going to diagnose that particular problem later. Any other clues you may offer, or can you educate me how to get debugging output relating to xkb? Thanks. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Maximum number of clients?
MAXCLIENTS is defined in xc/programs/Xserver/include/misc.h It's currently 256. Available fds would be another limiting factor. The client ID and the resource ID share 29 bits of the XIDs, so beware that doubling the number of client IDs will half the number of resources available to each client. Many thanks Mark. Is this a limitation that is possible or likely to be addressed in the future? I know 256 clients sounds like a lot but we have had many complaints from customers that its not. Lord knows what they're doing. Since I am just an X porter and not a real X hacker, I don't understand the rammifications of halving the resource ID's. At 256 clients, that's 8 bits for the client ID and 21 bits bits for the resource ID. If we increased the client limit to 512, using 9 bits for the client ID and 20 bits for the resource ID, that would leave 2^20 resource IDs. Since I don't really know how often and when resource IDs are used, I don't know if that is sufficient for most apps. If not I guess I'll have to live with the 256 client limitation. Can you venture an opinion on how many resource IDs are likely to be used, even by a large client? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Linux whining (was Re: xterm and UTF8)
I'm sure it gives you a hardon to bash Linux, but you're being intellectually dishonest. For openers, sexual references are inappropriate. This is a list of professionals, and it ill behoves you to not treat us that way. Secondly, I was in *NO WAY* bashing Linux. I am a HUGE fan of open source and have spent a large number of hours contributing to open source projects and trying to convince a not invented here company to accept more of it in their products. I was making a commentary on badly written *APPLICATIONS* that are very Linux-centric yet still trying to claim portability. That was the sum total of my gripe. GNOME and KDE applications are running successfully on Solaris, FreeBSD, and many other platforms. Sun is actively working on a desktop based on these Linux-centric applications. GNOME and KDE are in *NO WAY* Linux-centric. In fact they are shining examples of how software CAN be portable and how to do it right. You're just as bad as some of my friends, ignorantly bashing Microsoft without any real knowledge. Take your ignorance elsewhere. If I felt you were in any way qualified to make any kind of judgement about my level of ignorance or not, I may take offence. But since you seem to be a reactionary with an axe to grind or an over-inflated sense of defensiveness (is that a word?) towards Linux I will take it from whence it comes. In future, I strongly recommend you read what is actually writen, make an attempt to discern that was intended if the meaning was ambiguous, and inquire as to that intent before running your mouth. This is not the place for this discussion so I shall not continue it here further. If you feel the need for a flame war please respond to me privately. Have a nice timezone. Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: RELNOTES for 4.3.0
Please add: * Major SCO OpenServer Updates Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
