xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2019-05-10T18:37:16Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/406unwrap Glyphs, Composite and AddTraps at damageCloseScreen2019-05-10T18:37:16ZBugzilla Migration Userunwrap Glyphs, Composite and AddTraps at damageCloseScreen## Submitted by SooChan Lim
Assigned to **Xorg Project Team**
**[Link to original bug (#30058)](https://bugs.freedesktop.org/show_bug.cgi?id=30058)**
## Description
I had found that Xserver did not execute the exaGlyphsFini() whil...## Submitted by SooChan Lim
Assigned to **Xorg Project Team**
**[Link to original bug (#30058)](https://bugs.freedesktop.org/show_bug.cgi?id=30058)**
## Description
I had found that Xserver did not execute the exaGlyphsFini() while the Xserver calls closeScreen functions. The issue is that the server cannot free the exaglyph cache picture due to not calling exaGlyphsFini(),and then it cause the memory leak when the Xserver is termitated.
I have analyzed the closeScreen routines and I found the reason why the exaGlyphsFini() is not called. It is because the ps->Glyphs is not equal to exaGlyphs at exaCloseScreen.
=========================================================================
static Bool
exaCloseScreen(int i, ScreenPtr pScreen)
{
ExaScreenPriv(pScreen);
#ifdef RENDER
PictureScreenPtr ps = GetPictureScreenIfSet(pScreen);
#endif
if (ps->Glyphs == exaGlyphs) /* This is not TRUE */
exaGlyphsFini(pScreen);
---- omitted ---
xfree (pExaScr);
return (*pScreen->CloseScreen) (i, pScreen);
}
=========================================================================
In a depth analysis, I realized that the root cause of this leak is that unwrapping the private functions, which are Glyphs, Composite, and AddTraps, does not exist at damageCloseScreen().
The private functions of Glyphs, Composite, AddTraps are created at the time of DamageSetup(). However, there is no calling of unwrapping at the time of damageCloseScreen(). Therefore, I suggest that damageCloseScreen() func contains
unwrap function for the Glyphs, Compsoite, and AddTraps for preventing the memory leak.
The code to be fixed is below. Please check the code.
===============================================================================
static Bool
damageCloseScreen (int i, ScreenPtr pScreen)
{
damageScrPriv(pScreen);
PictureScreenPtr ps = GetPictureScreenIfSet(pScreen);
unwrap (pScrPriv, pScreen, DestroyPixmap);
unwrap (pScrPriv, pScreen, CreateGC);
unwrap (pScrPriv, pScreen, CopyWindow);
unwrap (pScrPriv, pScreen, CloseScreen);
if (ps) {
unwrap (pScrPriv, ps, Glyphs);
unwrap (pScrPriv, ps, Composite);
unwrap (pScrPriv, ps, AddTraps);
}
xfree (pScrPriv);
return (*pScreen->CloseScreen) (i, pScreen);
}
===============================================================================
Thank you.
SooChan Lim.
Version: 7.5 (2009.10)https://gitlab.freedesktop.org/xorg/xserver/-/issues/397Damage doesn't wrap CompositeRects2019-05-10T18:39:19ZBugzilla Migration UserDamage doesn't wrap CompositeRects## Submitted by Chris Wilson `@ickle`
Assigned to **Xorg Project Team**
**[Link to original bug (#28273)](https://bugs.freedesktop.org/show_bug.cgi?id=28273)**
## Description
Currently miCompositeRects() decomposes the operations ...## Submitted by Chris Wilson `@ickle`
Assigned to **Xorg Project Team**
**[Link to original bug (#28273)](https://bugs.freedesktop.org/show_bug.cgi?id=28273)**
## Description
Currently miCompositeRects() decomposes the operations into PolyFillRects or Composites and so the damage is captured. However, if a driver hooks into ps->CompositeRects, it must currently append the damage region itself.
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/364Damage extension reports backing store damage against the wrong window2019-05-10T18:38:27ZBugzilla Migration UserDamage extension reports backing store damage against the wrong window## Submitted by Keith Kriewall
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#15396)](https://bugs.freedesktop.org/show_bug.cgi?id=15396)**
## Description
Drawing to a window's backing store is reported as damage a...## Submitted by Keith Kriewall
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#15396)](https://bugs.freedesktop.org/show_bug.cgi?id=15396)**
## Description
Drawing to a window's backing store is reported as damage against the obscuring window, not the window actually drawn upon.
For example, given a window heirarchy as follows...
Parent and Child_1 (same size):
------------------------------
| |
| Child_2: Child_1a: |
| ---------- ---------- |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| ---------- ---------- |
| |
------------------------------
Parent: @(0,0) for [30,11]
Child_1: @(0,0) for [30,11], BackingStore=WhenMapped
Child_2 (a sibling of Child_1): @(3,3) for [10,6]
Child_1a (an inferior of Child_1): @(17,3) for [10,6]
... create and map the windows;
create DAMAGE level=RawRectangles for Child_1, Child_2, and Child_1a;
create a GC with SubwindowMode=ClipByChildren;
then draw a zero-width line drawn on Child_1 from (0,5) through (29,5).
Expected result:
DamageNotify on Child_1 @(0,5) for [30,1]
Actual result:
DamageNotify on Child_2 @(0,2) for [10,1]
DamageNotify on Child_1a @(0,2) for [10,1]
DamageNotify on Child_1 @(0,5) for [3,1]
DamageNotify on Child_1 @(13,5) for [17,1]
The damage reported on child_1a and child_2 is unexpected because the drawing has not affected either of these windows.
Tested on X.Org servers version 6.8.2 (Damage v1.0) and 1.3.0 (Damage v1.1). Possibly related to [bug 3785](https://bugs.freedesktop.org/show_bug.cgi?id=3785), but probably not.
Version: 7.3 (2007.09)Adam Jacksonajax@nwnk.netAdam Jacksonajax@nwnk.nethttps://gitlab.freedesktop.org/xorg/xserver/-/issues/361DamageSubtract is misdesigned, making DeltaRectangles mode unusable2019-05-10T18:38:15ZBugzilla Migration UserDamageSubtract is misdesigned, making DeltaRectangles mode unusable## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#14648)](https://bugs.freedesktop.org/show_bug.cgi?id=14648)**
## Description
damageproto.txt, when describing the DamageSu...## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#14648)](https://bugs.freedesktop.org/show_bug.cgi?id=14648)**
## Description
damageproto.txt, when describing the DamageSubtract request, states:
DamageSubtract
[...]
Synchronously modifies the regions in the following manner:
(A) If repair is None:
1) parts = damage
2) damage = `<empty>`
(B) Otherwise:
1) parts = damage INTERSECT repair
2) damage = damage - parts
3) Generate DamageNotify for remaining damage areas
(Letters added for ease of reference.) My issue is with point B.3.
In my application[1], I request damage mode DamageReportDeltaRectangles. I accumulate these damage notifications in a GdkRegion in my client, and from time to time a separate socket becomes writeable and I pick a rectangle from my Region, subtract it from the server damage region (to indicate that I would like to re-enable damage notification for that rectangle), and send the image of that rectangle down my socket. This all works nicely, except for B.3: every time I re-enable damage notifications on one rectangle with DamageSubtract, I get a giant flurry of pointless notifications for damage rectangles I have already recorded. Then I handle the next rectangle, and get another flurry... ultimately this makes a simple redraw operation O(n^2), and in real-world cases can cause my program to thrash for several minutes to deliver a single screen update.
The only way DeltaRectangles mode makes any sense to use at all is if one has this basic strategy of accumulating damage locally and issuing DamageSubtract when a piece of it is handled. Given such a strategy, re-issuing notifications is utterly pointless.
A simple but inefficient workaround is to use mode RawRectangles; for this mode the current X server violates the spec and makes DamageSubtract a complete no-op.
I am not entirely certain what the right fix here is:
Option 1: Stop re-issuing notifications, as per B.3, for damage level DeltaRectangles.
Option 2: Just kill B.3 entirely -- never re-issue damage notifications.
Either of these will solve my problem, obviously; the question is which is cleaner, and in particular whether there is any use case where the re-issued damage notifications are valuable. They seem to be in the spec entirely for the benefit of mode NonEmpty, but I can't figure out how one could use them without race conditions. If one is using notification mode NonEmpty, one should be setting repair=None anyway, and avoiding this whole problem... Maybe Keith or Eric, whose names are on the spec, can explain the rationale?
Also, looking through all the different uses of DamageSubtract in google codesearch, it appears that they fall into two classes:
-- traditional cm's, which use NonEmpty and set repair=None, so they take branch A and B.3 is irrelevant.
-- apps that want to keep track of what's on the screen (like xpra, and byzanz, and vino), which use DeltaRectangles and are bitten by this bug.
So just removing damage re-notifications entirely seems like a viable course of action.
Anyway, what I'd request:
-- damage re-issuing be fixed for, at least, DeltaRectangles mode for 7.4
-- the Damage protocol version get bumped to 1.2 so that apps can tell that DeltaRectangles is usable
Let me know if there's anything I can do to help this occur.
[1] http://partiwm.org/wiki/xpra
Version: 7.3 (2007.09)
### Blocking
* [Bug 44202](https://bugs.freedesktop.org/show_bug.cgi?id=44202)Keith PackardKeith Packardhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/337Moving a window generates damage events2019-05-10T18:40:24ZBugzilla Migration UserMoving a window generates damage events## Submitted by Søren Sandmann Pedersen
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#5275)](https://bugs.freedesktop.org/show_bug.cgi?id=5275)**
## Description
Just moving a window around causes damage events to ...## Submitted by Søren Sandmann Pedersen
Assigned to **Adam Jackson `@ajax`**
**[Link to original bug (#5275)](https://bugs.freedesktop.org/show_bug.cgi?id=5275)**
## Description
Just moving a window around causes damage events to be sent to the window
even though no pixels change in it. This happens regardless of whether the
window is redirected or not. See test program.
You could argue that this bug is a special case of a more general "The semantics
of the damage extension is entirely unclear".Adam Jacksonajax@nwnk.netAdam Jacksonajax@nwnk.nethttps://gitlab.freedesktop.org/xorg/xserver/-/issues/331Damage ignores clipping information2019-05-10T18:40:24ZBugzilla Migration UserDamage ignores clipping information## Submitted by Jorn Baayen
Assigned to **Xorg Project Team**
**[Link to original bug (#3785)](https://bugs.freedesktop.org/show_bug.cgi?id=3785)**
## Description
Damage presently ignores GC clipping information, causing damage to...## Submitted by Jorn Baayen
Assigned to **Xorg Project Team**
**[Link to original bug (#3785)](https://bugs.freedesktop.org/show_bug.cgi?id=3785)**
## Description
Damage presently ignores GC clipping information, causing damage to be
overreported. A fix has been committed to kdrive:
http://cvs.freedesktop.org/xserver/xserver/miext/damage/damage.c?r1=1.14&r2=1.15
To this report I'll attach a patch that fixes the same issue for xorg damage,
taking out an earlier fix that partially fixed overreporting. The previous fix
interesected against the window clip list according to the sub window mode. This
is not needed for the new fix because pGC->pCompositeClip is the intersection
between the window (depending on the sub window mode) and client clips already.
One thing I don't understand about the previous fix is why it only clipped when
there was no backing store ?
Version: git