Re: [Mesa-dev] [PATCH] glxproto: make GLX swap event struct match spec
On Wed, 2011-05-04 at 16:16 -0700, Jesse Barnes wrote: On Wed, 04 May 2011 15:17:31 -0700 Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2011 12:21 PM, Jesse Barnes wrote: We only spec a 32 bit swap count, so drop the high sbc field. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Is there any way we could do this and NOT break building older versions of Mesa? I'd like to be able to build 7.9, 7.10, and master on my system without having two different versions of glproto. We did that the last time glproto bumped (kept the req at 1.4.10 and added ifdefs), but that added bugs that we didn't find for awhile, so I wanted to try to avoid it this time. Another option for you would be to build 7.9, 7.10, and master against different install roots with PKG_CONFIG_PATH set appropriately... How about you try again, with an increased emphasis on not adding bugs, now that you know what you did wrong the first time? Dave. ___ 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: xf86-video-ati page flipping fixes
On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ 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 xf86-video-ati 1/2] dri2: Update front buffer pixmap and name before exchanging buffers
On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote:
Buffer exchange assumes that the front buffer pixmap and name
information is accurate. That may not be the case eg. if the window
has been (un)redirected since the buffer was created.
Signed-off-by: Ville Syrjala syrj...@sci.fi
---
src/radeon_dri2.c | 45 -
1 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index e618cc5..5d1a382 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -626,12 +626,42 @@ radeon_dri2_schedule_flip(ScrnInfoPtr scrn, ClientPtr
client,
}
static Bool
-can_exchange(ScrnInfoPtr pScrn,
+update_front(DrawablePtr draw, DRI2BufferPtr front)
+{
+int r;
+PixmapPtr pixmap;
+struct dri2_buffer_priv *priv = front-driverPrivate;
+struct radeon_exa_pixmap_priv *driver_priv;
+
+if (draw-type == DRAWABLE_PIXMAP)
+ pixmap = (PixmapPtr)draw;
+else
+ pixmap = (*draw-pScreen-GetWindowPixmap)((WindowPtr)draw);
+
+pixmap-refcnt++;
+
+exaMoveInPixmap(pixmap);
+driver_priv = exaGetPixmapDriverPrivate(pixmap);
+r = radeon_gem_get_kernel_name(driver_priv-bo, front-name);
+if (r) {
+ (*draw-pScreen-DestroyPixmap)(pixmap);
+ return FALSE;
+}
+(*draw-pScreen-DestroyPixmap)(priv-pixmap);
+front-pitch = pixmap-devKind;
+front-cpp = pixmap-drawable.bitsPerPixel / 8;
+priv-pixmap = pixmap;
+
+return TRUE;
+}
Maybe at least some of this could be short-circuited if it's still the
same pixmap.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
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 0/6] XKB event regression fixes and cleanup
On Thu, May 05, 2011 at 02:34:05AM +0100, Daniel Stone wrote: This series cleans up XKB event sending a bit, and hopefully fixes a couple of regressions from f06a9d. If these seem happy in master then I'll nominate them for stable branches too. Oh, and for those of you who prefer branches, all of these (as well as the missing two commits from Peter's previous pull request) are available in my for-peter tree, which is based on top of Peter's for-keith. Cheers, Daniel ___ 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] Added confine protocol.
---
XI2proto.h | 83 ---
1 files changed, 62 insertions(+), 21 deletions(-)
diff --git a/XI2proto.h b/XI2proto.h
index 84574a5..5ded2f3 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -71,27 +71,29 @@
/**
* XI2 Request opcodes
*/
-#define X_XIQueryPointer40
-#define X_XIWarpPointer 41
-#define X_XIChangeCursor42
-#define X_XIChangeHierarchy 43
-#define X_XISetClientPointer44
-#define X_XIGetClientPointer45
-#define X_XISelectEvents46
-#define X_XIQueryVersion47
-#define X_XIQueryDevice 48
-#define X_XISetFocus49
-#define X_XIGetFocus50
-#define X_XIGrabDevice 51
-#define X_XIUngrabDevice52
-#define X_XIAllowEvents 53
-#define X_XIPassiveGrabDevice 54
-#define X_XIPassiveUngrabDevice 55
-#define X_XIListProperties 56
-#define X_XIChangeProperty 57
-#define X_XIDeleteProperty 58
-#define X_XIGetProperty 59
-#define X_XIGetSelectedEvents 60
+#define X_XIQueryPointer 40
+#define X_XIWarpPointer 41
+#define X_XIChangeCursor 42
+#define X_XIChangeHierarchy 43
+#define X_XISetClientPointer 44
+#define X_XIGetClientPointer 45
+#define X_XISelectEvents 46
+#define X_XIQueryVersion 47
+#define X_XIQueryDevice 48
+#define X_XISetFocus 49
+#define X_XIGetFocus 50
+#define X_XIGrabDevice 51
+#define X_XIUngrabDevice 52
+#define X_XIAllowEvents 53
+#define X_XIPassiveGrabDevice54
+#define X_XIPassiveUngrabDevice 55
+#define X_XIListProperties 56
+#define X_XIChangeProperty 57
+#define X_XIDeleteProperty 58
+#define X_XIGetProperty 59
+#define X_XIGetSelectedEvents60
+#define X_XIGrabDeviceWithConfine61
+#define X_XIPassiveGrabDeviceWithConfine 62
/** Number of XI requests */
#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
@@ -569,6 +571,25 @@ typedef struct {
} xXIGrabDeviceReq;
#define sz_xXIGrabDeviceReq 24
+typedef struct {
+uint8_t reqType;
+uint8_t ReqType;/** Always
::X_XIGrabDeviceWithConfine */
+uint16_tlength; /** Length in 4 byte units */
+Window grab_window;
+Window confine_to;
+Timetime;
+Cursor cursor;
+uint16_tdeviceid;
+uint8_t grab_mode;
+uint8_t paired_device_mode;
+uint8_t owner_events;
+uint8_t pad;
+uint16_tmask_len;
+} xXIGrabDeviceWithConfineReq;
+
+#define sz_xXIGrabDeviceWithConfineReq 28
+
+
/**
* Return codes from a XIPassiveGrabDevice request.
*/
@@ -648,6 +669,26 @@ typedef struct {
#define sz_xXIPassiveGrabDeviceReq 32
typedef struct {
+uint8_t reqType;
+uint8_t ReqType;/** Always
::X_XIPassiveGrabDeviceWithConfine */
+uint16_tlength; /** Length in 4 byte units */
+Timetime;
+Window grab_window;
+Window confine_to;
+Cursor cursor;
+uint32_tdetail;
+uint16_tdeviceid;
+uint16_tnum_modifiers;
+uint16_tmask_len;
+uint8_t grab_type;
+uint8_t grab_mode;
+uint8_t paired_device_mode;
+uint8_t owner_events;
+uint16_tpad1;
+} xXIPassiveGrabDeviceWithConfineReq;
+#define sz_xXIPassiveGrabDeviceWithConfineReq 36
+
+typedef struct {
uint8_t repType;/** Input extension major opcode */
uint8_t RepType;/** Always ::X_XIPassiveGrabDevice */
uint16_tsequenceNumber;
--
1.7.5.rc3
___
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: xf86-video-ati page flipping fixes
On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ 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] Added WithConfine functions.
---
include/X11/extensions/XInput2.h | 43 +++
src/XIGrabDevice.c | 18 +++--
src/XIPassiveGrab.c | 52 +
3 files changed, 98 insertions(+), 15 deletions(-)
diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h
index 3fcf083..f297801 100644
--- a/include/X11/extensions/XInput2.h
+++ b/include/X11/extensions/XInput2.h
@@ -402,6 +402,19 @@ extern Status XIGrabDevice(
XIEventMask*mask
);
+extern Status XIGrabDeviceWithConfine(
+ Display* dpy,
+ intdeviceid,
+ Window grab_window,
+ Window confine_to,
+ Time time,
+ Cursor cursor,
+ intgrab_mode,
+ intpaired_device_mode,
+ Bool owner_events,
+ XIEventMask*mask
+);
+
extern Status XIUngrabDevice(
Display* dpy,
intdeviceid,
@@ -429,6 +442,21 @@ extern int XIGrabButton(
XIGrabModifiers *modifiers_inout
);
+extern int XIGrabButtonWithConfine(
+Display*display,
+int deviceid,
+int button,
+Window grab_window,
+Window confine_to,
+Cursor cursor,
+int grab_mode,
+int paired_device_mode,
+int owner_events,
+XIEventMask *mask,
+int num_modifiers,
+XIGrabModifiers *modifiers_inout
+);
+
extern int XIGrabKeycode(
Display*display,
int deviceid,
@@ -455,6 +483,20 @@ extern int XIGrabEnter(
XIGrabModifiers *modifiers_inout
);
+extern int XIGrabEnterWithConfine(
+Display*display,
+int deviceid,
+Window grab_window,
+Window confine_to,
+Cursor cursor,
+int grab_mode,
+int paired_device_mode,
+int owner_events,
+XIEventMask *mask,
+int num_modifiers,
+XIGrabModifiers *modifiers_inout
+);
+
extern int XIGrabFocusIn(
Display*display,
int deviceid,
@@ -466,6 +508,7 @@ extern int XIGrabFocusIn(
int num_modifiers,
XIGrabModifiers *modifiers_inout
);
+
extern Status XIUngrabButton(
Display*display,
int deviceid,
diff --git a/src/XIGrabDevice.c b/src/XIGrabDevice.c
index 94feaee..e989ee0 100644
--- a/src/XIGrabDevice.c
+++ b/src/XIGrabDevice.c
@@ -35,7 +35,18 @@ XIGrabDevice(Display* dpy, int deviceid, Window grab_window,
Time time,
Cursor cursor, int grab_mode, int paired_device_mode,
Bool owner_events, XIEventMask *mask)
{
-xXIGrabDeviceReq *req;
+return XIGrabDeviceWithConfine(dpy, deviceid, grab_window, None, time,
+ cursor, grab_mode, paired_device_mode,
+ owner_events, mask);
+}
+
+Status
+XIGrabDeviceWithConfine(Display* dpy, int deviceid, Window grab_window,
+Window confine_to, Time time, Cursor cursor,
+int grab_mode, int paired_device_mode,
+Bool owner_events, XIEventMask *mask)
+{
+xXIGrabDeviceWithConfineReq *req;
xXIGrabDeviceReply reply;
char* buff;
int len;
@@ -46,11 +57,12 @@ XIGrabDevice(Display* dpy, int deviceid, Window
grab_window, Time time,
if (_XiCheckExtInit(dpy, XInput_2_0, extinfo) == -1)
return (NoSuchExtension);
-GetReq(XIGrabDevice, req);
+GetReq(XIGrabDeviceWithConfine, req);
req-reqType = extinfo-codes-major_opcode;
-req-ReqType = X_XIGrabDevice;
+req-ReqType = X_XIGrabDeviceWithConfine;
req-deviceid = deviceid;
req-grab_window = grab_window;
+req-confine_to = confine_to;
req-time = time;
req-grab_mode = grab_mode;
req-paired_device_mode = paired_device_mode;
diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
index feef74b..3e10356 100644
--- a/src/XIPassiveGrab.c
+++ b/src/XIPassiveGrab.c
@@ -31,12 +31,12 @@
static int
_XIPassiveGrabDevice(Display* dpy, int deviceid, int grabtype, int detail,
- Window grab_window, Cursor cursor,
+ Window grab_window, Window confine_to, Cursor cursor,
int grab_mode, int paired_device_mode,
Bool owner_events, XIEventMask *mask,
int num_modifiers, XIGrabModifiers *modifiers_inout)
{
-xXIPassiveGrabDeviceReq *req;
+xXIPassiveGrabDeviceWithConfineReq *req;
xXIPassiveGrabDeviceReply reply;
xXIGrabModifierInfo *failed_mods;
int len = 0, i;
@@ -48,14 +48,15 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int
grabtype,
[PATCH] Added processing of confine protocol.
---
Xi/extinit.c |8 ++-
Xi/xigrabdev.c | 101 +
Xi/xigrabdev.h |3 +
Xi/xipassivegrab.c | 139 +++-
Xi/xipassivegrab.h |2 +
5 files changed, 194 insertions(+), 59 deletions(-)
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 51e0078..4a6f4cc 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -259,7 +259,9 @@ static int (*ProcIVector[])(ClientPtr) = {
ProcXIChangeProperty, /* 57 */
ProcXIDeleteProperty, /* 58 */
ProcXIGetProperty, /* 59 */
-ProcXIGetSelectedEvents /* 60 */
+ProcXIGetSelectedEvents,/* 60 */
+ProcXIGrabDeviceWithConfine,/* 61 */
+ProcXIPassiveGrabDeviceWithConfine /* 62 */
};
/* For swapped clients */
@@ -324,7 +326,9 @@ static int (*SProcIVector[])(ClientPtr) = {
SProcXIChangeProperty, /* 57 */
SProcXIDeleteProperty, /* 58 */
SProcXIGetProperty, /* 59 */
-SProcXIGetSelectedEvents /* 60 */
+SProcXIGetSelectedEvents,/* 60 */
+SProcXIGrabDeviceWithConfine,/* 61 */
+SProcXIPassiveGrabDeviceWithConfine /* 62 */
};
/*
diff --git a/Xi/xigrabdev.c b/Xi/xigrabdev.c
index 0adc878..25b19aa 100644
--- a/Xi/xigrabdev.c
+++ b/Xi/xigrabdev.c
@@ -42,25 +42,25 @@
#include exevents.h
#include xigrabdev.h
-int
-SProcXIGrabDevice(ClientPtr client)
+static void
+XIConvertGrabDeviceReq(xXIGrabDeviceWithConfineReq *result, xXIGrabDeviceReq
*source)
{
-char n;
-
-REQUEST(xXIGrabDeviceReq);
-
-swaps(stuff-length, n);
-swaps(stuff-deviceid, n);
-swapl(stuff-grab_window, n);
-swapl(stuff-cursor, n);
-swapl(stuff-time, n);
-swaps(stuff-mask_len, n);
-
-return ProcXIGrabDevice(client);
+result-reqType = X_XIGrabDeviceWithConfine;
+result-length = source-length + 1; /* length is always in 4 bytes, + 1
for confine_to field */
+result-grab_window = source-grab_window;
+result-confine_to = None;
+result-time = source-time;
+result-cursor = source-cursor;
+result-deviceid = source-deviceid;
+result-grab_mode = source-grab_mode;
+result-paired_device_mode = source-paired_device_mode;
+result-owner_events = source-owner_events;
+/*result-pad*/
+result-mask_len = source-mask_len;
}
-int
-ProcXIGrabDevice(ClientPtr client)
+static int
+XIGrabDeviceImpl(ClientPtr client, xXIGrabDeviceWithConfineReq *stuff,
unsigned char *extra)
{
DeviceIntPtr dev;
xXIGrabDeviceReply rep;
@@ -69,9 +69,6 @@ ProcXIGrabDevice(ClientPtr client)
GrabMask mask;
int mask_len;
-REQUEST(xXIGrabDeviceReq);
-REQUEST_AT_LEAST_SIZE(xXIGrabDeviceReq);
-
ret = dixLookupDevice(dev, stuff-deviceid, client, DixGrabAccess);
if (ret != Success)
return ret;
@@ -79,13 +76,13 @@ ProcXIGrabDevice(ClientPtr client)
if (!IsMaster(dev))
stuff-paired_device_mode = GrabModeAsync;
-if (XICheckInvalidMaskBits(client, (unsigned char*)stuff[1],
+if (XICheckInvalidMaskBits(client, extra,
stuff-mask_len * 4) != Success)
return BadValue;
mask_len = min(sizeof(mask.xi2mask[stuff-deviceid]), stuff-mask_len * 4);
memset(mask.xi2mask, 0, sizeof(mask.xi2mask));
-memcpy(mask.xi2mask, (char*)stuff[1], mask_len);
+memcpy(mask.xi2mask, extra, mask_len);
ret = GrabDevice(client, dev, stuff-grab_mode,
stuff-paired_device_mode,
@@ -95,7 +92,7 @@ ProcXIGrabDevice(ClientPtr client)
mask,
GRABTYPE_XI2,
stuff-cursor,
- None /* confineTo */,
+ stuff-confine_to,
status);
if (ret != Success)
@@ -112,6 +109,66 @@ ProcXIGrabDevice(ClientPtr client)
return ret;
}
+static int
+SXIGrabDeviceImpl(ClientPtr client, xXIGrabDeviceWithConfineReq *stuff,
unsigned char *extra)
+{
+char n;
+
+swaps(stuff-length, n);
+swaps(stuff-deviceid, n);
+swapl(stuff-grab_window, n);
+swapl(stuff-confine_to, n);
+swapl(stuff-cursor, n);
+swapl(stuff-time, n);
+swaps(stuff-mask_len, n);
+
+return XIGrabDeviceImpl(client, stuff, extra);
+}
+
+int
+SProcXIGrabDevice(ClientPtr client)
+{
+xXIGrabDeviceWithConfineReq new_stuff;
+
+REQUEST(xXIGrabDeviceReq);
+REQUEST_AT_LEAST_SIZE(xXIGrabDeviceReq);
+
+XIConvertGrabDeviceReq(new_stuff, stuff);
+
+return SXIGrabDeviceImpl(client, new_stuff, (unsigned char*)stuff[1]);
+}
+
+int
+ProcXIGrabDevice(ClientPtr client)
+{
+xXIGrabDeviceWithConfineReq new_stuff;
+
+REQUEST(xXIGrabDeviceReq);
+
Re: [PATCH xf86-video-ati 1/2] dri2: Update front buffer pixmap and name before exchanging buffers
On Thu, May 05, 2011 at 12:28:20PM +0200, Michel Dänzer wrote:
On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote:
Buffer exchange assumes that the front buffer pixmap and name
information is accurate. That may not be the case eg. if the window
has been (un)redirected since the buffer was created.
Signed-off-by: Ville Syrjala syrj...@sci.fi
---
src/radeon_dri2.c | 45 -
1 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index e618cc5..5d1a382 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -626,12 +626,42 @@ radeon_dri2_schedule_flip(ScrnInfoPtr scrn, ClientPtr
client,
}
static Bool
-can_exchange(ScrnInfoPtr pScrn,
+update_front(DrawablePtr draw, DRI2BufferPtr front)
+{
+int r;
+PixmapPtr pixmap;
+struct dri2_buffer_priv *priv = front-driverPrivate;
+struct radeon_exa_pixmap_priv *driver_priv;
+
+if (draw-type == DRAWABLE_PIXMAP)
+ pixmap = (PixmapPtr)draw;
+else
+ pixmap = (*draw-pScreen-GetWindowPixmap)((WindowPtr)draw);
+
+pixmap-refcnt++;
+
+exaMoveInPixmap(pixmap);
+driver_priv = exaGetPixmapDriverPrivate(pixmap);
+r = radeon_gem_get_kernel_name(driver_priv-bo, front-name);
+if (r) {
+ (*draw-pScreen-DestroyPixmap)(pixmap);
+ return FALSE;
+}
+(*draw-pScreen-DestroyPixmap)(priv-pixmap);
+front-pitch = pixmap-devKind;
+front-cpp = pixmap-drawable.bitsPerPixel / 8;
+priv-pixmap = pixmap;
+
+return TRUE;
+}
Maybe at least some of this could be short-circuited if it's still the
same pixmap.
Yeah, I had the same thought. There's one catch though; Even if it's the
same pixmap, the bo may have been exchanged, and so the buffer name may
need to be updated anyway.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
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
Adding Reviewed-by (and the like) tags
Hi,
I guess it might be worth mentioning somewhere in the wiki how to
easily (in an automated fashion) add r-b tags to a range of
commits. Following Jon's suggestion on IRC, I've opted for:
git filter-branch --msg-filter 'add-tag.sh Reviewed-by: Peter Hutterer
peter.hutte...@who-t.net Reviewed-by: Daniel Stone dan...@fooishbar.org'
origin/master..
(You may want to pass -f if you play with it several times in a row.)
add-tag.sh:
--o--o--o--
#!/bin/sh
# Build the awk command line, reverse param orders:
cmd=
for i in $@; do
cmd=print \$i\; $cmd
done
# Insert lines after the first/last empty line:
tac|awk BEGIN { done=0 }; /^$/ { if (done 1) $cmd ; done=1 }; { print };|tac
--o--o--o--
Seems to work fine for a few examples; and can easily be tweaked to
learn about usual tag aliases (r-b et al.), and possibly people
aliases (peter, daniels, etc.).
Or just put everything in a file (letting your editor deal with alias
expansion), and replace the first part of the “script” with a while
read loop on that file's contents.
That could become:
git filter-branch -f --msg-filter add-tag-two.sh $(pwd)/.rb origin/master..
add-tag-two.sh:
--o--o--o--
#!/bin/sh
# Make sure the file exists:
tagfile=$1
if [ -z $tagfile -o ! -f $tagfile ]; then
echo E: Missing tag file ($tagfile); cwd=$(pwd) 2
exit 1
fi
# Build the awk command line, reverse line orders:
cmd=
while read line; do
cmd=print \$line\; $cmd
done $tagfile
# Insert lines after the last empty line:
tac|awk BEGIN { done=0 }; /^$/ { if (done 1) $cmd ; done=1 }; { print };|tac
--o--o--o--
The pitfall is that cwd points to .git-rewrite/t when that script is
run, so passing just '.rb' would fail.
Mraw,
KiBi.
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
Re: xf86-video-ati page flipping fixes
On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. Could it be that your patch fixes a closely related, but different bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer assignment and only queries the current assignment from the x-server if its drawable has been invalidated, which is what the x-server patches do. I'd also think you will need both patch sets. -mario ___ 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: [Mesa-dev] glproto changes
On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 5 May 2011 11:17:02 +1000 Dave Airlie airl...@gmail.com wrote: So I wasn't watching and glproto broke its interface, and I think its bad. Why? You can no longer bisect things across this point without now moving glproto. glxproto.h:xGLXBufferSwapComplete was a released header file definition, you cannot go back and change history. This should have been handled with xGLXBufferSwapComplete2 struct that newer mesa and X server could would use instead of the older code. Old code would build against the old broken defintion but since its broken it wouldn't matter, and new code would build against the new fixed definition. This doesn't address the I need the latest glproto to build mesa and my distro doesn't have which concerns me less than the I can't bisect anymore and I fully agree with Jesse that the last time we tried using #ifdef for this sort of thing it led to a number of untested combos resulting in impossible to debug issues. Yes, in hindsight I was too shellshocked by our previous experience with dri2 invalidate, ifdefs, and untested paths to even consider allowing new code to build with old proto. But breaking bisect is bad, no doubt. But in this case adding a separate struct is probably the right thing to do, and I'd be happy to do it if people are willing to put up with the churn (glproto 1.4.14, dri2proto 2.5 plus changes to Mesa and X to use the new struct). Yes, please do a new struct. I'm happy to see the churn to make it happen if it means developers are likely to do better at testing stable branches. pgpJQDb5VCzXL.pgp Description: PGP 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
Re: [Mesa-dev] glproto changes
On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston jerem...@freedesktop.org wrote:
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we
need to brownbag retract and rethink this.
Damnit; right when Dave mentioned this last night I knew I had gone too
far in trying to make sure the fix was propagated. I hate it when he's
right!
Yeah, having a rule that we can't touch existing proto structs makes
sense unless we want to do a major break. It certainly makes pushing
out updates eaiser and preserves bisection...
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, protocol) certainly warrants much more than the +0.0.1
version bump. This also makes it impossible to build the current dev and
current stable with the same protos installed. I haven't looked at the
details specifically, but I suspect that it also changes what is on the wire,
meaning clients and the server may disagree depending on which glproto
version they were using. Is that the case? If not, can't we solve this with
some creative union{}ing?
In this case, what's on the wire is pretty much the same; if the client
and server don't match, you may get a different kind of corruption in
the affected field (0 vs some other value), but things are no worse.
Either way, I think we should retract the glproto 1.4.13 release until we can
get this straightened out.
Ok; fwiw my rationale was twofold:
1) make sure master requires the new proto headers to avoid some of
the trouble we've had in the past with ifdefs and untested paths
(though again, the failure mode is benign in this case)
2) make the proto breakage obvious even for older code; the fix is
trivial
But I guess (2) is a bit much... after pushing I started having
nightmares about the input proto changes from awhile back.
Here are what the backwards compatible changes look like... Look
better?
Thanks,
--
Jesse Breaker of Builds Barnes
diff --git a/configure.ac b/configure.ac
index 9505f56..297be0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([DRI2Proto], [2.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/dri2proto.h b/dri2proto.h
index ff76355..ab25565 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -290,6 +290,21 @@ typedef struct {
CARD8 pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable B32;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xDRI2BufferSwapComplete;
+#define sz_xDRI2BufferSwapComplete 32
+
+typedef struct {
+CARD8 type;
+CARD8 pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable B32;
CARD32 ust_hi B32;
@@ -297,7 +312,7 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xDRI2BufferSwapComplete;
+} xDRI2BufferSwapComplete2;
#define sz_xDRI2BufferSwapComplete 32
typedef struct {
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xGLXBufferSwapComplete;
+
+typedef struct {
+BYTE type;
+BYTE pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable;
CARD32 ust_hi B32;
@@ -1382,7 +1396,8 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xGLXBufferSwapComplete;
+} xGLXBufferSwapComplete2;
+
//
diff --git a/configure.ac b/configure.ac
index 54d9c29..fb38a4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,8 +21,8 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.24
LIBDRM_INTEL_REQUIRED=2.4.24
-DRI2PROTO_REQUIRED=2.1
-GLPROTO_REQUIRED=1.4.11
+DRI2PROTO_REQUIRED=2.5
+GLPROTO_REQUIRED=1.4.14
LIBDRM_XORG_REQUIRED=2.4.24
LIBKMS_XORG_REQUIRED=1.0.0
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index
Re: Adding Reviewed-by (and the like) tags
Hi,
On Thu, May 05, 2011 at 05:01:06PM +0200, Cyril Brulebois wrote:
git filter-branch --msg-filter 'add-tag.sh Reviewed-by: Peter Hutterer
peter.hutte...@who-t.net Reviewed-by: Daniel Stone
dan...@fooishbar.org' origin/master..
Or, in ~/.gitconfig:
[aliases]
addrb = filter-branch --msg-filter ~/bin/add-r-b
And my version of the script, which works with short entries, tries to
preserve order as much as possible, and defaults to adding a Reviewed-by
tag with your identity if no arguments are given:
---
#!/bin/sh
if [ -n $GIT_AUTHOR_NAME ] [ -n $GIT_AUTHOR_EMAIL ]; then
MY_ID=$GIT_AUTHOR_NAME $GIT_AUTHOR_EMAIL
elif [ -n $(git config --get user.name) ]
[ -n $(git config --get user.email) ]; then
MY_ID=$(git config --get user.name) $(git config --get user.email)
fi
ARGS=$@
if [ -z $ARGS ] [ -n $MY_ID ]; then
ARGS=Reviewed-by: $MY_ID
fi
# Build the awk command line, reverse param orders:
cmd=
for i in $ARGS; do
cmd=print \$i\; $cmd
done
# Insert lines after the first/last empty line:
cat | awk \
BEGIN {
needs_blank=1
};
/Signed-off-by/ || /Reviewed-by/ || /Tested-by/ || /Reported-by/ {
needs_blank=0
};
{
print
};
END {
if (needs_blank) {
print \\
}
$cmd
};
---
Cheers,
Daniel
___
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: xf86-video-ati page flipping fixes
On Thu, May 05, 2011 at 05:09:56PM +0200, Mario Kleiner wrote: On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. Could it be that your patch fixes a closely related, but different bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer assignment and only queries the current assignment from the x-server if its drawable has been invalidated, which is what the x-server patches do. I'd also think you will need both patch sets. Back buffers are private so a swap for one drawable doesn't need to invalidate them for other drawables. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ 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] Don't call pixman_disable_out_of_bounds_workaround() anymore.
Soeren Sandmann sandm...@cs.au.dk (03/05/2011): Jeremy Huddleston jerem...@apple.com writes: Is pixman_disable_out_of_bounds_workaround now just a no-op, or was the symbol removed from pixman? Hopefully the former, but I wanted to make sure... Yes, the function still exists as a no-op. Great. Reviewed-by: Cyril Brulebois k...@debian.org Mraw, KiBi. 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
Re: xf86-video-ati page flipping fixes
On May 5, 2011, at 6:06 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 05:09:56PM +0200, Mario Kleiner wrote: On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. Could it be that your patch fixes a closely related, but different bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer assignment and only queries the current assignment from the x-server if its drawable has been invalidated, which is what the x-server patches do. I'd also think you will need both patch sets. Back buffers are private so a swap for one drawable doesn't need to invalidate them for other drawables. Are you sure this is also the case even when kms page flipping is used for fullscreen drawables? The workaround i implemented in my toolkit for the page flipping problem when using fullscreen drawables on current x servers was to make sure that it always ends a session with an even number of completed page-flipping swaps, by checking 'sbc' and issuing an extra swap before closing its window if the sbc wasn't an even number. This makes sure that the same buffer objects are assigned as front- and backbuffer at the time the window closes as when the application started and opened its fullscreen window. This fixed any desktop corruption i'd usually get when running compiz with non-redirected fullscreen windows after quitting my application. I could be totally wrong, but at least the symptoms and the working workaround suggested fullscreen drawables do share their back buffers when page flipping is on. -mario -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ 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: xf86-video-ati page flipping fixes
On Thu, 5 May 2011 18:33:11 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: Are you sure this is also the case even when kms page flipping is used for fullscreen drawables? The workaround i implemented in my toolkit for the page flipping problem when using fullscreen drawables on current x servers was to make sure that it always ends a session with an even number of completed page-flipping swaps, by checking 'sbc' and issuing an extra swap before closing its window if the sbc wasn't an even number. This makes sure that the same buffer objects are assigned as front- and backbuffer at the time the window closes as when the application started and opened its fullscreen window. This fixed any desktop corruption i'd usually get when running compiz with non-redirected fullscreen windows after quitting my application. I could be totally wrong, but at least the symptoms and the working workaround suggested fullscreen drawables do share their back buffers when page flipping is on. Is this workaround needed on the Intel driver too? Or is this just a driver bo name tracking bug? Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ 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] libX11: allow inclusion of system level compose files
Hi, Sorry this has taken so long ... On Sun, Oct 11, 2009 at 09:12:09PM +0300, Marko Myllynen wrote: with the release of XFree86 4.4 an inclusion system of compose files was added to Xlib to allow inclusion of the default compose file (with %L), any compose files from user's home directory (with %H), or a compose file with a hard coded path [1]. However, even today including system level compose files is not possible in a platform independent manner although the machinery for including compose files and overriding previously defined compositions is already in place. With the ability to include system level compose files one could greatly reduce the need for compose file rule duplication and the work needed to propagate changes in one compose file to others. For example, currently the Finnish compose file fi_FI.UTF-8 weights over 5000 lines [2] but it is almost identical with en_US.UTF-8 except for perhaps half a dozen compositions. Please consider something like the patch below to allow one to include system level compose files with the following kind of syntax: include %S/en_US.UTF-8/Compose 1) http://www.xfree86.org/4.4.0/RELNOTES5.html#42 2) http://cgit.freedesktop.org/xorg/lib/libX11/tree/nls/fi_FI.UTF-8/Compose.pre Signed-off-by: Marko Myllynen mylly...@redhat.com This looks fine to me. Reviewed-by: Daniel Stone dan...@fooishbar.org Alan - thoughts? Cheers, Daniel ___ 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: [Mesa-dev] glproto changes
Why is sbc a 32bit field in xGLXBufferSwapComplete2 and
xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete?
The hunk at the bottom will result in casting a 64bit int to a 32bit int. If
you're going to change this, shouldn't you also change GLXBufferSwapComplete,
DRI2SwapEvent() and everything else that has a 64bit swap count?
Isn't it easier to correct the spec to match reality?
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -359,7 +359,7 @@ static void
DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
CARD64 sbc)
{
-xDRI2BufferSwapComplete event;
+xDRI2BufferSwapComplete2 event;
DrawablePtr pDrawable = data;
event.type = DRI2EventBase + DRI2_BufferSwapComplete;
@@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type,
CARD64 ust, CARD64 msc,
event.ust_lo = ust 0x;
event.msc_hi = (CARD64)msc 32;
event.msc_lo = msc 0x;
-event.sbc_hi = (CARD64)sbc 32;
-event.sbc_lo = sbc 0x;
+event.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *)event);
}
On May 5, 2011, at 08:28, Jesse Barnes wrote:
On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston jerem...@freedesktop.org wrote:
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we
need to brownbag retract and rethink this.
Damnit; right when Dave mentioned this last night I knew I had gone too
far in trying to make sure the fix was propagated. I hate it when he's
right!
Yeah, having a rule that we can't touch existing proto structs makes
sense unless we want to do a major break. It certainly makes pushing
out updates eaiser and preserves bisection...
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, protocol) certainly warrants much more than the +0.0.1
version bump. This also makes it impossible to build the current dev and
current stable with the same protos installed. I haven't looked at the
details specifically, but I suspect that it also changes what is on the
wire, meaning clients and the server may disagree depending on which glproto
version they were using. Is that the case? If not, can't we solve this
with some creative union{}ing?
In this case, what's on the wire is pretty much the same; if the client
and server don't match, you may get a different kind of corruption in
the affected field (0 vs some other value), but things are no worse.
Either way, I think we should retract the glproto 1.4.13 release until we
can get this straightened out.
Ok; fwiw my rationale was twofold:
1) make sure master requires the new proto headers to avoid some of
the trouble we've had in the past with ifdefs and untested paths
(though again, the failure mode is benign in this case)
2) make the proto breakage obvious even for older code; the fix is
trivial
But I guess (2) is a bit much... after pushing I started having
nightmares about the input proto changes from awhile back.
Here are what the backwards compatible changes look like... Look
better?
Thanks,
--
Jesse Breaker of Builds Barnes
dri2proto-compat-fix.patchglproto-compat-fix.patchmesa-glx-compat-fix.patchxserver-glproto-compat-fix.patch
___
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: xf86-video-ati page flipping fixes
On Thu, May 05, 2011 at 09:54:48AM -0700, Jesse Barnes wrote: On Thu, 5 May 2011 18:33:11 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: Are you sure this is also the case even when kms page flipping is used for fullscreen drawables? The workaround i implemented in my toolkit for the page flipping problem when using fullscreen drawables on current x servers was to make sure that it always ends a session with an even number of completed page-flipping swaps, by checking 'sbc' and issuing an extra swap before closing its window if the sbc wasn't an even number. This makes sure that the same buffer objects are assigned as front- and backbuffer at the time the window closes as when the application started and opened its fullscreen window. This fixed any desktop corruption i'd usually get when running compiz with non-redirected fullscreen windows after quitting my application. I could be totally wrong, but at least the symptoms and the working workaround suggested fullscreen drawables do share their back buffers when page flipping is on. Is this workaround needed on the Intel driver too? Or is this just a driver bo name tracking bug? I don't have Intel hw for testing, but as the code looks to be simply copy-pasted from one driver to the other, I'd say it needs the same fixes. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ 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: [Mesa-dev] glproto changes
On Thu, 5 May 2011 10:07:24 -0700 Jeremy Huddleston jerem...@freedesktop.org wrote: Why is sbc a 32bit field in xGLXBufferSwapComplete2 and xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete? The hunk at the bottom will result in casting a 64bit int to a 32bit int. If you're going to change this, shouldn't you also change GLXBufferSwapComplete, DRI2SwapEvent() and everything else that has a 64bit swap count? Isn't it easier to correct the spec to match reality? No because XEvents are only 32 bytes. We actually noticed that when publishing the spec, but we never updated the code. And yes, I should change the CARD64s to CARD32s as in the previous patch. Accidentally dropped that part when reverting. Thanks, Jesse ___ 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: xf86-video-ati page flipping fixes
On Thu, May 05, 2011 at 06:33:11PM +0200, ext Mario Kleiner wrote: On May 5, 2011, at 6:06 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 05:09:56PM +0200, Mario Kleiner wrote: On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv-buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. Could it be that your patch fixes a closely related, but different bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer assignment and only queries the current assignment from the x-server if its drawable has been invalidated, which is what the x-server patches do. I'd also think you will need both patch sets. Back buffers are private so a swap for one drawable doesn't need to invalidate them for other drawables. Are you sure this is also the case even when kms page flipping is used for fullscreen drawables? Yes, and if not, it's a driver bug. The workaround i implemented in my toolkit for the page flipping problem when using fullscreen drawables on current x servers was to make sure that it always ends a session with an even number of completed page-flipping swaps, by checking 'sbc' and issuing an extra swap before closing its window if the sbc wasn't an even number. This makes sure that the same buffer objects are assigned as front- and backbuffer at the time the window closes as when the application started and opened its fullscreen window. This fixed any desktop corruption i'd usually get when running compiz with non-redirected fullscreen windows after quitting my application. I could be totally wrong, but at least the symptoms and the working workaround suggested fullscreen drawables do share their back buffers when page flipping is on. The bug allows the BOs to get mixed up pretty much any which way between DRI2 buffers. Eg. if two drawables got the same BO as the front buffer in their GetBuffers requests, and then both would do a page flip, both would end up with the same BO as their new back buffer. -- Ville Syrjälä ___ 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] libX11: allow inclusion of system level compose files
DS == Daniel Stone dan...@fooishbar.org writes: Please consider something like the patch below to allow one to include system level compose files with the following kind of syntax: include %S/en_US.UTF-8/Compose DS This looks fine to me. DS Reviewed-by: Daniel Stone dan...@fooishbar.org DS Alan - thoughts? Didn't we already push this? Or something based on this? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ 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
Compatible GLX swap event fixes
This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ 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] glproto: add a new GLXBufferSwapComplete struct that matches the spec
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([GLProto], [1.4.14],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/glxproto.h b/glxproto.h
index dfa0647..3f9e837 100644
--- a/glxproto.h
+++ b/glxproto.h
@@ -1375,6 +1375,20 @@ typedef struct {
BYTE pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD32 drawable;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc_hi B32;
+CARD32 sbc_lo B32;
+} xGLXBufferSwapComplete;
+
+typedef struct {
+BYTE type;
+BYTE pad;
+CARD16 sequenceNumber B16;
+CARD16 event_type B16;
CARD16 pad2;
CARD32 drawable;
CARD32 ust_hi B32;
@@ -1382,7 +1396,8 @@ typedef struct {
CARD32 msc_hi B32;
CARD32 msc_lo B32;
CARD32 sbc B32;
-} xGLXBufferSwapComplete;
+} xGLXBufferSwapComplete2;
+
//
___
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] mesa/glx/dri2: use new GLX/DRI2 swap event types
Use the new swap event type so we get valid SBC values.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index 54d9c29..fb38a4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,8 +21,8 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRED=2.4.24
LIBDRM_INTEL_REQUIRED=2.4.24
-DRI2PROTO_REQUIRED=2.1
-GLPROTO_REQUIRED=1.4.11
+DRI2PROTO_REQUIRED=2.5
+GLPROTO_REQUIRED=1.4.14
LIBDRM_XORG_REQUIRED=2.4.24
LIBKMS_XORG_REQUIRED=1.0.0
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index adfd3d1..8654a37 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -97,7 +97,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
case DRI2_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xDRI2BufferSwapComplete *awire = (xDRI2BufferSwapComplete *)wire;
+ xDRI2BufferSwapComplete2 *awire = (xDRI2BufferSwapComplete2 *)wire;
/* Ignore swap events if we're not looking for them */
aevent-type = dri2GetSwapEventType(dpy, awire-drawable);
@@ -124,7 +124,7 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
}
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
#endif
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index 278c719..02652cb 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -133,12 +133,12 @@ __glXWireToEvent(Display *dpy, XEvent *event, xEvent
*wire)
case GLX_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
- xGLXBufferSwapComplete *awire = (xGLXBufferSwapComplete *)wire;
+ xGLXBufferSwapComplete2 *awire = (xGLXBufferSwapComplete2 *)wire;
aevent-event_type = awire-event_type;
aevent-drawable = awire-drawable;
aevent-ust = ((CARD64)awire-ust_hi 32) | awire-ust_lo;
aevent-msc = ((CARD64)awire-msc_hi 32) | awire-msc_lo;
- aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
+ aevent-sbc = awire-sbc;
return True;
}
default:
___
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: Compatible GLX swap event fixes
On Thu, 5 May 2011 12:38:24 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). Correction, new clients with old servers will generally see a 0 SBC count; they're no longer reading a value beyond the 32 byte XEvent, and old servers send the high 32 bits of the SBC count at the end. So they'll get 0 until the SBC exceeds 32 bits on the server side (which will take a long time). -- Jesse Barnes, Intel Open Source Technology Center ___ 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] xserver/glx/dri2: use new GLX/DRI2 swap event types
For *proto/mesa:
Reviewed-by: Jeremy Huddleston jerem...@apple.com
For xserver:
This looks incomplete. You also need to update swap_count in DRI2DrawableRec
to be CARD32.
On May 5, 2011, at 12:45 PM, Jesse Barnes wrote:
Use the new event types so we can pass a valid SBC value to clients.
Fix up the completion calls to use CARD32 instead of CARD64 to match
the new field size.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/configure.ac b/configure.ac
index 6eb780c..3e0ed5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -771,11 +771,11 @@ RECORDPROTO=recordproto = 1.13.99.1
SCRNSAVERPROTO=scrnsaverproto = 1.1
RESOURCEPROTO=resourceproto
DRIPROTO=xf86driproto = 2.1.0
-DRI2PROTO=dri2proto = 2.3
+DRI2PROTO=dri2proto = 2.5
XINERAMAPROTO=xineramaproto
BIGFONTPROTO=xf86bigfontproto = 1.2.0
DGAPROTO=xf86dgaproto = 2.0.99.1
-GLPROTO=glproto = 1.4.10
+GLPROTO=glproto = 1.4.14
DMXPROTO=dmxproto = 2.2.99.1
VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1
WINDOWSWMPROTO=windowswmproto
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 93c5e5b..e872258 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -163,10 +163,10 @@ __glXDRIdrawableWaitGL(__GLXdrawable *drawable)
static void
__glXdriSwapEvent(ClientPtr client, void *data, int type, CARD64 ust,
- CARD64 msc, CARD64 sbc)
+ CARD64 msc, CARD32 sbc)
{
__GLXdrawable *drawable = data;
-xGLXBufferSwapComplete wire;
+xGLXBufferSwapComplete2 wire;
if (!(drawable-eventMask GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
return;
@@ -192,8 +192,7 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type,
CARD64 ust,
wire.ust_lo = ust 0x;
wire.msc_hi = msc 32;
wire.msc_lo = msc 0x;
-wire.sbc_hi = sbc 32;
-wire.sbc_lo = sbc 0x;
+wire.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *) wire);
}
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index fe0bf6c..2a41ead 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -51,7 +51,7 @@ extern CARD8 dri2_minor;
typedef DRI2BufferRec DRI2Buffer2Rec, *DRI2Buffer2Ptr;
typedef void (*DRI2SwapEventPtr)(ClientPtr client, void *data, int type,
- CARD64 ust, CARD64 msc, CARD64 sbc);
+ CARD64 ust, CARD64 msc, CARD32 sbc);
typedef DRI2BufferPtr (*DRI2CreateBuffersProcPtr)(DrawablePtr pDraw,
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 4e48e65..552b26b 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -357,9 +357,9 @@ vals_to_card64(CARD32 lo, CARD32 hi)
static void
DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
- CARD64 sbc)
+ CARD32 sbc)
{
-xDRI2BufferSwapComplete event;
+xDRI2BufferSwapComplete2 event;
DrawablePtr pDrawable = data;
event.type = DRI2EventBase + DRI2_BufferSwapComplete;
@@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type,
CARD64 ust, CARD64 msc,
event.ust_lo = ust 0x;
event.msc_hi = (CARD64)msc 32;
event.msc_lo = msc 0x;
-event.sbc_hi = (CARD64)sbc 32;
-event.sbc_lo = sbc 0x;
+event.sbc = sbc;
WriteEventsToClient(client, 1, (xEvent *)event);
}
___
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
___
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] xserver/glx/dri2: use new GLX/DRI2 swap event types
On Thu, 05 May 2011 12:59:50 -0700 Jeremy Huddleston jerem...@apple.com wrote: For *proto/mesa: Reviewed-by: Jeremy Huddleston jerem...@apple.com Thanks. For xserver: This looks incomplete. You also need to update swap_count in DRI2DrawableRec to be CARD32. That value is used in other places that actually preserve the full 64 bits. I could add an explicit cast in the few places where we pass it to the swap completion though if you think that's better... -- Jesse Barnes, Intel Open Source Technology Center ___ 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] xserver/glx/dri2: use new GLX/DRI2 swap event types
On May 5, 2011, at 1:09 PM, Jesse Barnes wrote: On Thu, 05 May 2011 12:59:50 -0700 Jeremy Huddleston jerem...@apple.com wrote: For *proto/mesa: Reviewed-by: Jeremy Huddleston jerem...@apple.com Thanks. For xserver: This looks incomplete. You also need to update swap_count in DRI2DrawableRec to be CARD32. That value is used in other places that actually preserve the full 64 bits. I could add an explicit cast in the few places where we pass it to the swap completion though if you think that's better... Yes, I realize that there are some areas that use 64bit for sbc. Do we really need 64bits for this? If so, how do we properly to communicate the 64bit value between server/client? Currently, your changes result in an implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause problems if we really do need those extra bits: if (swap_complete) swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count); It looks to me like much more of DRI2 should be rewritten to use 32bit swap counts, or there should be some other mechanism in place to communicate the full 64bit value. ___ 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] xserver/glx/dri2: use new GLX/DRI2 swap event types
Yes, I realize that there are some areas that use 64bit for sbc. Do we
really need 64bits for this? If so, how do we properly to communicate the
64bit value between server/client? Currently, your changes result in an
implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause
problems if we really do need those extra bits:
if (swap_complete)
swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count);
It looks to me like much more of DRI2 should be rewritten to use 32bit swap
counts, or there should be some other mechanism in place to communicate the
full 64bit value.
Yeah there are other mechanisms (the OML sync extension) for
communicating the whole 64 bits. Both the swap reply and msc reply
deal in the full 64 bits, just the swap event (an unrelated extension)
truncates to 32 bits. (Also I think the 64 bit size for swap count in
the OML extension is just inertia; getting to a count that high even at
120Hz is going to take awhile.)
Ok, well this all really doesn't sit well with me, but it would put my mind
slightly at ease if you would do some logging of the problem if we encounter it
in DRI2SwapComplete. That might give your future self some clue as to what is
going wrong when you see issues down the road:
if (swap_complete) {
if (pPriv-swap_count 0x)
ErrorF(something appropriate);
swap_complete(client, swap_data, type, ust, frame,
(CARD32)pPriv-swap_count);
}
___
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] xserver/glx/dri2: use new GLX/DRI2 swap event types
On Thu, 05 May 2011 13:36:40 -0700
Jeremy Huddleston jerem...@apple.com wrote:
Yes, I realize that there are some areas that use 64bit for sbc. Do we
really need 64bits for this? If so, how do we properly to communicate the
64bit value between server/client? Currently, your changes result in an
implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause
problems if we really do need those extra bits:
if (swap_complete)
swap_complete(client, swap_data, type, ust, frame,
pPriv-swap_count);
It looks to me like much more of DRI2 should be rewritten to use 32bit
swap counts, or there should be some other mechanism in place to
communicate the full 64bit value.
Yeah there are other mechanisms (the OML sync extension) for
communicating the whole 64 bits. Both the swap reply and msc reply
deal in the full 64 bits, just the swap event (an unrelated extension)
truncates to 32 bits. (Also I think the 64 bit size for swap count in
the OML extension is just inertia; getting to a count that high even at
120Hz is going to take awhile.)
Ok, well this all really doesn't sit well with me, but it would put my mind
slightly at ease if you would do some logging of the problem if we encounter
it in DRI2SwapComplete. That might give your future self some clue as to
what is going wrong when you see issues down the road:
if (swap_complete) {
if (pPriv-swap_count 0x)
ErrorF(something appropriate);
swap_complete(client, swap_data, type, ust, frame,
(CARD32)pPriv-swap_count);
}
Yeah, it's annoying. How about I leave out the error message and handle
wrapping on the client side instead? That way at least the client code
won't notice that the server is only transmitting 32 bits...
--
Jesse Barnes, Intel Open Source Technology Center
___
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] xserver/glx/dri2: use new GLX/DRI2 swap event types
if (swap_complete) {
if (pPriv-swap_count 0x)
ErrorF(something appropriate);
swap_complete(client, swap_data, type, ust, frame,
(CARD32)pPriv-swap_count);
}
Yeah, it's annoying. How about I leave out the error message and handle
wrapping on the client side instead? That way at least the client code
won't notice that the server is only transmitting 32 bits...
Nevermind, that can't work generally since clients are free to
mask/unmask the events, so we could miss a 0 count and thus a wrap. We
just have to live with the fact that swap events have a 32 bit sbc and
OML uses 64 bit counts. I'll add the warning though; if it becomes a
real issue we can potentially add another round trip to get the value
using OML instead.
--
Jesse Barnes, Intel Open Source Technology Center
___
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: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 01:25 PM, Jesse Barnes wrote: On Thu, 05 May 2011 13:17:13 -0700 Jeremy Huddleston jerem...@apple.com wrote: Yes, I realize that there are some areas that use 64bit for sbc. Do we really need 64bits for this? If so, how do we properly to communicate the 64bit value between server/client? Currently, your changes result in an implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause problems if we really do need those extra bits: if (swap_complete) swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count); It looks to me like much more of DRI2 should be rewritten to use 32bit swap counts, or there should be some other mechanism in place to communicate the full 64bit value. Yeah there are other mechanisms (the OML sync extension) for communicating the whole 64 bits. Both the swap reply and msc reply deal in the full 64 bits, just the swap event (an unrelated extension) truncates to 32 bits. (Also I think the 64 bit size for swap count in the OML extension is just inertia; getting to a count that high even at 120Hz is going to take awhile.) But it could happen on, say, a desktop compositor that's been logged in for a month. I think the main reason is that the other two values really need to be 64-bits, so you might as well make all three be 64-bits. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3DEsoACgkQX1gOwKyEAw/a3gCePneowulpZhTz88vmU4DRr22K D20An35ff4MD3uuDUfJXNxE5m+wtsm1m =bzXJ -END PGP 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
Re: [Mesa-dev] Compatible GLX swap event fixes
On Thu, 05 May 2011 14:15:33 -0700 Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 12:38 PM, Jesse Barnes wrote: This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, This looks more like the changeset I was expecting. For the series, Reviewed-by: Ian Romanick ian.d.roman...@intel.com Thanks. -- Jesse Barnes, Intel Open Source Technology Center ___ 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] libX11: allow inclusion of system level compose files
On 05/ 5/11 11:42 AM, James Cloos wrote: DS == Daniel Stone dan...@fooishbar.org writes: Please consider something like the patch below to allow one to include system level compose files with the following kind of syntax: include %S/en_US.UTF-8/Compose DS This looks fine to me. DS Reviewed-by: Daniel Stone dan...@fooishbar.org DS Alan - thoughts? Didn't we already push this? Or something based on this? I thought so - and looking in git I see: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=9df349a7894725f9469b106af645f57f7f3f9af3 -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: Adding Reviewed-by (and the like) tags
Slightly less fancy than the other two, but the few lines below do the job
when using gitsnippets
http://who-t.blogspot.com/2010/11/adding-reviewed-by-tags-to-patches.html
---%-
#!/bin/sh
# fake some name that looks like a git commit to vim
FAKE_GIT_DIR=/tmp/filter-branch-msg/.git
FILE=$FAKE_GIT_DIR/COMMIT_EDITMSG
if [ $# -ne 1 ]; then
echo usage: $0 commit range
fi
mkdir -p $FAKE_GIT_DIR
vim $FILE
git filter-branch -f --msg-filter sed '\$a `cat $FILE`' $1
rm -rf $FAKE_GIT_DIR
rmdir `dirname $FAKE_GIT_DIR`
---%-
then just call with git-add-tag HEAD~4.. and add all lines you need to add.
Cheers,
Peter
On Thu, May 05, 2011 at 04:46:58PM +0100, Daniel Stone wrote:
Hi,
On Thu, May 05, 2011 at 05:01:06PM +0200, Cyril Brulebois wrote:
git filter-branch --msg-filter 'add-tag.sh Reviewed-by: Peter Hutterer
peter.hutte...@who-t.net Reviewed-by: Daniel Stone
dan...@fooishbar.org' origin/master..
Or, in ~/.gitconfig:
[aliases]
addrb = filter-branch --msg-filter ~/bin/add-r-b
And my version of the script, which works with short entries, tries to
preserve order as much as possible, and defaults to adding a Reviewed-by
tag with your identity if no arguments are given:
---
#!/bin/sh
if [ -n $GIT_AUTHOR_NAME ] [ -n $GIT_AUTHOR_EMAIL ]; then
MY_ID=$GIT_AUTHOR_NAME $GIT_AUTHOR_EMAIL
elif [ -n $(git config --get user.name) ]
[ -n $(git config --get user.email) ]; then
MY_ID=$(git config --get user.name) $(git config --get user.email)
fi
ARGS=$@
if [ -z $ARGS ] [ -n $MY_ID ]; then
ARGS=Reviewed-by: $MY_ID
fi
# Build the awk command line, reverse param orders:
cmd=
for i in $ARGS; do
cmd=print \$i\; $cmd
done
# Insert lines after the first/last empty line:
cat | awk \
BEGIN {
needs_blank=1
};
/Signed-off-by/ || /Reviewed-by/ || /Tested-by/ || /Reported-by/ {
needs_blank=0
};
{
print
};
END {
if (needs_blank) {
print \\
}
$cmd
};
---
Cheers,
Daniel
___
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: xf86-input-synaptics
On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: Hello list, I've two questions concerning synaptic: 1.) I've one of those snyaptics driven HP Clickpads (HP Touchsmart tm2) and it has a little LED on it, which is supposed to be lit when the TP is off, but it doesn't when I turn the TP off with synclient. Why, or how do I fix that? not yet. clickpad patches were floating around at some point but IIRC the last round of them had a few outstanding review comments. 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Cheers, Peter ___ 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] libX11: allow inclusion of system level compose files
On Thu, May 05, 2011 at 02:51:19PM -0700, Alan Coopersmith wrote: On 05/ 5/11 11:42 AM, James Cloos wrote: DS == Daniel Stone dan...@fooishbar.org writes: DS This looks fine to me. DS DS Alan - thoughts? Didn't we already push this? Or something based on this? I thought so - and looking in git I see: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=9df349a7894725f9469b106af645f57f7f3f9af3 Aha, sorry, I'd searched for Myllynen, and that hadn't come up. Cheers, Daniel ___ 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: xf86-input-synaptics
On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: I've two questions concerning synaptic: 1.) I've one of those snyaptics driven HP Clickpads (HP Touchsmart tm2) and it has a little LED on it, which is supposed to be lit when the TP is off, but it doesn't when I turn the TP off with synclient. Why, or how do I fix that? not yet. clickpad patches were floating around at some point but IIRC the last round of them had a few outstanding review comments. I have a working clickpad tree that I will be pushing for review soon, but I don't have any HP laptops, or any of the ones with LEDs. 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. Cheers, Daniel ___ 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: xf86-input-synaptics
On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: I've two questions concerning synaptic: 1.) I've one of those snyaptics driven HP Clickpads (HP Touchsmart tm2) and it has a little LED on it, which is supposed to be lit when the TP is off, but it doesn't when I turn the TP off with synclient. Why, or how do I fix that? not yet. clickpad patches were floating around at some point but IIRC the last round of them had a few outstanding review comments. I have a working clickpad tree that I will be pushing for review soon, but I don't have any HP laptops, or any of the ones with LEDs. 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. do you want to enable/disable based on modifiers too? only modifiers, but combos as well (ctrl+c, ctrl+v)? do you want to only disable tapping/scrolling, but not movement? seriously, the options will just pile up, requiring configuration, etc. and the last thing we need is more config options and properties. we've got something that's working now. not ideal, but well enough. afaiui the biggest issue is the costly monitoring of keyboard input by the client, not the single request to enable/disable the device. Cheers, Peter ___ 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: xf86-input-synaptics
On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote: On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. do you want to enable/disable based on modifiers too? No. Why would you? only modifiers, but combos as well (ctrl+c, ctrl+v)? As above. do you want to only disable tapping/scrolling, but not movement? No. seriously, the options will just pile up, requiring configuration, etc. and the last thing we need is more config options and properties. I agree, but we don't have to add them. Cheers, Daniel ___ 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 libXi 1/3] man: fix typo, layout in XGetExtensionVersion.man
Fix a typo and move from MPX to XI2. Add a linebreak to make the depreciation separate from the function description. Changes in the second paragraph are just realignment due to the linebreak. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- man/XGetExtensionVersion.txt | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/man/XGetExtensionVersion.txt b/man/XGetExtensionVersion.txt index 3e24fc7..c7d45f4 100644 --- a/man/XGetExtensionVersion.txt +++ b/man/XGetExtensionVersion.txt @@ -25,11 +25,12 @@ DESCRIPTION --- The XGetExtensionVersion request is deprecated and should not - be used. Clients issuing a XgetExtensionVersion request will - not be able to use MPX features. The XGetExtensionVersion - request queries the version of the input extension, and returns - an XExtensionVersion structure. This structure contains a - major_version and minor_version number which can be compared + be used in XI2 applications. Clients issuing a XGetExtensionVersion + request will not be able to use XI2 features. + + The XGetExtensionVersion request queries the version of the input + extension, and returns an XExtensionVersion structure. This structure + contains a major_version and minor_version number which can be compared with constants defined in XI.h. Support for additional protocol requests added to the input extension after its initial release is indicated by a version number corresponding to the added -- 1.7.4.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 libXi 2/3] Silence compiler warning in XListDProp.c
XListDProp.c: In function 'XListDeviceProperties': XListDProp.c:72:9: warning: pointer targets in passing argument 2 of '_XRead32' differ in signedness /usr/include/X11/Xlibint.h:652:13: note: expected 'long int *' but argument is of type 'Atom *' Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- src/XListDProp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/XListDProp.c b/src/XListDProp.c index 66b9eca..8667350 100644 --- a/src/XListDProp.c +++ b/src/XListDProp.c @@ -69,7 +69,7 @@ XListDeviceProperties(Display* dpy, XDevice* dev, int *nprops_return) goto cleanup; } -_XRead32(dpy, props, rep.nAtoms 2); +_XRead32(dpy, (long*)props, rep.nAtoms 2); } *nprops_return = rep.nAtoms; -- 1.7.4.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 libXi 3/3] Silence compiler warning due to differnent event conversion procs
XExtInt.c:161:5: warning: initialization from incompatible pointer type
XSndExEv.c: In function 'XSendExtensionEvent':
XSndExEv.c:84:8: warning: assignment from incompatible pointer type
Xlib and libXi differ in the conversion functions. libXi takes an xEvent**
and a num_events parameter since it may split an event into multiple
xEvents.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/XExtInt.c |4 +++-
src/XSndExEv.c | 11 ---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/XExtInt.c b/src/XExtInt.c
index 55144c6..32df6f9 100644
--- a/src/XExtInt.c
+++ b/src/XExtInt.c
@@ -149,6 +149,8 @@ wireToPropertyEvent(xXIPropertyEvent *in,
XGenericEventCookie *cookie);
static /* const */ XEvent emptyevent;
+typedef Status (*core_event_to_wire)(Display*, XEvent*, xEvent*);
+
static /* const */ XExtensionHooks xinput_extension_hooks = {
NULL, /* create_gc */
NULL, /* copy_gc */
@@ -158,7 +160,7 @@ static /* const */ XExtensionHooks xinput_extension_hooks =
{
NULL, /* free_font */
XInputClose, /* close_display */
XInputWireToEvent, /* wire_to_event */
-_XiEventToWire,/* event_to_wire */
+(core_event_to_wire)_XiEventToWire, /* event_to_wire */
NULL, /* error */
XInputError, /* error_string */
};
diff --git a/src/XSndExEv.c b/src/XSndExEv.c
index ebaab33..e21f8f7 100644
--- a/src/XSndExEv.c
+++ b/src/XSndExEv.c
@@ -57,6 +57,11 @@ SOFTWARE.
#include X11/extensions/extutil.h
#include XIint.h
+/* Xlib's wire_vec is defined for a single event only, libXi may return
+ * multiple events.
+ */
+typedef Status (*ext_event_to_wire)(Display*, XEvent*, xEvent**, int*);
+
Status
XSendExtensionEvent(
register Display *dpy,
@@ -71,7 +76,7 @@ XSendExtensionEvent(
int ev_size;
xSendExtensionEventReq *req;
xEvent *ev;
-register Status(**fp) (Display *, XEvent*, xEvent **, int *);
+ext_event_to_wire *fp;
Status status;
XExtDisplayInfo *info = XInput_find_display(dpy);
@@ -81,10 +86,10 @@ XSendExtensionEvent(
/* call through display to find proper conversion routine */
-fp = dpy-wire_vec[event-type 0177];
+fp = (ext_event_to_wire*)dpy-wire_vec[event-type 0177];
if (*fp == NULL)
*fp = _XiEventToWire;
-status = (**fp) (dpy, event, ev, num_events);
+status = (*fp) (dpy, event, ev, num_events);
if (status) {
GetReq(SendExtensionEvent, req);
--
1.7.4.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 libXi 2/3] Silence compiler warning in XListDProp.c
On Fri, May 06, 2011 at 10:46:02AM +1000, Peter Hutterer wrote: XListDProp.c: In function 'XListDeviceProperties': XListDProp.c:72:9: warning: pointer targets in passing argument 2 of '_XRead32' differ in signedness /usr/include/X11/Xlibint.h:652:13: note: expected 'long int *' but argument is of type 'Atom *' God I hate Xlib. This does seem correct though. Reviewed-by: Daniel Stone dan...@fooishbar.org Cheers, Daniel ___ 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: xf86-input-synaptics
On Fri, May 06, 2011 at 01:45:18AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote: On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: 2.) Would you consider including an option which turns the touchpad off on keyboard (or other) input into the driver - so that ones doesnt requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. do you want to enable/disable based on modifiers too? No. Why would you? only modifiers, but combos as well (ctrl+c, ctrl+v)? As above. yes. that's actually one of the rather important features. People get annoyed if they can't use their mouse cursor while holding Ctrl down, or just after ctrl+rc. but then again, what is a modifier, what if the modifier is already in use (or not in use) by a client library? IIRC gtk has a concept of consumed modifiers, so some modifiers may not qualify to disable the touchpad. long story short, we should look at making it easier and less expensive for a client to monitor keyboards and toggle functionality in other devices. Cheers, Peter do you want to only disable tapping/scrolling, but not movement? No. seriously, the options will just pile up, requiring configuration, etc. and the last thing we need is more config options and properties. I agree, but we don't have to add them. ___ 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 libXi 2/3] Silence compiler warning in XListDProp.c
On Fri, May 06, 2011 at 01:57:32AM +0100, Daniel Stone wrote: On Fri, May 06, 2011 at 10:46:02AM +1000, Peter Hutterer wrote: XListDProp.c: In function 'XListDeviceProperties': XListDProp.c:72:9: warning: pointer targets in passing argument 2 of '_XRead32' differ in signedness /usr/include/X11/Xlibint.h:652:13: note: expected 'long int *' but argument is of type 'Atom *' God I hate Xlib. This does seem correct though. Reviewed-by: Daniel Stone dan...@fooishbar.org should've probably been more expansive on the commit message but: Atoms are typedef'd as unsigned long, see Xdefs.h. Hence the hilarity with 32 bit property handling on 64 bit. _XRead32 is a macro on 32bit (casting to (char*), hence no warning) but a function that takes a long* on 64 bit (hence the warning). Cheers, Peter ___ 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
Are we ready to tag release libXext 1.3.0?
It looks like we've still not done a release of libXext with the new XSyncAwaitFence() API yet, even though the proto server were released a while ago - is there anything remaining to do there or any reason not to go ahead and make a libXext 1.3.0 release? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: Are we ready to tag release libXext 1.3.0?
I'm not aware of any fence sync issues that would hold up a release. Everything should be ready to go. Thanks, -James nvpublic On 5/5/11 7:09 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: It looks like we've still not done a release of libXext with the new XSyncAwaitFence() API yet, even though the proto server were released a while ago - is there anything remaining to do there or any reason not to go ahead and make a libXext 1.3.0 release? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
[PULL updated] input fixes
Same as before, with the two patches daniel fixed up now and a number of XKB cleanups added. The following changes since commit 5cb31cd0cbf83fff5f17a475e7b0e45246b19bf3: Merge remote-tracking branch 'jturney/remove-opengl-spec-download' (2011-04-29 09:59:49 -0700) are available in the git repository at: git://people.freedesktop.org/~whot/xserver.git for-keith Alan Coopersmith (1): Move event filter initializer out of the structure itself Chase Douglas (1): Input: Pass co-ordinates by reference to transformAbsolute Daniel Stone (10): Input: Add DeepestSpriteWin function Input: Fix event size confusion in CheckPassiveGrabsOnWindow Input: Make CheckPassiveGrabsOnWindow take InternalEvent Input: Simplify CheckPassiveGrabsOnWindow loop XKB: Don't send unnecessary NewKeyboardNotifies XKB: Simplify a loop in ProcXkbGetKbdByName XKB: Remove duplicate keymap-copying loop XKB: Send NewKeyboardNotify for dev before its master/slaves XKB: Send XKB events for all devices to all clients XKB: Fix sense inversion for core MapNotify events Peter Hutterer (2): input: Only release SD buttons for explicit floating/reattachment (#36146) input: change CHECKEVENT macro to verify_internal_event function Xi/exevents.c |3 +- Xi/xichangehierarchy.c |2 + dix/devices.c |4 +- dix/events.c | 265 ++- dix/getevents.c| 28 +++--- dix/inpututils.c | 28 + include/dix.h |2 +- include/eventstr.h |4 - include/input.h|2 + include/inputstr.h | 10 ++ include/inpututils.h |2 + mi/mieq.c | 10 +- xkb/xkb.c | 51 +- xkb/xkbEvents.c| 43 +++- 14 files changed, 255 insertions(+), 199 deletions(-) pgpRPlQm2xiBP.pgp Description: PGP 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
