--- Sven Luther <[EMAIL PROTECTED]> wrote: > 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 ?
Not sure. I'm not familiar with the memory manager either. I seem to recall some drivers have the (compile time) option of allocating more or less to 2D vs 3D. I believe it was the mga driver, and the issue was not having enough memory for Xv cause 3D has reserved too much. > > > 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. Would this work with the current shareable entity stuff? it seems like that would predicate two separate instances of the driver, in this case we would only want one, right? one instance driving two heads. > > 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 ? maybe you could make the zoomed mode part of the mirror mode, but specify the viewport in the "screen" section of the XF86Config. > > 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 ?). I think several driver authors have brought this up before. I don't think there was a way for the driver to intercept keystrokes. Thomas Winischhofer brought it up on one of the Xfree ML's, but I'm not sure if it was ever resolved. > > 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. yeah. Most dualhead boards have two HW cursors, some also have 2 overlays, so those could be set up screen specifically. However, for cards with one overlay, would it be possible to use the overlay on either head? Say, if more of the window is on head 1 use the overlay with that crtc, if more is on head 2, then use it with that crtc, and specify head 1 as the default for cases with an even divide. I know most boards with one overlay can usually choose which head to use it on. In fact the matrox driver for beos works that way. the source is even available. > > 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 ? Looks pretty good. now if I could just get this savage driver worked out... One more thing, this is somewhat off topic, but more most dualhead boards, the crtc registers are generally shadowed in some form (savage, Chips, at least, BTW, for those of you interested in dual head cards and specs, the specs are available for the chips 69030 http://www.asiliant.com/69030.htm -- I find it very helpful). Usually there is another register that you change the value of to flip which set of cr registers you are dealing with. Now, other than mode setup (and in some cases cursor and overlay), would I need to flip that bit for ongoing operations once the mode and cursor, etc. is initially set up? Thanks, Alex __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- 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
