From: Roland S. <rsc...@hi...> - 2005-01-19 02:55:33
|
Michel D=C3=A4nzer wrote: > On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote: >=20 >> Michel D=C3=A4nzer wrote: >>=20 >>> 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? >>=20 >> Maybe, but I couldn't figure out a semi-sane way. The problem is=20 >> those values get set in the generic _DRIAdjustFrame in dri.c, which >> knows nothing about mergedfb. >=20 >=20 > Hmm... I was hoping that DRIAdjustFrame() would call the wrapped=20 > function (ultimately the driver's AdjustFrame() hook) last, as most=20 > wrapper functions seem to do, but apparently it doesn't. :( Still,=20 > the driver should be able to wrap around DRIAdjustFrame() again after > it's been installed, and the wrapper could fix up the generic SAREA=20 > 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). >=20 >=20 >>> What happened to Stephane's surface allocator, BTW? If you just=20 >>> whack the surface registers directly from the X server, it=20 >>> becomes hard if not impossible to introduce such an allocator, at >>> least for the surfaces touched directly by the X server... >>=20 >> 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=20 >> is. For all shared buffers, it seems to be ok that ddx would=20 >> allocate the surfaces. So it would just use the allocator instead=20 >> of doing it directly (in case of direct rendering, otherwise still=20 >> needs to set it up manually for the front buffer). >=20 >=20 > But (how) will the DRM surface allocator detect an old DDX that=20 > doesn't know about it and touches the surface registers directly and=20 > 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. >>> The DRM could update the register in the vblank interrupt=20 >>> handler? >>=20 >> That sounds right (didn't know there was such a handler, but there=20 >> it is...). I can't see how to do that though. Looks complicated=20 >> :-(. >=20 >=20 > I guess it would require yet another ioctl/setparam/SAREA field. Hmpf, I hate pageflip :-(. In an ideal world, only ddx or drm would mess=20 with offset and offset_cntl, not both :-(. I don't consider that a show-stopper, though. Roland |