On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:

> I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
> disabled frame and buffer aging with the pattern registers.  I've disabled
> saving/restoring the pattern registers in the DDX and moved the wait for
> idle to the XAA Sync.  This fixes the slowdown on mouse moves.  I also
> fixed a bug in getting the ring head.  One bug that remains is that when
> starting tuxracer or quake (and possibly other apps) from a fresh restart
> of X, there is a problem where old bits of the back- or frame-buffer show
> through.  With tuxracer (windowed), if I move the window, the problem goes
> away.  It seems that some initial state is not being set correctly or
> clears aren't working.  If I run glxgears (or even tunnel, which uses
> textures) first, after starting X and before starting another app, the
> problem isn't there.  If someone has a cvs build or binary from before
> Monday the 20th but after Saturday the 18th, could you test to see if this
> happens? I'm not sure if this is new behavior or not.
>
> I tried removing the flush on swaps in my tree and things seem to still
> work fine (the bug mentioned above is still there, however).  We may need
> to think of an alternate way to do frame aging and throttling, without
> using a pattern register.

I've been pondering the code you've done (not the latest commited, but what 
was described to me a couple of weeks back...) how do you account for 
securing the BM_GUI_TABLE check and the pattern register aging in light of 
the engine being able to write to most all registers?  It occured to me that 
there's a potential security risk (allowing malicious clients to possibly 
confuse/hang the engine) with the design described to me back a little while 
ago.

-- 
Frank Earl

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to