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. > 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. > 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 :/ cu, Nicolai
pgpITuv579OQb.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
