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.
Everyone should update anyway to get color tiling working ;-). As a simpler fix, would it be safe to simply change the order of the calls to the wrapped function and _DRIAdjustFrame() in dri.c? That would definitely change the semantic of the function, but I don't know if it would actually hurt. Ah well maybe not a very good idea. I'll give the double-wrap a try, should also work for tiling, if some creative frame.y and frame.x values are put there (I'm not too keen on redoing the calculation in the drm again).
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?
Argh. Well, maybe require dri drivers to query for ddx minor version and not use it if they detect an old version? Sounds like a kludge. Maybe it would be worth to integrate it now.
Hmpf, I hate pageflip :-(. In an ideal world, only ddx or drm would mess with offset and offset_cntl, not both :-(.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.
I don't consider that a show-stopper, though.
Roland
------------------------------------------------------- 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
