On Mon, Feb 24, 2003 at 01:28:15PM -0800, Alex Deucher wrote: > 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.
Yes, and you have to divide the fb memory in two, one for each head, or something such, and each head will have its separate offscreen memory manager, possibly using different screen strides. It should be possible to allocate memory for both framebuffers and have the offscreen memory manager be part of the EntRec, or something such, that is common for both heads. I haven't looked at it much yet. Also, this would need to be coordinated with ian's work on the texmem memory manager, in particular the open point on XAA memory integration. How is it done right now ? Is a part of the onchip memory reserved for framebuffer and XAA, and another part free for 3D use ? > 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. Notice that the current entity sharing stuff does distinguish between primary head and secondary head, so you could just test if you are on the primary head, and do the offscreen memory allocation and (double) framebuffer reservation on the secondary head (the one that gets initialized second), so we know the size of both framebuffers. Naturally, this info should be shareable, but since i think it will not change, it is also ok to have it in the device specific Rec. Now, then the only thing that would differ would be the viewport, which should not cause problem. Note that we need to maybe separate the modeinit stuff, into one part which will be responsible for setting up the framebuffers, and another part for setting up the viewport (the video mode one both heads, that is). This way, you would still have two screen sections in the config file, the only difference from traditional dual head, would be that we specify some flag to have it handled like that. Now, lets see what configuration option we would like for such a setup. The following things come to mind (i don't know if all the cards, or even mine support all of these, but assuredly future board will). o Traditional dual head. => No additional flag is used. o Double buffer dual head (what i did just describe) => We use the "Double" or whatever flag, we can also use an additional (optional) flag or argument to give the head mapping, after all, there is no reason why head 0 should be the primary head and vice-versa). o Mirrored viewports. => We use a mirror flag, both heads will be set to the same viewport. o Zoomed window. => One of the heads will have a viewport corresponding to a subpart of the other. with optional zooming if the size don't correspond. Maybe the two later could be merged, with some clever option handling or such. Are there other things i am missing here ? Also, as a later point, it would be nice if these things could be changed dynamically, maybe as a response to some special key stroke or such like they have on laptops (or do these keystroke work even if there is no driver support for those ?). Notice that this should work fine for most boards, even those having an offchip second ramdac or a third like the matrox parhelia. There may be some issues though with the accel engine of some chips which can only do 2048 width, but i guess these sizes will increase in the future, and anyway, we could staple the screen vertically, thus not reaching too big screen stride, and have the function which setup for each screen move the base address or something such. This would be a problem if you want to see both screens side by side though. Now, this was the easy part, what are the problems we are facing ? o We need to make Xinerama aware of this. o Xv support (and possibly HW cursor). Well this works fine for most 2D drawing and probably 3D drawing, but the video or cursor overlays will not know about it. We will still need to do those per screen, which may not be possible on all dual head boards. o 3D memory management. Ideally we would use Ian's new memeory manager for all memory allocation, including the framebuffer, XAA and Xv. I will have to look again at Ian's proposal, but i suppose you can declare the framebuffer as pinned to the onboard memory or something such. If i understood this correctly, this would _not_ work when the drm is not supported, because all the memory management is to be done in the drm kernel module, right ? Also this would need the offscreen memory manager to be adapted. Well, i hope this covers it, i will no go to reread ian's proposal and see how the XAA interaction will work out. Are there things i have missed or additional ideas ? Friendly, Sven Luther ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel