Marc,
I have fixed two other problems in smi_accel. They are as follows:
1. Endian-swapped hwcursor ("X" hwcursor appears as a diamond rather
than an "X")
2. Y-value put incorrectly into DPR:
So if you're in the mood, here are my diffs. Forgive my ignorance of
how to properly submit changes.
Also, forgive my down-and-dirty endian-swapping method; I'm sure
there are better ways.
I have changed other smi modules, but I'll hopefully submit the changes later.
smi_accel.c:
==============================
120,123c120,127
<
| NO_PLANEMASK
<
| BIT_ORDER_IN_BYTE_MSBFIRST
<
| LEFT_EDGE_CLIPPING
<
| CPU_TRANSFER_PAD_DWORD
---
> | NO_PLANEMASK
> #if X_BYTE_ORDER == X_BIG_ENDIAN
> | BIT_ORDER_IN_BYTE_LSBFIRST
> #else
> | BIT_ORDER_IN_BYTE_MSBFIRST
> #endif
> | LEFT_EDGE_CLIPPING
> | CPU_TRANSFER_PAD_DWORD
727c731
< memcpy(pSmi->DataPortBase, pattern, 8 * pSmi->Bpp * 8);
---
> memsloppy(pSmi->DataPortBase, pattern, 8 * pSmi->Bpp * 8);
863c867
< WRITE_DPR(pSmi, 0x04, (x << 16) | (y * 0xFFFF));
---
> WRITE_DPR(pSmi, 0x04, (x << 16) | (y & 0xFFFF));
regsmi.h:
==============================
121a122,141
> static __inline__ void memsloppy(unsigned char *dst, unsigned char
*src, int len)
> {
> #if X_BYTE_ORDER == X_BIG_ENDIAN
> int i;
> unsigned char *csrc,*cdst;
>
> csrc=(unsigned char *)(src);
> cdst=(unsigned char *)(dst);
> for (i=0; i<len; i+=4) {
> *cdst++=*(csrc+3);
> *cdst++=*(csrc+2);
> *cdst++=*(csrc+1);
> *cdst++=*(csrc+0);
> csrc+=4; /* go to next dword */
> }
> #else
> memcpy(pSmi->FBBase + pSmi->FBCursorOffset, src, len);
> #endif
> }
>
Regards,
Bob Peterson
ACD
At 09:53 AM 8/8/2005, you wrote:
On Mon, 8 Aug 2005, Bob Peterson wrote:
That was it. I fixed smi_accel to set byte order based
on X_BYTE_ORDER and it worked perfectly. Thanks a bunch Mark!
I have just committed this change. Thanks for trying it out.
At 04:40 PM 8/6/2005, you wrote:
That sounds like a driver acceleration bug. Most drivers support
a "noaccel" option. You might want to try that to verify a driver
acceleration problem. My guess is that, for big endian, the driver
needs to add BIT_ORDER_IN_BYTE_LSBFIRST instead of
BIT_ORDER_IN_BYTE_MSBFIRST to the CPUToScreenColorExpandFillFlags in
smi_accel.c.
Mark.
On Fri, 5 Aug 2005, Bob Peterson wrote:
> I'm new to the list. I've been searching the net for days, but
> unable to find similar issues out there.
> I am using XFree86 4.5.0 on a small embedded power-pc (ppc)
> platform. I compiled X natively
> and everything went fine. After the make install, I did a
> startx. My windows appear as expected,
> but my fonts are all messed up / hosed / horked. I am not using xfs.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@xxxxxxxxxxx |
| 352 General Services Building +-----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 developer and VP. ATI driver and X server internals.
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86
