Re: dri client framebuffer access..
On 9/26/05, Alan Cox <[EMAIL PROTECTED]> wrote: > On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: > > Do we need to restrict the size of the maps we allow the DRI clients to > > acess in the FB area? > > Yes - SiS has a 64K command queue in the frame buffer for example > > Savage has a command overflow buffer in vram as well. Alex --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri client framebuffer access..
On Llu, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: > Do we need to restrict the size of the maps we allow the DRI clients to > acess in the FB area? Yes - SiS has a 64K command queue in the frame buffer for example --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri client framebuffer access..
On Mon, 2005-09-26 at 01:54 +0100, Dave Airlie wrote: > I was talking to Ben on IRC about this and I realised I wasn't really sure > about this.. > > At the moment we allow the DRI client full r/w access to the framebuffer > if I'm not mistaken (for software fallbacks and the like).. > > If I put the PCIE GART table into fb memory (which I've no choice in), the > user can mess it up and potentially in my mind cause us to read data from > anywhere in system RAM... > > Do we need to restrict the size of the maps we allow the DRI clients to > acess in the FB area? That would be good. FWIW, it's done that way in fglrx. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
dri client framebuffer access..
I was talking to Ben on IRC about this and I realised I wasn't really sure about this.. At the moment we allow the DRI client full r/w access to the framebuffer if I'm not mistaken (for software fallbacks and the like).. If I put the PCIE GART table into fb memory (which I've no choice in), the user can mess it up and potentially in my mind cause us to read data from anywhere in system RAM... Do we need to restrict the size of the maps we allow the DRI clients to acess in the FB area? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
