DomainKey-Signatur/cvs/xorg/xc/programs/xedit/lisp
7Ï . 2Ï .. 8Ï CVS <Ï Ü progmodes 8Ï . 7Ï .. 9Ï
Repository ÈÍ ÔEntries @Ï Ä Entries.Log ÈÍ °Entries.Backup /cvs/xorg/xc/programs/xedit/lisp/modules
e.at (unknown [213.229.38.66])
by gabe.freedesktop.org (Postfix) with SMTP id 252D19F6A3
for <xorg at lists.freedesktop.org>; Mon, 4 Jul 2005 03:31:20 -0700 (PDT)
Received: (qmail 21391 invoked from network); 4 Jul 2005 10:31:17 -0000
Received: from unknown (HELO ?10.0.0.170?) (10.0.0.170)
by 10.0.0.194 with SMTP; 4 Jul 2005 10:31:17 -0000
Message-ID: <42C90F73.6020305 at winischhofer.net>
Date: Mon, 04 Jul 2005 12:29:07 +0200
From: Thomas Winischhofer <thomas at winischhofer.net>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050602)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: zrusin at trolltech.com, xorg at lists.freedesktop.org
References: <200506251820.11513.zrusin at trolltech.com> <da0qp8$tqs$1 at sea.gmane.org> <1120164247.6482.109.camel at localhost.localdomain> <200507010909.43517.zrusin at trolltech.com> <42C67514.20708 at winischhofer.net> <42C681EC.6010208 at winischhofer.net> <42C69806.7080402 at winischhofer.net> <1120320641.25984.37.camel at evo.keithp.com> <42C86DC1.9090203 at winischhofer.net> <42C87F7E.8000609 at winischhofer.net> <1120439422.4040.0.camel at evo.keithp.com>
<42C8ECD7.3020405 at winischhofer.net>
In-Reply-To: <42C8ECD7.3020405 at winischhofer.net>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: New acceleration architecture
X-BeenThere: xorg at lists.freedesktop.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discuss issues related to the xorg tree <xorg.lists.freedesktop.org>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/xorg>
List-Post: <mailto:xorg at lists.freedesktop.org>
List-Help: <mailto:xorg-request at lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2005 10:31:22 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Winischhofer wrote:
> Keith Packard wrote:
>
>>>On Mon, 2005-07-04 at 02:14 +0200, Thomas Winischhofer wrote:
>>>
>>>
>>>
>>>>Not that I had time now, but....
>>>>
>>>>The calls are issued from miDCCloseScreen. I am too tired now to find
>>>>out what to make of this.
>>>
>>>
>>>Thanks, Thomas. Those are software cursor pixmaps, which clearly should
>>>have been cleaned up before the screen was finished. In other words, I
>>>believe the CloseScreen chain-of-wrappers is broken somehow.
>
>
>
> And I now also know why this only happens on my SiS6326: This is the
> only card not capable of ARGB HW cursors. Since I have a colored cursor
> scheme installed on this machine, it's using the SWCursors on the
> 6326... all other cards use the HWCursors.
XAA does it like this:
XAAInit() wraps pScreen's CreatePixmap and DestroyPixmap, and
CloseScreen. XAA's CloseScreen unwraps all of these functions again. So
that's why this problem never showed up while using XAA and the old fb
manager.
I strongly assume that simply unwrapping the pScreen CreatePixmap and
DestroyPixmap pointers is not the real fix, but it would at least do for
now.
At a closer look, in my driver's ScreenInit, the order of wrapping
pScreen->CloseScreen is the following:
- - fbScreenInit(): fbCloseScreen() only frees private data, and returns
TRUE. This is obviously meant to be the last one in the chain - but see
immediately below.
- - fbPictureInit() calls miPictureInit which calls PictureInit(). The
last one wraps CloseScreen with PictureCloseScreen() which makes sure
it's the last one executed as it does not simply call the next
CloseScreen wrapper at its end, but right at start. So, the essence of
PictureCloseScreen() is done AFTER all other CloseScreen()'s are
finished. All its subroutines (PictureResetFilters(), CloseIndexed())
do only free private data, so no harm there.
- - DGA: Its CloseScreen wrapper only frees private data.
- - EXA/XAA - see below
- - miInitializeBackingStore() - mibstore.c: Its miBSCloseScreen() only
frees private data.
- - miDCInitialize() - init sw cursor - midispcur.c: miDCCloseScreen() is
the bad guy, calling pScreen->DestroyPixmap for freeing cursor data.
(EXA is already destroyed by that time).
- - xf86InitCursor() - init hw cursor - ramdac/xf86Cursor.c:
xf86CursorCloseScreen() unwraps everything, frees private data and
eventually calls xf86SetCursor with a null-cursor.
- - shadowfb (eventually): ShadowCloseScreen() only unwraps and frees
private data.
- - DPMS: CloseScreen() unwraps, frees private data and calls
pScrn->DPMSSet() for (re-)enabling the display. That's an interesting
one since it is also called AFTER the driver's own CloseScreen(), but
granted, this fact is mentioned in the comment before the call. (My
driver circumvents this call by setting pScrn->vtSema to FALSE at the
end of its own CloseScreen()).
- - Xv: Its CloseScreen() wrapper unwraps, frees private data; it also
eventually calls FreeGC (dix/gc.c) which itself ALSO eventually calls
pScreen->DestroyPixmap. So basically, this one could be a trouble maker
as well.
- - And finally, the driver's CloseScreen(): This is called FIRST:
Restores display mode, unmaps memory, frees int10 data, frees some
private data, [deregisters the XAA hooks | calls EXA's DriverFini()],
destroys the cursor InfoRec, frees shadow framebuffer, frees xv
adaptors, and proceeds to next CloseScreen wrapper.
- From looking at this closely, I get the impression that EXA is somewhat
not conforming to the standard behavior, as it does not wrap
CloseScreen() itself, but relies on the driver to call DriverFini()
which is executed at a different time than a potential exaCloseScreen()
would. DriverFini() not only destroys the offscreen memory manager, but
all EXA related stuff in connection with the pScreen in question.
While XAA's XAADestroyInfoRec(), which is called from the driver's
CloseScreen(), only frees the pixmap cache, EXA's DriverFini() destroys
... EXA basically. Without unwrapping the pointers it wrapper in
DriverInit().
So, the proper solution (for now?) would be,
1) either wrap closeScreen() in exaDriverInit(), and unwrap everything
there, or
2) unwrap everything in DriverFini() (which is certainly easier to do
quickly).
Thomas
- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCyQ9yzydIRAktyUcRAhWbAJ42TBBvlsy0AaSwypiPWSQaSJHOXACeJDET
VdNDdVynq0iNm+Rhy2ce2vk=
=PPuS
-----END PGP SIGNATURE-----