Hi!
Jon Smirl wrote:
Looking at driver/server all of the drivers are effectively creating
an sarea of size SAREA_MAX. I also grepped through x.org and could not
find any place where it is set to anything besides SAREA_MAX. There is
code that sets it to other values but it is ifdef'd out.
x.org ifdef's have this comment...
/* FIXME: Need to extend DRI protocol to pass this size back to
* client for SAREA mapping that includes a device private record
*/
[EMAIL PROTECTED] dri]$ grep -rI SAREASize * | grep =
fb/fb_dri.c: ctx->shared.SAREASize = SAREA_MAX;
i810/server/i810_dri.c: ctx->shared.SAREASize = 0x2000;
mga/server/mga_dri.c: ctx->shared.SAREASize = SAREA_MAX;
r128/server/r128_dri.c: ctx->shared.SAREASize = SAREA_MAX;
r200/server/radeon_dri.c: ctx->shared.SAREASize = SAREA_MAX;
r200/server/radeon_egl.c: disp->SAREASize = SAREA_MAX;
radeon/server/radeon_dri.c: ctx->shared.SAREASize = SAREA_MAX;
radeon/server/radeon_egl.c: disp->SAREASize = SAREA_MAX;
tdfx/server/tdfx_dri.c: ctx->shared.SAREASize = SAREA_MAX;
unichrome/server/via_dri.c: ctx->shared.SAREASize =
((sizeof(drm_sarea_t) + 0xfff) & 0x1000);
unichrome/server/via_dri.c: ctx->shared.SAREASize = SAREA_MAX;
Exception is i810 at 0x2000 which is what SAREA_MAX is minimally
defined too so i810 can be changed. The odd line in the via driver is
if'd out and SAREA_MAX is used.
Given that everyone is using SAREA_MAX I can modify DRM to pre-create
a SAREA_MAX region and return it from AddMap instead of making a new
one. Doing it that way will keep the old binaries working.
New apps use a loop similar to this instead of doing AddMap:
for (i = 0;; i++) {
if ((rc = drmGetMap(display->drmFD, i, &offset, &size, &type,
&flags, &handle, &mtrr)) != 0)
break;
if (type == DRM_SHM {
drmMap(fd, handle, size, (drmAddressPtr)&display->sarea);
break;
}
}
This lets new non-root apps avoid calling AddMap for sarea. The AddMap
call has to stay marked as root only.
Any objections to why this won't work?
While this will probably work today it will leave little room for future
applications of DRI.
A concrete example is the Unichrome driver. XvMC and OpenGL were
developed in parallell and to some extent entered entries in the SAREA
one after another with what information was available then. In later
hardware VIA has added more mpeg decoders and video engines which
increases the needs for XvMC locks. Today this will either fragment the
SAREA or break all forms of binary compatibility. One possibility to
avoid this in the future is to have a separate SAREA for XvMC specific
stuff. Whatever DRI is used for in the future either than OpenGL the
developer will very early encounter the problem how to share data
between clients and master. Keeping this in a fixed sized SAREA is one
solution, being able to put it in a _application specific_ shared memory
region mappable only by authenticated clients is another. Given the
mentioned experience and expansion plans for the via drm, IMHO the
latter capability of drm needs being kept.
/Thomas
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
