Quoting Nicolai Haehnle <[EMAIL PROTECTED]>: > On Thursday 17 March 2005 08:14, [EMAIL PROTECTED] wrote: > > Quoting Nicolai Haehnle <[EMAIL PROTECTED]>: > > > > > On Wednesday 16 March 2005 12:08, Daniel Phillips wrote: > > > > On Tuesday 15 March 2005 18:43, Nicolai Haehnle wrote: > > > > > If we enforce window boundaries (which is btw not enforced by any > > > > > graphics driver on Linux that I know of), we would also have to > think > > > > > about how mmap()'ing the framebuffer could (or couldn't) work. > > > > > > > > Can you do that? If a normal task can do that, then forget about > > > > per-window security, it's impossible. But I have a feeling it's not > > > > allowed. > > > > > > Well, software rendering fallbacks need some way to read to and write > from > > > the framebuffer. All current DRI drivers do this via a mapping of the > > > framebuffer. > > > > Do you have a link to the source code? I've had a lot of difficulty > > understanding the hooks between Mesa3D and the kernel source code. > > A lot of the setup code is in src/mesa/drivers/dri/common, e.g. the code > that maps the framebuffer (via drmMap, which is a wrapper around mmap) is > in dri/common/dri_util.c. However, the actual programming of the graphics > cards can be very different between drivers. Search the Mesa driver source > code for drmCommand to find all the places where custom ioctls are called. > Most (all?) drivers also use the drmDMA command to allocate DMA buffers, > but the exact handling of these buffers also tends to be different. > > The pointer to the framebuffer is passed around in the DRIScreenPrivate > structure as "pFB". All drivers have so-called span functions (usually > defined in a file called something like mgaspan.c), which are registered > with the Mesa software renderer. When the software renderer runs, it > rasterizes triangles one row (span) at a time, and then calls the span > functions to write the result to the framebuffer. The span functions are > also used to read values for the depth test, blending, and so on.
Thanks for the info the source code makes much more sense with this in mind. > > The UseNix paper on the experimental Kdrive server goes into some depth on > > a > > design of copying the Pixmaps from System Memory to Graphics Memory and > back. It > > also discusses the XOrg/XFree approach: > > http://www.usenix.org/events/usenix04/tech/freenix/anholt.html > > Apparently, one has to be a USENIX member to view this paper. Opps I gave the wrong link. The paper can be downloaded directly from: http://www.anholt.net/papers/kdrive-2004/kdrive-v6.pdf > > Interesting the White Paper on the design of the SGI Xserver/OpenGL > interface > > also briefly discusses the 2D acceleration by the Xserver in section 5.3. > > Apparently not much is done. It could have changed by now. > > http://citeseer.ist.psu.edu/kilgard95system.html > > ... and this server appears to be down or extremely slow :/ I have managed to download a copy. I can email you a copy if you like. tim. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
