Thank you. I think we should begin by doing what we've already been doing under Linux to access the card. Using lspci, we can find the PCI busid. Then using libpci, we can search devices for the right one to get the physical memory locations. Then using mmap, we can map the memory space into the user process (x.org). (I'm hoping that libpci functionality is provided by x.org to the DDX module.)
One of the BARs is the framebuffer, and we'll configure it as a simple 24-bit display. Another one is the "engine". We'll provide offsets for things like the video controller and memory controller. When we have them all together, we can change the #defines in a header file and go. I'm not sure there's much else to do. On 6/14/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > Certainly the "dummy" and "fbdev" drivers look fairly straightforward, > > maybe steal some of the PCI code from a card with a simple linear > > framebuffer (s3?) > > Ok. So I was wondering if I could get someone to help me with that, > because I have a gajillion other things to do. Ok, I'll bite. Where can I find a description of the interface I'm supposed to be talking to (PCI IDs, mbars, registers, etc)? Paul
-- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
