[PATCH] dri2: Invalidate DRI2Buffers upon SetWindowPixmap updates

2012-09-30 Thread Chris Wilson 
When transitioning to a redirected or unredirected Window, the Composite
layer modifies the Window's Pixmap. However, the DRI2Buffer for the
Drawable is still pointing to the backing bo of the old Pixmap with the
result that rendering goes astray.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Reinis Danne reinis.da...@gmail.com
---
 hw/xfree86/dri2/dri2.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 804664e..063a351 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -133,6 +133,7 @@ typedef struct _DRI2Screen {
 DRI2AsyncSwapProcPtr AsyncSwap;
 
 ConfigNotifyProcPtr ConfigNotify;
+SetWindowPixmapProcPtr SetWindowPixmap;
 DRI2CreateBuffer2ProcPtr CreateBuffer2;
 DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
 DRI2CopyRegion2ProcPtr CopyRegion2;
@@ -1417,6 +1418,21 @@ DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w, 
int h, int bw,
 return Success;
 }
 
+static void
+DRI2SetWindowPixmap(WindowPtr pWin, PixmapPtr pPix)
+{
+DrawablePtr pDraw = (DrawablePtr) pWin;
+ScreenPtr pScreen = pDraw-pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
+(*pScreen-SetWindowPixmap) (pWin, pPix);
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
+DRI2Invalidate(pDraw);
+}
+
 #define MAX_PRIME DRI2DriverPrimeMask
 static int
 get_prime_id(void)
@@ -1569,6 +1585,9 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 ds-ConfigNotify = pScreen-ConfigNotify;
 pScreen-ConfigNotify = DRI2ConfigNotify;
 
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
 xf86DrvMsg(pScreen-myNum, X_INFO, [DRI2] Setup complete\n);
 for (i = 0; i  sizeof(driverTypeNames) / sizeof(driverTypeNames[0]); i++) 
{
 if (i  ds-numDrivers  ds-driverNames[i]) {
@@ -1593,6 +1612,7 @@ DRI2CloseScreen(ScreenPtr pScreen)
 DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
 
 pScreen-ConfigNotify = ds-ConfigNotify;
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
 
 if (ds-prime_id)
 prime_id_allocate_bitmask = ~(1  ds-prime_id);
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Bug#686153: [PATCH] int10: fix pci_device_read_rom usage

2012-09-30 Thread Julien Cristau 
Keith, could you pick up this patch?

Thanks,
Julien

On Wed, Aug 29, 2012 at 20:03:58 +0200, Julien Cristau wrote:

 From: Stephan Schreiber i...@fs-driver.org
 
 I noticed that the build-in int10 driver always reports
 Unable to retrieve all of segment 0x0C.
 even though the entire BIOS data is retrieved with success.
 
 The associated code is in hw/xfree86/int10/generic.c, in the function
 xf86ExtendedInitInt10():
 
 if (pci_device_read_rom(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
 xf86DrvMsg(screen, X_WARNING,
Unable to retrieve all of segment 0x0C.\n);
 }
 
 The function pci_device_read_rom() is from libpciaccess; its return
 value is not a size but an error status code: 0 means success.
 If pci_device_read_rom() returns 0 for success, the warning is generated.
 
 The proposed patch corrects the evaluation of the return value of
 pci_device_read_rom() and of the supplied BIOS size.
 
 Debian bug#686153
 
 Signed-off-by: Julien Cristau jcris...@debian.org
 ---
  hw/xfree86/int10/generic.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
 index 4633120..d7594de 100644
 --- a/hw/xfree86/int10/generic.c
 +++ b/hw/xfree86/int10/generic.c
 @@ -178,7 +178,8 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
   */
  vbiosMem = (char *) base + V_BIOS;
  memset(vbiosMem, 0, 2 * V_BIOS_SIZE);
 -if (pci_device_read_rom(pInt-dev, vbiosMem)  V_BIOS_SIZE) {
 +if (pci_device_read_rom(pInt-dev, vbiosMem) != 0
 +|| pInt-dev-rom_size  V_BIOS_SIZE) {
  xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
 Unable to retrieve all of segment 0x0C.\n);
  }
 -- 
 1.7.10.4


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 2/2] dri2: Export DRI2InvalidateDrawableAll()

2012-09-30 Thread Chris Wilson 
There may be multiple clients running concurrently with the same set of
buffers, for example an OpenGL game and a redirected OpenGL compositor.
Under the normal circumstances the game has its view of the buffers kept
consistent through the use of invalidate events and throttling. However,
the compositor is not limited by the throttling and so may call
GetBuffers() immediately after the invalidate event in SwapBuffers() and
yet before the actual exchange has occurred. By exporting the invalidate
method, the drivers can notify the clients of the updated buffers at the
right point in the event sequence, notably before the compositor is
informed of the damage.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Reinis Danne reinis.da...@gmail.com
---
 hw/xfree86/dri2/dri2.c |2 +-
 hw/xfree86/dri2/dri2.h |4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 53ef83c..c4705e9 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -782,7 +782,7 @@ DRI2InvalidateWalk(WindowPtr pWin, pointer data)
 return WT_WALKCHILDREN;
 }
 
-static void
+void
 DRI2InvalidateDrawableAll(DrawablePtr pDraw)
 {
 if (pDraw-type == DRAWABLE_WINDOW) {
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 64538ea..5804e30 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -379,4 +379,8 @@ extern _X_EXPORT int DRI2GetParam(ClientPtr client,
   CARD64 *value);
 
 extern _X_EXPORT DrawablePtr DRI2UpdatePrime(DrawablePtr pDraw, DRI2BufferPtr 
pDest);
+
+extern _X_EXPORT void DRI2InvalidateDrawableAll(DrawablePtr pDraw);
+#define DRI2_HAS_INVALIDATE_DRAWABLE 1
+
 #endif
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 1/2] dri2: Invalidate DRI2Buffers upon SetWindowPixmap updates

2012-09-30 Thread Chris Wilson 
When transitioning to a redirected or unredirected Window, the Composite
layer modifies the Window's Pixmap. However, the DRI2Buffer for the
Drawable is still pointing to the backing bo of the old Pixmap with the
result that rendering goes astray.

v2: Fixup the function name after rebasing

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Reinis Danne reinis.da...@gmail.com
---
 hw/xfree86/dri2/dri2.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 1a416a3..53ef83c 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -133,6 +133,7 @@ typedef struct _DRI2Screen {
 DRI2AsyncSwapProcPtr AsyncSwap;
 
 ConfigNotifyProcPtr ConfigNotify;
+SetWindowPixmapProcPtr SetWindowPixmap;
 DRI2CreateBuffer2ProcPtr CreateBuffer2;
 DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
 DRI2CopyRegion2ProcPtr CopyRegion2;
@@ -1416,6 +1417,21 @@ DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w, 
int h, int bw,
 return Success;
 }
 
+static void
+DRI2SetWindowPixmap(WindowPtr pWin, PixmapPtr pPix)
+{
+DrawablePtr pDraw = (DrawablePtr) pWin;
+ScreenPtr pScreen = pDraw-pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
+(*pScreen-SetWindowPixmap) (pWin, pPix);
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
+DRI2InvalidateDrawableAll(pDraw);
+}
+
 #define MAX_PRIME DRI2DriverPrimeMask
 static int
 get_prime_id(void)
@@ -1568,6 +1584,9 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 ds-ConfigNotify = pScreen-ConfigNotify;
 pScreen-ConfigNotify = DRI2ConfigNotify;
 
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
 xf86DrvMsg(pScreen-myNum, X_INFO, [DRI2] Setup complete\n);
 for (i = 0; i  sizeof(driverTypeNames) / sizeof(driverTypeNames[0]); i++) 
{
 if (i  ds-numDrivers  ds-driverNames[i]) {
@@ -1592,6 +1611,7 @@ DRI2CloseScreen(ScreenPtr pScreen)
 DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
 
 pScreen-ConfigNotify = ds-ConfigNotify;
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
 
 if (ds-prime_id)
 prime_id_allocate_bitmask = ~(1  ds-prime_id);
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] configure: Stop using AM_MAINTAINER_MODE

2012-09-30 Thread Gaetan Nadon 
On 12-09-29 04:37 PM, Dan Nicholson wrote:

  Some distros may prefer maintainer mode. A way to appease everyone is:
 
  AM_MAINTAINER_MODE([enable])

 Oh, yeah. That would be the best.

The historical background is that mode was added as a CVS tarball
timestamp loss workaround before the git days. Whoever wishes to keep
this workaround should demonstrate that they extract tarballs from CVS
and want to prevent the build to re-create the configuration because the
timestamp was lost and files appear to be out-of-date.

The most desirable option is to remove both the --enable-maintainer-mode
parameter in autohen.sh (to avoid introducing a new warning) and the
AM_MAINTAINER_MODE statement in configure.ac. This will relieve  people
who edit configure.ac from a tarball. As it is today, the configuration
is not re-creared. That is  why people insisted on keeping autogen.sh in
tarballs, which was a workaround to the CVS workaround.

Peter is right, it should be done in all the repos.

The patch is incomplete. It will introduce a new warning as the option
--enable-maintainer-mode is not recognized because of the missing
AM_MAINTAINER_MODE statement. If the statement is amended with the
enable parameter, then the CVS workaround is disabled. This will not
stop, however, other people from proposing the restoration of the
workaround, asking questions, and reopening the discussion many times
over the next few decades. Might as well take in out of the files and
out of sight.

The burden of the proof lies on some distros.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel