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? 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? 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
