2004-07-29 16:40:33 +02:00
|
|
|
/*
|
2004-12-04 01:43:13 +01:00
|
|
|
* Copyright © 2002 Keith Packard
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
* Copyright 2013 Red Hat, Inc.
|
2004-07-29 16:40:33 +02:00
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
* the above copyright notice appear in all copies and that both that
|
|
|
|
* copyright notice and this permission notice appear in supporting
|
|
|
|
* documentation, and that the name of Keith Packard not be used in
|
|
|
|
* advertising or publicity pertaining to distribution of the software without
|
|
|
|
* specific, written prior permission. Keith Packard makes no
|
|
|
|
* representations about the suitability of this software for any purpose. It
|
|
|
|
* is provided "as is" without express or implied warranty.
|
|
|
|
*
|
|
|
|
* KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
* EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
|
|
|
* PERFORMANCE OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2005-07-03 09:02:09 +02:00
|
|
|
#ifdef HAVE_DIX_CONFIG_H
|
|
|
|
#include <dix-config.h>
|
|
|
|
#endif
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
#include "damageextint.h"
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
#include "damagestr.h"
|
2009-09-18 08:27:54 +02:00
|
|
|
#include "protocol-versions.h"
|
2012-07-10 03:02:56 +02:00
|
|
|
#include "extinit.h"
|
2004-07-29 16:40:33 +02:00
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
#ifdef PANORAMIX
|
|
|
|
#include "panoramiX.h"
|
|
|
|
#include "panoramiXsrv.h"
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
DamageExtPtr ext;
|
|
|
|
DamagePtr damage[MAXSCREENS];
|
|
|
|
} PanoramiXDamageRes;
|
|
|
|
|
|
|
|
static RESTYPE XRT_DAMAGE;
|
|
|
|
static int (*PanoramiXSaveDamageCreate) (ClientPtr);
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
static unsigned char DamageReqCode;
|
|
|
|
static int DamageEventBase;
|
|
|
|
static RESTYPE DamageExtType;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2010-04-27 02:22:21 +02:00
|
|
|
static DevPrivateKeyRec DamageClientPrivateKeyRec;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2010-04-27 02:22:21 +02:00
|
|
|
#define DamageClientPrivateKey (&DamageClientPrivateKeyRec)
|
2008-08-29 00:05:40 +02:00
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
static void
|
|
|
|
DamageNoteCritical(ClientPtr pClient)
|
|
|
|
{
|
|
|
|
DamageClientPtr pDamageClient = GetDamageClient(pClient);
|
|
|
|
|
|
|
|
/* Composite extension marks clients with manual Subwindows as critical */
|
|
|
|
if (pDamageClient->critical > 0) {
|
|
|
|
SetCriticalOutputPending();
|
|
|
|
pClient->smart_priority = SMART_MAX_PRIORITY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
damageGetGeometry(DrawablePtr draw, int *x, int *y, int *w, int *h)
|
|
|
|
{
|
|
|
|
#ifdef PANORAMIX
|
|
|
|
if (!noPanoramiXExtension && draw->type == DRAWABLE_WINDOW) {
|
|
|
|
WindowPtr win = (WindowPtr)draw;
|
|
|
|
|
|
|
|
if (!win->parent) {
|
|
|
|
*x = screenInfo.x;
|
|
|
|
*y = screenInfo.y;
|
|
|
|
*w = screenInfo.width;
|
|
|
|
*h = screenInfo.height;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
*x = draw->x;
|
|
|
|
*y = draw->y;
|
|
|
|
*w = draw->width;
|
|
|
|
*h = draw->height;
|
|
|
|
}
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
static void
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtNotify(DamageExtPtr pDamageExt, BoxPtr pBoxes, int nBoxes)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
ClientPtr pClient = pDamageExt->pClient;
|
|
|
|
DrawablePtr pDrawable = pDamageExt->pDrawable;
|
|
|
|
xDamageNotifyEvent ev;
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
int i, x, y, w, h;
|
|
|
|
|
|
|
|
damageGetGeometry(pDrawable, &x, &y, &w, &h);
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
UpdateCurrentTimeIf();
|
2012-07-10 04:12:44 +02:00
|
|
|
ev = (xDamageNotifyEvent) {
|
|
|
|
.type = DamageEventBase + XDamageNotify,
|
|
|
|
.level = pDamageExt->level,
|
|
|
|
.drawable = pDamageExt->drawable,
|
|
|
|
.damage = pDamageExt->id,
|
|
|
|
.timestamp = currentTime.milliseconds,
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
.geometry.x = x,
|
|
|
|
.geometry.y = y,
|
|
|
|
.geometry.width = w,
|
|
|
|
.geometry.height = h
|
2012-07-10 04:12:44 +02:00
|
|
|
};
|
2012-03-21 20:55:09 +01:00
|
|
|
if (pBoxes) {
|
|
|
|
for (i = 0; i < nBoxes; i++) {
|
|
|
|
ev.level = pDamageExt->level;
|
|
|
|
if (i < nBoxes - 1)
|
|
|
|
ev.level |= DamageNotifyMore;
|
|
|
|
ev.area.x = pBoxes[i].x1;
|
|
|
|
ev.area.y = pBoxes[i].y1;
|
|
|
|
ev.area.width = pBoxes[i].x2 - pBoxes[i].x1;
|
|
|
|
ev.area.height = pBoxes[i].y2 - pBoxes[i].y1;
|
|
|
|
WriteEventsToClient(pClient, 1, (xEvent *) &ev);
|
|
|
|
}
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
else {
|
|
|
|
ev.area.x = 0;
|
|
|
|
ev.area.y = 0;
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
ev.area.width = w;
|
|
|
|
ev.area.height = h;
|
2012-03-21 20:55:09 +01:00
|
|
|
WriteEventsToClient(pClient, 1, (xEvent *) &ev);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
|
|
|
|
DamageNoteCritical(pClient);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtReport(DamagePtr pDamage, RegionPtr pRegion, void *closure)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtPtr pDamageExt = closure;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
switch (pDamageExt->level) {
|
|
|
|
case DamageReportRawRegion:
|
|
|
|
case DamageReportDeltaRegion:
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtNotify(pDamageExt, RegionRects(pRegion),
|
|
|
|
RegionNumRects(pRegion));
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case DamageReportBoundingBox:
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtNotify(pDamageExt, RegionExtents(pRegion), 1);
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case DamageReportNonEmpty:
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtNotify(pDamageExt, NullBox, 0);
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case DamageReportNone:
|
2012-03-21 20:55:09 +01:00
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtDestroy(DamagePtr pDamage, void *closure)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtPtr pDamageExt = closure;
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
pDamageExt->pDamage = 0;
|
|
|
|
if (pDamageExt->id)
|
2012-03-21 20:55:09 +01:00
|
|
|
FreeResource(pDamageExt->id, RT_NONE);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtSetCritical(ClientPtr pClient, Bool critical)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageClientPtr pDamageClient = GetDamageClient(pClient);
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
if (pDamageClient)
|
2012-03-21 20:55:09 +01:00
|
|
|
pDamageClient->critical += critical ? 1 : -1;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ProcDamageQueryVersion(ClientPtr client)
|
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageClientPtr pDamageClient = GetDamageClient(client);
|
2012-07-10 04:12:43 +02:00
|
|
|
xDamageQueryVersionReply rep = {
|
|
|
|
.type = X_Reply,
|
|
|
|
.sequenceNumber = client->sequence,
|
|
|
|
.length = 0
|
|
|
|
};
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST(xDamageQueryVersionReq);
|
|
|
|
|
|
|
|
REQUEST_SIZE_MATCH(xDamageQueryVersionReq);
|
2012-07-10 04:12:43 +02:00
|
|
|
|
2009-09-18 08:27:54 +02:00
|
|
|
if (stuff->majorVersion < SERVER_DAMAGE_MAJOR_VERSION) {
|
2012-03-21 20:55:09 +01:00
|
|
|
rep.majorVersion = stuff->majorVersion;
|
|
|
|
rep.minorVersion = stuff->minorVersion;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
rep.majorVersion = SERVER_DAMAGE_MAJOR_VERSION;
|
|
|
|
if (stuff->majorVersion == SERVER_DAMAGE_MAJOR_VERSION &&
|
|
|
|
stuff->minorVersion < SERVER_DAMAGE_MINOR_VERSION)
|
|
|
|
rep.minorVersion = stuff->minorVersion;
|
|
|
|
else
|
|
|
|
rep.minorVersion = SERVER_DAMAGE_MINOR_VERSION;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
pDamageClient->major_version = rep.majorVersion;
|
|
|
|
pDamageClient->minor_version = rep.minorVersion;
|
|
|
|
if (client->swapped) {
|
2012-03-21 20:55:09 +01:00
|
|
|
swaps(&rep.sequenceNumber);
|
|
|
|
swapl(&rep.length);
|
|
|
|
swapl(&rep.majorVersion);
|
|
|
|
swapl(&rep.minorVersion);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
2012-05-13 09:03:35 +02:00
|
|
|
WriteToClient(client, sizeof(xDamageQueryVersionReply), &rep);
|
2010-05-11 05:22:05 +02:00
|
|
|
return Success;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
static void
|
|
|
|
DamageExtRegister(DrawablePtr pDrawable, DamagePtr pDamage, Bool report)
|
|
|
|
{
|
|
|
|
DamageSetReportAfterOp(pDamage, TRUE);
|
|
|
|
DamageRegister(pDrawable, pDamage);
|
|
|
|
|
|
|
|
if (report) {
|
|
|
|
RegionPtr pRegion = &((WindowPtr) pDrawable)->borderClip;
|
|
|
|
RegionTranslate(pRegion, -pDrawable->x, -pDrawable->y);
|
|
|
|
DamageReportDamage(pDamage, pRegion);
|
|
|
|
RegionTranslate(pRegion, pDrawable->x, pDrawable->y);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static DamageExtPtr
|
|
|
|
DamageExtCreate(DrawablePtr pDrawable, DamageReportLevel level,
|
|
|
|
ClientPtr client, XID id, XID drawable)
|
|
|
|
{
|
|
|
|
DamageExtPtr pDamageExt = malloc(sizeof(DamageExtRec));
|
|
|
|
if (!pDamageExt)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
pDamageExt->id = id;
|
|
|
|
pDamageExt->drawable = drawable;
|
|
|
|
pDamageExt->pDrawable = pDrawable;
|
|
|
|
pDamageExt->level = level;
|
|
|
|
pDamageExt->pClient = client;
|
|
|
|
pDamageExt->pDamage = DamageCreate(DamageExtReport, DamageExtDestroy, level,
|
|
|
|
FALSE, pDrawable->pScreen, pDamageExt);
|
|
|
|
if (!pDamageExt->pDamage) {
|
|
|
|
free(pDamageExt);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-12-15 10:05:51 +01:00
|
|
|
if (!AddResource(id, DamageExtType, (void *) pDamageExt))
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
DamageExtRegister(pDrawable, pDamageExt->pDamage,
|
|
|
|
pDrawable->type == DRAWABLE_WINDOW);
|
|
|
|
|
|
|
|
return pDamageExt;
|
|
|
|
}
|
|
|
|
|
|
|
|
static DamageExtPtr
|
|
|
|
doDamageCreate(ClientPtr client, int *rc)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DrawablePtr pDrawable;
|
|
|
|
DamageExtPtr pDamageExt;
|
|
|
|
DamageReportLevel level;
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST(xDamageCreateReq);
|
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
*rc = dixLookupDrawable(&pDrawable, stuff->drawable, client, 0,
|
|
|
|
DixGetAttrAccess | DixReadAccess);
|
|
|
|
if (*rc != Success)
|
|
|
|
return NULL;
|
2006-12-14 23:53:43 +01:00
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
switch (stuff->level) {
|
|
|
|
case XDamageReportRawRectangles:
|
2012-03-21 20:55:09 +01:00
|
|
|
level = DamageReportRawRegion;
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case XDamageReportDeltaRectangles:
|
2012-03-21 20:55:09 +01:00
|
|
|
level = DamageReportDeltaRegion;
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case XDamageReportBoundingBox:
|
2012-03-21 20:55:09 +01:00
|
|
|
level = DamageReportBoundingBox;
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
case XDamageReportNonEmpty:
|
2012-03-21 20:55:09 +01:00
|
|
|
level = DamageReportNonEmpty;
|
|
|
|
break;
|
2004-07-29 16:40:33 +02:00
|
|
|
default:
|
2012-03-21 20:55:09 +01:00
|
|
|
client->errorValue = stuff->level;
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
*rc = BadValue;
|
|
|
|
return NULL;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
pDamageExt = DamageExtCreate(pDrawable, level, client, stuff->damage,
|
|
|
|
stuff->drawable);
|
2004-07-29 16:40:33 +02:00
|
|
|
if (!pDamageExt)
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
*rc = BadAlloc;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
return pDamageExt;
|
|
|
|
}
|
2004-07-29 16:40:33 +02:00
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
static int
|
|
|
|
ProcDamageCreate(ClientPtr client)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
REQUEST(xDamageCreateReq);
|
|
|
|
REQUEST_SIZE_MATCH(xDamageCreateReq);
|
|
|
|
LEGAL_NEW_RESOURCE(stuff->damage, client);
|
|
|
|
doDamageCreate(client, &rc);
|
|
|
|
return rc;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2012-03-21 20:55:09 +01:00
|
|
|
ProcDamageDestroy(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageDestroyReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtPtr pDamageExt;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
REQUEST_SIZE_MATCH(xDamageDestroyReq);
|
2006-12-14 20:45:42 +01:00
|
|
|
VERIFY_DAMAGEEXT(pDamageExt, stuff->damage, client, DixWriteAccess);
|
2012-03-21 20:55:09 +01:00
|
|
|
FreeResource(stuff->damage, RT_NONE);
|
2010-05-11 05:22:05 +02:00
|
|
|
return Success;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
#ifdef PANORAMIX
|
|
|
|
static RegionPtr
|
|
|
|
DamageExtSubtractWindowClip(DamageExtPtr pDamageExt)
|
|
|
|
{
|
|
|
|
WindowPtr win = (WindowPtr)pDamageExt->pDrawable;
|
|
|
|
PanoramiXRes *res = NULL;
|
|
|
|
RegionPtr ret;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!win->parent)
|
|
|
|
return &PanoramiXScreenRegion;
|
|
|
|
|
|
|
|
dixLookupResourceByType((void **)&res, win->drawable.id, XRT_WINDOW,
|
|
|
|
serverClient, DixReadAccess);
|
|
|
|
if (!res)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
ret = RegionCreate(NULL, 0);
|
|
|
|
if (!ret)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
FOR_NSCREENS_FORWARD(i) {
|
|
|
|
ScreenPtr screen;
|
|
|
|
if (Success != dixLookupWindow(&win, res->info[i].id, serverClient,
|
|
|
|
DixReadAccess))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
screen = win->drawable.pScreen;
|
|
|
|
|
|
|
|
RegionTranslate(ret, -screen->x, -screen->y);
|
|
|
|
if (!RegionUnion(ret, ret, &win->borderClip))
|
|
|
|
goto out;
|
|
|
|
RegionTranslate(ret, screen->x, screen->y);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
out:
|
|
|
|
RegionDestroy(ret);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
DamageExtFreeWindowClip(RegionPtr reg)
|
|
|
|
{
|
|
|
|
if (reg != &PanoramiXScreenRegion)
|
|
|
|
RegionDestroy(reg);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* DamageSubtract intersects with borderClip, so we must reconstruct the
|
|
|
|
* protocol's perspective of same...
|
|
|
|
*/
|
|
|
|
static Bool
|
|
|
|
DamageExtSubtract(DamageExtPtr pDamageExt, const RegionPtr pRegion)
|
|
|
|
{
|
|
|
|
DamagePtr pDamage = pDamageExt->pDamage;
|
|
|
|
|
|
|
|
#ifdef PANORAMIX
|
|
|
|
if (!noPanoramiXExtension) {
|
|
|
|
RegionPtr damage = DamageRegion(pDamage);
|
|
|
|
RegionSubtract(damage, damage, pRegion);
|
|
|
|
|
|
|
|
if (pDamageExt->pDrawable->type == DRAWABLE_WINDOW) {
|
|
|
|
DrawablePtr pDraw = pDamageExt->pDrawable;
|
|
|
|
RegionPtr clip = DamageExtSubtractWindowClip(pDamageExt);
|
|
|
|
if (clip) {
|
|
|
|
RegionTranslate(clip, -pDraw->x, -pDraw->y);
|
|
|
|
RegionIntersect(damage, damage, clip);
|
|
|
|
RegionTranslate(clip, pDraw->x, pDraw->y);
|
|
|
|
DamageExtFreeWindowClip(clip);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return RegionNotEmpty(damage);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return DamageSubtract(pDamage, pRegion);
|
|
|
|
}
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
static int
|
2012-03-21 20:55:09 +01:00
|
|
|
ProcDamageSubtract(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageSubtractReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtPtr pDamageExt;
|
|
|
|
RegionPtr pRepair;
|
|
|
|
RegionPtr pParts;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
REQUEST_SIZE_MATCH(xDamageSubtractReq);
|
2006-12-14 20:45:42 +01:00
|
|
|
VERIFY_DAMAGEEXT(pDamageExt, stuff->damage, client, DixWriteAccess);
|
|
|
|
VERIFY_REGION_OR_NONE(pRepair, stuff->repair, client, DixWriteAccess);
|
|
|
|
VERIFY_REGION_OR_NONE(pParts, stuff->parts, client, DixWriteAccess);
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
if (pDamageExt->level != DamageReportRawRegion) {
|
|
|
|
DamagePtr pDamage = pDamageExt->pDamage;
|
|
|
|
|
|
|
|
if (pRepair) {
|
|
|
|
if (pParts)
|
|
|
|
RegionIntersect(pParts, DamageRegion(pDamage), pRepair);
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
if (DamageExtSubtract(pDamageExt, pRepair))
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtReport(pDamage, DamageRegion(pDamage),
|
|
|
|
(void *) pDamageExt);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (pParts)
|
|
|
|
RegionCopy(pParts, DamageRegion(pDamage));
|
|
|
|
DamageEmpty(pDamage);
|
|
|
|
}
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
|
2010-05-11 05:22:05 +02:00
|
|
|
return Success;
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
2007-01-06 03:12:04 +01:00
|
|
|
static int
|
2012-03-21 20:55:09 +01:00
|
|
|
ProcDamageAdd(ClientPtr client)
|
2007-01-06 03:12:04 +01:00
|
|
|
{
|
2007-01-10 01:34:40 +01:00
|
|
|
REQUEST(xDamageAddReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
DrawablePtr pDrawable;
|
|
|
|
RegionPtr pRegion;
|
|
|
|
int rc;
|
2007-01-06 03:12:04 +01:00
|
|
|
|
2007-01-10 01:34:40 +01:00
|
|
|
REQUEST_SIZE_MATCH(xDamageAddReq);
|
2007-01-06 03:12:04 +01:00
|
|
|
VERIFY_REGION(pRegion, stuff->region, client, DixWriteAccess);
|
|
|
|
rc = dixLookupDrawable(&pDrawable, stuff->drawable, client, 0,
|
2012-03-21 20:55:09 +01:00
|
|
|
DixWriteAccess);
|
2007-01-06 03:12:04 +01:00
|
|
|
if (rc != Success)
|
2012-03-21 20:55:09 +01:00
|
|
|
return rc;
|
2007-01-06 03:12:04 +01:00
|
|
|
|
|
|
|
/* The region is relative to the drawable origin, so translate it out to
|
|
|
|
* screen coordinates like damage expects.
|
|
|
|
*/
|
2010-05-22 00:05:48 +02:00
|
|
|
RegionTranslate(pRegion, pDrawable->x, pDrawable->y);
|
2010-10-29 05:46:22 +02:00
|
|
|
DamageDamageRegion(pDrawable, pRegion);
|
2010-05-22 00:05:48 +02:00
|
|
|
RegionTranslate(pRegion, -pDrawable->x, -pDrawable->y);
|
2007-01-06 03:12:04 +01:00
|
|
|
|
2010-05-11 05:22:05 +02:00
|
|
|
return Success;
|
2007-01-06 03:12:04 +01:00
|
|
|
}
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
/* Major version controls available requests */
|
|
|
|
static const int version_requests[] = {
|
2012-03-21 20:55:09 +01:00
|
|
|
X_DamageQueryVersion, /* before client sends QueryVersion */
|
|
|
|
X_DamageAdd, /* Version 1 */
|
2004-07-29 16:40:33 +02:00
|
|
|
};
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
static int (*ProcDamageVector[XDamageNumberRequests]) (ClientPtr) = {
|
2013-08-22 22:42:23 +02:00
|
|
|
/*************** Version 1 ******************/
|
2004-07-29 16:40:33 +02:00
|
|
|
ProcDamageQueryVersion,
|
2013-08-22 22:42:23 +02:00
|
|
|
ProcDamageCreate,
|
|
|
|
ProcDamageDestroy,
|
|
|
|
ProcDamageSubtract,
|
|
|
|
/*************** Version 1.1 ****************/
|
|
|
|
ProcDamageAdd,
|
|
|
|
};
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
static int
|
2012-03-21 20:55:09 +01:00
|
|
|
ProcDamageDispatch(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageClientPtr pDamageClient = GetDamageClient(client);
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2017-10-27 16:11:56 +02:00
|
|
|
if (pDamageClient->major_version >= ARRAY_SIZE(version_requests))
|
2012-03-21 20:55:09 +01:00
|
|
|
return BadRequest;
|
2004-07-29 16:40:33 +02:00
|
|
|
if (stuff->damageReqType > version_requests[pDamageClient->major_version])
|
2012-03-21 20:55:09 +01:00
|
|
|
return BadRequest;
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2004-07-29 16:40:33 +02:00
|
|
|
SProcDamageQueryVersion(ClientPtr client)
|
|
|
|
{
|
|
|
|
REQUEST(xDamageQueryVersionReq);
|
|
|
|
|
2011-08-04 21:35:41 +02:00
|
|
|
swaps(&stuff->length);
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST_SIZE_MATCH(xDamageQueryVersionReq);
|
2011-08-04 21:35:41 +02:00
|
|
|
swapl(&stuff->majorVersion);
|
|
|
|
swapl(&stuff->minorVersion);
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SProcDamageCreate(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageCreateReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2011-08-04 21:35:41 +02:00
|
|
|
swaps(&stuff->length);
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST_SIZE_MATCH(xDamageCreateReq);
|
2011-08-04 21:35:41 +02:00
|
|
|
swapl(&stuff->damage);
|
|
|
|
swapl(&stuff->drawable);
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SProcDamageDestroy(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageDestroyReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2011-08-04 21:35:41 +02:00
|
|
|
swaps(&stuff->length);
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST_SIZE_MATCH(xDamageDestroyReq);
|
2011-08-04 21:35:41 +02:00
|
|
|
swapl(&stuff->damage);
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SProcDamageSubtract(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageSubtractReq);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2011-08-04 21:35:41 +02:00
|
|
|
swaps(&stuff->length);
|
2004-07-29 16:40:33 +02:00
|
|
|
REQUEST_SIZE_MATCH(xDamageSubtractReq);
|
2011-08-04 21:35:41 +02:00
|
|
|
swapl(&stuff->damage);
|
|
|
|
swapl(&stuff->repair);
|
|
|
|
swapl(&stuff->parts);
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SProcDamageAdd(ClientPtr client)
|
2007-01-06 03:12:04 +01:00
|
|
|
{
|
2007-01-10 01:34:40 +01:00
|
|
|
REQUEST(xDamageAddReq);
|
2007-01-06 03:12:04 +01:00
|
|
|
|
2011-08-04 21:35:41 +02:00
|
|
|
swaps(&stuff->length);
|
2007-01-06 03:12:04 +01:00
|
|
|
REQUEST_SIZE_MATCH(xDamageSubtractReq);
|
2011-08-04 21:35:41 +02:00
|
|
|
swapl(&stuff->drawable);
|
|
|
|
swapl(&stuff->region);
|
2007-01-06 03:12:04 +01:00
|
|
|
return (*ProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
static int (*SProcDamageVector[XDamageNumberRequests]) (ClientPtr) = {
|
2013-08-22 22:42:23 +02:00
|
|
|
/*************** Version 1 ******************/
|
2004-07-29 16:40:33 +02:00
|
|
|
SProcDamageQueryVersion,
|
2013-08-22 22:42:23 +02:00
|
|
|
SProcDamageCreate,
|
|
|
|
SProcDamageDestroy,
|
|
|
|
SProcDamageSubtract,
|
|
|
|
/*************** Version 1.1 ****************/
|
|
|
|
SProcDamageAdd,
|
|
|
|
};
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static int _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SProcDamageDispatch(ClientPtr client)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
REQUEST(xDamageReq);
|
|
|
|
if (stuff->damageReqType >= XDamageNumberRequests)
|
2012-03-21 20:55:09 +01:00
|
|
|
return BadRequest;
|
2004-07-29 16:40:33 +02:00
|
|
|
return (*SProcDamageVector[stuff->damageReqType]) (client);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2013-12-15 10:05:51 +01:00
|
|
|
FreeDamageExt(void *value, XID did)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtPtr pDamageExt = (DamageExtPtr) value;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get rid of the resource table entry hanging from the window id
|
|
|
|
*/
|
|
|
|
pDamageExt->id = 0;
|
2012-03-21 20:55:09 +01:00
|
|
|
if (pDamageExt->pDamage) {
|
|
|
|
DamageDestroy(pDamageExt->pDamage);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
2010-05-05 20:44:06 +02:00
|
|
|
free(pDamageExt);
|
2004-07-29 16:40:33 +02:00
|
|
|
return Success;
|
|
|
|
}
|
|
|
|
|
2017-02-16 20:56:45 +01:00
|
|
|
static void _X_COLD
|
2012-03-21 20:55:09 +01:00
|
|
|
SDamageNotifyEvent(xDamageNotifyEvent * from, xDamageNotifyEvent * to)
|
2004-07-29 16:40:33 +02:00
|
|
|
{
|
|
|
|
to->type = from->type;
|
2012-03-21 20:55:09 +01:00
|
|
|
cpswaps(from->sequenceNumber, to->sequenceNumber);
|
|
|
|
cpswapl(from->drawable, to->drawable);
|
|
|
|
cpswapl(from->damage, to->damage);
|
|
|
|
cpswaps(from->area.x, to->area.x);
|
|
|
|
cpswaps(from->area.y, to->area.y);
|
|
|
|
cpswaps(from->area.width, to->area.width);
|
|
|
|
cpswaps(from->area.height, to->area.height);
|
|
|
|
cpswaps(from->geometry.x, to->geometry.x);
|
|
|
|
cpswaps(from->geometry.y, to->geometry.y);
|
|
|
|
cpswaps(from->geometry.width, to->geometry.width);
|
|
|
|
cpswaps(from->geometry.height, to->geometry.height);
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|
|
|
|
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
#ifdef PANORAMIX
|
|
|
|
|
|
|
|
static void
|
|
|
|
PanoramiXDamageReport(DamagePtr pDamage, RegionPtr pRegion, void *closure)
|
|
|
|
{
|
|
|
|
PanoramiXDamageRes *res = closure;
|
|
|
|
DamageExtPtr pDamageExt = res->ext;
|
|
|
|
WindowPtr pWin = (WindowPtr)pDamage->pDrawable;
|
|
|
|
ScreenPtr pScreen = pDamage->pScreen;
|
|
|
|
|
|
|
|
/* happens on unmap? sigh xinerama */
|
|
|
|
if (RegionNil(pRegion))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* translate root windows if necessary */
|
|
|
|
if (!pWin->parent)
|
|
|
|
RegionTranslate(pRegion, pScreen->x, pScreen->y);
|
|
|
|
|
|
|
|
/* add our damage to the protocol view */
|
|
|
|
DamageReportDamage(pDamageExt->pDamage, pRegion);
|
|
|
|
|
|
|
|
/* empty our view */
|
|
|
|
DamageEmpty(pDamage);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
PanoramiXDamageExtDestroy(DamagePtr pDamage, void *closure)
|
|
|
|
{
|
|
|
|
PanoramiXDamageRes *damage = closure;
|
|
|
|
damage->damage[pDamage->pScreen->myNum] = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
PanoramiXDamageCreate(ClientPtr client)
|
|
|
|
{
|
|
|
|
PanoramiXDamageRes *damage;
|
|
|
|
PanoramiXRes *draw;
|
|
|
|
int i, rc;
|
|
|
|
|
|
|
|
REQUEST(xDamageCreateReq);
|
|
|
|
|
|
|
|
REQUEST_SIZE_MATCH(xDamageCreateReq);
|
|
|
|
LEGAL_NEW_RESOURCE(stuff->damage, client);
|
|
|
|
rc = dixLookupResourceByClass((void **)&draw, stuff->drawable, XRC_DRAWABLE,
|
|
|
|
client, DixGetAttrAccess | DixReadAccess);
|
|
|
|
if (rc != Success)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
if (!(damage = calloc(1, sizeof(PanoramiXDamageRes))))
|
|
|
|
return BadAlloc;
|
|
|
|
|
|
|
|
if (!AddResource(stuff->damage, XRT_DAMAGE, damage))
|
|
|
|
return BadAlloc;
|
|
|
|
|
|
|
|
damage->ext = doDamageCreate(client, &rc);
|
|
|
|
if (rc == Success && draw->type == XRT_WINDOW) {
|
|
|
|
FOR_NSCREENS_FORWARD(i) {
|
|
|
|
DrawablePtr pDrawable;
|
|
|
|
DamagePtr pDamage = DamageCreate(PanoramiXDamageReport,
|
|
|
|
PanoramiXDamageExtDestroy,
|
|
|
|
DamageReportRawRegion,
|
|
|
|
FALSE,
|
|
|
|
screenInfo.screens[i],
|
|
|
|
damage);
|
|
|
|
if (!pDamage) {
|
|
|
|
rc = BadAlloc;
|
|
|
|
} else {
|
|
|
|
damage->damage[i] = pDamage;
|
|
|
|
rc = dixLookupDrawable(&pDrawable, draw->info[i].id, client,
|
|
|
|
M_WINDOW,
|
|
|
|
DixGetAttrAccess | DixReadAccess);
|
|
|
|
}
|
|
|
|
if (rc != Success)
|
|
|
|
break;
|
|
|
|
|
|
|
|
DamageExtRegister(pDrawable, pDamage, i != 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rc != Success)
|
|
|
|
FreeResource(stuff->damage, RT_NONE);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
PanoramiXDamageDelete(void *res, XID id)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
PanoramiXDamageRes *damage = res;
|
|
|
|
|
|
|
|
FOR_NSCREENS_BACKWARD(i) {
|
|
|
|
if (damage->damage[i]) {
|
|
|
|
DamageDestroy(damage->damage[i]);
|
|
|
|
damage->damage[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
free(damage);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
PanoramiXDamageInit(void)
|
|
|
|
{
|
|
|
|
XRT_DAMAGE = CreateNewResourceType(PanoramiXDamageDelete, "XineramaDamage");
|
2013-12-09 19:16:01 +01:00
|
|
|
if (!XRT_DAMAGE)
|
|
|
|
FatalError("Couldn't Xineramify Damage extension\n");
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
|
|
|
|
PanoramiXSaveDamageCreate = ProcDamageVector[X_DamageCreate];
|
|
|
|
ProcDamageVector[X_DamageCreate] = PanoramiXDamageCreate;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
PanoramiXDamageReset(void)
|
|
|
|
{
|
|
|
|
ProcDamageVector[X_DamageCreate] = PanoramiXSaveDamageCreate;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* PANORAMIX */
|
|
|
|
|
2004-07-29 16:40:33 +02:00
|
|
|
void
|
|
|
|
DamageExtensionInit(void)
|
|
|
|
{
|
|
|
|
ExtensionEntry *extEntry;
|
2012-03-21 20:55:09 +01:00
|
|
|
int s;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
|
|
|
for (s = 0; s < screenInfo.numScreens; s++)
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageSetup(screenInfo.screens[s]);
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageExtType = CreateNewResourceType(FreeDamageExt, "DamageExt");
|
2004-07-29 16:40:33 +02:00
|
|
|
if (!DamageExtType)
|
2012-03-21 20:55:09 +01:00
|
|
|
return;
|
2004-07-29 16:40:33 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
if (!dixRegisterPrivateKey
|
|
|
|
(&DamageClientPrivateKeyRec, PRIVATE_CLIENT, sizeof(DamageClientRec)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if ((extEntry = AddExtension(DAMAGE_NAME, XDamageNumberEvents,
|
|
|
|
XDamageNumberErrors,
|
|
|
|
ProcDamageDispatch, SProcDamageDispatch,
|
2016-04-18 18:56:17 +02:00
|
|
|
NULL, StandardMinorOpcode)) != 0) {
|
2012-03-21 20:55:09 +01:00
|
|
|
DamageReqCode = (unsigned char) extEntry->base;
|
|
|
|
DamageEventBase = extEntry->eventBase;
|
|
|
|
EventSwapVector[DamageEventBase + XDamageNotify] =
|
|
|
|
(EventSwapPtr) SDamageNotifyEvent;
|
|
|
|
SetResourceTypeErrorValue(DamageExtType,
|
|
|
|
extEntry->errorBase + BadDamage);
|
damageext: Xineramify (v7)
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
2013-09-16 21:17:26 +02:00
|
|
|
#ifdef PANORAMIX
|
|
|
|
if (XRT_DAMAGE)
|
|
|
|
SetResourceTypeErrorValue(XRT_DAMAGE,
|
|
|
|
extEntry->errorBase + BadDamage);
|
|
|
|
#endif
|
2007-11-20 23:31:00 +01:00
|
|
|
}
|
2004-07-29 16:40:33 +02:00
|
|
|
}
|