On Wed, Feb 19, 2003 at 01:46:39 +0100, Michel D�nzer wrote: > On Die, 2003-02-18 at 20:10, Alan Hourihane wrote: > > On Tue, Feb 18, 2003 at 10:49:58 -0800, Nolan Leake wrote: > > > On Sun, 2003-02-16 at 16:36, Mark Vojkovich wrote: > > > > I don't really know what the point of fbIsVirtual was. > > > > Apps that use ShadowFBInit need to repaint when entering > > > > the VT. We didn't have the EnableDisableFBAccess stuff > > > > when I wrote shadowfb and the refresh at EnterVT was to > > > > catch the copy from the old root window backing pixmap. > > > > With EnableDisableFBAccess handling exposures, it shouldn't > > > > be needed anymore but we definitely don't want to > > > > block EnableDisableFBAccess like the code is doing. > > > > > > > > It seems like having ShadowFBInit call ShadowFBInit2 with > > > > FALSE is the correct behavior. Experimentation shows > > > > this to remove the corruption. > > > > > > The previous shadowfb code blocked EnableDisableFBAccess and updated on > > > VT switching. Since the code looked stale (I couldn't find where the > > > screen got stored in the backing pixmap anywhere), I disabled it for the > > > vmware driver, but since I didn't have a way to test the other clients > > > of shadowfb, I preserved the old behavior for them. > > > > > > If having ShadowFBInit call ShadowFBInit2 with FALSE works for all > > > clients, then the fbIsVirtual flag can be removed entirely; the only > > > caller of ShadowFBInit2 is vmware.c, and it passes in FALSE. > > > > O.k. Thanks Nolan. > > > > I've just removed that code from the CVS. > > You missed this.
Thanks, although there's no functional difference. Alan. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
