On Sun, 2003-03-02 at 21:57, Sven Luther wrote: > 1. fbdev will be secure. Without access to the MMIO regions, crashing > the chipset is unlikely or at least difficult. Even malicious blit > commands (blits to/from system memory) will not work.
For some cases. The truth is a bit more horrible, and current fbdev has the same problem here. Any early Athlon, and almost any PII/PIII derived chip allows the user to bring the box down if they have access to a mix of cached and uncached RAM. DRM and fbdev already make this tradeoff. > 3. Because DRM will handle both 2D and 3D and is pretty much the only > one with hardware access, performance might actually increase. It gives you real DMA of 2D texture objects. It also improves the situation with tv cards on buggy chipsets no end because you can run two DMA operations via main memory on busted hardware (eg ALi Magik) > In linux-2.5, fbcon is already separate from fbdev. Perhaps in 2.7, > fbdev can be further reduced to a minimal core, moving the rest of the > code to fbaa. Exporting the mmio regions to userland must be > disallowed. I disagree here. There are chips with useful safe mmio areas for many things. "Exporting mmio regions must be up to the DRM layer" > Any comments? Take a look at the SiS DRM. It has the memory manager and fb in one module but otherwise its not that disimilar to your basic description ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
