xf86-input-synaptics

[Cedric Sodhi]

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?

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?

Thanks
___
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

[Michel Dänzer]

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

[Michel Dänzer]

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 
> ---
>  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

[Daniel Stone]

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.

[Philipp Reh]

---
 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

[Ville Syrjälä]

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.

[Philipp Reh]

---
 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 

[PATCH] Added processing of confine protocol.

[Philipp Reh]

---
 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;
+
+  

Re: [PATCH xf86-video-ati 1/2] dri2: Update front buffer pixmap and name before exchanging buffers

[Ville Syrjälä]

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 
> > ---
> >  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

[Cyril Brulebois]

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 
" "Reviewed-by: Daniel Stone "' 
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

[Mario Kleiner]

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

[Eric Anholt]

On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes  
wrote:
> On Thu, 5 May 2011 11:17:02 +1000
> Dave Airlie  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

[Jesse Barnes]

On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston  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 adfd3d1..8654a37 10064

Re: Adding Reviewed-by (and the like) tags

[Daniel Stone]

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 
> " "Reviewed-by: Daniel Stone 
> "' 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

[Ville Syrjälä]

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.

[Cyril Brulebois]

Soeren Sandmann  (03/05/2011):
> Jeremy Huddleston  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 

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

[Mario Kleiner]

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: [PULL] Accumulated small input changes

[Daniel Stone]

On Wed, May 04, 2011 at 04:18:58PM +1000, Peter Hutterer wrote:
> On Tue, May 03, 2011 at 01:48:34AM +0100, Daniel Stone wrote:
> > On Fri, Apr 29, 2011 at 07:34:28AM -0700, Keith Packard wrote:
> > > Reviewed-by: Keith Packard 
> > > 
> > > I think that's all of them.
> > 
> > Ta, and yes.  Tree updated again (fa965fd..5bf3439).
> 
> please don't pull this one yet, it introduces a bug. something with grabs
> breaks.  test case is simply to open a gnome-terminal and try to select
> text, or close a window, or try click anything actually (xev that still sees
> the events for some reason). Haven't found the actual issue yet, but
> git bisect points at commit 3b9ab1dd7da48e3230f642b8e351ef76af40d1f8
> Input: Make CheckPassiveGrabsOnWindow take InternalEvent

Yeah, rebase error: a 'return TRUE;' from CheckPassiveGrabsOnWindow
landed in CheckDeviceGrabs, with broken indentation and all.  Oops.
Have pushed these, plus the as-yet-unreviewed XKB fixes from earlier, to
daniels/for-peter.

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

[Jesse Barnes]

On Thu, 5 May 2011 18:33:11 +0200
Mario Kleiner  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

[Daniel Stone]

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 

This looks fine to me.
Reviewed-by: Daniel Stone 

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

[Jeremy Huddleston]

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  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
> 

___
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

[Ville Syrjälä]

On Thu, May 05, 2011 at 09:54:48AM -0700, Jesse Barnes wrote:
> On Thu, 5 May 2011 18:33:11 +0200
> Mario Kleiner  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

[Jesse Barnes]

On Thu, 5 May 2011 10:07:24 -0700
Jeremy Huddleston  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

[Ville Syrjälä]

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

[James Cloos]

> "DS" == Daniel Stone  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 

DS> Alan - thoughts?

Didn't we already push this?  Or something based on this?

-JimC
-- 
James Cloos  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

[Jesse Barnes]

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

[Jesse Barnes]

Just add a new struct to remain compatible with existing code.

Signed-off-by: Jesse Barnes 

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] dri2proto: add new DRI2BufferSwapComplete struct to match spec

[Jesse Barnes]

Just add a new struct to remain compatible with existing code.

Signed-off-by: Jesse 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 9708a4a..ae7701b 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -304,6 +304,21 @@ typedef struct {
 CARD8 type;
 CARD8 pad;
 CARD16 sequenceNumber B16;
+CARD16 event_type B16;
+CARD16 pad2;
+CARD32 drawable B32;
+CARD32 ust_hi B32;
+CARD32 ust_lo B32;
+CARD32 msc_hi B32;
+CARD32 msc_lo B32;
+CARD32 sbc B32;
+} xDRI2BufferSwapComplete2;
+#define sz_xDRI2BufferSwapComplete2 32
+
+typedef struct {
+CARD8 type;
+CARD8 pad;
+CARD16 sequenceNumber B16;
 CARD32 drawable B32;
 CARD32 pad1 B32;
 CARD32 pad2 B32;
___
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

[Jesse Barnes]

Use the new swap event type so we get valid SBC values.

Signed-off-by: Jesse Barnes 

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

[PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jesse Barnes]

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 

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

Re: Compatible GLX swap event fixes

[Jesse Barnes]

On Thu, 5 May 2011 12:38:24 -0700
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).

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

[Jeremy Huddleston]

For *proto/mesa:
Reviewed-by: Jeremy Huddleston 

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 
> 
> 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

[Jesse Barnes]

On Thu, 05 May 2011 12:59:50 -0700
Jeremy Huddleston  wrote:

> For *proto/mesa:
> Reviewed-by: Jeremy Huddleston 

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

[Jeremy Huddleston]

On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:

> On Thu, 05 May 2011 12:59:50 -0700
> Jeremy Huddleston  wrote:
> 
>> For *proto/mesa:
>> Reviewed-by: Jeremy Huddleston 
> 
> 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

[Jesse Barnes]

On Thu, 05 May 2011 13:17:13 -0700
Jeremy Huddleston  wrote:

> 
> On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:
> 
> > On Thu, 05 May 2011 12:59:50 -0700
> > Jeremy Huddleston  wrote:
> > 
> >> For *proto/mesa:
> >> Reviewed-by: Jeremy Huddleston 
> > 
> > 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.

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.)

-- 
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

[Jeremy Huddleston]

>> 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

[Jesse Barnes]

On Thu, 05 May 2011 13:36:40 -0700
Jeremy Huddleston  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

[Jesse Barnes]

> >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

[Ian Romanick]

-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  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

[Ian Romanick]

-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 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3DE3UACgkQX1gOwKyEAw+bnwCfetNHCC9tVmfMwEG1rftt0ooH
oXsAn0eryd+YZCS8S5hsVQq/ILEtzX5A
=T9g0
-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

[Jesse Barnes]

On Thu, 05 May 2011 14:15:33 -0700
Ian Romanick  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 

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

[Alan Coopersmith]

On 05/ 5/11 11:42 AM, James Cloos wrote:
>> "DS" == Daniel Stone  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 
> 
> 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

[Peter Hutterer]

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 "
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 
> > " "Reviewed-by: Daniel Stone 
> > "' 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

[Peter Hutterer]

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

[Daniel Stone]

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  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

[Daniel Stone]

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

[Peter Hutterer]

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

[Daniel Stone]

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

[Peter Hutterer]

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 
---
 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

[Peter Hutterer]

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 
---
 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

[Peter Hutterer]

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 
---
 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 
 #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

[Daniel Stone]

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 

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

[Peter Hutterer]

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

[Peter Hutterer]

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 

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?

[Alan Coopersmith]

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?

[James Jones]

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"  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

[Peter Hutterer]

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

Re: xf86-input-synaptics

[Cedric Sodhi]

As for 1) (Clickpad). Will these new patches happen to adress the kernel
driver as well, so that we might have an option "Emulate 2/3-Button
presses" as with ClickFinger-2-3 in the kernel? So far, using GPM is out
of the question because I can only left click with that pad*.

2) Although I think Peter is making the issue seem more
complicated than it is (as for detecting when a user means to hold a
mod), I see his point that this is unlikely to be the responsbility of
the driver.

I for my part will probably go for a "double click in upper left corner
disabled touchpad", as it's proposed by HP. The LED would be perfect for
that :P

Cedric


* The Hp-Clickpad has a single, strip at the bottom of the touchpad
which is clickable. According to HP, the exact click should be
determined by accounting for the current "touch" when the click is made.


On Fri, May 06, 2011 at 11:04:02AM +1000, Peter Hutterer wrote:
> 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
___
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