[Dri-devel] Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel]future of DRI?]
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
[Dri-devel] Re: [adaplas@pol.net: Re: [Linux-fbdev-devel] Fwd: Re: [Dri-devel]future of DRI?]
On Mon, 2003-03-03 at 08:27, Alan Cox wrote: Sven, Thanks for posting this. I was actually waiting for the fbdev maintainers (Geert and James) to respond first. Seems Geert is receptive to the idea. 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. I do not understand. Do you mean such as writing to framebuffer memory and making it execute? [snip] 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 I was speaking more of fbdev which allows mmapping of the mmio besides graphics memory. DirectFB does its acceleration this way. So, yes, this task can relegated to DRM. 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 Thanks. Tony --- 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
