xf86-input-synaptics
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
On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > I came to the conclusion that the xserver DRI2 invalidate patches that > have been discussed aren't really fixing the problem. I suppose they may > make the problem slightly less likely to happen, but at least for me that > likelyhood is still very high. The whole mess looks like a simple driver > bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv->buffers updated for other windows sharing the same pixmap? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-ati 1/2] dri2: Update front buffer pixmap and name before exchanging buffers
On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > Buffer exchange assumes that the front buffer pixmap and name > information is accurate. That may not be the case eg. if the window > has been (un)redirected since the buffer was created. > > Signed-off-by: Ville Syrjala > --- > src/radeon_dri2.c | 45 - > 1 files changed, 40 insertions(+), 5 deletions(-) > > diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c > index e618cc5..5d1a382 100644 > --- a/src/radeon_dri2.c > +++ b/src/radeon_dri2.c > @@ -626,12 +626,42 @@ radeon_dri2_schedule_flip(ScrnInfoPtr scrn, ClientPtr > client, > } > > static Bool > -can_exchange(ScrnInfoPtr pScrn, > +update_front(DrawablePtr draw, DRI2BufferPtr front) > +{ > +int r; > +PixmapPtr pixmap; > +struct dri2_buffer_priv *priv = front->driverPrivate; > +struct radeon_exa_pixmap_priv *driver_priv; > + > +if (draw->type == DRAWABLE_PIXMAP) > + pixmap = (PixmapPtr)draw; > +else > + pixmap = (*draw->pScreen->GetWindowPixmap)((WindowPtr)draw); > + > +pixmap->refcnt++; > + > +exaMoveInPixmap(pixmap); > +driver_priv = exaGetPixmapDriverPrivate(pixmap); > +r = radeon_gem_get_kernel_name(driver_priv->bo, &front->name); > +if (r) { > + (*draw->pScreen->DestroyPixmap)(pixmap); > + return FALSE; > +} > +(*draw->pScreen->DestroyPixmap)(priv->pixmap); > +front->pitch = pixmap->devKind; > +front->cpp = pixmap->drawable.bitsPerPixel / 8; > +priv->pixmap = pixmap; > + > +return TRUE; > +} Maybe at least some of this could be short-circuited if it's still the same pixmap. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/6] XKB event regression fixes and cleanup
On Thu, May 05, 2011 at 02:34:05AM +0100, Daniel Stone wrote: > This series cleans up XKB event sending a bit, and hopefully fixes a > couple of regressions from f06a9d. If these seem happy in master then > I'll nominate them for stable branches too. Oh, and for those of you who prefer branches, all of these (as well as the missing two commits from Peter's previous pull request) are available in my for-peter tree, which is based on top of Peter's for-keith. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Added confine protocol.
--- XI2proto.h | 83 --- 1 files changed, 62 insertions(+), 21 deletions(-) diff --git a/XI2proto.h b/XI2proto.h index 84574a5..5ded2f3 100644 --- a/XI2proto.h +++ b/XI2proto.h @@ -71,27 +71,29 @@ /** * XI2 Request opcodes */ -#define X_XIQueryPointer40 -#define X_XIWarpPointer 41 -#define X_XIChangeCursor42 -#define X_XIChangeHierarchy 43 -#define X_XISetClientPointer44 -#define X_XIGetClientPointer45 -#define X_XISelectEvents46 -#define X_XIQueryVersion47 -#define X_XIQueryDevice 48 -#define X_XISetFocus49 -#define X_XIGetFocus50 -#define X_XIGrabDevice 51 -#define X_XIUngrabDevice52 -#define X_XIAllowEvents 53 -#define X_XIPassiveGrabDevice 54 -#define X_XIPassiveUngrabDevice 55 -#define X_XIListProperties 56 -#define X_XIChangeProperty 57 -#define X_XIDeleteProperty 58 -#define X_XIGetProperty 59 -#define X_XIGetSelectedEvents 60 +#define X_XIQueryPointer 40 +#define X_XIWarpPointer 41 +#define X_XIChangeCursor 42 +#define X_XIChangeHierarchy 43 +#define X_XISetClientPointer 44 +#define X_XIGetClientPointer 45 +#define X_XISelectEvents 46 +#define X_XIQueryVersion 47 +#define X_XIQueryDevice 48 +#define X_XISetFocus 49 +#define X_XIGetFocus 50 +#define X_XIGrabDevice 51 +#define X_XIUngrabDevice 52 +#define X_XIAllowEvents 53 +#define X_XIPassiveGrabDevice54 +#define X_XIPassiveUngrabDevice 55 +#define X_XIListProperties 56 +#define X_XIChangeProperty 57 +#define X_XIDeleteProperty 58 +#define X_XIGetProperty 59 +#define X_XIGetSelectedEvents60 +#define X_XIGrabDeviceWithConfine61 +#define X_XIPassiveGrabDeviceWithConfine 62 /** Number of XI requests */ #define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) @@ -569,6 +571,25 @@ typedef struct { } xXIGrabDeviceReq; #define sz_xXIGrabDeviceReq 24 +typedef struct { +uint8_t reqType; +uint8_t ReqType;/**< Always ::X_XIGrabDeviceWithConfine */ +uint16_tlength; /**< Length in 4 byte units */ +Window grab_window; +Window confine_to; +Timetime; +Cursor cursor; +uint16_tdeviceid; +uint8_t grab_mode; +uint8_t paired_device_mode; +uint8_t owner_events; +uint8_t pad; +uint16_tmask_len; +} xXIGrabDeviceWithConfineReq; + +#define sz_xXIGrabDeviceWithConfineReq 28 + + /** * Return codes from a XIPassiveGrabDevice request. */ @@ -648,6 +669,26 @@ typedef struct { #define sz_xXIPassiveGrabDeviceReq 32 typedef struct { +uint8_t reqType; +uint8_t ReqType;/**< Always ::X_XIPassiveGrabDeviceWithConfine */ +uint16_tlength; /**< Length in 4 byte units */ +Timetime; +Window grab_window; +Window confine_to; +Cursor cursor; +uint32_tdetail; +uint16_tdeviceid; +uint16_tnum_modifiers; +uint16_tmask_len; +uint8_t grab_type; +uint8_t grab_mode; +uint8_t paired_device_mode; +uint8_t owner_events; +uint16_tpad1; +} xXIPassiveGrabDeviceWithConfineReq; +#define sz_xXIPassiveGrabDeviceWithConfineReq 36 + +typedef struct { uint8_t repType;/**< Input extension major opcode */ uint8_t RepType;/**< Always ::X_XIPassiveGrabDevice */ uint16_tsequenceNumber; -- 1.7.5.rc3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-ati page flipping fixes
On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: > On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > > I came to the conclusion that the xserver DRI2 invalidate patches that > > have been discussed aren't really fixing the problem. I suppose they may > > make the problem slightly less likely to happen, but at least for me that > > likelyhood is still very high. The whole mess looks like a simple driver > > bug to me. > > I think the xserver patches are still necessary, otherwise how are the > cached DRI2 pPriv->buffers updated for other windows sharing the same > pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Added WithConfine functions.
--- include/X11/extensions/XInput2.h | 43 +++ src/XIGrabDevice.c | 18 +++-- src/XIPassiveGrab.c | 52 + 3 files changed, 98 insertions(+), 15 deletions(-) diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h index 3fcf083..f297801 100644 --- a/include/X11/extensions/XInput2.h +++ b/include/X11/extensions/XInput2.h @@ -402,6 +402,19 @@ extern Status XIGrabDevice( XIEventMask*mask ); +extern Status XIGrabDeviceWithConfine( + Display* dpy, + intdeviceid, + Window grab_window, + Window confine_to, + Time time, + Cursor cursor, + intgrab_mode, + intpaired_device_mode, + Bool owner_events, + XIEventMask*mask +); + extern Status XIUngrabDevice( Display* dpy, intdeviceid, @@ -429,6 +442,21 @@ extern int XIGrabButton( XIGrabModifiers *modifiers_inout ); +extern int XIGrabButtonWithConfine( +Display*display, +int deviceid, +int button, +Window grab_window, +Window confine_to, +Cursor cursor, +int grab_mode, +int paired_device_mode, +int owner_events, +XIEventMask *mask, +int num_modifiers, +XIGrabModifiers *modifiers_inout +); + extern int XIGrabKeycode( Display*display, int deviceid, @@ -455,6 +483,20 @@ extern int XIGrabEnter( XIGrabModifiers *modifiers_inout ); +extern int XIGrabEnterWithConfine( +Display*display, +int deviceid, +Window grab_window, +Window confine_to, +Cursor cursor, +int grab_mode, +int paired_device_mode, +int owner_events, +XIEventMask *mask, +int num_modifiers, +XIGrabModifiers *modifiers_inout +); + extern int XIGrabFocusIn( Display*display, int deviceid, @@ -466,6 +508,7 @@ extern int XIGrabFocusIn( int num_modifiers, XIGrabModifiers *modifiers_inout ); + extern Status XIUngrabButton( Display*display, int deviceid, diff --git a/src/XIGrabDevice.c b/src/XIGrabDevice.c index 94feaee..e989ee0 100644 --- a/src/XIGrabDevice.c +++ b/src/XIGrabDevice.c @@ -35,7 +35,18 @@ XIGrabDevice(Display* dpy, int deviceid, Window grab_window, Time time, Cursor cursor, int grab_mode, int paired_device_mode, Bool owner_events, XIEventMask *mask) { -xXIGrabDeviceReq *req; +return XIGrabDeviceWithConfine(dpy, deviceid, grab_window, None, time, + cursor, grab_mode, paired_device_mode, + owner_events, mask); +} + +Status +XIGrabDeviceWithConfine(Display* dpy, int deviceid, Window grab_window, +Window confine_to, Time time, Cursor cursor, +int grab_mode, int paired_device_mode, +Bool owner_events, XIEventMask *mask) +{ +xXIGrabDeviceWithConfineReq *req; xXIGrabDeviceReply reply; char* buff; int len; @@ -46,11 +57,12 @@ XIGrabDevice(Display* dpy, int deviceid, Window grab_window, Time time, if (_XiCheckExtInit(dpy, XInput_2_0, extinfo) == -1) return (NoSuchExtension); -GetReq(XIGrabDevice, req); +GetReq(XIGrabDeviceWithConfine, req); req->reqType = extinfo->codes->major_opcode; -req->ReqType = X_XIGrabDevice; +req->ReqType = X_XIGrabDeviceWithConfine; req->deviceid = deviceid; req->grab_window = grab_window; +req->confine_to = confine_to; req->time = time; req->grab_mode = grab_mode; req->paired_device_mode = paired_device_mode; diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c index feef74b..3e10356 100644 --- a/src/XIPassiveGrab.c +++ b/src/XIPassiveGrab.c @@ -31,12 +31,12 @@ static int _XIPassiveGrabDevice(Display* dpy, int deviceid, int grabtype, int detail, - Window grab_window, Cursor cursor, + Window grab_window, Window confine_to, Cursor cursor, int grab_mode, int paired_device_mode, Bool owner_events, XIEventMask *mask, int num_modifiers, XIGrabModifiers *modifiers_inout) { -xXIPassiveGrabDeviceReq *req; +xXIPassiveGrabDeviceWithConfineReq *req; xXIPassiveGrabDeviceReply reply; xXIGrabModifierInfo *failed_mods; int len = 0, i; @@ -48,14 +48,15 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int
[PATCH] Added processing of confine protocol.
--- Xi/extinit.c |8 ++- Xi/xigrabdev.c | 101 + Xi/xigrabdev.h |3 + Xi/xipassivegrab.c | 139 +++- Xi/xipassivegrab.h |2 + 5 files changed, 194 insertions(+), 59 deletions(-) diff --git a/Xi/extinit.c b/Xi/extinit.c index 51e0078..4a6f4cc 100644 --- a/Xi/extinit.c +++ b/Xi/extinit.c @@ -259,7 +259,9 @@ static int (*ProcIVector[])(ClientPtr) = { ProcXIChangeProperty, /* 57 */ ProcXIDeleteProperty, /* 58 */ ProcXIGetProperty, /* 59 */ -ProcXIGetSelectedEvents /* 60 */ +ProcXIGetSelectedEvents,/* 60 */ +ProcXIGrabDeviceWithConfine,/* 61 */ +ProcXIPassiveGrabDeviceWithConfine /* 62 */ }; /* For swapped clients */ @@ -324,7 +326,9 @@ static int (*SProcIVector[])(ClientPtr) = { SProcXIChangeProperty, /* 57 */ SProcXIDeleteProperty, /* 58 */ SProcXIGetProperty, /* 59 */ -SProcXIGetSelectedEvents /* 60 */ +SProcXIGetSelectedEvents,/* 60 */ +SProcXIGrabDeviceWithConfine,/* 61 */ +SProcXIPassiveGrabDeviceWithConfine /* 62 */ }; /* diff --git a/Xi/xigrabdev.c b/Xi/xigrabdev.c index 0adc878..25b19aa 100644 --- a/Xi/xigrabdev.c +++ b/Xi/xigrabdev.c @@ -42,25 +42,25 @@ #include "exevents.h" #include "xigrabdev.h" -int -SProcXIGrabDevice(ClientPtr client) +static void +XIConvertGrabDeviceReq(xXIGrabDeviceWithConfineReq *result, xXIGrabDeviceReq *source) { -char n; - -REQUEST(xXIGrabDeviceReq); - -swaps(&stuff->length, n); -swaps(&stuff->deviceid, n); -swapl(&stuff->grab_window, n); -swapl(&stuff->cursor, n); -swapl(&stuff->time, n); -swaps(&stuff->mask_len, n); - -return ProcXIGrabDevice(client); +result->reqType = X_XIGrabDeviceWithConfine; +result->length = source->length + 1; /* length is always in 4 bytes, + 1 for confine_to field */ +result->grab_window = source->grab_window; +result->confine_to = None; +result->time = source->time; +result->cursor = source->cursor; +result->deviceid = source->deviceid; +result->grab_mode = source->grab_mode; +result->paired_device_mode = source->paired_device_mode; +result->owner_events = source->owner_events; +/*result->pad*/ +result->mask_len = source->mask_len; } -int -ProcXIGrabDevice(ClientPtr client) +static int +XIGrabDeviceImpl(ClientPtr client, xXIGrabDeviceWithConfineReq *stuff, unsigned char *extra) { DeviceIntPtr dev; xXIGrabDeviceReply rep; @@ -69,9 +69,6 @@ ProcXIGrabDevice(ClientPtr client) GrabMask mask; int mask_len; -REQUEST(xXIGrabDeviceReq); -REQUEST_AT_LEAST_SIZE(xXIGrabDeviceReq); - ret = dixLookupDevice(&dev, stuff->deviceid, client, DixGrabAccess); if (ret != Success) return ret; @@ -79,13 +76,13 @@ ProcXIGrabDevice(ClientPtr client) if (!IsMaster(dev)) stuff->paired_device_mode = GrabModeAsync; -if (XICheckInvalidMaskBits(client, (unsigned char*)&stuff[1], +if (XICheckInvalidMaskBits(client, extra, stuff->mask_len * 4) != Success) return BadValue; mask_len = min(sizeof(mask.xi2mask[stuff->deviceid]), stuff->mask_len * 4); memset(mask.xi2mask, 0, sizeof(mask.xi2mask)); -memcpy(mask.xi2mask, (char*)&stuff[1], mask_len); +memcpy(mask.xi2mask, extra, mask_len); ret = GrabDevice(client, dev, stuff->grab_mode, stuff->paired_device_mode, @@ -95,7 +92,7 @@ ProcXIGrabDevice(ClientPtr client) &mask, GRABTYPE_XI2, stuff->cursor, - None /* confineTo */, + stuff->confine_to, &status); if (ret != Success) @@ -112,6 +109,66 @@ ProcXIGrabDevice(ClientPtr client) return ret; } +static int +SXIGrabDeviceImpl(ClientPtr client, xXIGrabDeviceWithConfineReq *stuff, unsigned char *extra) +{ +char n; + +swaps(&stuff->length, n); +swaps(&stuff->deviceid, n); +swapl(&stuff->grab_window, n); +swapl(&stuff->confine_to, n); +swapl(&stuff->cursor, n); +swapl(&stuff->time, n); +swaps(&stuff->mask_len, n); + +return XIGrabDeviceImpl(client, stuff, extra); +} + +int +SProcXIGrabDevice(ClientPtr client) +{ +xXIGrabDeviceWithConfineReq new_stuff; + +REQUEST(xXIGrabDeviceReq); +REQUEST_AT_LEAST_SIZE(xXIGrabDeviceReq); + +XIConvertGrabDeviceReq(&new_stuff, stuff); + +return SXIGrabDeviceImpl(client, &new_stuff, (unsigned char*)&stuff[1]); +} + +int +ProcXIGrabDevice(ClientPtr client) +{ +xXIGrabDeviceWithConfineReq new_stuff; + +
Re: [PATCH xf86-video-ati 1/2] dri2: Update front buffer pixmap and name before exchanging buffers
On Thu, May 05, 2011 at 12:28:20PM +0200, Michel Dänzer wrote: > On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > > Buffer exchange assumes that the front buffer pixmap and name > > information is accurate. That may not be the case eg. if the window > > has been (un)redirected since the buffer was created. > > > > Signed-off-by: Ville Syrjala > > --- > > src/radeon_dri2.c | 45 - > > 1 files changed, 40 insertions(+), 5 deletions(-) > > > > diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c > > index e618cc5..5d1a382 100644 > > --- a/src/radeon_dri2.c > > +++ b/src/radeon_dri2.c > > @@ -626,12 +626,42 @@ radeon_dri2_schedule_flip(ScrnInfoPtr scrn, ClientPtr > > client, > > } > > > > static Bool > > -can_exchange(ScrnInfoPtr pScrn, > > +update_front(DrawablePtr draw, DRI2BufferPtr front) > > +{ > > +int r; > > +PixmapPtr pixmap; > > +struct dri2_buffer_priv *priv = front->driverPrivate; > > +struct radeon_exa_pixmap_priv *driver_priv; > > + > > +if (draw->type == DRAWABLE_PIXMAP) > > + pixmap = (PixmapPtr)draw; > > +else > > + pixmap = (*draw->pScreen->GetWindowPixmap)((WindowPtr)draw); > > + > > +pixmap->refcnt++; > > + > > +exaMoveInPixmap(pixmap); > > +driver_priv = exaGetPixmapDriverPrivate(pixmap); > > +r = radeon_gem_get_kernel_name(driver_priv->bo, &front->name); > > +if (r) { > > + (*draw->pScreen->DestroyPixmap)(pixmap); > > + return FALSE; > > +} > > +(*draw->pScreen->DestroyPixmap)(priv->pixmap); > > +front->pitch = pixmap->devKind; > > +front->cpp = pixmap->drawable.bitsPerPixel / 8; > > +priv->pixmap = pixmap; > > + > > +return TRUE; > > +} > > Maybe at least some of this could be short-circuited if it's still the > same pixmap. Yeah, I had the same thought. There's one catch though; Even if it's the same pixmap, the bo may have been exchanged, and so the buffer name may need to be updated anyway. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Adding Reviewed-by (and the like) tags
Hi, I guess it might be worth mentioning somewhere in the wiki how to easily (in an automated fashion) add r-b tags to a range of commits. Following Jon's suggestion on IRC, I've opted for: git filter-branch --msg-filter 'add-tag.sh "Reviewed-by: Peter Hutterer " "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
On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: I came to the conclusion that the xserver DRI2 invalidate patches that have been discussed aren't really fixing the problem. I suppose they may make the problem slightly less likely to happen, but at least for me that likelyhood is still very high. The whole mess looks like a simple driver bug to me. I think the xserver patches are still necessary, otherwise how are the cached DRI2 pPriv->buffers updated for other windows sharing the same pixmap? As the real front buffers are not handed out to clients, there isn't that much reason to update them. Making sure the fake front buffer contain a more recent snapshot of the real front would be one reason though. Could it be that your patch fixes a closely related, but different bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer assignment and only queries the current assignment from the x-server if its drawable has been invalidated, which is what the x-server patches do. I'd also think you will need both patch sets. -mario ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] glproto changes
On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes 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
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
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
On Thu, May 05, 2011 at 05:09:56PM +0200, Mario Kleiner wrote: > On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: > > > On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: > >> On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > >>> I came to the conclusion that the xserver DRI2 invalidate patches > >>> that > >>> have been discussed aren't really fixing the problem. I suppose > >>> they may > >>> make the problem slightly less likely to happen, but at least for > >>> me that > >>> likelyhood is still very high. The whole mess looks like a simple > >>> driver > >>> bug to me. > >> > >> I think the xserver patches are still necessary, otherwise how are > >> the > >> cached DRI2 pPriv->buffers updated for other windows sharing the same > >> pixmap? > > > > As the real front buffers are not handed out to clients, there isn't > > that much reason to update them. Making sure the fake front buffer > > contain a more recent snapshot of the real front would be one reason > > though. > > > > Could it be that your patch fixes a closely related, but different > bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer > assignment and only queries the current assignment from the x-server > if its drawable has been invalidated, which is what the x-server > patches do. > > I'd also think you will need both patch sets. Back buffers are private so a swap for one drawable doesn't need to invalidate them for other drawables. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Don't call pixman_disable_out_of_bounds_workaround() anymore.
Soeren Sandmann (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
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
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
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
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
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
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
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
On Thu, May 05, 2011 at 06:33:11PM +0200, ext Mario Kleiner wrote: > > On May 5, 2011, at 6:06 PM, Ville Syrjälä wrote: > > > On Thu, May 05, 2011 at 05:09:56PM +0200, Mario Kleiner wrote: > >> On May 5, 2011, at 4:23 PM, Ville Syrjälä wrote: > >> > >>> On Thu, May 05, 2011 at 11:46:45AM +0200, Michel Dänzer wrote: > On Mit, 2011-05-04 at 23:51 +0300, Ville Syrjala wrote: > > I came to the conclusion that the xserver DRI2 invalidate patches > > that > > have been discussed aren't really fixing the problem. I suppose > > they may > > make the problem slightly less likely to happen, but at least for > > me that > > likelyhood is still very high. The whole mess looks like a simple > > driver > > bug to me. > > I think the xserver patches are still necessary, otherwise how are > the > cached DRI2 pPriv->buffers updated for other windows sharing the > same > pixmap? > >>> > >>> As the real front buffers are not handed out to clients, there isn't > >>> that much reason to update them. Making sure the fake front buffer > >>> contain a more recent snapshot of the real front would be one reason > >>> though. > >>> > >> > >> Could it be that your patch fixes a closely related, but different > >> bug? During OpenGL rendering, Mesa/Gallium caches the backbuffer > >> assignment and only queries the current assignment from the x-server > >> if its drawable has been invalidated, which is what the x-server > >> patches do. > >> > >> I'd also think you will need both patch sets. > > > > Back buffers are private so a swap for one drawable doesn't need to > > invalidate them for other drawables. > > > > Are you sure this is also the case even when kms page flipping is > used for fullscreen drawables? Yes, and if not, it's a driver bug. > The workaround i implemented in my toolkit for the page flipping > problem when using fullscreen drawables on current x servers was to > make sure that it always ends a session with an even number of > completed page-flipping swaps, by checking 'sbc' and issuing an extra > swap before closing its window if the sbc wasn't an even number. This > makes sure that the same buffer objects are assigned as front- and > backbuffer at the time the window closes as when the application > started and opened its fullscreen window. This fixed any desktop > corruption i'd usually get when running compiz with non-redirected > fullscreen windows after quitting my application. > > I could be totally wrong, but at least the symptoms and the working > workaround suggested fullscreen drawables do share their back buffers > when page flipping is on. The bug allows the BOs to get mixed up pretty much any which way between DRI2 buffers. Eg. if two drawables got the same BO as the front buffer in their GetBuffers requests, and then both would do a page flip, both would end up with the same BO as their new back buffer. -- Ville Syrjälä ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] libX11: allow inclusion of system level compose files
> "DS" == Daniel Stone 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
This set is compatible with existing code bases since it adds a new struct to the glx and dri2 proto files instead of renaming existing fields. New clients with old servers will see larger, but still broken, SBC values. Old clients with new servers will see the same bad values they see today. And new clients with new servers will see correct SBC values (yay). I won't push until I get at least a couple of reviewed-by and at least one tested-by from people. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec
Just add a new struct to remain compatible with existing code. Signed-off-by: Jesse Barnes 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
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
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
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
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
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
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
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
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
>> Yes, I realize that there are some areas that use 64bit for sbc. Do we >> really need 64bits for this? If so, how do we properly to communicate the >> 64bit value between server/client? Currently, your changes result in an >> implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause >> problems if we really do need those extra bits: >> >>if (swap_complete) >>swap_complete(client, swap_data, type, ust, frame, pPriv->swap_count); >> >> It looks to me like much more of DRI2 should be rewritten to use 32bit swap >> counts, or there should be some other mechanism in place to communicate the >> full 64bit value. > > Yeah there are other mechanisms (the OML sync extension) for > communicating the whole 64 bits. Both the swap reply and msc reply > deal in the full 64 bits, just the swap event (an unrelated extension) > truncates to 32 bits. (Also I think the 64 bit size for swap count in > the OML extension is just inertia; getting to a count that high even at > 120Hz is going to take awhile.) Ok, well this all really doesn't sit well with me, but it would put my mind slightly at ease if you would do some logging of the problem if we encounter it in DRI2SwapComplete. That might give your future self some clue as to what is going wrong when you see issues down the road: if (swap_complete) { if (pPriv->swap_count > 0x) ErrorF("something appropriate"); swap_complete(client, swap_data, type, ust, frame, (CARD32)pPriv->swap_count); } ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
On Thu, 05 May 2011 13:36:40 -0700 Jeremy Huddleston wrote: > >> Yes, I realize that there are some areas that use 64bit for sbc. Do we > >> really need 64bits for this? If so, how do we properly to communicate the > >> 64bit value between server/client? Currently, your changes result in an > >> implicit cast from 64bit to 32bits in DRI2SwapComplete which will cause > >> problems if we really do need those extra bits: > >> > >>if (swap_complete) > >>swap_complete(client, swap_data, type, ust, frame, > >> pPriv->swap_count); > >> > >> It looks to me like much more of DRI2 should be rewritten to use 32bit > >> swap counts, or there should be some other mechanism in place to > >> communicate the full 64bit value. > > > > Yeah there are other mechanisms (the OML sync extension) for > > communicating the whole 64 bits. Both the swap reply and msc reply > > deal in the full 64 bits, just the swap event (an unrelated extension) > > truncates to 32 bits. (Also I think the 64 bit size for swap count in > > the OML extension is just inertia; getting to a count that high even at > > 120Hz is going to take awhile.) > > Ok, well this all really doesn't sit well with me, but it would put my mind > slightly at ease if you would do some logging of the problem if we encounter > it in DRI2SwapComplete. That might give your future self some clue as to > what is going wrong when you see issues down the road: > >if (swap_complete) { >if (pPriv->swap_count > 0x) >ErrorF("something appropriate"); >swap_complete(client, swap_data, type, ust, frame, > (CARD32)pPriv->swap_count); >} Yeah, it's annoying. How about I leave out the error message and handle wrapping on the client side instead? That way at least the client code won't notice that the server is only transmitting 32 bits... -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
> >if (swap_complete) { > >if (pPriv->swap_count > 0x) > >ErrorF("something appropriate"); > >swap_complete(client, swap_data, type, ust, frame, > > (CARD32)pPriv->swap_count); > >} > > Yeah, it's annoying. How about I leave out the error message and handle > wrapping on the client side instead? That way at least the client code > won't notice that the server is only transmitting 32 bits... Nevermind, that can't work generally since clients are free to mask/unmask the events, so we could miss a 0 count and thus a wrap. We just have to live with the fact that swap events have a 32 bit sbc and OML uses 64 bit counts. I'll add the warning though; if it becomes a real issue we can potentially add another round trip to get the value using OML instead. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/2011 01:25 PM, Jesse Barnes wrote: > On Thu, 05 May 2011 13:17:13 -0700 > Jeremy Huddleston 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
-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
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
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
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
On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: > Hello list, > > I've two questions concerning synaptic: > > 1.) I've one of those snyaptics driven HP "Clickpads" (HP Touchsmart > tm2) and it has a little LED on it, which is supposed to be lit when the > TP is off, but it doesn't when I turn the TP off with synclient. Why, or > how do I fix that? not yet. clickpad patches were floating around at some point but IIRC the last round of them had a few outstanding review comments. > 2.) Would you consider including an option which turns the touchpad off > on keyboard (or other) input into the driver - so that ones doesnt > requie a helper program for that? no, the driver doesn't know when keyboard input is made. and given that any such option will soon want about 15 configuration options, it's better to keep it in a client program. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] libX11: allow inclusion of system level compose files
On Thu, May 05, 2011 at 02:51:19PM -0700, Alan Coopersmith wrote: > On 05/ 5/11 11:42 AM, James Cloos wrote: > >> "DS" == Daniel Stone writes: > > DS> This looks fine to me. > > DS> > > DS> Alan - thoughts? > > > > Didn't we already push this? Or something based on this? > > I thought so - and looking in git I see: > > http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=9df349a7894725f9469b106af645f57f7f3f9af3 Aha, sorry, I'd searched for Myllynen, and that hadn't come up. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-input-synaptics
On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: > On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: > > I've two questions concerning synaptic: > > > > 1.) I've one of those snyaptics driven HP "Clickpads" (HP Touchsmart > > tm2) and it has a little LED on it, which is supposed to be lit when the > > TP is off, but it doesn't when I turn the TP off with synclient. Why, or > > how do I fix that? > > not yet. clickpad patches were floating around at some point but IIRC the > last round of them had a few outstanding review comments. I have a working clickpad tree that I will be pushing for review soon, but I don't have any HP laptops, or any of the ones with LEDs. > > 2.) Would you consider including an option which turns the touchpad off > > on keyboard (or other) input into the driver - so that ones doesnt > > requie a helper program for that? > > no, the driver doesn't know when keyboard input is made. and given that any > such option will soon want about 15 configuration options, it's better to > keep it in a client program. Eh, it's actually easily doable; just have a per-device property for the time in millis to ignore all input for after a keyboard event, and do it all in DIX if that property is ever set on a device. That way you can still have the clients in control, but you don't have to rely on an external daemon constantly enabling and disabling your touchpad. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-input-synaptics
On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: > On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: > > On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: > > > I've two questions concerning synaptic: > > > > > > 1.) I've one of those snyaptics driven HP "Clickpads" (HP Touchsmart > > > tm2) and it has a little LED on it, which is supposed to be lit when the > > > TP is off, but it doesn't when I turn the TP off with synclient. Why, or > > > how do I fix that? > > > > not yet. clickpad patches were floating around at some point but IIRC the > > last round of them had a few outstanding review comments. > > I have a working clickpad tree that I will be pushing for review soon, > but I don't have any HP laptops, or any of the ones with LEDs. > > > > 2.) Would you consider including an option which turns the touchpad off > > > on keyboard (or other) input into the driver - so that ones doesnt > > > requie a helper program for that? > > > > no, the driver doesn't know when keyboard input is made. and given that any > > such option will soon want about 15 configuration options, it's better to > > keep it in a client program. > > Eh, it's actually easily doable; just have a per-device property for the > time in millis to ignore all input for after a keyboard event, and do it > all in DIX if that property is ever set on a device. > > That way you can still have the clients in control, but you don't have > to rely on an external daemon constantly enabling and disabling your > touchpad. do you want to enable/disable based on modifiers too? only modifiers, but combos as well (ctrl+c, ctrl+v)? do you want to only disable tapping/scrolling, but not movement? seriously, the options will just pile up, requiring configuration, etc. and the last thing we need is more config options and properties. we've got something that's working now. not ideal, but well enough. afaiui the biggest issue is the costly monitoring of keyboard input by the client, not the single request to enable/disable the device. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-input-synaptics
On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote: > On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: > > On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: > > > On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: > > > > 2.) Would you consider including an option which turns the touchpad off > > > > on keyboard (or other) input into the driver - so that ones doesnt > > > > requie a helper program for that? > > > > > > no, the driver doesn't know when keyboard input is made. and given that > > > any > > > such option will soon want about 15 configuration options, it's better to > > > keep it in a client program. > > > > Eh, it's actually easily doable; just have a per-device property for the > > time in millis to ignore all input for after a keyboard event, and do it > > all in DIX if that property is ever set on a device. > > > > That way you can still have the clients in control, but you don't have > > to rely on an external daemon constantly enabling and disabling your > > touchpad. > > do you want to enable/disable based on modifiers too? No. Why would you? > only modifiers, but combos as well (ctrl+c, ctrl+v)? As above. > do you want to only disable tapping/scrolling, but not movement? No. > seriously, the options will just pile up, requiring configuration, etc. and > the last thing we need is more config options and properties. I agree, but we don't have to add them. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXi 1/3] man: fix typo, layout in XGetExtensionVersion.man
Fix a typo and move from MPX to XI2. Add a linebreak to make the depreciation separate from the function description. Changes in the second paragraph are just realignment due to the linebreak. Signed-off-by: Peter Hutterer --- man/XGetExtensionVersion.txt | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/man/XGetExtensionVersion.txt b/man/XGetExtensionVersion.txt index 3e24fc7..c7d45f4 100644 --- a/man/XGetExtensionVersion.txt +++ b/man/XGetExtensionVersion.txt @@ -25,11 +25,12 @@ DESCRIPTION --- The XGetExtensionVersion request is deprecated and should not - be used. Clients issuing a XgetExtensionVersion request will - not be able to use MPX features. The XGetExtensionVersion - request queries the version of the input extension, and returns - an XExtensionVersion structure. This structure contains a - major_version and minor_version number which can be compared + be used in XI2 applications. Clients issuing a XGetExtensionVersion + request will not be able to use XI2 features. + + The XGetExtensionVersion request queries the version of the input + extension, and returns an XExtensionVersion structure. This structure + contains a major_version and minor_version number which can be compared with constants defined in XI.h. Support for additional protocol requests added to the input extension after its initial release is indicated by a version number corresponding to the added -- 1.7.4.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXi 2/3] Silence compiler warning in XListDProp.c
XListDProp.c: In function 'XListDeviceProperties': XListDProp.c:72:9: warning: pointer targets in passing argument 2 of '_XRead32' differ in signedness /usr/include/X11/Xlibint.h:652:13: note: expected 'long int *' but argument is of type 'Atom *' Signed-off-by: Peter Hutterer --- src/XListDProp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/XListDProp.c b/src/XListDProp.c index 66b9eca..8667350 100644 --- a/src/XListDProp.c +++ b/src/XListDProp.c @@ -69,7 +69,7 @@ XListDeviceProperties(Display* dpy, XDevice* dev, int *nprops_return) goto cleanup; } -_XRead32(dpy, props, rep.nAtoms << 2); +_XRead32(dpy, (long*)props, rep.nAtoms << 2); } *nprops_return = rep.nAtoms; -- 1.7.4.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXi 3/3] Silence compiler warning due to differnent event conversion procs
XExtInt.c:161:5: warning: initialization from incompatible pointer type XSndExEv.c: In function 'XSendExtensionEvent': XSndExEv.c:84:8: warning: assignment from incompatible pointer type Xlib and libXi differ in the conversion functions. libXi takes an xEvent** and a num_events parameter since it may split an event into multiple xEvents. Signed-off-by: Peter Hutterer --- 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
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
On Fri, May 06, 2011 at 01:45:18AM +0100, Daniel Stone wrote: > On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote: > > On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote: > > > On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote: > > > > On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote: > > > > > 2.) Would you consider including an option which turns the touchpad > > > > > off > > > > > on keyboard (or other) input into the driver - so that ones doesnt > > > > > requie a helper program for that? > > > > > > > > no, the driver doesn't know when keyboard input is made. and given that > > > > any > > > > such option will soon want about 15 configuration options, it's better > > > > to > > > > keep it in a client program. > > > > > > Eh, it's actually easily doable; just have a per-device property for the > > > time in millis to ignore all input for after a keyboard event, and do it > > > all in DIX if that property is ever set on a device. > > > > > > That way you can still have the clients in control, but you don't have > > > to rely on an external daemon constantly enabling and disabling your > > > touchpad. > > > > do you want to enable/disable based on modifiers too? > > No. Why would you? > > > only modifiers, but combos as well (ctrl+c, ctrl+v)? > > As above. yes. that's actually one of the rather important features. People get annoyed if they can't use their mouse cursor while holding Ctrl down, or just after ctrl+rc. but then again, what is a modifier, what if the modifier is already in use (or not in use) by a client library? IIRC gtk has a concept of "consumed modifiers", so some modifiers may not qualify to disable the touchpad. long story short, we should look at making it easier and less expensive for a client to monitor keyboards and toggle functionality in other devices. Cheers, Peter > > do you want to only disable tapping/scrolling, but not movement? > > No. > > > seriously, the options will just pile up, requiring configuration, etc. and > > the last thing we need is more config options and properties. > > I agree, but we don't have to add them. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libXi 2/3] Silence compiler warning in XListDProp.c
On Fri, May 06, 2011 at 01:57:32AM +0100, Daniel Stone wrote: > On Fri, May 06, 2011 at 10:46:02AM +1000, Peter Hutterer wrote: > > XListDProp.c: In function 'XListDeviceProperties': > > XListDProp.c:72:9: warning: pointer targets in passing argument 2 of > > '_XRead32' differ in signedness > > /usr/include/X11/Xlibint.h:652:13: note: expected 'long int *' but argument > > is of type 'Atom *' > > God I hate Xlib. This does seem correct though. > > Reviewed-by: Daniel Stone should've probably been more expansive on the commit message but: Atoms are typedef'd as unsigned long, see Xdefs.h. Hence the hilarity with 32 bit property handling on 64 bit. _XRead32 is a macro on 32bit (casting to (char*), hence no warning) but a function that takes a long* on 64 bit (hence the warning). Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Are we ready to tag & release libXext 1.3.0?
It looks like we've still not done a release of libXext with the new XSyncAwaitFence() API yet, even though the proto & server were released a while ago - is there anything remaining to do there or any reason not to go ahead and make a libXext 1.3.0 release? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Are we ready to tag & release libXext 1.3.0?
I'm not aware of any fence sync issues that would hold up a release. Everything should be ready to go. Thanks, -James nvpublic On 5/5/11 7:09 PM, "Alan Coopersmith" wrote: > It looks like we've still not done a release of libXext with the > new XSyncAwaitFence() API yet, even though the proto & server > were released a while ago - is there anything remaining to do there > or any reason not to go ahead and make a libXext 1.3.0 release? > > -- > -Alan Coopersmith-alan.coopersm...@oracle.com > Oracle Solaris Platform Engineering: X Window System > > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL updated] input fixes
Same as before, with the two patches daniel fixed up now and a number of XKB cleanups added. The following changes since commit 5cb31cd0cbf83fff5f17a475e7b0e45246b19bf3: Merge remote-tracking branch 'jturney/remove-opengl-spec-download' (2011-04-29 09:59:49 -0700) are available in the git repository at: git://people.freedesktop.org/~whot/xserver.git for-keith Alan Coopersmith (1): Move event filter initializer out of the structure itself Chase Douglas (1): Input: Pass co-ordinates by reference to transformAbsolute Daniel Stone (10): Input: Add DeepestSpriteWin function Input: Fix event size confusion in CheckPassiveGrabsOnWindow Input: Make CheckPassiveGrabsOnWindow take InternalEvent Input: Simplify CheckPassiveGrabsOnWindow loop XKB: Don't send unnecessary NewKeyboardNotifies XKB: Simplify a loop in ProcXkbGetKbdByName XKB: Remove duplicate keymap-copying loop XKB: Send NewKeyboardNotify for dev before its master/slaves XKB: Send XKB events for all devices to all clients XKB: Fix sense inversion for core MapNotify events Peter Hutterer (2): input: Only release SD buttons for explicit floating/reattachment (#36146) input: change CHECKEVENT macro to verify_internal_event function Xi/exevents.c |3 +- Xi/xichangehierarchy.c |2 + dix/devices.c |4 +- dix/events.c | 265 ++- dix/getevents.c| 28 +++--- dix/inpututils.c | 28 + include/dix.h |2 +- include/eventstr.h |4 - include/input.h|2 + include/inputstr.h | 10 ++ include/inpututils.h |2 + mi/mieq.c | 10 +- xkb/xkb.c | 51 +- xkb/xkbEvents.c| 43 +++- 14 files changed, 255 insertions(+), 199 deletions(-) pgpRPlQm2xiBP.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-input-synaptics
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