update window
i have changed the background picture of the desktop window, but i dont know how to tell it to update, after changing it if i move a window on top of the desktop, as i move it behind the window appears the right background (cause moving the window i force that zone to repaint), how can i tell the whole window to repaint itself so the new wallpaper shows up? -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
David Dawes writes: 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). The truth is that we don't know what MGA HAL does exactly. It does a lot of initialization stuff when it is called in PreInit()(!) and it sets up video modes differently than the OpenSource code does. In some cases it does the wrong thing so I had to add a lot of workarounds. In some other cases it does a better job - for example when setting up a video mode for flat panels. We could try to make the OpenSource driver better so we didn't have to use the HAL library any more - this however isn't really feasable without detailed docs on the chipsets and I don't think anybody is into register dumping and comparing. 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. Yes, it does a lot more than just enable the secondary display on a G400. 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. Probably not. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
--- Egbert Eich [EMAIL PROTECTED] wrote: The truth is that we don't know what MGA HAL does exactly. It does a lot of initialization stuff when it is called in PreInit()(!) and it sets up video modes differently than the OpenSource code does. In some cases it does the wrong thing so I had to add a lot of workarounds. In some other cases it does a better job - for example when setting up a video mode for flat panels. We could try to make the OpenSource driver better so we didn't have to use the HAL library any more - this however isn't really feasable without detailed docs on the chipsets and I don't think anybody is into register dumping and comparing. Actually you could probably replace the HAL functionality by using the linux matrox framebuffer driver or directfb driver as a reference. it exposes just about all the functionality of the Gxxx driver (tv out, flatpanel, YUV modes on the second crtc). Alex __ 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
Juliusz Chroboczek writes: 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. No problem. I guess it was my mistake. So far submitted code was thoroughly tested and often heavily modified by the committers. This has delayed code commit and loaded a overly hard burdeon on the person who did the commit (in the majority of cases David, but also Alan, Marc and others). I would like to get to a situation where the submitter himself takes over more responsibilities and takes his code to a committable state - if necessary accompanied by an experienced developer. This would also mean that I'd expect from a contributor with your expertise to only submit code he has given some testing himself unless he says otherwise. Of course, everybody makes mistakes - I have done a lot lately - there may always be bugs that fell thru the cracks and nobody expects submitters to test their code on several different platforms before submitting. You could not know that I would make these assumptions. 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. Sure, I know this situation. 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 take a look at this later, thanks. I'll try to be even more cautious in the future. Thanks :-) Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xinerama on GeForce4 cards?
Hi Guys! We are trying to figure out how to get Dual Head working on the NVIDIA NV driver that is included in XFree86. From looking at the code, it would appear dual head mode is supposed to work; is that correct? If so, what graphics chipsets should it work on? We have figured out how to configure the XF86Config file to enable Xinerama on a Matrox G450 (with the help of SuSE's SaX2), however using the same basic config file for the GeForce4 MX440, XFree86 fails to start with the error message Requested entity already in use!. We are going to try the binary NVIDIA driver to see if that performs any differently, but perhaps we are configuring XFree86 incorrectly for this card? If dual head does work, can someone send me a working XF86Config file for 4.3.0 that enables Xinerama on the GeForce4 MX440? Thanks! --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ 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
Re: Xinerama on GeForce4 cards?
On Wed, 2 Jul 2003, Kendall Bennett wrote: Hi Guys! We are trying to figure out how to get Dual Head working on the NVIDIA NV driver that is included in XFree86. From looking at the code, it would appear dual head mode is supposed to work; is that correct? Not at all. It only supports one head. While the driver can be configured to use one or the other, it will only work on the head that was posted because it relies on the BIOS to do much of the HW setup. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Kean Johnston writes:
Yes, if we don't have an improved version by the end of the week
I will revert this.
I didnt see any comment on my message ... did you see my patch from
yesterday that implements the -r and -n options?
I'm sorry I have overlooked your posting.
I've combined Juliusz's and your patch.
Juliusz, Kean, please check below and tell me if it does what you expect.
Egbert.
Index: config/cf/X11.tmpl
===
RCS file: /home/x-cvs/xc/config/cf/X11.tmpl,v
retrieving revision 1.208
diff -u -r1.208 X11.tmpl
--- config/cf/X11.tmpl 27 Jun 2003 14:53:08 - 1.208
+++ config/cf/X11.tmpl 2 Jul 2003 19:16:40 -
@@ -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: /home/x-cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.9
diff -u -r1.9 mkfontscale.c
--- programs/mkfontscale/mkfontscale.c 1 Jul 2003 13:05:34 - 1.9
+++ programs/mkfontscale/mkfontscale.c 2 Jul 2003 19:16:52 -
@@ -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 *dirname);
ListPtr makeXLFD(char *filename, FT_Face face, int);
+static int readEncodings(ListPtr encodings, char *dirname);
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) {
@@ -117,6 +120,7 @@
}
if(prefix[strlen(prefix) - 1] != '/')
strcat(prefix, /);
+encodingPrefix = dsprintf(%s, prefix);
outfilename = NULL;
@@ -127,8 +131,9 @@
NULL, 0);
doBitmaps = 0;
doScalable = 1;
+onlyEncodings = 0;
+relative = 0;
reencodeLegacy = 1;
-doEncodings = 0;
encodingsToDo = NULL;
argn = 1;
@@ -154,14 +159,14 @@
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) {
usage();
exit(1);
}
-doEncodings = 1;
rc = readEncodings(encodingsToDo, argv[argn + 1]);
if(rc 0)
exit(1);
@@ -172,6 +177,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++;
@@ -199,8 +210,6 @@
}
}
-encodingPrefix = dsprintf(%s, prefix);
-
if(outfilename == NULL) {
if(doBitmaps)
outfilename = fonts.dir;
@@ -213,13 +222,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);
Re: Xinerama on GeForce4 cards?
Mark Vojkovich [EMAIL PROTECTED] wrote: We are trying to figure out how to get Dual Head working on the NVIDIA NV driver that is included in XFree86. From looking at the code, it would appear dual head mode is supposed to work; is that correct? Not at all. It only supports one head. While the driver can be configured to use one or the other, it will only work on the head that was posted because it relies on the BIOS to do much of the HW setup. Ok. Our code is actually working with dual head on the NVIDIA cards provided that the BIOS has posted both heads to run in clone mode. On some cards the BIOS does not post the second head and only one head comes up, and the riva_hw.c module is not able to initialise the second head. I guess we are stuck in that case ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Dr Andrew C Aitchison wrote: 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 Weired. I don't see that problem when running mkfontscale (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... 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-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xinerama on GeForce4 cards?
I don't suppose you can contribute your code back? I've sure someone could get it working in due time. Alex --- Kendall Bennett [EMAIL PROTECTED] wrote: Mark Vojkovich [EMAIL PROTECTED] wrote: We are trying to figure out how to get Dual Head working on the NVIDIA NV driver that is included in XFree86. From looking at the code, it would appear dual head mode is supposed to work; is that correct? Not at all. It only supports one head. While the driver can be configured to use one or the other, it will only work on the head that was posted because it relies on the BIOS to do much of the HW setup. Ok. Our code is actually working with dual head on the NVIDIA cards provided that the BIOS has posted both heads to run in clone mode. On some cards the BIOS does not post the second head and only one head comes up, and the riva_hw.c module is not able to initialise the second head. I guess we are stuck in that case ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ 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: Xinerama on GeForce4 cards?
On Wed, 2 Jul 2003, Kendall Bennett wrote: Mark Vojkovich [EMAIL PROTECTED] wrote: We are trying to figure out how to get Dual Head working on the NVIDIA NV driver that is included in XFree86. From looking at the code, it would appear dual head mode is supposed to work; is that correct? Not at all. It only supports one head. While the driver can be configured to use one or the other, it will only work on the head that was posted because it relies on the BIOS to do much of the HW setup. Ok. Our code is actually working with dual head on the NVIDIA cards provided that the BIOS has posted both heads to run in clone mode. On some cards the BIOS does not post the second head and only one head comes up, and the riva_hw.c module is not able to initialise the second head. I guess we are stuck in that case ;-) This would be the expected behavior. You can run either head if the card was posted in clone mode. You can probably even run CRTs on the secondary head, but DFP will only work if it was posted. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
