I too am curious about that. I've been working on adding duoview support to the s3 savage driver. I talked to Tim Roberts a while back and I figured out the basics of how it works. I've got a semi-working driver, but alas, I think I need some help getting the second crtc to output to the vga port. Right now it seems to think it's connected to the LCD. such is the case of writing drivers blind. Do any of you have access to savage MX/IX docs (or know where I could find some) and would be willing to answer some questions? I'm working on a Savage IX on an IBM T20.
BTW, here's my code as well as a binary and a sample XF86Config file: http://www.botchco.com/alex/new-savage/savage/ Also to any of you would-be developers out there, it's actually not as hard as it seems, I mean docs are nice (and often necessary), but you can figure out a lot just looking at code from other drivers. after fiddling with duoview for a few weeks I have a pretty good understanding of 2D. I haven't messed with 3D...yet. It's sort of really daunting for a while and then all of a sudden you get a moment of clarity and it all starts to make sense. Which bring me to the subject of this email. I've been giving this some thought... The thing is there isn't really a sample of this to work from at the moment, but once the first on got converted, I think it would be pretty easy to convert others (at least for single chips with dual CRTCs). here are my thoughts on it, from my perspective anyway, keep in mind I'm still pretty green. right now for these chips you set up the entity as shareable and then divide your framebuffer into two or more frambuffers, one for each CRTC. Each instance of the driver then works using its framebuffer. each head is distinguished using the "screen 0/1/etc." flag in the XF86Config file. (entity functions and operations for this sort of thing are not so well documented, at least not that I could find). Each pscrn gets it's framebuffer size and address mapped to the part of video ram you allocated for each frambuffer. For chips with dual crtcs you could do just what the diagram below shows and create a single frame buffer with two sort of virtual framebuffers. I'm not sure how this would work with the existing entity code. I guess as far as XF86Config goes you have to create a custom flag. As Sven said, this is I think what the matrox and Nvidia drivers do. They can also announce xinerama for the benefit of window managers and such (even though it's technically not two pscrns). You could add the stuff from the device specific EntRec's to device specific Rec's. then each pscrn would be responsible for not only frambuffer base and address but also primary and secondary virtual frame buffers and address. The main framebuffer would hold the whole contents of the screen and each virtual framebuffer would basically be a viewport into the total "screen." I haven't had time to think this through throughly and I'm already starting to have questions... I dunno...food for thought I guess. If and when I finish duoview support, I'd like to work on this, or at least help out. Also for anyone out there who's working on 3D support for the savage IX/MX I'd be happy to help out testing and what not. Thanks, Alex -------------------------------------- On Mon, Feb 24, 2003 at 07:58:55AM -0700, Jens Owen wrote: > A short cut to this whole thing would be to work on getting a second > head supported on a single X11 screen. Then 3D comes for free: > > http://www.tungstengraphics.com/dri/Simple_Xinerama_DH.txt > > This solution provides Xinerama functionality without actually using the > Xinerama wrapper. Mmm, i am curious about this, how does it get handled in the XFree86 configuration file. Also, i guess this would facilitate the memory management in dual head configurations. In general, dual head configuration is pretty poor in the current X server, at least in the documented part. There is no way from specifying mirrored or zoomed window output, or to be able to change the configuration dynamically, but this would probably not be achievable without an extension, or maybe incorporated with the RandR stuff. I think that matrox did something such in their proprietary drivers. Friendly, Sven Luther __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
