error while closing connection
i get the following error when i call XCloseDisplay(dpy) at the end of a program (dpy is a valid display) received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 85 error_code 2 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) does anybody know what it can be due to? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Subject: Problems with DMC touch screen driver (FIT-10 controller).
I have a problem with the DMC touch screen driver. Almost everything is working fine except clicking a button. I think the reason is that XFree86 doesnt get a ButtonRelease event after releasing the button (touch screen). I conclude this from the events that occur. Example nr1: If I push a button, the button keeps pushed-down until I push on another location. Normally with a mouse you push the left mouse button and if you dont release the left mouse button, the button on the screen will be pushed down. Example nr2: If I want to drag a window I push and hold the window and drag it over the screen. When I release the window (I stop pushing the touch screen) I can move the window by using a mouse without touching any buttons from the mouse. I think XFree86 didnt get a ButtonRelease event because it is still reacting like someone pushed and hold the left button to drag a window. Physically nobody is touching the buttons from the mouse or touching the touch screen. Congiguration of the system: XFree86 4.3.0 glibc21 /etc/X11/XF86Config Section InputDevice Identifier touchscreen0 Driver dmc Option Device /dev/ttyS0 Option MinX 74 Option MaxX 990 Option MinY 960 Option MaxY 43 Option ScreenNumber 0 Option ReportingMode Scaled Option ButtonNumber 1 Option SendCoreEvents Option ClickMode 1 EndSection Section ServerLayout # The Identifier line must be present Identifier Simple Layout # Each Screen line specifies a Screen section name, and optionally # the relative position of other screens. The four names after # primary screen name are the screens to the top, bottom, left and right # of the primary screen. In this example, screen 2 is located to the # right of screen 1. Screen Screen 1 # Each InputDevice line specifies an InputDevice section name and # optionally some options to specify the way the device is to be # used. Those options include CorePointer, CoreKeyboard and # SendCoreEvents. InputDevice touchscreen0 SendCoreEvents InputDevice Mouse1 CorePointer InputDevice Keyboard1 CoreKeyboard EndSection I appreciate any help on this subject. Marcel van der Veen
Re: error while closing connection - forget it its fixed (thx anyway)
-- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
nautilus root window
i have been trying to paint on the root window, i am using an include file (vroot.h) that defines a function to get the virtual root window the window manager sets but i guess nautilus puts another window on top of that one because i can only see the canges when i stop nautilus, doe sanybody know how to get nautilus' root window? thx -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
nautilus window
to get the nautilus root window i tried to use the NAUTILUS_DESKTOP_WINDOW_ID property, y get a pointer to the root of the data but then i dont know what to do with that, i tired mywindow = *((Window*)data_root); but it doesnt wqork, could anybody give me a hand on this -- ___ 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: nautilus root window
try your query on Nautilus-devel (http://www.gnome.org). one of the nautilus developers should be able to answer your question. Alex --- Daniel Godas Lopez [EMAIL PROTECTED] wrote: i have been trying to paint on the root window, i am using an include file (vroot.h) that defines a function to get the virtual root window the window manager sets but i guess nautilus puts another window on top of that one because i can only see the canges when i stop nautilus, doe sanybody know how to get nautilus' root window? thx -- __ 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: 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: Dell C400 fix applied to 855GM?
Thanks a bunch for the update Hope! In the mean time, I've resorted to using debian as the guest OS in VMWare, works out pretty nicely in fact. (I get to use the 802.11g card, and XP's suspend/hibernate/power management! =) -Oliver 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 Intel's 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. Best regards, Hope Merritt, III Intel Corporation Software Applications Engineer Desk: 916-356-0936 Text: [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: aid for TODO tasks offered
As I was the one who pointed you to this list I think I should answer this: If you woul like to do driver work there is a list of drivers which are little maintained at the moment. This list incudes: i740 i810 rendition tseng cirrus (alpine and laguna) s3 (not s3Virge or savage) silicon motion (I don't know who currently maintains the i128 and r128) Of those listed above the last three - especially the silicon motion - are the most importand ones. If you'd like to you can pick one of those and play with them. This of course depends on which HW is available to you. Egbert. Lucas Correia Villa Real writes: Hi, I have been reading the XFree86 X server draft found in http://www.xfree86.org/current/design.html. Firstly, I would like to thanks for the excellent quality of the documentation seen there. Secondly, I would like to know if is there something I can aid on TODO tasks, such as some driver needing major assistance. As an undergraduate student, I still can enjoy my spare time doing these cool things :) Actually, all I did was recursivelly grep for TODO on hw/xfree86/drivers and choose one of the results to implement (I did choose the easiest one, recognize when CLGD7548 has 2MBs of RAM, just to get in touch with the code), but I wonder if is there something else not marked as TODO needing more attention. Moreover, I have some personal projects I would like to do with video cards, such as adding asymmetric multiprocessing support to the Linux kernel by using some video card instructions (vectorial ones) instead of using CPU cycles to do that, hence my major interest is to aid on video drivers. Also, given this subject, if someone can suggest me a good card with available specs I could give a look on, I will be very glad. Thanks in advance, Lucas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re : aid for TODO tasks offered
On 2003.06.30 12:55, Egbert Eich wrote: As I was the one who pointed you to this list I think I should answer this: If you woul like to do driver work there is a list of drivers which are little maintained at the moment. This list incudes: i740 i810 rendition tseng cirrus (alpine and laguna) s3 (not s3Virge or savage) silicon motion (I don't know who currently maintains the i128 and r128) Of those listed above the last three - especially the silicon motion - are the most importand ones. If you'd like to you can pick one of those and play with them. This of course depends on which HW is available to you. Thanks, I will put this on the XJANITOR page. Bye Manu pgp0.pgp Description: PGP signature
Re: Dell C400 fix applied to 855GM?
why aren't the windows drivers affected? they must be a way around it without needing a new bios... The same thing was claimed the last time around with the 830s and dell never fixed the bios, but someone came up with a work around. Alex --- Hope Merritt [EMAIL PROTECTED] 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 Intel#8217;s 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. Best regards, Hope Merritt, III Intel Corporation Software Applications Engineer Desk: 916-356-0936 Text: [EMAIL PROTECTED] __ 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
bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
There is a report in bugzilla (#439) which claims: the bug is in xc/lib/GL/glx/glxcmds.c int bufSize = XMaxRequestSize(dpy) * 4; should be int bufSize = XMaxRequestSize(dpy) * 4 - 8; or more cleanly int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq); it happens that you may completely fill your GLX buffer if you use variable size command larger than 156 bytes (and smaller than 4096 bytes) in that case you find yourself with an X command larger than 256Kbytes. This is very unlikely but possible. It explain why this bug has not shown itself before in this very old SGI code. I've briefly looked at the code and it seems to be correct. However I would like to double check before I commit anything. Any opinions? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
imake template to install files from a third directory
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? Thanks in advance! -- Alexander Pohoyda [EMAIL PROTECTED] Imake.rules.diff Description: Binary data
How to calculate the SIZE tag of a font encodings file?
1. How is the SIZE tag of a font encodings files calculated? I cannot find any documentation how to to calculate it from a unicode mapping table 2. Why is the SIZE tag needed at all ? The Sun encodings format works happily without it... :-) Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen Sie mit! Nutzen Sie den Serien-Testsieger. http://user.web.de/Regenwald ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Egbert Eich wrote: There is a report in bugzilla (#439) which claims: the bug is in xc/lib/GL/glx/glxcmds.c int bufSize = XMaxRequestSize(dpy) * 4; should be int bufSize = XMaxRequestSize(dpy) * 4 - 8; or more cleanly int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq); it happens that you may completely fill your GLX buffer if you use variable size command larger than 156 bytes (and smaller than 4096 bytes) in that case you find yourself with an X command larger than 256Kbytes. This is very unlikely but possible. It explain why this bug has not shown itself before in this very old SGI code. I've briefly looked at the code and it seems to be correct. However I would like to double check before I commit anything. Any opinions? I'm not sure this is correct. bufSize is used to allocate the buffer (gc-buf in the code) that will hold the commands, including the xGLXRenderReq header. I've been doing a lot of work lately on the GLX code (both client-side server-side) in the DRI tree lately. I'll take a look at this a bit more and get back to you. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
well, yeah. My point was that intel should just release a patch to fix the driver (or specs to let us fix it) rather than fixing the bios and making us wait for dell to (possibly) update the bios. Alex --- Mike A. Harris [EMAIL PROTECTED] wrote: Simple. Because the Windows drivers have workarounds built into them which manually program the chipset to do what the BIOS should, but is not doing. Why do they just work in Windows? Because 95% of the desktop market is Windows, and the various companies involved have a lot of money tied up in making sure things just work the first time they hit the public eye the majority of time. As such problems like this are fixed in Windows-land long before end users ever realize there was a problem that needed to be fixed. In the land of OSS however, we do not have that same status. We get specifications for hardware long after the fact if ever from the majority of video hardware companies, and when someone releases hardware with a broken BIOS that needs software driver workarounds, someone needs to know what the exact problem is, and then also have access to the specifications to know how to code those workarounds, and also have the hardware in question in order to test it. So it is no surprise that what works in Windows is not any form of indicator of what works in XFree86. They are 2 different environments, not privy to the same amount of technical information as each other, and with very different number of manpower working on each, and with IHV pressure also being quite different for each. -- Mike A. Harris __ 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: aid for TODO tasks offered
On Mon, 2003-06-30 at 18:55, Egbert Eich wrote: (I don't know who currently maintains the i128 and r128) AFAIK Kevin E. Martin still maintains the r128 driver. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bugzilla #439: bufSize in lib/GL/glx/glxcmds.c can be too large.
Ian Romanick wrote:
Egbert Eich wrote:
There is a report in bugzilla (#439) which claims:
the bug is in xc/lib/GL/glx/glxcmds.c int bufSize =
XMaxRequestSize(dpy) * 4;
should be int bufSize = XMaxRequestSize(dpy) * 4 - 8;
or more cleanly
int bufSize = XMaxRequestSize(dpy) * 4 - sizeof(xGLXRenderReq);
it happens that you may completely fill your GLX buffer if you use
variable size command larger than 156 bytes (and smaller than 4096 bytes)
in that case you find yourself with an X command larger than
256Kbytes. This
is very unlikely but possible. It explain why this bug has not shown
itself
before in this very old SGI code.
I've briefly looked at the code and it seems to be correct.
However I would like to double check before I commit anything.
Any opinions?
I'm not sure this is correct. bufSize is used to allocate the buffer
(gc-buf in the code) that will hold the commands, including the
xGLXRenderReq header. I've been doing a lot of work lately on the GLX
code (both client-side server-side) in the DRI tree lately. I'll take
a look at this a bit more and get back to you.
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.
Index: glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/glxcmds.c,v
retrieving revision 1.44
diff -u -d -r1.44 glxcmds.c
--- glxcmds.c 25 Jun 2003 00:39:58 - 1.44
+++ glxcmds.c 30 Jun 2003 20:49:15 -
@@ -198,7 +261,7 @@
GLXContext AllocateGLXContext( Display *dpy )
{
GLXContext gc;
- int bufSize = XMaxRequestSize(dpy) * 4;
+ int bufSize;
CARD8 opcode;
if (!dpy)
@@ -217,7 +280,14 @@
}
memset(gc, 0, sizeof(struct __GLXcontextRec));
-/* Allocate transport buffer */
+/*
+** Create a temporary buffer to hold GLX rendering commands. The size
+** of the buffer is selected so that the maximum number of GLX rendering
+** commands can fit in a single X packet and still have room in the X
+** packed to for the GLXRenderReq header.
+*/
+
+bufSize = (XMaxRequestSize(dpy) * 4) - sz_xGLXRenderReq;
gc-buf = (GLubyte *) Xmalloc(bufSize);
if (!gc-buf) {
Xfree(gc);
2003_06_30 mkfontscale creates encodings.dir in wrong order
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.c 2003/06/20 15:49:52 1.7
+++ mkfontscale.c 2003/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);
Re: Dell C400 fix applied to 855GM?
On Mon, 30 Jun 2003, Alex Deucher wrote: Date: Mon, 30 Jun 2003 09:55:44 -0700 (PDT) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Dell C400 fix applied to 855GM? why aren't the windows drivers affected? they must be a way around it without needing a new bios... The same thing was claimed the last time around with the 830s and dell never fixed the bios, but someone came up with a work around. Simple. Because the Windows drivers have workarounds built into them which manually program the chipset to do what the BIOS should, but is not doing. Why do they just work in Windows? Because 95% of the desktop market is Windows, and the various companies involved have a lot of money tied up in making sure things just work the first time they hit the public eye the majority of time. As such problems like this are fixed in Windows-land long before end users ever realize there was a problem that needed to be fixed. In the land of OSS however, we do not have that same status. We get specifications for hardware long after the fact if ever from the majority of video hardware companies, and when someone releases hardware with a broken BIOS that needs software driver workarounds, someone needs to know what the exact problem is, and then also have access to the specifications to know how to code those workarounds, and also have the hardware in question in order to test it. So it is no surprise that what works in Windows is not any form of indicator of what works in XFree86. They are 2 different environments, not privy to the same amount of technical information as each other, and with very different number of manpower working on each, and with IHV pressure also being quite different for each. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
