On Wed, Feb 26, 2003 at 09:16:53AM -0800, Alex Deucher wrote: > > --- Sven Luther <[EMAIL PROTECTED]> wrote: > > 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.
Yes, i also am faced with choice of how to allocate memory, altough i have not yet gotten to DRI support, and it may also depend on the specific graphic hardware, like Michel said. > > > 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. No, i think it would work ok, i would need to test though, and have not much time for it right now. When we are in the chipset_probe function, we set the entity as shareable, and allocate the private entrec, as well as give some special cases there. Once we are in PreInit or even in ScreenInit we can do finer tests, and postpone the memory reservation and such until we have info on both screens. We are not showing it anyway before ModeInit is called, and both ScreenInit are called successively, if i remember well. Some care must be taken though and checking. > > 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. Mmm, and how do you set the zoom values ? You know, i think this could work, as the info in the screen section is used to call the modeinit function. There is also X/Y Mirrored mode, and rotated modes, but i guess not all hardware can do this, and it would be difficult to implement. > > 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. Ok, ... > > 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. I don't really know, some allow to use the overlay only in single head mode, i guess. > > 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... I cannot help you with that. > 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? I guess you need to flip it each time the viewport changes, that is when you move the cursor or the overlay ? 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
