The fail_pattern.jpg looks like the driver incorrectly sets the HARDWARE_PATTERN_SCREEN_ORIGIN flag. See section 2.6 of xc/programs/Xserver/hw/xfree86/xaa/XAA.HOWTO Mark. On Mon, 28 Aug 2006, cckuo wrote: > Sorry for late replying this letter. > The option "XaaNoMono8x8PatternFillRect" did solve my problem, and I have my > HW colleague to download the pattern as the attach file,fail_pattern.jpg, > that XAA pass to me by infoPtr->SetupForMono8x8PatternFill, the call back > function I register during XAA initialization. > > As you can see the black two 't' in "fail_pattern.jpg" is quite similar to > the bug I mention in Debian3.1.jpg (You can flip the black 't' vertically > and compare it with the "start" button in Debian3.1.jpg). > > According to this pattern simulation, the text looks like already dirty > before passing to the driver. If it really is, the bug will also happen when > I set the option, XaaNoMono8x8PatternFillRect. > Right now I am trying to patch the XFree4.3.01 to 4.3.0.2 by > 4.3.0.1-4.3.0.2.diff.gz, the file I download from > ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/ > I type "gzip -d < 4.3.0.1-4.3.0.2.diff.gz |patch -p0 -E", but it says it > cannot find the file to patch in line 5. Below are the messages I occur, > > > can't find file to patch at input line 5 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -------------------------- > |Index: xc/config/cf/Imake.tmpl > |diff -u xc/config/cf/Imake.tmpl:3.139 xc/config/cf/Imake.tmpl:3.139.2.1 > |--- xc/config/cf/Imake.tmpl:3.139 Tue Jan 28 17:06:08 2003 > |+++ xc/config/cf/Imake.tmpl Sun Feb 8 20:58:52 2004 > -------------------------- > File to patch: > > Did I use the wrong command or I need to download some other file to finish > the patch? > Meanwhile, If it is not the HW bug, what is the next proper step I should do > to clarify this bug, tracing the application, rdesktop, or some component in > XFree86? > > Appreciate your help very much. > Sincerely Yours, > cckuo > > > > -----Original Message----- > From: xfree86-admin@xxxxxxxxxxx [mailto:xfree86-admin@xxxxxxxxxxx] On Behalf > Of Mark Vojkovich > Sent: Monday, August 07, 2006 2:37 AM > To: cckuo > Cc: xfree86@xxxxxxxxxxx > Subject: RE: Will the behaviors of XFree86 be effected by > different kernel? > > On Sun, 6 Aug 2006, cckuo wrote: > > > Thanks for your help. > > I closed all the CPUToScreenColorExpand I report to XAA. But the text is > > still blurred, so I mark the callback functions one by one and the text > > become clear until unmarked the 8x8 mono pattern fill. > > Does that mean the application like "remotedesktop" can have different > > choice to draw the text on the screen? > > There are a lot of ways that text can be drawn. Does > Option "XaaNoMono8x8PatternFillRect" also solve your problem? If > so, it sounds like the 8x8 pattern fill hardware isn't working > correctly, or as expected in this case. > > > > By the way, would you please tell me what " the card is in the POSTed > > State" mean? Is that a state I can read from somewhere else or some > > procedure the driver have to follow? > > By POST (Power On Self Test, I think), I mean the state into which > the VBIOS put the card. In the presence of a kernel framebuffer device > it's not valid to assume that the card is in the same state that the > VBIOS initialized. The kernel framebuffer driver may have changed > some things since the VBIOS initialized the card. Often, graphics > drivers don't full initialize the card because they assume that the > VBIOS would have done some of the basic initializations already. > > Did you try without a kernel framebuffer device? > > Mark. > > > > > Appreciate your help very much, > > cckuo > > > > -----Original Message----- > > From: xfree86-admin@xxxxxxxxxxx [mailto:xfree86-admin@xxxxxxxxxxx] On > Behalf > > Of Mark Vojkovich > > Sent: Saturday, August 05, 2006 12:53 AM > > To: cckuo > > Cc: xfree86@xxxxxxxxxxx > > Subject: RE: Will the behaviors of XFree86 be effected by > > different kernel? > > > > On Fri, 4 Aug 2006, cckuo wrote: > > > > > Thanks for your reply. > > > > > > I rmmod the fb module and try again, and I found the text blur still > > occur. > > > I will rebuild a new kernel without fb inside and try it again. > > > > > > By the way, I think I may give wrong description about #3. The > "disappear" > > I > > > mean in #3 is the text blur will not happen while using "xinit' to > > activate > > > Xserver. And I don't mean the whole screen will disappear. I am sorry > > about > > > that. > > > > > > > > > > > > I also done some test about decreasing the size of memory I pass to > > > xf86InitFBManager function call. The text blur will be normal when the > > size > > > is below 4Mb. I know this size control the number of different slots > > created > > > by XAAInitPixmapCache. Since the driver didn't report any HW > accelerations > > > about characters, I guess the text part of the picture may be taken as > > some > > > pixmaps and call HW bitblt function to move it from offscreen to > onscreen. > > > If my assumption is correct, would you please tell me what functions in > > XAA > > > take charge of text such that I can trace the command made by that > > function > > > to check whether the content of offscreen pixmaps are already wrong or > the > > > HW blur it during bitblt. > > > > Most simple text is rendered with the CPUToScreenColorExpand functions. > > Anti-aliased text or some other text used by the RENDER extension > > is rendered with the CPUToScreenAlphaTexture or CPUToScreenTexture > > functions. > > > > > > Mark. > > > > > > > > > > > > > > > > > > Thanks for your help very much, > > > > > > cckuo > > > > > > > > > > > > -----Original Message----- > > > > > > From: xfree86-admin@xxxxxxxxxxx [mailto:xfree86-admin@xxxxxxxxxxx] On > > Behalf > > > Of Mark Vojkovich > > > > > > Sent: Friday, August 04, 2006 1:12 AM > > > > > > To: cckuo > > > > > > Cc: xfree86@xxxxxxxxxxx > > > > > > Subject: RE: Will the behaviors of XFree86 be effected by > > > different kernel? > > > > > > > > > > > > Most likely, part of the offscreen video memory that the driver > > > > > > told XAA it could use for pixmap caching is not accessible so things > > > > > > placed there disappear. The order in which things are started > > > > > > determines the packing order of offscreen pixmaps so that's why > > > > > > #3 changes which things disappear. Most likely it is an interaction > > > > > > with a kernel framebuffer device. Namely, the kernel framebuffer > > > > > > device is setting some graphics card state that prevents all the > > > > > > videoram from being accessible and the XFree86 driver is unaware > > > > > > of this. This is unlikely to be an XAA issue. > > > > > > > > > > > > If the XFree86 driver is assuming the card is in the POSTed > > > > > > state, that may be a bad assumption in light of a kernel framebuffer > > > > > > device. You might want to check what the kernel framebuffer > > > > > > device is doing with regards to video memory partitions, etc... > > > > > > > > > > > > Mark. > > > > > > > > > > > > On Thu, 3 Aug 2006, cckuo wrote: > > > > > > > > > > > > > Sorry for late replying your email. > > > > > > > The situation is attached as the picture and we use the "rdesktop", a > > > remote > > > > > > > connect tool to control English Server 2003, the text part will be > > broken. > > > > > > > 1. After setting the option "XaaNoOffscreenPixmaps" or > > > > > > > "XaaNoScreenToScreenCopy" I can't reproduce the problem. I know these > > two > > > > > > > option will let the XAA determine whether it can call the call back > > > > > > > functions that driver registered in the beginning. > > > > > > > > > > > > > > 2. If I reduce the memory size reported to FBmanager, less than 4Mb, > it > > > will > > > > > > > also disappear. I know this behavior will let the XAA generate less > big > > > > > > > slots. > > > > > > > > > > > > > > 3. if I use xinit instead of windows manager to activate the Xserver, > > > > > > > execute "rdesktop" in xterm. It will disappear. > > > > > > > > > > > > > > 4. So far it only happens on the English Server 2003, and English XP > is > > > OK. > > > > > > > > > > > > > > 5. use kernel 2.4.X it will disappear, but kernel 2.6.X will fail. > > > > > > > I am right now studying the source codes to realize the relationships > > > > > > > between 1 and 2. > > > > > > > But I really confuse why the 3, 4 and 5 will happen. > > > > > > > I am not quite sure whether it was a bug of XAA, the windows manager > or > > > even > > > > > > > the driver's fault. But from 3, I guess it may not driver's fault. > > > > > > > > > > > > > > If you have any opinions about this bug, please let me know. > > > > > > > > > > > > > > Appreciate your help in advance. > > > > > > > Sincerely Yours, > > > > > > > cckuo > > > > > > > > > > > > > > > > > > > > > To: cckuo > > > > > > > Cc: xfree86@xxxxxxxxxxx > > > > > > > Subject: Re: Will the behaviors of XFree86 be effected by > > > > > > > different kernel? > > > > > > > > > > > > > > > > > > > > > I wouldn't expect the behavior of an XFree86 graphics driver to > > > > > > > change with a kernel except for, perhaps, something related to 3D > > > > > > > using the DRI. I suppose it's also possible that a kernel > > > > > > > framebuffer device could interfere with an xfree86 driver in some > > > > > > > way. The XFree86 sis driver has a "NoAccel" option you can use to > > > > > > > force software rendering. If there is still rendering corruption > > > > > > > with that option, that would suggest that it's not a driver > > > > > > > acceleration problem. > > > > > > > > > > > > > > Mark. > > > > > > > > > > > > > > > > > > > > > cckuo wrote: > > > > > > > > > > > > > > > Dear X friends: > > > > > > > > Recently I play the "rdesktop", a software like XP remote desktop, > on > > > > > > > > XFree86 4.3.0. > > > > > > > > And the text will get blur only when I use Kernel 2.6.15.1 but it > will > > > > > > > > disappear when I change to kernel 2.4.27. > > > > > > > > Since the accelerator in the XFree4.3.0 is XAA, are there some > > > > > > > acceleration > > > > > > > > in XAA will be effected by the kernel? > > > > > > > > Ps: My platform is sis741. > > > > > > > > Appreciate your help in advance. > > > > > > > > Sincerely Yours, > > > > > > > > cckuo > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > XFree86 mailing list > > > > > > > > XFree86@xxxxxxxxxxx > > > > > > > > http://XFree86.Org/mailman/listinfo/xfree86 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > XFree86 mailing list > > > > > > XFree86@xxxxxxxxxxx > > > > > > http://XFree86.Org/mailman/listinfo/xfree86 > > > > > > > > _______________________________________________ > > XFree86 mailing list > > XFree86@xxxxxxxxxxx > > http://XFree86.Org/mailman/listinfo/xfree86 > > > > _______________________________________________ > > XFree86 mailing list > > XFree86@xxxxxxxxxxx > > http://XFree86.Org/mailman/listinfo/xfree86 > > > _______________________________________________ > XFree86 mailing list > XFree86@xxxxxxxxxxx > http://XFree86.Org/mailman/listinfo/xfree86 > _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
