reviewed policy
Hi all, here's a question that I carry around for some time: What's the policy on signing something with Reviewed-by:? Does it mean: a) I've read the patch carefully and don't see any problems. (i.e. for small and ovious fixes) and/or b) I've read the patch carefully and tested it. Thanks, Daniel Martin ___ 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] hw/dmx: fix build without GLX
Fixes this compile break that showed up on arm recently:
dmxinit.c:746:26: error: 'glxSupported' undeclared (first use in this function)
dmxinit.c:746:26: note: each undeclared identifier is reported only once for
each function it appears in
Signed-off-by: Rob Clark robdcl...@gmail.com
---
hw/dmx/dmxinit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/dmx/dmxinit.c b/hw/dmx/dmxinit.c
index 7a50aeb..7de402b 100644
--- a/hw/dmx/dmxinit.c
+++ b/hw/dmx/dmxinit.c
@@ -740,10 +740,10 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char
*argv[])
/* Check if GLX extension exists on all back-end servers */
for (i = 0; i dmxNumScreens; i++)
glxSupported = (dmxScreens[i].glxMajorOpcode 0);
-#endif
if (serverGeneration == 1)
dmxAddExtensions(glxSupported);
+#endif
/* Tell dix layer about the backend displays */
for (i = 0; i dmxNumScreens; i++) {
--
1.8.0.1
___
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
1.14 feature window closes ... today?
I just discovered that a note I sent out a couple of days ago about the feature window never made it off my machine... In any case, we're supposed to be at RC1 today, but I'm going to hold off for a day or so until I hear whether anyone has stuff they'd like to get into the 1.14 release before that. Anyone? (I probably should have wondered why I didn't get any response to my email before this evening...) -- keith.pack...@intel.com pgpAOD7F6s7Ak.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: any more nominations for xserver 1.13.1 ?
Hi Maarten, I don't see that reply anywhere. Can you resend to me? thanks, Matt On 12/04/2012 03:17 AM, Maarten Lankhorst wrote: Op 03-12-12 23:31, Matt Dew schreef: Hi all, RC2 is this Thursday, 3 days from now. Are there any additional submissions other than Thierry's? I posted an updated patch in a reply about fixing acpid corruption, and never had a reply maybe that one? Although I might resubmit it to be sure it gets into upstream/master as well. ~Maarten ___ 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: any more nominations for xserver 1.13.1 ?
Op 06-12-12 05:42, Matt Dew schreef: Hi Maarten, I don't see that reply anywhere. Can you resend to me? Ok, basically the acpi corruption fix patch I submitted: [PATCH v2] xf86: take next pointer before calling handler ___ 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: reviewed policy
On Mit, 2012-12-05 at 23:14 +0100, Daniel Martin wrote: Hi all, here's a question that I carry around for some time: What's the policy on signing something with Reviewed-by:? Does it mean: a) I've read the patch carefully and don't see any problems. (i.e. for small and ovious fixes) and/or b) I've read the patch carefully and tested it. Reviewed-by: doesn't imply testing, there's Tested-by: for that. Does this answer your question? -- Earthling Michel Dänzer | http://www.amd.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 xserver] hw/dmx: fix build without GLX
On Wed, Dec 5, 2012 at 6:21 PM, Rob Clark robdcl...@gmail.com wrote:
Fixes this compile break that showed up on arm recently:
dmxinit.c:746:26: error: 'glxSupported' undeclared (first use in this
function)
dmxinit.c:746:26: note: each undeclared identifier is reported only once for
each function it appears in
Signed-off-by: Rob Clark robdcl...@gmail.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
hw/dmx/dmxinit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/dmx/dmxinit.c b/hw/dmx/dmxinit.c
index 7a50aeb..7de402b 100644
--- a/hw/dmx/dmxinit.c
+++ b/hw/dmx/dmxinit.c
@@ -740,10 +740,10 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char
*argv[])
/* Check if GLX extension exists on all back-end servers */
for (i = 0; i dmxNumScreens; i++)
glxSupported = (dmxScreens[i].glxMajorOpcode 0);
-#endif
if (serverGeneration == 1)
dmxAddExtensions(glxSupported);
+#endif
/* Tell dix layer about the backend displays */
for (i = 0; i dmxNumScreens; i++) {
--
1.8.0.1
___
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: reviewed policy
On 12/ 5/12 02:14 PM, Daniel Martin wrote: Hi all, here's a question that I carry around for some time: What's the policy on signing something with Reviewed-by:? Does it mean: a) I've read the patch carefully and don't see any problems. (i.e. for small and ovious fixes) and/or b) I've read the patch carefully and tested it. a - if you did b, then you'd send Tested-by as well. http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches#Signing_off_and_reviewing -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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] formatting fix
Keith, The following changes since commit b51a1bd2766e7dc975ca8f1cacc3f8bd0e1a68a3: Merge remote-tracking branch 'whot/for-keith' (2012-11-30 09:31:46 -0800) are available in the git repository at: git://people.freedesktop.org/~yselkowitz/xserver.git master for you to fetch changes up to ea1d76d1b68c7cbcedcaa1f967c5027e0cc1c7a2: Fix formatting of address operators (2012-12-05 18:09:48 -0600) Yaakov Selkowitz (1): Fix formatting of address operators Xext/saver.c |2 +- Xi/extinit.c |6 +- Xi/gtmotion.c |2 +- Xi/xichangehierarchy.c |2 +- Xi/xiquerydevice.c |4 +- dix/colormap.c |8 +- dix/devices.c |4 +- dix/dispatch.c |2 +- dix/eventconvert.c |2 +- dix/window.c |2 +- exa/exa.c |4 +- fb/fbgc.c |4 +- glx/glapi.c|2 +- glx/glxdri.c |2 +- glx/indirect_program.c |2 +- glx/indirect_texture_compression.c |4 +- glx/renderpixswap.c| 20 ++-- glx/singlepix.c| 18 +- glx/singlepixswap.c| 18 +- glx/xfont.c|2 +- hw/dmx/config/Canvas.c |4 +- hw/dmx/dmx_glxvisuals.c|4 +- hw/dmx/dmxwindow.c |2 +- hw/dmx/examples/xinput.c |4 +- hw/dmx/glxProxy/glxcmds.c | 16 +- hw/dmx/glxProxy/glxcmdsswap.c |2 +- hw/dmx/glxProxy/glxscreens.c |4 +- hw/dmx/glxProxy/glxsingle.c|6 +- hw/dmx/glxProxy/glxvendor.c|4 +- hw/dmx/glxProxy/renderpixswap.c| 310 ++-- hw/kdrive/ephyr/XF86dri.c | 18 +- hw/kdrive/ephyr/ephyrdriext.c |4 +- hw/kdrive/ephyr/ephyrhostglx.c | 10 +- hw/kdrive/ephyr/ephyrhostproxy.c |2 +- hw/kdrive/ephyr/ephyrhostvideo.c |4 +- hw/kdrive/ephyr/ephyrvideo.c |2 +- hw/xfree86/common/xf86cmap.c |2 +- hw/xfree86/dri/xf86dri.c |4 +- hw/xfree86/i2c/fi1236.c| 10 +- hw/xfree86/i2c/tda9850.c |2 +- hw/xwin/InitOutput.c |2 +- hw/xwin/glx/indirect.c |4 +- hw/xwin/winclipboardxevents.c |6 +- hw/xwin/wincursor.c|6 +- hw/xwin/winengine.c|2 +- hw/xwin/wingc.c|4 +- hw/xwin/winmsg.c |2 +- hw/xwin/winmultiwindowicons.c |2 +- hw/xwin/winmultiwindowshape.c |2 +- hw/xwin/winmultiwindowwndproc.c|2 +- hw/xwin/winpfbdd.c |8 +- hw/xwin/winpixmap.c|2 +- hw/xwin/winscrinit.c |2 +- hw/xwin/winsetsp.c |4 +- hw/xwin/winshaddd.c|8 +- hw/xwin/winshadddnl.c | 10 +- hw/xwin/winshadgdi.c |2 +- hw/xwin/winwin32rootless.c |6 +- hw/xwin/winwin32rootlesswndproc.c |6 +- os/access.c|2 +- os/utils.c |2 +- os/xdmcp.c | 12 +- test/input.c |2 +- test/xi2/protocol-eventconvert.c |2 +- test/xi2/protocol-xiquerydevice.c |2 +- test/xi2/protocol-xiselectevents.c | 12 +- xkb/xkb.c | 36 ++-- xkb/xkbout.c |2 +- 68 files changed, 338 insertions(+), 338 deletions(-) ___ 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: reviewed policy
On 12-12-05 05:14 PM, Daniel Martin wrote: Hi all, here's a question that I carry around for some time: What's the policy on signing something with Reviewed-by:? Does it mean: a) I've read the patch carefully and don't see any problems. (i.e. for small and ovious fixes) and/or b) I've read the patch carefully and tested it. Find more at: http://www.x.org/wiki/Development/Documentation/SubmittingPatches in section Signing off and reviewing Thanks, Daniel Martin ___ 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: mach64 broken with xserver 1.13 ?
On 11/18/12 11:25 PM, Connor Behan wrote:
On 18/11/12 12:00 PM, xorg-devel-requ...@lists.x.org wrote:
I'm seeing the xf86-video-mach64 6.9.3 crashing with xserver 1.13 on
OpenBSD, both on sparc64 and intel (x86_64) machines.
here's some debugging information. Apparently something in devPrivate
doesn't get initialized properly, but I'm not able to figure out
what. Any suggestion ?
I'd bet its a long standing exa bug somewhere or maybe a mach64 exa
specific problem. Since on previous servers mach64 would default to
XAA, but that got removed. Dave.
This summer I suspected that such a bug would hit mach64 so I made this
patch: https://bugs.freedesktop.org/show_bug.cgi?id=51137 I didn't push
to get it accepted because I couldn't test it and I was having a hard
enough time working on the patch I could test.
Unfortunately, that patch doesn't seem to be enough here - it gets past
the crash initializing the root window, but crashes later bringing up
GNOME in another place it seems to be trying to access pixmap data
directly:
called from signal handler with signal 11 (SIGSEGV) --
=[14] Mach64PixelARGB(pPixmap = 0x1d32820, format = 537004168U, argb =
0x80ffbfffcc60), line 219 in atimach64render.c
[15] Mach64PrepareMask(m3d = 0xc81750, op = 8, pSrcPicture = 0x1d32a10,
pMaskPicture = 0x1d314e0, pSrc = 0x1d32820, pMask = 0x1e1b300), line 504 in
atimach64render.c
[16] Mach64PrepareComposite(op = 8, pSrcPicture = 0x1d32a10, pMaskPicture =
0x1d314e0, pDstPicture = 0x1d31190, pSrc = 0x1d32820, pMask = 0x1e1b300, pDst =
0x1dfe5c0), line 706 in atimach64render.c
[17] exaTryDriverComposite(op = '\b', pSrc = 0x1d32a10, pMask = 0x1d314e0,
pDst = 0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst = 1194, yDst
= 5, width = 79U, height = 11U), line 746 in exa_render.c
[18] exaComposite(op = '\b', pSrc = 0x1d32a10, pMask = 0x1d314e0, pDst =
0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst = 1194, yDst = 5,
width = 79U, height = 11U), line 1008 in exa_render.c
[19] exaTryMagicTwoPassCompositeHelper(op = '\003', pSrc = 0x1d32a10, pMask =
0x1d314e0, pDst = 0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst =
1194, yDst = 5, width = 79U, height = 11U), line 855 in exa_render.c
[20] exaComposite(op = '\003', pSrc = 0x1d32a10, pMask = 0x1d314e0, pDst =
0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst = 1194, yDst = 5,
width = 79U, height = 11U), line 1029 in exa_render.c
[21] damageComposite(op = '\003', pSrc = 0x1d32a10, pMask = 0x1d314e0, pDst =
0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst = 1194, yDst = 5,
width = 79U, height = 11U), line 563 in damage.c
[22] CompositePicture(op = '\003', pSrc = 0x1d32a10, pMask = 0x1d314e0, pDst =
0x1d31190, xSrc = 1194, ySrc = 5, xMask = 0, yMask = 0, xDst = 1194, yDst = 5,
width = 79U, height = 11U), line 1615 in picture.c
[23] exaGlyphs(op = '\003', pSrc = 0x1d32a10, pDst = 0x1d31190, maskFormat =
0xc84ce8, xSrc = 1194, ySrc = 15, nlist = -1, list = 0x80ffb660, glyphs
= 0x80ffbfffee90), line 835 in exa_glyphs.c
[24] damageGlyphs(op = '\003', pSrc = 0x1d32a10, pDst = 0x1d31190, maskFormat
= 0xc84ce8, xSrc = 1194, ySrc = 15, nlist = 2, list = 0x80ffb640, glyphs
= 0x80ffbfffee30), line 625 in damage.c
[25] CompositeGlyphs(op = '\003', pSrc = 0x1d32a10, pDst = 0x1d31190,
maskFormat = 0xc84ce8, xSrc = 1194, ySrc = 15, nlist = 2, lists =
0x80ffb640, glyphs = 0x80ffbfffee30), line 559 in glyph.c
[26] ProcRenderCompositeGlyphs(client = 0x12c21f0), line 1394 in render.c
[27] ProcRenderDispatch(client = 0x12c21f0), line 1989 in render.c
[28] Dispatch(), line 433 in dispatch.c
[29] main(argc = 8, argv = 0x80ffbba8, envp = 0x80ffbbf0),
line 343 in main.c
(dbx) list
215 /* exaGetPixmapFirstPixel() */
216
217 switch (pPixmap-drawable.bitsPerPixel) {
218 case 32:
219 pixel = *(CARD32 *)(pPixmap-devPrivate.ptr);
220 break;
221 case 16:
222 pixel = *(CARD16 *)(pPixmap-devPrivate.ptr);
223 break;
224 default:
225 pixel = *(CARD8 *)(pPixmap-devPrivate.ptr);
226 break;
227 }
228
(dbx) print pPixmap
pPixmap = 0x1d32820
(dbx) print *pPixmap
*pPixmap = {
drawable = {
type = '\001'
class= '\0'
depth= '\030'
bitsPerPixel = ' '
id = 23068727U
x= 0
y= 0
width= 1U
height = 1U
pScreen = 0xc84310
serialNumber = 237U
}
devPrivates = 0x1d32868
refcnt= 3
devKind = 64
devPrivate= {
ptr = (nil)
val = 0
uval = 0
fptr = (nil)
}
screen_x = 0
screen_y = 0
usage_hint= 0
master_pixmap = 0xe0db40
}
For now, I've just added --disable-exa to the build flags for our mach64
Re: [PATCH xtest] Allow space in read buffer for CRLF and NUL
I'll take your word for it that tcc does what the message says. A comment above linebuf mentioning why it's 515 bytes might be nice, but in any case, Reviewed-by: Aaron Plattner aplatt...@nvidia.com On 12/04/2012 03:38 PM, Peter Harris wrote: tcc will limit output lines to 512 characters not including CRLF. In addition, there needs to be space in the buffer for the trailing NUL that fgets will append. Without this change, xts-report will exit prematurely if it sees a maximum length line. Signed-off-by: Peter Harris phar...@opentext.com --- xts5/src/bin/reports/xts-report.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xts5/src/bin/reports/xts-report.c b/xts5/src/bin/reports/xts-report.c index 8e4b1e4..c1ca468 100644 --- a/xts5/src/bin/reports/xts-report.c +++ b/xts5/src/bin/reports/xts-report.c @@ -219,7 +219,7 @@ int fabort=0; /*message type*/ int mtype; /*messages read in here*/ -char linebuf[512]; +char linebuf[515]; /*pointer into where we are in the message*/ char *pline; ___ 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 v2] xf86: take next pointer before calling handler
Seems fine.
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
--
Aaron
On 12/04/2012 02:21 AM, Maarten Lankhorst wrote:
Stopping acpid before Xorg with valgrind --free-fill=df results in this crash
backtrace:
==2670== Invalid read of size 8
==2670==at 0x1B9CB0: xf86Wakeup (xf86Events.c:276)
==2670==by 0x1687B2: WakeupHandler (dixutils.c:423)
==2670==by 0x334793: WaitForSomething (WaitFor.c:224)
==2670==by 0x159E4B: Dispatch (dispatch.c:357)
==2670==by 0x14AA78: main (main.c:295)
==2670== Address 0x783aa90 is 32 bytes inside a block of size 40 free'd
==2670==at 0x4C2A739: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2670==by 0x1BA8CA: removeInputHandler (xf86Events.c:645)
==2670==by 0x1BA96D: xf86RemoveGeneralHandler (xf86Events.c:681)
==2670==by 0x1F106C: lnxCloseACPI (lnx_acpi.c:174)
==2670==by 0x1F0CC7: lnxACPIGetEventFromOs (lnx_acpi.c:68)
==2670==by 0x1CCF49: xf86HandlePMEvents (xf86PM.c:208)
==2670==by 0x1B9CAB: xf86Wakeup (xf86Events.c:279)
==2670==by 0x1687B2: WakeupHandler (dixutils.c:423)
==2670==by 0x334793: WaitForSomething (WaitFor.c:224)
==2670==by 0x159E4B: Dispatch (dispatch.c:357)
==2670==by 0x14AA78: main (main.c:295)
==2670==
==2670== Invalid read of size 4
==2670==at 0x1B9C29: xf86Wakeup (xf86Events.c:277)
==2670==by 0x1687B2: WakeupHandler (dixutils.c:423)
==2670==by 0x334793: WaitForSomething (WaitFor.c:224)
==2670==by 0x159E4B: Dispatch (dispatch.c:357)
==2670==by 0x14AA78: main (main.c:295)
==2670== Address 0xdfdfdfdfdfdfdff7 is not stack'd, malloc'd or (recently)
free'd
==2670==
(EE)==2670==
==2670== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
Taking a pointer to ih-next before calling the event handler fixes this.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Changes since v1:
- Use nt_list_for_each_entry_safe, as suggested by Aaron Plattner
---
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index 41ffabd..6082bee 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -270,10 +270,10 @@ xf86Wakeup(pointer blockData, int err, pointer pReadmask)
}
}
-if (err = 0) { /* we don't want the handlers called if select() */
- IHPtr ih; /* returned with an error condition, do we? */
-
- for (ih = InputHandlers; ih; ih = ih-next) {
+if (err = 0) { /* we don't want the handlers called if select() */
+IHPtr ih, ih_tmp; /* returned with an error condition, do we? */
+
+nt_list_for_each_entry_safe(ih, ih_tmp, InputHandlers, next) {
if (ih-enabled ih-fd = 0 ih-ihproc
(FD_ISSET(ih-fd, ((fd_set *)pReadmask)) != 0)) {
ih-ihproc(ih-fd, ih-data);
___
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: 1.14 feature window closes ... today?
On Wed, Dec 05, 2012 at 07:02:03PM -0800, Keith Packard wrote: I just discovered that a note I sent out a couple of days ago about the feature window never made it off my machine... In any case, we're supposed to be at RC1 today, but I'm going to hold off for a day or so until I hear whether anyone has stuff they'd like to get into the 1.14 release before that. Anyone? (I probably should have wondered why I didn't get any response to my email before this evening...) Jasper and I are currently finishing off the new pointer barrier features as part of XI 2.3. they're coming along nicely, not overly intrusive, and they're already well tested. I think this could make 1.14, especially given that we don't have a lot of other big features in this version anyways. 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
[PATCH] Support compilers with alternate spellings of typeof
The AC_C_TYPEOF adds a #undef typeof to its autogenerated config.h.in template, but b8ab93dfbc7f292 didn't copy that to dix-config.h.in when HAVE_TYPEOF was, so the macro could claim typeof support but not make it work, when used with compilers like Solaris Studio 12.1 which only recognize it as __typeof__. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- include/dix-config.h.in |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dix-config.h.in b/include/dix-config.h.in index b270a32..e1cb9eb 100644 --- a/include/dix-config.h.in +++ b/include/dix-config.h.in @@ -429,6 +429,9 @@ /* Define to 1 if typeof works with your compiler. */ #undef HAVE_TYPEOF +/* Define to __typeof__ if your compiler spells it that way. */ +#undef typeof + /* The compiler supported TLS storage class, prefering initial-exec if tls_model is supported */ #undef TLS -- 1.7.9.2 ___ 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
cirRefreshArea (Cirrus driver) clipping
Hi, I've been trying to fix a bug that shows up on Ubuntu in KVM guests ( https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-cirrus/+bug/1043513 ) using the cirrus driver. Areas to refresh appear to be passed to cirRefreshArea that are off the side of the display and hence it crashes as it tries to copy into/from the middle of nowhere. I've got a patch: https://launchpadlibrarian.net/125025494/11-clip-refresh.patch that seems to work (against ubuntu package version 1:1.5.1-0ubuntu2), but had a few questions since I don't regularly work with the X code base : 1) I looked at the code at: http://cgit.freedesktop.org/xorg/driver/xf86-video-cirrus/tree/src/cir_shadow.c and it doesn't seem to have a clip in to solve this; am I checking the right place? 2) In this case I'm adding the clip in the generic routine; that leaves me wondering two things; a) I guess the same should be added to the 8/16/24/32 specialisations? b) Why would it be using the generic version anyway? 3) Is there an existing routine somewhere to clip a BoxRec that I should be using? 4) Is it the job of the driver at this level to do this check, or should something higher in the stack have done it? Thanks in advance, Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ ___ 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:xf86-video-mach64] Mach64PixelARGB should use exaGetPixmapFirstPixel when EXA is in use
Fixes crash attempting to read a pixel from a NULL pPixmap-devPrivate.ptr
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
src/atimach64render.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
Mostly just cut-and-paste and guess-and-hope, but it seems to work and stops
the crash for me.
diff --git a/src/atimach64render.c b/src/atimach64render.c
index 4862cd4..1328cca 100644
--- a/src/atimach64render.c
+++ b/src/atimach64render.c
@@ -208,22 +208,31 @@ Mach64PixelARGB(PixmapPtr pPixmap, CARD32 format, CARD32
*argb)
CARD32 pixel;
CARD8 comp;
intbits, shift;
+#ifdef USE_EXA
+ScrnInfoPtr pScreenInfo = xf86ScreenToScrn(pPixmap-drawable.pScreen);
+ATIPtr pATI = ATIPTR(pScreenInfo);
+#endif
/* Ensure that texture drawing has completed. */
exaWaitSync(pPixmap-drawable.pScreen);
-/* exaGetPixmapFirstPixel() */
-
-switch (pPixmap-drawable.bitsPerPixel) {
-case 32:
-pixel = *(CARD32 *)(pPixmap-devPrivate.ptr);
-break;
-case 16:
-pixel = *(CARD16 *)(pPixmap-devPrivate.ptr);
-break;
-default:
-pixel = *(CARD8 *)(pPixmap-devPrivate.ptr);
-break;
+#ifdef USE_EXA
+if (pATI-useEXA)
+pixel = exaGetPixmapFirstPixel(pPixmap);
+else
+#endif
+{
+switch (pPixmap-drawable.bitsPerPixel) {
+case 32:
+pixel = *(CARD32 *)(pPixmap-devPrivate.ptr);
+break;
+case 16:
+pixel = *(CARD16 *)(pPixmap-devPrivate.ptr);
+break;
+default:
+pixel = *(CARD8 *)(pPixmap-devPrivate.ptr);
+break;
+}
}
/* exaGetRGBAFromPixel()/viaPixelARGB() */
--
1.7.9.2
___
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-mach64] Mach64PixelARGB should use exaGetPixmapFirstPixel when EXA is in use
Fixes crash attempting to read a pixel from a NULL pPixmap-devPrivate.ptr
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
seems sane, well as sane as a mach64.
Reviewed-by: Dave Airlie airl...@redhat.com
---
src/atimach64render.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
Mostly just cut-and-paste and guess-and-hope, but it seems to work and stops
the crash for me.
diff --git a/src/atimach64render.c b/src/atimach64render.c
index 4862cd4..1328cca 100644
--- a/src/atimach64render.c
+++ b/src/atimach64render.c
@@ -208,22 +208,31 @@ Mach64PixelARGB(PixmapPtr pPixmap, CARD32 format,
CARD32 *argb)
CARD32 pixel;
CARD8 comp;
intbits, shift;
+#ifdef USE_EXA
+ScrnInfoPtr pScreenInfo = xf86ScreenToScrn(pPixmap-drawable.pScreen);
+ATIPtr pATI = ATIPTR(pScreenInfo);
+#endif
/* Ensure that texture drawing has completed. */
exaWaitSync(pPixmap-drawable.pScreen);
-/* exaGetPixmapFirstPixel() */
-
-switch (pPixmap-drawable.bitsPerPixel) {
-case 32:
-pixel = *(CARD32 *)(pPixmap-devPrivate.ptr);
-break;
-case 16:
-pixel = *(CARD16 *)(pPixmap-devPrivate.ptr);
-break;
-default:
-pixel = *(CARD8 *)(pPixmap-devPrivate.ptr);
-break;
+#ifdef USE_EXA
+if (pATI-useEXA)
+pixel = exaGetPixmapFirstPixel(pPixmap);
+else
+#endif
+{
+switch (pPixmap-drawable.bitsPerPixel) {
+case 32:
+pixel = *(CARD32 *)(pPixmap-devPrivate.ptr);
+break;
+case 16:
+pixel = *(CARD16 *)(pPixmap-devPrivate.ptr);
+break;
+default:
+pixel = *(CARD8 *)(pPixmap-devPrivate.ptr);
+break;
+}
}
/* exaGetRGBAFromPixel()/viaPixelARGB() */
--
1.7.9.2
___
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: 1.14 feature window closes ... today?
Peter Hutterer peter.hutte...@who-t.net writes: Jasper and I are currently finishing off the new pointer barrier features as part of XI 2.3. they're coming along nicely, not overly intrusive, and they're already well tested. Yeah, I wondered if you thought these might be nice to get into the release. I think this could make 1.14, especially given that we don't have a lot of other big features in this version anyways. Any idea how long this might take? Sometime next week? -- keith.pack...@intel.com pgpJ0jDsjujYE.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: 1.14 feature window closes ... today?
On Thu, Dec 06, 2012 at 06:15:16PM -0800, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: Jasper and I are currently finishing off the new pointer barrier features as part of XI 2.3. they're coming along nicely, not overly intrusive, and they're already well tested. Yeah, I wondered if you thought these might be nice to get into the release. I think this could make 1.14, especially given that we don't have a lot of other big features in this version anyways. Any idea how long this might take? Sometime next week? At this point I'm hoping to get the protocol out within a day or so, followed by the server patches once we cleaned up the history a bit. So next week for review is realistic. 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: 1.14 feature window closes ... today?
Hi, On 6 December 2012 14:02, Keith Packard kei...@keithp.com wrote: I just discovered that a note I sent out a couple of days ago about the feature window never made it off my machine... In any case, we're supposed to be at RC1 today, but I'm going to hold off for a day or so until I hear whether anyone has stuff they'd like to get into the 1.14 release before that. I really wouldn't mind getting the XWayland stuff in, but I won't be able to finish that off until Monday. There's a patch series on the list with only a couple of comments from Peter so far, but in any case most of it is only adding codepaths used by XWayland and nothing else, so it shouldn't be particularly intrusive/risky. 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: [PATCH] Support compilers with alternate spellings of typeof
On Thu, Dec 06, 2012 at 04:19:44PM -0800, Alan Coopersmith wrote: The AC_C_TYPEOF adds a #undef typeof to its autogenerated config.h.in template, but b8ab93dfbc7f292 didn't copy that to dix-config.h.in when HAVE_TYPEOF was, so the macro could claim typeof support but not make it work, when used with compilers like Solaris Studio 12.1 which only recognize it as __typeof__. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Acked-by: Peter Hutterer peter.hutte...@who-t.net --- include/dix-config.h.in |3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dix-config.h.in b/include/dix-config.h.in index b270a32..e1cb9eb 100644 --- a/include/dix-config.h.in +++ b/include/dix-config.h.in @@ -429,6 +429,9 @@ /* Define to 1 if typeof works with your compiler. */ #undef HAVE_TYPEOF +/* Define to __typeof__ if your compiler spells it that way. */ +#undef typeof + /* The compiler supported TLS storage class, prefering initial-exec if tls_model is supported */ #undef TLS -- 1.7.9.2 ___ 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
[PATCH libXi 2/2] Fix const compiler warnings
XExtInt.c:80:38: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
XExtInt.c:150:5: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
XExtInt.c:151:5: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
XExtInt.c:152:5: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
XExtInt.c:153:5: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
XExtInt.c:154:5: warning: initialization discards 'const' qualifier from
pointer target type [enabled by default]
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/XExtInt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/XExtInt.c b/src/XExtInt.c
index fd1ae6c..1c668c7 100644
--- a/src/XExtInt.c
+++ b/src/XExtInt.c
@@ -77,7 +77,7 @@ int copy_classes(XIDeviceInfo *to, xXIAnyInfo* from, int
*nclasses);
int size_classes(xXIAnyInfo* from, int nclasses);
static XExtensionInfo *xinput_info;
-static /* const */ char *xinput_extension_name = INAME;
+static const char *xinput_extension_name = INAME;
static int XInputClose(
Display * /* dpy */,
@@ -143,7 +143,7 @@ static /* const */ XExtensionHooks xinput_extension_hooks =
{
XInputError, /* error_string */
};
-static char *XInputErrorList[] = {
+static const char *XInputErrorList[] = {
BadDevice, invalid or uninitialized input device,/* BadDevice */
BadEvent, invalid event type,/* BadEvent */
BadMode, invalid mode parameter, /* BadMode */
--
1.7.11.7
___
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/2] Fix compiler warnings
XIQueryVersion.c: In function '_xiQueryVersion':
XIQueryVersion.c:63:26: warning: declaration of 'info' shadows a parameter
[-Wshadow]
XIQueryVersion.c:53:73: warning: shadowed declaration is here [-Wshadow]
XExtInt.c: In function 'XInputWireToEvent':
XExtInt.c:823:25: warning: declaration of 'i' shadows a previous local
[-Wshadow]
XExtInt.c:502:18: warning: shadowed declaration is here [-Wshadow]
XExtInt.c:850:25: warning: declaration of 'i' shadows a previous local
[-Wshadow]
XExtInt.c:502:18: warning: shadowed declaration is here [-Wshadow]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:166:17: note: previous declaration of
'_xidevicebusy' was here
XExtInt.c:101:12: warning: redundant redeclaration of
'_XiGetDevicePresenceNotifyEvent' [-Wredundant-decls]
XExtInt.c:76:13: warning: redundant redeclaration of '_xibaddevice'
[-Wredundant-decls]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:162:17: note: previous declaration of
'_xibaddevice' was here
XExtInt.c:81:13: warning: redundant redeclaration of '_xibadclass'
[-Wredundant-decls]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:163:17: note: previous declaration of
'_xibadclass' was here
XExtInt.c:86:13: warning: redundant redeclaration of '_xibadevent'
[-Wredundant-decls]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:164:17: note: previous declaration of
'_xibadevent' was here
XExtInt.c:91:13: warning: redundant redeclaration of '_xibadmode'
[-Wredundant-decls]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:165:17: note: previous declaration of
'_xibadmode' was here
XExtInt.c:96:13: warning: redundant redeclaration of '_xidevicebusy'
[-Wredundant-decls]
In file included from XExtInt.c:64:0:
../include/X11/extensions/XInput.h:166:17: note: previous declaration of
'_xidevicebusy' was here
XListDev.c: In function 'ParseClassInfo':
XListDev.c:116:33: warning: declaration of 'k' shadows a previous local
[-Wshadow]
XListDev.c:109:12: warning: shadowed declaration is here [-Wshadow]
XGetFCtl.c: In function 'XGetFeedbackControl':
XGetFCtl.c:184:26: warning: declaration of 'i' shadows a previous local
[-Wshadow]
XGetFCtl.c:72:17: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/XExtInt.c| 33 +++--
src/XGetFCtl.c | 14 +++---
src/XIQueryVersion.c | 6 +++---
src/XListDev.c | 3 ++-
4 files changed, 15 insertions(+), 41 deletions(-)
diff --git a/src/XExtInt.c b/src/XExtInt.c
index 27638bd..fd1ae6c 100644
--- a/src/XExtInt.c
+++ b/src/XExtInt.c
@@ -73,35 +73,6 @@ SOFTWARE.
#define DONT_ENQUEUE False
#define FP1616toDBL(x) ((x) * 1.0 / (1 16))
-extern void _xibaddevice(
-Display * /* dpy */,
-int * /* error */
-);
-
-extern void _xibadclass(
-Display * /* dpy */,
-int * /* error */
-);
-
-extern void _xibadevent(
-Display * /* dpy */,
-int * /* error */
-);
-
-extern void _xibadmode(
-Display * /* dpy */,
-int * /* error */
-);
-
-extern void _xidevicebusy(
-Display * /* dpy */,
-int * /* error */
-);
-
-extern int _XiGetDevicePresenceNotifyEvent(
-Display * /* dpy */
-);
-
int copy_classes(XIDeviceInfo *to, xXIAnyInfo* from, int *nclasses);
int size_classes(xXIAnyInfo* from, int nclasses);
@@ -496,7 +467,6 @@ XInputWireToEvent(
xEvent *event)
{
unsigned int type, reltype;
-unsigned int i, j;
XExtDisplayInfo *info = XInput_find_display(dpy);
XEvent *save = (XEvent *) info-data;
@@ -621,6 +591,7 @@ XInputWireToEvent(
{
deviceValuator *xev = (deviceValuator *) event;
int save_type = save-type - info-codes-first_event;
+int i;
if (save_type == XI_DeviceKeyPress || save_type ==
XI_DeviceKeyRelease) {
XDeviceKeyEvent *kev = (XDeviceKeyEvent *) save;
@@ -716,6 +687,7 @@ XInputWireToEvent(
pev-axis_data[0] = xev-valuator0;
}
} else if (save_type == XI_DeviceStateNotify) {
+int j;
XDeviceStateNotifyEvent *sev =
(XDeviceStateNotifyEvent *) save;
XInputClass *any = (XInputClass *) sev-data[0];
XValuatorStatus *v;
@@ -760,6 +732,7 @@ XInputWireToEvent(
break;
case XI_DeviceStateNotify:
{
+int j;
XDeviceStateNotifyEvent *stev = (XDeviceStateNotifyEvent
*) save;
deviceStateNotify *sev = (deviceStateNotify *) event;
char *data;
diff --git a/src/XGetFCtl.c b/src/XGetFCtl.c
index
[PATCH inputproto] Add pointer barrier events
New events:
XI_BarrierHit ... when a pointer moves against or along a barrier
XI_BarrierLeave . when a pointer moves away from or through a barrier
New requests:
XIBarrierReleasePointer ... allow movement through the barrier for the
next event
Co-authored-by: Jasper St. Pierre jstpie...@mecheye.net
Co-authored-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
XI2.h | 11 +++-
XI2proto.h | 49 +-
specs/XI2proto.txt | 187 +
3 files changed, 245 insertions(+), 2 deletions(-)
diff --git a/XI2.h b/XI2.h
index e864b06..5a245e8 100644
--- a/XI2.h
+++ b/XI2.h
@@ -160,6 +160,11 @@
#define XITouchPendingEnd (1 16)
#define XITouchEmulatingPointer (1 17)
+/* Barrier event flags */
+#define XIBarrierPointerReleased(1 0)
+#define XIBarrierDeviceIsGrabbed(1 1)
+
+
/* Touch modes */
#define XIDirectTouch 1
#define XIDependentTouch2
@@ -199,7 +204,9 @@
#define XI_RawTouchBegin 22
#define XI_RawTouchUpdate23
#define XI_RawTouchEnd 24
-#define XI_LASTEVENT XI_RawTouchEnd
+#define XI_BarrierHit25 /* XI 2.3 */
+#define XI_BarrierLeave 26
+#define XI_LASTEVENT XI_BarrierLeave
/* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value
* as XI_LASTEVENT if the server is supposed to handle masks etc. for this
* type of event. */
@@ -232,5 +239,7 @@
#define XI_RawTouchBeginMask (1 XI_RawTouchBegin)
#define XI_RawTouchEndMask (1 XI_RawTouchEnd)
#define XI_RawTouchUpdateMask(1 XI_RawTouchUpdate)
+#define XI_BarrierHitMask(1 XI_BarrierHit)
+#define XI_BarrierLeaveMask (1 XI_BarrierLeave)
#endif /* _XI2_H_ */
diff --git a/XI2proto.h b/XI2proto.h
index 9418357..4cdaa0d 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -67,6 +67,7 @@
#define Timeuint32_t
#define Atomuint32_t
#define Cursor uint32_t
+#define Barrier uint32_t
/**
* XI2 Request opcodes
@@ -92,9 +93,10 @@
#define X_XIDeleteProperty 58
#define X_XIGetProperty 59
#define X_XIGetSelectedEvents 60
+#define X_XIBarrierReleasePointer 61
/** Number of XI requests */
-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
+#define XI2REQUESTS (X_XIBarrierReleasePointer - X_XIQueryPointer + 1)
/** Number of XI2 events */
#define XI2EVENTS (XI_LASTEVENT + 1)
@@ -815,6 +817,22 @@ typedef struct {
} xXIGetPropertyReply;
#define sz_xXIGetPropertyReply 32
+typedef struct {
+uint16_tdeviceid;
+uint16_tpad;
+Barrier barrier;
+uint32_teventid;
+} xXIBarrierReleasePointerInfo;
+
+typedef struct {
+uint8_t reqType;/** Input extension major opcode */
+uint8_t ReqType;/** Always X_XIBarrierReleasePointer
*/
+uint16_tlength;
+uint32_tnum_barriers;
+/* array of xXIBarrierReleasePointerInfo */
+} xXIBarrierReleasePointerReq;
+#define sz_xXIBarrierReleasePointerReq 8
+
/*
*
*
* EVENTS
*
@@ -1035,10 +1053,39 @@ typedef struct
uint32_tpad3;
} xXIPropertyEvent;
+typedef struct
+{
+uint8_t type; /** Always GenericEvent */
+uint8_t extension; /** XI extension offset */
+uint16_tsequenceNumber;
+uint32_tlength; /** Length in 4 byte units */
+uint16_tevtype; /** ::XI_BarrierHit or
::XI_BarrierLeave */
+uint16_tdeviceid;
+Timetime;
+uint32_teventid;
+Window root;
+Window event;
+Barrier barrier;
+/* └ 32 byte boundary ┘ */
+uint32_tdtime;
+uint32_tflags; /** ::XIBarrierPointerReleased
+ ::XIBarrierDeviceIsGrabbed */
+uint16_tsourceid;
+int16_t pad;
+FP1616 root_x;
+FP1616 root_y;
+FP3232 dx;
+FP3232 dy;
+} xXIBarrierEvent;
+
+typedef xXIBarrierEvent xXIBarrierHitEvent;
+typedef xXIBarrierEvent xXIBarrierPointerReleasedEvent;
+typedef xXIBarrierEvent xXIBarrierLeaveEvent;
#undef Window
#undef Time
#undef Atom
#undef Cursor
+#undef Barrier
#endif /* _XI2PROTO_H_ */
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index c018026..402210f 100644
--- a/specs/XI2proto.txt
+++
[RFC/PATCH] Pointer barrier events (XI 2.3)
This is the protocol and client-side for the proposed XI 2.3 extension for pointer barrier events and barrier release requests. This feature adds two things: - if a pointer hits a barrier, events are sent to selected clients - a client may release the pointer, allowing it to pass through the barrier with the next movement. This enables two distinct user-visible features: - hot corners/edges that respond to pushing against them (GNOME3 wants this) - ad-hoc transparent barriers, so that depending on the speed of the pointer the user can move through the barrier (Unity wants this) Potential/current issues: - grab behaviour is different to other events - loss of predictable pointer acceleration across a barrier. In my tests, I have not found this to be noticable - device-specific release has not yet been implemented - one of the passive grab tests currently fails For a full view of the development history plus server and tests see the following repos: git://people.freedesktop.org/~whot/inputproto.git :barriers git://people.freedesktop.org/~whot/libXi.git :barriers git://people.freedesktop.org/~whot/xserver.git :barriers git://people.freedesktop.org/~whot/xorg-integration-tests.git :barriers Many thanks to Jasper and Chris, who did most of the work here. I think this is a valuable addition to 1.14, unless someone can find significant issues with the protocol as it is proposed here. Should we merge this for 1.14, I do reserve the right to disable this feature in the server before the release, unless we have a credible client-side implementation. We've learned the lesson with smooth scrolling that a server-implementation only is not good enough. Comments appreciated. 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
[PATCH libXi] Add support for pointer barrier events
From: Jasper St. Pierre jstpie...@mecheye.net
Co-authored-by: Peter Hutterer peter.hutte...@who-t.net
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/X11/extensions/XInput2.h | 47 +++
man/Makefile.am | 3 ++
man/XIBarrierReleasePointer.txt | 76 +
src/Makefile.am | 3 +-
src/XExtInt.c| 62 ++
src/XIBarrier.c | 81
src/XIint.h | 1 +
7 files changed, 272 insertions(+), 1 deletion(-)
create mode 100644 man/XIBarrierReleasePointer.txt
create mode 100644 src/XIBarrier.c
diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h
index 26de695..a746012 100644
--- a/include/X11/extensions/XInput2.h
+++ b/include/X11/extensions/XInput2.h
@@ -169,6 +169,16 @@ typedef struct
int status;
} XIGrabModifiers;
+typedef XID PointerBarrier;
+typedef unsigned int BarrierEventID;
+
+typedef struct
+{
+int deviceid;
+PointerBarrier barrier;
+BarrierEventID eventid;
+} XIBarrierReleasePointerInfo;
+
/**
* Generic XI2 event. All XI2 events have the same header.
*/
@@ -328,6 +338,28 @@ typedef struct {
int flags;
} XITouchOwnershipEvent;
+typedef struct {
+int type; /* GenericEvent */
+unsigned long serial; /* # of last request processed by server */
+Bool send_event; /* true if this came from a SendEvent request
*/
+Display *display; /* Display the event was read from */
+int extension;/* XI extension offset */
+int evtype;
+Time time;
+int deviceid;
+int sourceid;
+Windowevent;
+Windowroot;
+doubleroot_x;
+doubleroot_y;
+doubledx;
+doubledy;
+int dtime;
+int flags;
+PointerBarrier barrier;
+BarrierEventID eventid;
+} XIBarrierEvent;
+
_XFUNCPROTOBEGIN
extern Bool XIQueryPointer(
@@ -603,6 +635,21 @@ XIGetProperty(
unsigned char **data
);
+extern void
+XIBarrierReleasePointers(
+Display*display,
+XIBarrierReleasePointerInfo *barriers,
+int num_barriers
+);
+
+extern void
+XIBarrierReleasePointer(
+Display*display,
+int deviceid,
+PointerBarrier barrier,
+BarrierEventID eventid
+);
+
extern void XIFreeDeviceInfo(XIDeviceInfo *info);
_XFUNCPROTOEND
diff --git a/man/Makefile.am b/man/Makefile.am
index af63952..b92d486 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -25,6 +25,7 @@ libmandir = $(LIB_MAN_DIR)
# Source files for X Input v2 man pages
XI2_txt = \
+ XIBarrierReleasePointer.txt \
XIChangeHierarchy.txt \
XIDefineCursor.txt \
XIGrabButton.txt\
@@ -76,6 +77,7 @@ libman_xml = $(libman_txt:.txt=.xml)
# They are created by the xmlto command when generating man pages from DocBook
# The shadow man page contains a gtroff .so request to include the main man
page
XI2_shadows = \
+ XIBarrierReleasePointers.man\
XIUndefineCursor.man\
XIUngrabButton.man \
XIGrabKeycode.man \
@@ -152,6 +154,7 @@ XIDeleteProperty.man: XIChangeProperty.man
XIUngrabEnter.man XIGrabFocusIn.man XIUngrabFocusIn.man: XIGrabEnter.man
XIGetSelectedEvents.man: XISelectEvents.man
XIFreeDeviceInfo.man: XIQueryDevice.man
+XIBarrierReleasePointers.man: XIBarrierReleasePointer.man
# String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
# Unable to use __libmansuffix__ as underscores are lost in txt -- xml
conversion
diff --git a/man/XIBarrierReleasePointer.txt b/man/XIBarrierReleasePointer.txt
new file mode 100644
index 000..4fa48fe
--- /dev/null
+++ b/man/XIBarrierReleasePointer.txt
@@ -0,0 +1,76 @@
+XIBARRIERRELEASEPOINTER(libmansuffix)
+=
+
+NAME
+
+
+ XIBarrierReleasePointer, XIBarrierReleasePointers - allow pointer movement
across a pointer barrier
+
+SYNOPSIS
+
+
+ #include X11/extensions/XInput2.h
+
+ int XIBarrierReleasePointer( Display *display,
+int deviceid,
+PointerBarrier barrier,
+BarrierEventID eventid);
+
+ int XIBarrierReleasePointers( Display *display,
+ XIBarrierReleasePointerInfo *barriers,
+ int num_barriers);
+
+ display
+ Specifies the
Re: 1.14 feature window closes ... today?
Daniel Stone dan...@fooishbar.org writes: I really wouldn't mind getting the XWayland stuff in, but I won't be able to finish that off until Monday. There's a patch series on the list with only a couple of comments from Peter so far, but in any case most of it is only adding codepaths used by XWayland and nothing else, so it shouldn't be particularly intrusive/risky. Sounds like pushing the RC1 out until next Thursday (PST) might be good then. Wouldn't hurt to have XWayland ready for testing with 1.14 as Wayland starts to pick up steam after 1.0. I don't want to push much beyond that; we're already taking a schedule hit by making some of the bug window cross the holidays, which tends to have a fairly dramatic impact on work getting done (too much egg nog?). Thursday, Dec 13, 2012. I don't think we'll need to push the other dates out, If we get catastrophic problems with the 'late arrivals', we can always decide to back them out instead of fixing them (been done before, after all). -- keith.pack...@intel.com pgpYjmfRlsxnP.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
