On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote: > Michel DÃnzer wrote: > > > > Speaking of mergedfb and page flipping: Is it really necessary to add > > a new private SAREA field and a corresponding setparam? Isn't it > > possible to set the generic SAREA fields as the DRM expects them, to > > make this work with older DRMs as well? > Maybe, but I couldn't figure out a semi-sane way. The problem is those > values get set in the generic _DRIAdjustFrame in dri.c, which knows > nothing about mergedfb.
Hmm... I was hoping that DRIAdjustFrame() would call the wrapped function (ultimately the driver's AdjustFrame() hook) last, as most wrapper functions seem to do, but apparently it doesn't. :( Still, the driver should be able to wrap around DRIAdjustFrame() again after it's been installed, and the wrapper could fix up the generic SAREA fields as needed. I agree that's not exactly an elegant solution, but I think it's still better than requiring users to upgrade the DRM to get this working. > > What happened to Stephane's surface allocator, BTW? If you just whack > > the surface registers directly from the X server, it becomes hard if > > not impossible to introduce such an allocator, at least for the > > surfaces touched directly by the X server... > Stephane told me it doesn't work yet. I thought about it briefly if it > would be a problem to introduce it later, and I don't think it is. For > all shared buffers, it seems to be ok that ddx would allocate the > surfaces. So it would just use the allocator instead of doing it > directly (in case of direct rendering, otherwise still needs to set it > up manually for the front buffer). But (how) will the DRM surface allocator detect an old DDX that doesn't know about it and touches the surface registers directly and deal with it? > In an ideal world, surface allocation should probably be directly tied > to memory allocation. Yeah, one problem being that surfaces are scarce... > >> + however disabling flip_cntl also gets rid of the flickering > >> we get when hw scrolling + in a virtual screen (since the crtc > >> will pick up the new offset after each scanline, + but it will > >> only pick up the new offset_cntl value after a vsync). + We'd > >> probably need to wait for vsync somehow if we've scrolled before > >> changing the + offset to fix that flickering - unfixable ?*/ > > > > > > The DRM could update the register in the vblank interrupt handler? > That sounds right (didn't know there was such a handler, but there it > is...). I can't see how to do that though. Looks complicated :-(. I guess it would require yet another ioctl/setparam/SAREA field. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
