xf86-video-chips driver support for multiple heads & CPU to Screen Color Expansion

[Donald Kayser]

A link to the source is http://kayser.net/xf86-video- 
chips.src.tar.gz   The only files modified are ones in xf86-video- 
chips/src. I tried to attach the tarball but could not due to size  
constraints. I don't have the time to learn how to patch in the manner  
that this organization expects, so the best that I am going to be able  
to provide is the source code.  Upon final completion of the project,  
I will update again.

This code works for my target, which has the aperture for the upper  
PCI memory linear frame buffer in the 69030 set to byte swap. This  
code makes use of that upper memory frame buffer without any provision  
for changing it on an x86 little-endian platform. This is also true of  
the 64K data window provided in acceleration: the upper PCI memory  
addresses are used for byte swapping. This allows me to configure the  
expansion and copy flags in XAA without the BIT_ORDER_IN_BYTE_MSBFIRST  
flag.

BTW. I asked in this original mail about the XAA in color expansion. I  
have solved this by using the upper memory address 64K data blt   
window which gets properly swapped.

Also, upon inspection of the original driver, there are bugs related  
to ISA. If anyone uses that drive on and ISA bus, it will crash.  
Another area of concern with the driver is that I have seen other use  
it's initialization code with respect to sharing entities among  
multiple heads: it will work with one card, but will not work with  
multiple cards if you happen to be using xserver 4.1. The reason is  
that xf86MatchPciInstances() returns invalid data for entity  
information in the last parameter. In my specific case the array came  
back 0,1,0,1 when it should have been 0,0,1,1.  Of course my reverse  
engineering of xserver and reading code of other may have this point  
wrong, but this data was used in a subsequent call to  
xf86ConfigPciEntity() and was wrong.

For any questions, I am available via email.

Regards,
Donald Kayser
xorg at kayser.net



On Jun 28, 2009, at 12:15 PM, Alex Deucher wrote:

> On Tue, Jun 23, 2009 at 12:14 PM, Donald Kayser<xorg at kayser.net>  
> wrote:
>> Hello,
>>
>> I have been able to modify the driver to support independent images  
>> on
>> each head for the C&T 69030. I will make it available to all when
>> complete. I do not intend to check this in for a few reasons. 1) I
>> didn't like the way it was written with respect to formatting and  
>> with
>> respect to the number of devices it supports. 2) I only needed to
>> support one device, so I have mostly stripped out any code that did
>> not compile for my platform. Trying to cram and learn enough of
>> xserver and driver code into one several week project was enough of a
>> task. 3) These changes only work on the X7.3 release. I don't need it
>> to work beyond that, even for the target I have. 4) The code only
>> supported mirrored data from one head to the other, it also used IO
>> space that get's mapped to PCI/IO space to communicate with the  
>> driver
>> and partly uses memory registers. My product has two 69030
>> controllers, so only memory mapped I/O is allowed. 5) I made major
>> changes to the way registers are restored, and have no way of testing
>> against any other platforms.
>>
>> Now, I have problems with CPU to Screen Color Expansion. When the XAA
>> architecture uses color expansion registers to transfer data to the
>> graphics memory, it is not accomplished through the frame buffer, but
>> through a 64K bit of PCI bus memory. I have a PPC processor, so I  
>> have
>> to worry about byte swapping, and all data that is Blit'd out he 64K
>> addresses have an odd swapping going on. It is hard to describe, but
>> if you start xfontsel and pick a family of nice 8x8 fixed pitch font
>> and look at the display, it read BADCFE... This has to be a swapping
>> problem somewhere, so I was wondering if anyone had insight on the
>> color expansion notion in a PPC environment.
>
> Could you post the patch to the mailing list or file a bug with the
> patch so it will be available to future developers?
>
> Alex
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>