[PATCH (v5) xinput 1/1] Add experimental multitouch support from XI 2.1
From: Chase Douglas chase.doug...@canonical.com
This patch adds experimental support for listening to touch streams
(TouchBegin, TouchMotion, TouchMotionUnowned, TouchOwnership, and
TouchEnd) with test-xi2, as well as showing TouchClass information
with list.
NOTE: This patch stlil contains experimental grab-testing code (the TouchBegin
grab, as well as 'thong' and the associated XIAllowTouchEvents), which
will be removed from the final revision. For the time being, it's
useful for testing.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Co-authored-by: Daniel Stone dan...@fooishbar.org
---
v5: Updated for TouchMotionUnowned and TouchOwnership events.
Fix buglet with 'thong' where it reset touch_events_received twice.
configure.ac |6 +++
src/list.c | 26 +++
src/test_xi2.c | 98 ---
3 files changed, 117 insertions(+), 13 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1dc2ce2..d657a59 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,6 +28,12 @@ PKG_CHECK_MODULES(XI2, [xi = 1.2.99.2] [inputproto =
1.9.99.15],
HAVE_XI2=no);
AM_CONDITIONAL(HAVE_XI2, [ test $HAVE_XI2 = yes ])
+# XI2.1 support
+PKG_CHECK_MODULES(XI2_1, [xi = 1.4.99.1] [inputproto = 2.0.99.1],
+ HAVE_XI2_1=yes; AC_DEFINE(HAVE_XI2_1, 1, [XI2_1
available]),
+ HAVE_XI2_1=no);
+AM_CONDITIONAL(HAVE_XI2_1, [ test $HAVE_XI2_1 = yes ])
+
AC_SUBST(XINPUT_CFLAGS)
AC_SUBST(XINPUT_LIBS)
AC_SUBST(HAVE_XI2)
diff --git a/src/list.c b/src/list.c
index aa88b28..48a74c2 100644
--- a/src/list.c
+++ b/src/list.c
@@ -177,6 +177,32 @@ print_classes_xi2(Display* display, XIAnyClassInfo
**classes,
XFree(name);
}
break;
+#ifdef HAVE_XI2_1
+case XITouchClass:
+{
+XITouchClassInfo *t = (XITouchClassInfo *)classes[i];
+
+printf(\t\tMultitouch capable (max %d touches):\n,
+ t-num_touches);
+printf(\t\t Mode: %s\n,
+ t-mode == XIDirectTouch ? direct : dependent);
+}
+break;
+case XITouchValuatorClass:
+{
+XITouchValuatorClassInfo *tv =
+(XITouchValuatorClassInfo *)classes[i];
+char *name = tv-label ?
+XGetAtomName(display, tv-label) : NULL;
+
+printf(\t\tDetail for Touch Valuator %d:\n, tv-number);
+printf(\t\t Label: %s\n, (name) ? name : None);
+printf(\t\t Range: %f - %f\n, tv-min, tv-max);
+printf(\t\t Resolution: %d units/m\n, tv-resolution);
+XFree(name);
+}
+break;
+#endif /* HAVE_XI2_1 */
}
}
diff --git a/src/test_xi2.c b/src/test_xi2.c
index 5b56397..2708c71 100644
--- a/src/test_xi2.c
+++ b/src/test_xi2.c
@@ -29,26 +29,46 @@
extern void print_classes_xi2(Display*, XIAnyClassInfo **classes,
int num_classes);
-static Window create_win(Display *dpy)
+static void create_win(Display *dpy, Window *win, Window *subwin)
{
-Window win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, 200,
-200, 0, 0, WhitePixel(dpy, 0));
-Window subwindow = XCreateSimpleWindow(dpy, win, 50, 50, 50, 50, 0, 0,
-BlackPixel(dpy, 0));
-
-XMapWindow(dpy, subwindow);
-XSelectInput(dpy, win, ExposureMask);
-return win;
+*win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, 200,
+ 200, 0, 0, WhitePixel(dpy, 0));
+*subwin = XCreateSimpleWindow(dpy, *win, 50, 50, 50, 50, 0, 0,
+ BlackPixel(dpy, 0));
+XMapWindow(dpy, *subwin);
+XSelectInput(dpy, *win, ExposureMask);
}
static void print_deviceevent(XIDeviceEvent* event)
{
double *val;
int i;
+static int touch_events_received = 0;
+static int thong = 0;
printf(device: %d (%d)\n, event-deviceid, event-sourceid);
printf(detail: %d\n, event-detail);
-printf(flags: %s\n, (event-flags XIKeyRepeat) ? repeat : );
+
+switch (event-evtype)
+{
+case XI_KeyPress:
+case XI_KeyRelease:
+printf(flags: %s\n,
+ (event-flags XIKeyRepeat) ? repeat : );
+break;
+#ifdef HAVE_XI2_1
+case XI_TouchBegin:
+case XI_TouchMotion:
+case XI_TouchMotionUnowned:
+case XI_TouchEnd:
+printf(flags: %s%s\n,
+ (event-flags XITouchOwnerAccepted) ?
+owner accepted : ,
+ (event-flags XITouchPendingFinish) ?
+pending finish : );
+break;
+#endif
+}
printf(root: %.2f/%.2f\n,
Re: [PATCH xf86-video-mach64] Remove libc wrappers for malloc, realloc and free.
On Wed, Jan 19, 2011 at 3:35 PM, Cyril Brulebois k...@debian.org wrote:
Signed-off-by: Cyril Brulebois k...@debian.org
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
---
src/aticonfig.c | 2 +-
src/aticonsole.c | 10
src/atidga.c | 2 +-
src/atidri.c | 54
+-
src/atii2c.c | 8 +++---
src/atimach64exa.c | 2 +-
src/atimach64i2c.c | 2 +-
src/atimach64probe.c | 4 +-
src/atimach64xv.c | 8 +++---
src/atimode.c | 2 +-
src/atipreinit.c | 2 +-
src/atiscreen.c | 8 +++---
12 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/src/aticonfig.c b/src/aticonfig.c
index 9102497..621e79e 100644
--- a/src/aticonfig.c
+++ b/src/aticonfig.c
@@ -502,5 +502,5 @@ ATIProcessOptions
#endif
}
- xfree(PublicOption);
+ free(PublicOption);
}
diff --git a/src/aticonsole.c b/src/aticonsole.c
index 6e742d9..50cc6e1 100644
--- a/src/aticonsole.c
+++ b/src/aticonsole.c
@@ -799,19 +799,19 @@ ATIFreeScreen
#ifndef AVOID_CPIO
- xfree(pATI-OldHW.frame_buffer);
- xfree(pATI-NewHW.frame_buffer);
+ free(pATI-OldHW.frame_buffer);
+ free(pATI-NewHW.frame_buffer);
#endif /* AVOID_CPIO */
- xfree(pATI-pShadow);
+ free(pATI-pShadow);
#ifndef AVOID_DGA
- xfree(pATI-pDGAMode);
+ free(pATI-pDGAMode);
#endif /* AVOID_DGA */
- xfree(pATI);
+ free(pATI);
pScreenInfo-driverPrivate = NULL;
}
diff --git a/src/atidga.c b/src/atidga.c
index fb6d1d7..c1cd163 100644
--- a/src/atidga.c
+++ b/src/atidga.c
@@ -324,7 +324,7 @@ ATIDGAAddModes
if ((modePitch * bitsPerPixel * pMode-VDisplay) = videoBits)
{
/* Stop generating modes on out-of-memory conditions */
- pDGAMode = xrealloc(pATI-pDGAMode,
+ pDGAMode = realloc(pATI-pDGAMode,
(pATI-nDGAMode + 1) * SizeOf(DGAModeRec));
if (!pDGAMode)
break;
diff --git a/src/atidri.c b/src/atidri.c
index 15d0014..9c6719b 100644
--- a/src/atidri.c
+++ b/src/atidri.c
@@ -109,14 +109,14 @@ static Bool ATIInitVisualConfigs( ScreenPtr pScreen )
pATIConfigs = (ATIConfigPrivPtr)
xnfcalloc( sizeof(ATIConfigPrivRec), numConfigs );
if ( !pATIConfigs ) {
- xfree( pConfigs );
+ free( pConfigs );
return FALSE;
}
pATIConfigPtrs = (ATIConfigPrivPtr*)
xnfcalloc( sizeof(ATIConfigPrivPtr), numConfigs );
if ( !pATIConfigPtrs ) {
- xfree( pConfigs );
- xfree( pATIConfigs );
+ free( pConfigs );
+ free( pATIConfigs );
return FALSE;
}
@@ -190,14 +190,14 @@ static Bool ATIInitVisualConfigs( ScreenPtr pScreen )
pATIConfigs = (ATIConfigPrivPtr)
xnfcalloc( sizeof(ATIConfigPrivRec), numConfigs );
if ( !pATIConfigs ) {
- xfree( pConfigs );
+ free( pConfigs );
return FALSE;
}
pATIConfigPtrs = (ATIConfigPrivPtr*)
xnfcalloc( sizeof(ATIConfigPrivPtr), numConfigs );
if ( !pATIConfigPtrs ) {
- xfree( pConfigs );
- xfree( pATIConfigs );
+ free( pConfigs );
+ free( pATIConfigs );
return FALSE;
}
@@ -553,11 +553,11 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
if (nbox 1) {
/* Keep ordering in each band, reverse order of bands */
- pboxNew1 = (BoxPtr)xalloc(sizeof(BoxRec)*nbox);
+ pboxNew1 = (BoxPtr)malloc(sizeof(BoxRec)*nbox);
if (!pboxNew1) return;
- pptNew1 = (DDXPointPtr)xalloc(sizeof(DDXPointRec)*nbox);
+ pptNew1 = (DDXPointPtr)malloc(sizeof(DDXPointRec)*nbox);
if (!pptNew1) {
- xfree(pboxNew1);
+ free(pboxNew1);
return;
}
pboxBase = pboxNext = pbox+nbox-1;
@@ -588,13 +588,13 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
if (nbox 1) {
/* reverse order of rects in each band */
- pboxNew2 = (BoxPtr)xalloc(sizeof(BoxRec)*nbox);
- pptNew2 = (DDXPointPtr)xalloc(sizeof(DDXPointRec)*nbox);
+ pboxNew2 = (BoxPtr)malloc(sizeof(BoxRec)*nbox);
+ pptNew2 = (DDXPointPtr)malloc(sizeof(DDXPointRec)*nbox);
if (!pboxNew2 || !pptNew2) {
- xfree(pptNew2);
- xfree(pboxNew2);
- xfree(pptNew1);
- xfree(pboxNew1);
+ free(pptNew2);
+ free(pboxNew2);
+ free(pptNew1);
+ free(pboxNew1);
return;
}
pboxBase = pboxNext = pbox;
@@ -665,10 +665,10 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
outf(SRC_OFF_PITCH, pATI-NewHW.dst_off_pitch);
Re: [PATCH 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, 2011-01-19 at 13:53 -0800, Dan Nicholson wrote: On Wed, Jan 19, 2011 at 1:25 PM, Gaetan Nadon mems...@videotron.ca wrote: On Wed, 2011-01-19 at 12:51 -0800, Dan Nicholson wrote: This seems like more of a problem with the macros. I don't know why XORG_STRICT_OPTION doesn't just AC_REQUIRE AC_PROG_CC so that we don't get these kinds of issues. I have not found a way to avoid these issues. The last call wins. If C99 is invoked before AC_REQUIRE C89, C89 will win simply because it is not C99. They don't know about each other, even if some of the work they do is cached and reused by the other. However, for this particular case I think it would be better if we just moved the XORG_DEFAULT_OPTIONS call below AC_PROG_CC. The statements become order sensitive, which is hard to maintain, even when commented. The day will come where there will be a dead lock. If we comment or remove AC_PROG_CC, then it becomes really unclear that we're getting it implicitly through XORG_DEFAULT_OPTIONS. This is also true for any macro that is being invoked from XORG_DEFAULT_OPTIONS. The XORG_STRICT_OPTION was intended to enforce C99 by virtue of inclusion in configure.ac. It ceased to be optional once it got included in XORG_DEFAULT_OPTIONS. Other comments from reviewers so far indicate there is no objections to C99, with some pros and cons. The reason why AC_PROG_CC are removed is for the module to be compiled C99. If we find something better to do, it should be applied to all 240 modules, unless there is a reason to configure the modules with different compiler levels. And if we later remove XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS (which isn't a crazy suggestion), then there is nothing calling AC_PROG_CC*. That's why I was suggesting to just move the XORG_DEFAULT_OPTIONS call later so that the original call is still there and it's not some implicit thing buried in another macro. Removing XORG_STRICT_OPTION will never pass review as it would break backward compatibility. In fact, we can only add or fix bugs. Suppose we switch order, no harm done. C99 will prevail. It will be very confusing. Reading configure.ac one will thing C89 is in effect, not knowing C99 is called somewhere buried in a macro. To find out which version it is compiled with: grep ^CC= `find . -name config.log -type f -print` For a C99: CC='gcc -std=gnu99' We want to try to ensure that we get C99 if XORG_STRICT_OPTION is used. The intention of the author was to always use C99 and this was accomplished by moving XORG_STRICT_OPTION in XORG_DEFAULT_OPTIONS. The only optional part is the usage of -pedantic -Werror flags. So, if we AC_REQUIRE([AC_PROG_CC]) before AC_REQUIRE([AC_PROG_CC_C99]) in XORG_STRICT_OPTION, then it should ensure the ordering, right? Or can you just keep calling them and the last one wins? I haven't checked. The last one wins. If one call is in configure.ac and the other call is buried, it is confusing to the reader. If neither is called in configure.ac, it's like any other statement that is buried in util-macros. I guess it's like any reusable code you can't see from the calling program. You don't know what it does until you dig in. There are pros and cons. The module developer can concentrate on the configuration that is unique to the module and not have to deal with dozens of details that are the same in all modules. Some modules print a summary of the important configuration aspects of the module at the end of the configuration. That would be a nice feature. -- Dan signature.asc Description: This is a digitally signed message part ___ 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 app-sessreg 1/1] config: use AC_CHECK_MEMBERS rather than AC_CHECK_MEMBER
Let Autoconf do the work of setting up the #define in config.h. Apply and comment standard sections layout. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 11 --- sessreg.c|2 +- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index f3c9f4e..c7e5e90 100644 --- a/configure.ac +++ b/configure.ac @@ -42,17 +42,14 @@ XORG_WITH_LINT # Checks for header files. AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h]) -AC_CHECK_MEMBER([struct utmpx.ut_syslen], - HAVE_SYSLEN=1, - HAVE_SYSLEN=0, - [#include utmpx.h]) -AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN, - [utmpx structure includes ut_syslen field]) # Checks for typedefs, structures, and compiler characteristics. +AC_CHECK_MEMBERS([struct utmpx.ut_syslen], [], [], [#include utmpx.h]) + +# Checks for library functions. AC_CHECK_FUNCS([updwtmpx utmpxname]) -# Checks for pkg-config packages +# Obtain compiler/linker options for depedencies PKG_CHECK_MODULES(SESSREG, xproto) AC_CONFIG_FILES([ diff --git a/sessreg.c b/sessreg.c index 809bed4..40ec450 100644 --- a/sessreg.c +++ b/sessreg.c @@ -477,7 +477,7 @@ set_utmpx (struct utmpx *u, const char *line, const char *user, (void) strncpy (u-ut_line, line, sizeof (u-ut_line)); strncpy(u-ut_host, line, sizeof(u-ut_host)); -#if HAVE_UTMPX_UT_SYSLEN +#ifdef HAVE_STRUCT_UTMPX_UT_SYSLEN u-ut_syslen = strlen(line); #endif } -- 1.6.0.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 5/5] input: use a thread for the generation of input events
Hi, On Thu, Dec 16, 2010 at 03:31:40PM -0500, Adam Jackson wrote: If configured, and enabled at runtime, use a separate thread for handling input devices. Use pipes to communicate plug events from main thread to input thread, and to communicate event queue updates from input thread to main thread. The locking in this isn't quite sufficient. Pretty much all Get*Events() users will need locking around their event-handling body, as the following can go badly wrong: * One master device with an XTest and a physical slave device * Main thread gets a request to generate an XTest event, calls GetPointerEvents which sends a DeviceChangedEvent to switch the MD to the XTest SD's caps, as well as the pointer event itself * Main thread posts DCE through mieqEnqueue * Input thread turns up and griefs the entire process by calling GetPointerEvents, generating a DCE to switch the MD's caps to the physical SD's, posts its DCE * XTest posts its pointer event * Input thread posts its pointer event (Took me three goes to type GetPointerEvents instead of GetTouchEvents. Ugh.) Mind you, we have the same race with SIGIO, so it's not a strictly a regression, but still not ideal. Cheers, Daniel 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: [PATCH] xkb: after making changes to the xkb ctrls, copy them back into kbdfeed.
Hi, On Thu, Jan 13, 2011 at 01:45:02PM +1000, Peter Hutterer wrote: enabled_ctrls_changes is nowhere near the usual event or config paths. So this condition always evaluated to false and the memcpy would thus never been hit. As a result, any modification to the XKB struct during XkbUpdateDescActions was not reflected in the kbdfeed ctrls. The flag that is set by XkbUpdateDescActions() if ctrls were changed are in enabled_ctrls. Hm. EnableDisableControls does affect enabled_ctrls_changes, but cunningly, it only sees fit to call XkbUpdateIndicators when it's done. So it could in theory toggle global autorepeat state when a client vanishes (because that's the only caller), and no-one would realise until something else caused it to be kicked. Nice one. So, on the grounds that this almost certainly doesn't make anything worse, and the client-gone path needed fixing anyway (please file a bug): Reviewed-and-regretted-by: Daniel Stone dan...@fooishbar.org Cheers, Daniel 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: [PATCH 1/2] mi: Call pScreen-ConstrainCursorHarder from the position update path
Hi, On Wed, Jan 19, 2011 at 12:58:40AM -0500, Adam Jackson wrote: Signed-off-by: Adam Jackson a...@redhat.com --- mi/mipointer.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/mi/mipointer.c b/mi/mipointer.c index 554397a..1f08133 100644 --- a/mi/mipointer.c +++ b/mi/mipointer.c @@ -229,6 +229,10 @@ miPointerSetCursorPosition(DeviceIntPtr pDev, ScreenPtr pScreen, SetupScreen (pScreen); GenerateEvent = generateEvent; + +if (pScreen-ConstrainCursorHarder) +pScreen-ConstrainCursorHarder(pDev, pScreen, x, y); + /* device dependent - must pend signal and call miPointerWarpCursor */ (*pScreenPriv-screenFuncs-WarpCursor) (pDev, pScreen, x, y); if (!generateEvent) This looks good to me, except that now I think about it, we might need CCH in _both_ miPointerSetCursorPosition, and miPointerSetPosition, or a call to CCH in dix/getevents.c:positionSprite(). We do the right thing in the event handling path, but without the call (direct or not) from positionSprite(), we might send out constrained events, but have unconstrained events recorded in the history, which is bad for any clients still using pointer hints. Not that anyone should be using pointer hints at all ever, but still. Anyway, as far as I can tell, doing it both in SetCursorPosition and SetPosition covers every possible base (WarpPointer, GetPointerEvents, as well as making triply sure in every event handler), so with that: Reviewed-by: Daniel Stone dan...@fooishbar.org Cheers, Daniel 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: [PATCH] dix: Simpler and faster XID hash
On Wed, 19 Jan 2011 19:58:01 -0500, Adam Jackson a...@redhat.com wrote:
-id = RESOURCE_ID_MASK;
-switch (clientTable[client].hashsize)
-{
- case 6:
- return ((int)(0x03F (id ^ (id6) ^ (id12;
- case 7:
- return ((int)(0x07F (id ^ (id7) ^ (id13;
- case 8:
- return ((int)(0x0FF (id ^ (id8) ^ (id16;
- case 9:
- return ((int)(0x1FF (id ^ (id9;
- case 10:
- return ((int)(0x3FF (id ^ (id10;
- case 11:
- return ((int)(0x7FF (id ^ (id11;
-}
-return -1;
+return id (clientTable[client].hashsize - 1);
This makes no sense to me. Did you meak (id ((1 hashsize) - 1) ?
(in which case, hashsize might want to be precomputed as 'hashmask' or
some such.
--
keith.pack...@intel.com
pgpb5PN0tQe8Z.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: [PATCH 1/2] mi: Call pScreen-ConstrainCursorHarder from the position update path
On Jan 19, 2011, at 9:27 PM, Daniel Stone wrote: On Wed, Jan 19, 2011 at 12:58:40AM -0500, Adam Jackson wrote: Signed-off-by: Adam Jackson a...@redhat.com --- mi/mipointer.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/mi/mipointer.c b/mi/mipointer.c index 554397a..1f08133 100644 --- a/mi/mipointer.c +++ b/mi/mipointer.c @@ -229,6 +229,10 @@ miPointerSetCursorPosition(DeviceIntPtr pDev, ScreenPtr pScreen, SetupScreen (pScreen); GenerateEvent = generateEvent; + +if (pScreen-ConstrainCursorHarder) +pScreen-ConstrainCursorHarder(pDev, pScreen, x, y); + /* device dependent - must pend signal and call miPointerWarpCursor */ (*pScreenPriv-screenFuncs-WarpCursor) (pDev, pScreen, x, y); if (!generateEvent) This looks good to me, except that now I think about it, we might need CCH in _both_ miPointerSetCursorPosition, and miPointerSetPosition, or a call to CCH in dix/getevents.c:positionSprite(). We do the right thing in the event handling path, but without the call (direct or not) from positionSprite(), we might send out constrained events, but have unconstrained events recorded in the history, which is bad for any clients still using pointer hints. Ugh. If I'm reading you right, that means pointer hints could be wrong if the CRTC config changes between when they're recorded and when they're sent? I mean I have difficulty caring too much about that, but still. - ajax ___ 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 1/2] mi: Call pScreen-ConstrainCursorHarder from the position update path
On Wed, Jan 19, 2011 at 10:59:21PM -0500, Adam Jackson wrote: On Jan 19, 2011, at 9:27 PM, Daniel Stone wrote: On Wed, Jan 19, 2011 at 12:58:40AM -0500, Adam Jackson wrote: @@ -229,6 +229,10 @@ miPointerSetCursorPosition(DeviceIntPtr pDev, ScreenPtr pScreen, [...] This looks good to me, except that now I think about it, we might need CCH in _both_ miPointerSetCursorPosition, and miPointerSetPosition, or a call to CCH in dix/getevents.c:positionSprite(). We do the right thing in the event handling path, but without the call (direct or not) from positionSprite(), we might send out constrained events, but have unconstrained events recorded in the history, which is bad for any clients still using pointer hints. Ugh. If I'm reading you right, that means pointer hints could be wrong if the CRTC config changes between when they're recorded and when they're sent? I mean I have difficulty caring too much about that, but still. Yep. If you really cared, you could move updateHistory to be called from UpdateDeviceState instead of GetPointerEvents, which would eliminate the race. And if you _really_ cared, you could call ProcessInputEvents from the top of ProcGetMotionEvents, to make sure that clients requesting motion history still got as much history as had been dealt with by SIGIO by the time the request got processed. I don't think any jury would convict for not caring though. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] privates.h: remove return in function returning void
dixSetScreenPrivate and dixSetPrivate are function returning void.
Signed-off-by: Roberto Branciforti rbb...@gmail.com
---
include/privates.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/privates.h b/include/privates.h
index 7ef2cb7..2b0040c 100644
--- a/include/privates.h
+++ b/include/privates.h
@@ -195,7 +195,7 @@ dixGetScreenPrivate(PrivatePtr *privates, const
DevScreenPrivateKey key, ScreenP
static inline void
dixSetScreenPrivate(PrivatePtr *privates, const DevScreenPrivateKey key,
ScreenPtr pScreen, pointer val)
{
-return dixSetPrivate(privates, _dixGetScreenPrivateKey(key, pScreen), val);
+dixSetPrivate(privates, _dixGetScreenPrivateKey(key, pScreen), val);
}
static inline pointer
--
1.6.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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
On Die, 2011-01-18 at 23:59 +0100, Maarten Maathuis wrote: 2011/1/18 Maarten Maathuis madman2...@gmail.com: 2011/1/18 Maarten Maathuis madman2...@gmail.com: 2011/1/18 Michel Dänzer mic...@daenzer.net: On Mon, 2011-01-17 at 21:45 +0100, Maarten Maathuis wrote: 2010/12/20 Michel Dänzer mic...@daenzer.net: On Mon, 2010-12-20 at 15:54 +0100, Maarten Maathuis wrote: 2010/12/20 Michel Dänzer mic...@daenzer.net: On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote: 2010/12/14 Michel Dänzer mic...@daenzer.net: On Mon, 2010-12-13 at 19:42 +0100, Maarten Maathuis wrote: - Apps like xterm can trigger a lot of fallback rendering. - This can lead to (annoyingly) high latencies, because you have to wait for the block handler. - You need a driver that doesn't directly access the front buffer to trigger this (NV50+ nouveau for example). - Repeatingly doing dmesg on an xterm with a bitmap font will reveal that you never see part of the text. - I have recieved at least one complaint in the past of slow terminal performance, which was related to core font rendering. - This does sacrifice some throughput, not sure how much, Shouldn't be hard to measure. I did a little test (catting a saved copy of dmesg) and the throughput loss is about 25%. What are the absolute numbers? Roughly 250 ms vs 330 ms (error margin is about 20-30 ms if i had to guess). That seems rather inaccurate, can you try something at least an order of magnitude bigger? Forgot about it for a while, but it remains 33% slower, for 10 times the text. Times are typically 2.7 - 2.8 s vs 3.6 - 3.7 s. Okay, thanks. I guess this might be acceptable for a substantial decrease in latency, but I can't help wondering if we couldn't get that with less if any sacrifice in throughput. Have you tried or thought about anything else? Some random ideas offhand: * Limit the amount of deferred dirtiness, be it wall clock based or even just a simple counter of deferred ops. * Flushing the deferred dirtiness in other places in addition to (or instead of) the BlockHandler, e.g. a flush callback. I kind of went for the best solution in terms of latency (considering it doesn't happen all that often for most people), the second best would probably be a frontbuffer area counter, requiring a certain square pixel damaged area before flushing. The downside is that latency while typing in a console will still be there. Some kind of maximum latency timer might work as well, although i don't know if the xserver has those. But that won't reduce latency to a minimum in low throughput situations. Another idea would be to use a rate limit. It gives you the low throughput low latency situation, but still gives decent behaviour at higher throughput. Just need to think of the right timer to use and what maximum rate to use. The rate limiting quickly converges to the new times, while still giving the impression of missing text. So the question is, should the user get what he/she expects (namely line by line drawing of text instead of the quasi random blocks appearing on screen) or do we compromise on just reducing latency for low throughput cases like typing in a terminal or relatively short multi line output? Please show us what exactly you have tried. -- 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:setxkbmap] Fix crash when when -device is specified without argument
On Tue, Jan 18, 2011 at 10:35:59PM -0800, Alan Coopersmith wrote:
From: Stuart Kreitman stuart.kreit...@oracle.com
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6971649
Signed-off-by: Stuart Kreitman stuart.kreit...@oracle.com
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
setxkbmap.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index 338b06c..e812a9c 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -397,7 +397,14 @@ parseArgs(int argc, char **argv)
else if (streq(argv[i], -config))
ok = setOptString(i, argc, argv, CONFIG_NDX, FROM_CMD_LINE);
else if (streq(argv[i], -device))
-deviceSpec = atoi(argv[++i]); /* only allow device IDs, not
names */
+{
+if ( ++i argc ) {
+deviceSpec = atoi(argv[i]); /* only allow device IDs, not
names */
+} else {
+usage(argc, argv);
+exit(-1);
+}
+}
else if (streq(argv[i], -display))
ok = setOptString(i, argc, argv, DISPLAY_NDX, FROM_CMD_LINE);
else if (streq(argv[i], -geometry))
--
1.7.3.2
Reviewed-by: Dirk Wallenstein hals...@t-online.de
--
Greetings,
Dirk
___
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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa/exa_migration_mixed.c
@@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
RegionPtr pRegion, void *closure)
if (!pExaPixmap-use_gpu_copy exaPixmapHasGpuCopy(pPixmap)) {
ExaScreenPriv(pPixmap-drawable.pScreen);
- /* Front buffer: Don't wait for the block handler to copy back the data.
-* This avoids annoying latency if you encounter a lot of software
rendering.
+ /* Front buffer: Don't wait for the block handler to copy back the
data, unless
+* it has been moved back in the last 10 ms. This avoid annoying
latency when
+* troughput is low, but keeps troughput acceptable at higher levels.
*/
- if (pPixmap == pScreen-GetScreenPixmap(pScreen))
- exaMoveInPixmap_mixed(pPixmap);
- else {
+ if (pPixmap == pScreen-GetScreenPixmap(pScreen)) {
+ CARD32 now = GetTimeInMillis();
+ if ((now - pExaScr-last_time_front_mixed_pixmap) 10) {
+ pExaScr-last_time_front_mixed_pixmap = now;
+ exaMoveInPixmap_mixed(pPixmap);
+
+ if (pExaScr-deferred_mixed_pixmap == pPixmap)
+ pExaScr-deferred_mixed_pixmap = NULL;
+ } else {
+ if (pExaScr-deferred_mixed_pixmap
+ pExaScr-deferred_mixed_pixmap != pPixmap)
+
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
+
+ pExaScr-deferred_mixed_pixmap = pPixmap;
+ }
+ } else {
if (pExaScr-deferred_mixed_pixmap
pExaScr-deferred_mixed_pixmap != pPixmap)
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index e5d90d4..cb58a02 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -185,6 +185,7 @@ typedef struct {
CARD32 lastDefragment;
CARD32 nextDefragment;
PixmapPtr deferred_mixed_pixmap;
+CARD32 last_time_front_mixed_pixmap;
/* Reference counting for accessed pixmaps */
struct {
___
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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa/exa_migration_mixed.c
@@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
RegionPtr pRegion, void *closure)
if (!pExaPixmap-use_gpu_copy exaPixmapHasGpuCopy(pPixmap)) {
ExaScreenPriv(pPixmap-drawable.pScreen);
- /* Front buffer: Don't wait for the block handler to copy back the data.
- * This avoids annoying latency if you encounter a lot of software
rendering.
+ /* Front buffer: Don't wait for the block handler to copy back the
data, unless
+ * it has been moved back in the last 10 ms. This avoid annoying
latency when
+ * troughput is low, but keeps troughput acceptable at higher levels.
*/
- if (pPixmap == pScreen-GetScreenPixmap(pScreen))
- exaMoveInPixmap_mixed(pPixmap);
- else {
+ if (pPixmap == pScreen-GetScreenPixmap(pScreen)) {
+ CARD32 now = GetTimeInMillis();
+ if ((now - pExaScr-last_time_front_mixed_pixmap) 10) {
+ pExaScr-last_time_front_mixed_pixmap = now;
+ exaMoveInPixmap_mixed(pPixmap);
+
+ if (pExaScr-deferred_mixed_pixmap == pPixmap)
+ pExaScr-deferred_mixed_pixmap = NULL;
+ } else {
+ if (pExaScr-deferred_mixed_pixmap
+ pExaScr-deferred_mixed_pixmap != pPixmap)
+
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
+
+ pExaScr-deferred_mixed_pixmap = pPixmap;
+ }
+ } else {
if (pExaScr-deferred_mixed_pixmap
pExaScr-deferred_mixed_pixmap != pPixmap)
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
I still can't help wondering if we aren't missing something about what
makes the difference between the text being 'shown' or not[0], but this
approach would be getting rather complicated already, and if there's no
timeout period which gives a better tradeoff between latency and
throughput, I guess erring on the side of the former is better for now.
So, feel free to add my
Reviewed-by: Michel Dänzer mic...@daenzer.net
to your patch 3/3, and thanks for taking the time to get more
information.
[0] E.g., maybe the larger number of UploadToScreen operations results
in the driver flushing commands to the GPU more often?
--
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:setxkbmap] Fix crash when when -device is specified without argument
On Tue, Jan 18, 2011 at 10:35:59PM -0800, Alan Coopersmith wrote: From: Stuart Kreitman stuart.kreit...@oracle.com http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6971649 Signed-off-by: Stuart Kreitman stuart.kreit...@oracle.com Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Reviewed-by: Daniel Stone dan...@fooishbar.org 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: [PATCH xinput 0/3] Add different formats for --list option
On Tue, Jan 18, 2011 at 01:08:57PM +1000, Peter Hutterer wrote: When using XI2, the output of xinput list shows the device hierarchy including attachment, device type and a few others. This is useful for humans but hard to parse for scripts who usually only care about a device name or about the device ID. Add two more flags to xinput list to display name or id only. Cheers, Peter The new options are missing in the help output. With that addition For the series (all 4 of 3): Reviewed-by: Dirk Wallenstein hals...@t-online.de Tested-by: Dirk Wallenstein hals...@t-online.de -- Greetings, Dirk ___ 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] Add xorg.conf.d shadow man page pointing to xorg.conf man page
On Tue, Jan 18, 2011 at 7:26 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Reviewed-by: Gaetan Nadon mems...@videotron.ca Tested-by: Gaetan Nadon mems...@videotron.ca Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ 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 2/3 v2] config: Use correct AC_CONFIG_HEADERS macro
On Tue, 2011-01-18 at 19:34 -0800, Alan Coopersmith wrote: Replaces obsolete AM_CONFIG_HEADER and undocumented AC_CONFIG_HEADER Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- Updated to use preferred macro as suggested by Gaetan configure.ac |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a41d642..2e96d58 100644 --- a/configure.ac +++ b/configure.ac @@ -7,14 +7,13 @@ AC_INIT([libX11], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libX11) AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([src/config.h include/X11/XlibConf.h]) AC_CONFIG_MACRO_DIR([m4]) AC_CANONICAL_BUILD AC_CANONICAL_HOST AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER([src/config.h]) -AC_CONFIG_HEADER([include/X11/XlibConf.h]) # Set common system defines for POSIX extensions, such as _GNU_SOURCE # Must be called before any macros that run the compiler (like AC_PROG_LIBTOOL) Reviewed-by: Gaetan Nadon mems...@videotron.ca In autoconf/status.m4: # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) signature.asc Description: This is a digitally signed message part ___ 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] RANDR support for XWin DDX
Hi Keith, The following set of patches adds some RANDR support to the XWin DDX, as well as various cleanups in the related area of the code. Please consider pulling into master. Thanks. The following changes since commit c6aa4755ec355101a62bef86dbb090262fe806f6: xkb/ddxLoad.c doesn't need paths.h any more (2011-01-18 15:22:04 -0800) are available in the git repository at: git://anongit.freedesktop.org/~jturney/xserver jturney-framebuffer-resize-for-master Jon TURNEY (16): Cygwin/X: Enable building of nativegdi and primaryfb engines to avoid further rusting Cygwin/X: Refactor framebuffer allocation/release in drawing engines Cygwin/X: Rather than storing calculated physical display sizes, calculate them when needed Cygwin/X: Remove an attempt at detecting if WM_DISPLAYCHANGE affects the X screen Cygwin/X: Move QueryMonitor() out of windprocarg.c Cygwin/X: Add -resize command line option Cygwin/X: Implement framebuffer resizing in RANDR extension Cygwin/X: Make WM_SIZE use RandR resizing when -resize=randr Cygwin/X: Generate RANDR change on WM_DISPLAYCHANGE for rootless modes Cygwin/X: Don't turn off -multiplemonitors when all monitors don't have the same pixel format when using shadow GDI engine Cygwin/X: Fix a typo in command line argument validation code Cygwin/X: Remove WIN_DIB_MAXIMUM_SIZE check Cygwin/X: Use winUpdateFBPointer() in winshaddd.c rather than duplicating it inline Cygwin/X: Deal with RANDR depth changes correctly in ShadowGDI drawing engine Cygwin/X: Simplify and consolidate reporting of the bpp value we are going to use Cygwin/X: DirectDraw engines shouldn't try to blit if the surface wasn't allocated configure.ac |4 +- hw/xwin/InitOutput.c | 13 ++- hw/xwin/Makefile.am|1 + hw/xwin/man/XWin.man | 85 +++--- hw/xwin/win.h | 56 +++-- hw/xwin/wincreatewnd.c | 48 hw/xwin/windialogs.c | 13 +- hw/xwin/winmonitors.c | 92 ++ hw/xwin/winmonitors.h | 14 ++ hw/xwin/winnativegdi.c | 37 +++ hw/xwin/winpfbdd.c | 108 + hw/xwin/winprocarg.c | 131 +++- hw/xwin/winrandr.c | 302 ++-- hw/xwin/winscrinit.c | 66 ++- hw/xwin/winshaddd.c| 164 ++ hw/xwin/winshadddnl.c | 152 +++- hw/xwin/winshadgdi.c | 124 +-- hw/xwin/winvalargs.c |8 +- hw/xwin/winwindow.c|1 + hw/xwin/winwndproc.c | 307 20 files changed, 1026 insertions(+), 700 deletions(-) create mode 100644 hw/xwin/winmonitors.c create mode 100644 hw/xwin/winmonitors.h ___ 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 2/3 v2] config: Use correct AC_CONFIG_HEADERS macro
On Tue, Jan 18, 2011 at 7:34 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Replaces obsolete AM_CONFIG_HEADER and undocumented AC_CONFIG_HEADER Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- Updated to use preferred macro as suggested by Gaetan configure.ac | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a41d642..2e96d58 100644 --- a/configure.ac +++ b/configure.ac @@ -7,14 +7,13 @@ AC_INIT([libX11], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libX11) AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([src/config.h include/X11/XlibConf.h]) AC_CONFIG_MACRO_DIR([m4]) AC_CANONICAL_BUILD AC_CANONICAL_HOST AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER([src/config.h]) -AC_CONFIG_HEADER([include/X11/XlibConf.h]) I was worried that AM_CONFIG_HEADER did something slightly different, but a little google tells me it's just aliased to AC_CONFIG_HEADERS nowadays anyway. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ 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 16/17] Input: Add initial multitouch support from Xi 2.1
Hi, On Fri, Jan 07, 2011 at 12:39:48PM -0500, Chase Douglas wrote: On 01/07/2011 10:57 AM, Daniel Stone wrote: On Thu, Jan 06, 2011 at 02:30:07PM -0500, Chase Douglas wrote: Maybe we should prohibit XIAllMasterDevices and any slave device selection at the same time, just as is done for XIAllDevices? That would prevent anyone from ever receiving touch events for a floating direct touch device if someone had an XIAllMasterDevices grab. I've been thinking about just allowing both grabs and selections on different devices (e.g. allowing them on all of the SD, the MD, all MDs, and all devices), and using the most specific one for delivery. So, first check a grab on the specific SD, then the specific MD, then all MDs, then all devices. At the moment, I can't think of how to manage the floating - attached corner case in that comment (i.e. when you have a grab on a floating device which later becomes attached to an MD that also has a touch grab, or if there's an AllMasterDevices touch grab), so I'm inclined to not pretend we can always ensure exclusive access. I want to ensure that whatever we do, we fall on the side of emitting events only to one owning client at a time. Yep, I agree, and I can't see that the current code violates that assumption. I wonder if maybe we should instead cause an attachment to fail if it would break exclusivity here. With an appropriate error code the requesting client would understand what's going on. It's a bit of a kludge though, since XI 2.0 clients may get an error they don't understand. In reality, this corner case shouldn't come up too often, so maybe the kludge would be acceptable? Hm, I really don't like emitting non-obvious errors though, especially as pointer reconfiguration would be done via things like a desktop environment control panel, or a dumb client like xinput. Especially if an application has long-running grabs, the solution would be to close all your applications or even restart the X server, in order to change your device hierachy. That doesn't sound too pleasant. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Fix compilation of xf86bigfont.c
xf86bigfont.c: In function 'XFree86BigfontExtensionInit':
xf86bigfont.c:146: error: 'ProcXF86BigfontDispatch' undeclared (first use in
this function)
xf86bigfont.c:147: error: 'SProcXF86BigfontDispatch' undeclared (first use in
this function)
It seems this has been broken since commit
cbd4d5dbb70db62ba1cb79c7b904e6fa11f62d7e
delete pervasively use of DISPATCH_PROC (2010-09-28), which is a bit worrying
as
that presumably indicates that no tinderbox is configuring with
--enable-xf86bigfont.
In a similar fashion to that commit, fix by moving XFree86BigfontExtensionInit()
below the definitions of the static dispatch functions is references.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
Xext/xf86bigfont.c | 89 +--
1 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/Xext/xf86bigfont.c b/Xext/xf86bigfont.c
index da35287..c32c090 100644
--- a/Xext/xf86bigfont.c
+++ b/Xext/xf86bigfont.c
@@ -137,51 +137,6 @@ CheckForShmSyscall(void)
#endif
-void
-XFree86BigfontExtensionInit(void)
-{
-if (AddExtension(XF86BIGFONTNAME,
-XF86BigfontNumberEvents,
-XF86BigfontNumberErrors,
-ProcXF86BigfontDispatch,
-SProcXF86BigfontDispatch,
-XF86BigfontResetProc,
-StandardMinorOpcode)) {
-#ifdef HAS_SHM
-#ifdef MUST_CHECK_FOR_SHM_SYSCALL
- /*
-* Note: Local-clients will not be optimized without shared memory
-* support. Remote-client optimization does not depend on shared
-* memory support. Thus, the extension is still registered even
-* when shared memory support is not functional.
-*/
- if (!CheckForShmSyscall()) {
- ErrorF(XF86BIGFONTNAME extension local-client optimization
disabled due to lack of shared memory support in the kernel\n);
- return;
- }
-#endif
-
- srand((unsigned int) time(NULL));
- signature = ((unsigned int) (65536.0/(RAND_MAX+1.0) * rand()) 16)
- + (unsigned int) (65536.0/(RAND_MAX+1.0) * rand());
- /* fprintf(stderr, signature = 0x%08X\n, signature); */
-
- FontShmdescIndex = AllocateFontPrivateIndex();
-
-#if !defined(CSRG_BASED) !defined(__CYGWIN__)
- pagesize = SHMLBA;
-#else
-# ifdef _SC_PAGESIZE
- pagesize = sysconf(_SC_PAGESIZE);
-# else
- pagesize = getpagesize();
-# endif
-#endif
-#endif
-}
-}
-
-
/* == Management of shared memory segments == */
#ifdef HAS_SHM
@@ -749,3 +704,47 @@ SProcXF86BigfontDispatch(
return BadRequest;
}
}
+
+void
+XFree86BigfontExtensionInit(void)
+{
+if (AddExtension(XF86BIGFONTNAME,
+XF86BigfontNumberEvents,
+XF86BigfontNumberErrors,
+ProcXF86BigfontDispatch,
+SProcXF86BigfontDispatch,
+XF86BigfontResetProc,
+StandardMinorOpcode)) {
+#ifdef HAS_SHM
+#ifdef MUST_CHECK_FOR_SHM_SYSCALL
+ /*
+* Note: Local-clients will not be optimized without shared memory
+* support. Remote-client optimization does not depend on shared
+* memory support. Thus, the extension is still registered even
+* when shared memory support is not functional.
+*/
+ if (!CheckForShmSyscall()) {
+ ErrorF(XF86BIGFONTNAME extension local-client optimization
disabled due to lack of shared memory support in the kernel\n);
+ return;
+ }
+#endif
+
+ srand((unsigned int) time(NULL));
+ signature = ((unsigned int) (65536.0/(RAND_MAX+1.0) * rand()) 16)
+ + (unsigned int) (65536.0/(RAND_MAX+1.0) * rand());
+ /* fprintf(stderr, signature = 0x%08X\n, signature); */
+
+ FontShmdescIndex = AllocateFontPrivateIndex();
+
+#if !defined(CSRG_BASED) !defined(__CYGWIN__)
+ pagesize = SHMLBA;
+#else
+# ifdef _SC_PAGESIZE
+ pagesize = sysconf(_SC_PAGESIZE);
+# else
+ pagesize = getpagesize();
+# endif
+#endif
+#endif
+}
+}
--
1.7.3.3
___
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] Fix compilation of xf86bigfont.c
On Wed, Jan 19, 2011 at 16:06:28 +, Jon TURNEY wrote: xf86bigfont.c: In function 'XFree86BigfontExtensionInit': xf86bigfont.c:146: error: 'ProcXF86BigfontDispatch' undeclared (first use in this function) xf86bigfont.c:147: error: 'SProcXF86BigfontDispatch' undeclared (first use in this function) It seems this has been broken since commit cbd4d5dbb70db62ba1cb79c7b904e6fa11f62d7e delete pervasively use of DISPATCH_PROC (2010-09-28), which is a bit worrying as that presumably indicates that no tinderbox is configuring with --enable-xf86bigfont. In a similar fashion to that commit, fix by moving XFree86BigfontExtensionInit() below the definitions of the static dispatch functions is references. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- Xext/xf86bigfont.c | 89 +-- 1 files changed, 44 insertions(+), 45 deletions(-) Reviewed-by: Julien Cristau jcris...@debian.org Cheers, Julien ___ 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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa/exa_migration_mixed.c
@@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
RegionPtr pRegion, void *closure)
if (!pExaPixmap-use_gpu_copy exaPixmapHasGpuCopy(pPixmap)) {
ExaScreenPriv(pPixmap-drawable.pScreen);
- /* Front buffer: Don't wait for the block handler to copy back the
data.
- * This avoids annoying latency if you encounter a lot of software
rendering.
+ /* Front buffer: Don't wait for the block handler to copy back the
data, unless
+ * it has been moved back in the last 10 ms. This avoid annoying
latency when
+ * troughput is low, but keeps troughput acceptable at higher levels.
*/
- if (pPixmap == pScreen-GetScreenPixmap(pScreen))
- exaMoveInPixmap_mixed(pPixmap);
- else {
+ if (pPixmap == pScreen-GetScreenPixmap(pScreen)) {
+ CARD32 now = GetTimeInMillis();
+ if ((now - pExaScr-last_time_front_mixed_pixmap) 10) {
+ pExaScr-last_time_front_mixed_pixmap = now;
+ exaMoveInPixmap_mixed(pPixmap);
+
+ if (pExaScr-deferred_mixed_pixmap == pPixmap)
+ pExaScr-deferred_mixed_pixmap = NULL;
+ } else {
+ if (pExaScr-deferred_mixed_pixmap
+ pExaScr-deferred_mixed_pixmap != pPixmap)
+
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
+
+ pExaScr-deferred_mixed_pixmap = pPixmap;
+ }
+ } else {
if (pExaScr-deferred_mixed_pixmap
pExaScr-deferred_mixed_pixmap != pPixmap)
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
I still can't help wondering if we aren't missing something about what
makes the difference between the text being 'shown' or not[0], but this
approach would be getting rather complicated already, and if there's no
timeout period which gives a better tradeoff between latency and
throughput, I guess erring on the side of the former is better for now.
So, feel free to add my
One experiment would be to do a exaMoveInPixmap_mixed when (let's say)
10% of the screen becomes dirty, but this is even more complicated.
But I'm willing to try if you think it's a good idea.
Reviewed-by: Michel Dänzer mic...@daenzer.net
to your patch 3/3, and thanks for taking the time to get more
information.
[0] E.g., maybe the larger number of UploadToScreen operations results
in the driver flushing commands to the GPU more often?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
On Mit, 2011-01-19 at 18:29 +0100, Maarten Maathuis wrote:
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa/exa_migration_mixed.c
@@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
RegionPtr pRegion, void *closure)
if (!pExaPixmap-use_gpu_copy exaPixmapHasGpuCopy(pPixmap)) {
ExaScreenPriv(pPixmap-drawable.pScreen);
- /* Front buffer: Don't wait for the block handler to copy back the
data.
- * This avoids annoying latency if you encounter a lot of software
rendering.
+ /* Front buffer: Don't wait for the block handler to copy back the
data, unless
+ * it has been moved back in the last 10 ms. This avoid annoying
latency when
+ * troughput is low, but keeps troughput acceptable at higher levels.
*/
- if (pPixmap == pScreen-GetScreenPixmap(pScreen))
- exaMoveInPixmap_mixed(pPixmap);
- else {
+ if (pPixmap == pScreen-GetScreenPixmap(pScreen)) {
+ CARD32 now = GetTimeInMillis();
+ if ((now - pExaScr-last_time_front_mixed_pixmap) 10) {
+ pExaScr-last_time_front_mixed_pixmap = now;
+ exaMoveInPixmap_mixed(pPixmap);
+
+ if (pExaScr-deferred_mixed_pixmap == pPixmap)
+ pExaScr-deferred_mixed_pixmap = NULL;
+ } else {
+ if (pExaScr-deferred_mixed_pixmap
+ pExaScr-deferred_mixed_pixmap != pPixmap)
+
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
+
+ pExaScr-deferred_mixed_pixmap = pPixmap;
+ }
+ } else {
if (pExaScr-deferred_mixed_pixmap
pExaScr-deferred_mixed_pixmap != pPixmap)
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
I still can't help wondering if we aren't missing something about what
makes the difference between the text being 'shown' or not[0], but this
approach would be getting rather complicated already, and if there's no
timeout period which gives a better tradeoff between latency and
throughput, I guess erring on the side of the former is better for now.
So, feel free to add my
One experiment would be to do a exaMoveInPixmap_mixed when (let's say)
10% of the screen becomes dirty, but this is even more complicated.
But I'm willing to try if you think it's a good idea.
I don't think it is. If latency is really the issue, the timeout period
approach seems most appropriate.
--
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 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 18:29 +0100, Maarten Maathuis wrote:
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa/exa_migration_mixed.c
@@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
RegionPtr pRegion, void *closure)
if (!pExaPixmap-use_gpu_copy exaPixmapHasGpuCopy(pPixmap)) {
ExaScreenPriv(pPixmap-drawable.pScreen);
- /* Front buffer: Don't wait for the block handler to copy back the
data.
- * This avoids annoying latency if you encounter a lot of software
rendering.
+ /* Front buffer: Don't wait for the block handler to copy back the
data, unless
+ * it has been moved back in the last 10 ms. This avoid annoying
latency when
+ * troughput is low, but keeps troughput acceptable at higher
levels.
*/
- if (pPixmap == pScreen-GetScreenPixmap(pScreen))
- exaMoveInPixmap_mixed(pPixmap);
- else {
+ if (pPixmap == pScreen-GetScreenPixmap(pScreen)) {
+ CARD32 now = GetTimeInMillis();
+ if ((now - pExaScr-last_time_front_mixed_pixmap) 10) {
+ pExaScr-last_time_front_mixed_pixmap = now;
+ exaMoveInPixmap_mixed(pPixmap);
+
+ if (pExaScr-deferred_mixed_pixmap == pPixmap)
+ pExaScr-deferred_mixed_pixmap = NULL;
+ } else {
+ if (pExaScr-deferred_mixed_pixmap
+ pExaScr-deferred_mixed_pixmap != pPixmap)
+
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
+
+ pExaScr-deferred_mixed_pixmap = pPixmap;
+ }
+ } else {
if (pExaScr-deferred_mixed_pixmap
pExaScr-deferred_mixed_pixmap != pPixmap)
exaMoveInPixmap_mixed(pExaScr-deferred_mixed_pixmap);
I still can't help wondering if we aren't missing something about what
makes the difference between the text being 'shown' or not[0], but this
approach would be getting rather complicated already, and if there's no
timeout period which gives a better tradeoff between latency and
throughput, I guess erring on the side of the former is better for now.
So, feel free to add my
One experiment would be to do a exaMoveInPixmap_mixed when (let's say)
10% of the screen becomes dirty, but this is even more complicated.
But I'm willing to try if you think it's a good idea.
I don't think it is. If latency is really the issue, the timeout period
approach seems most appropriate.
I just remembered that nouveau will do UTS by pushing data into the
command stream at small sizes and using gart to vram transfers
otherwise. Might have to look into that (not that you want to push
very large amounts of data into the command stream all the time).
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls AC_PROG_C_C99. This sets gcc with -std=gnu99. If AC_PROG_CC macro is called afterwards, it resets CC to gcc. Signed-off-by: Roberto Branciforti rbb...@gmail.com --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index f35eb91..6ef023a 100644 --- a/configure.ac +++ b/configure.ac @@ -43,7 +43,7 @@ XORG_DEFAULT_OPTIONS AM_CONFIG_HEADER(config.h) # checks for progs -AC_PROG_CC +#AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_SED -- 1.6.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 xf86-input-acecad] Fix type for default options.
InputDriverRec's default_options is char **, without const. Also,
declare it static, it's not used outside this file.
Fix build failure with CFLAGS=-Wall -Werror:
| CC acecad.lo
| cc1: warnings being treated as errors
| acecad.c:132: error: initialization from incompatible pointer type
Signed-off-by: Cyril Brulebois k...@debian.org
---
src/acecad.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
I know it's not really maintained, but oh well, two-minute fix…
diff --git a/src/acecad.c b/src/acecad.c
index 6259f21..c5e1611 100644
--- a/src/acecad.c
+++ b/src/acecad.c
@@ -106,7 +106,7 @@
/* max number of input events to read in one read call */
#define MAX_EVENTS 50
-static const char *default_options[] =
+char *default_options[] =
{
BaudRate, 9600,
StopBits, 1,
--
1.7.2.3
___
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] Remove libc wrappers for malloc, realloc and free.
Signed-off-by: Cyril Brulebois k...@debian.org
---
src/aticonfig.c |2 +-
src/aticonsole.c | 10
src/atidga.c |2 +-
src/atidri.c | 54 +-
src/atii2c.c |8 +++---
src/atimach64exa.c |2 +-
src/atimach64i2c.c |2 +-
src/atimach64probe.c |4 +-
src/atimach64xv.c|8 +++---
src/atimode.c|2 +-
src/atipreinit.c |2 +-
src/atiscreen.c |8 +++---
12 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/src/aticonfig.c b/src/aticonfig.c
index 9102497..621e79e 100644
--- a/src/aticonfig.c
+++ b/src/aticonfig.c
@@ -502,5 +502,5 @@ ATIProcessOptions
#endif
}
-xfree(PublicOption);
+free(PublicOption);
}
diff --git a/src/aticonsole.c b/src/aticonsole.c
index 6e742d9..50cc6e1 100644
--- a/src/aticonsole.c
+++ b/src/aticonsole.c
@@ -799,19 +799,19 @@ ATIFreeScreen
#ifndef AVOID_CPIO
-xfree(pATI-OldHW.frame_buffer);
-xfree(pATI-NewHW.frame_buffer);
+free(pATI-OldHW.frame_buffer);
+free(pATI-NewHW.frame_buffer);
#endif /* AVOID_CPIO */
-xfree(pATI-pShadow);
+free(pATI-pShadow);
#ifndef AVOID_DGA
-xfree(pATI-pDGAMode);
+free(pATI-pDGAMode);
#endif /* AVOID_DGA */
-xfree(pATI);
+free(pATI);
pScreenInfo-driverPrivate = NULL;
}
diff --git a/src/atidga.c b/src/atidga.c
index fb6d1d7..c1cd163 100644
--- a/src/atidga.c
+++ b/src/atidga.c
@@ -324,7 +324,7 @@ ATIDGAAddModes
if ((modePitch * bitsPerPixel * pMode-VDisplay) = videoBits)
{
/* Stop generating modes on out-of-memory conditions */
-pDGAMode = xrealloc(pATI-pDGAMode,
+pDGAMode = realloc(pATI-pDGAMode,
(pATI-nDGAMode + 1) * SizeOf(DGAModeRec));
if (!pDGAMode)
break;
diff --git a/src/atidri.c b/src/atidri.c
index 15d0014..9c6719b 100644
--- a/src/atidri.c
+++ b/src/atidri.c
@@ -109,14 +109,14 @@ static Bool ATIInitVisualConfigs( ScreenPtr pScreen )
pATIConfigs = (ATIConfigPrivPtr)
xnfcalloc( sizeof(ATIConfigPrivRec), numConfigs );
if ( !pATIConfigs ) {
-xfree( pConfigs );
+free( pConfigs );
return FALSE;
}
pATIConfigPtrs = (ATIConfigPrivPtr*)
xnfcalloc( sizeof(ATIConfigPrivPtr), numConfigs );
if ( !pATIConfigPtrs ) {
-xfree( pConfigs );
-xfree( pATIConfigs );
+free( pConfigs );
+free( pATIConfigs );
return FALSE;
}
@@ -190,14 +190,14 @@ static Bool ATIInitVisualConfigs( ScreenPtr pScreen )
pATIConfigs = (ATIConfigPrivPtr)
xnfcalloc( sizeof(ATIConfigPrivRec), numConfigs );
if ( !pATIConfigs ) {
-xfree( pConfigs );
+free( pConfigs );
return FALSE;
}
pATIConfigPtrs = (ATIConfigPrivPtr*)
xnfcalloc( sizeof(ATIConfigPrivPtr), numConfigs );
if ( !pATIConfigPtrs ) {
-xfree( pConfigs );
-xfree( pATIConfigs );
+free( pConfigs );
+free( pATIConfigs );
return FALSE;
}
@@ -553,11 +553,11 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
if (nbox 1) {
/* Keep ordering in each band, reverse order of bands */
- pboxNew1 = (BoxPtr)xalloc(sizeof(BoxRec)*nbox);
+ pboxNew1 = (BoxPtr)malloc(sizeof(BoxRec)*nbox);
if (!pboxNew1) return;
- pptNew1 = (DDXPointPtr)xalloc(sizeof(DDXPointRec)*nbox);
+ pptNew1 = (DDXPointPtr)malloc(sizeof(DDXPointRec)*nbox);
if (!pptNew1) {
- xfree(pboxNew1);
+ free(pboxNew1);
return;
}
pboxBase = pboxNext = pbox+nbox-1;
@@ -588,13 +588,13 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
if (nbox 1) {
/* reverse order of rects in each band */
- pboxNew2 = (BoxPtr)xalloc(sizeof(BoxRec)*nbox);
- pptNew2 = (DDXPointPtr)xalloc(sizeof(DDXPointRec)*nbox);
+ pboxNew2 = (BoxPtr)malloc(sizeof(BoxRec)*nbox);
+ pptNew2 = (DDXPointPtr)malloc(sizeof(DDXPointRec)*nbox);
if (!pboxNew2 || !pptNew2) {
- xfree(pptNew2);
- xfree(pboxNew2);
- xfree(pptNew1);
- xfree(pboxNew1);
+ free(pptNew2);
+ free(pboxNew2);
+ free(pptNew1);
+ free(pboxNew1);
return;
}
pboxBase = pboxNext = pbox;
@@ -665,10 +665,10 @@ static void ATIDRIMoveBuffers( WindowPtr pWin,
DDXPointRec ptOldOrg,
outf(SRC_OFF_PITCH, pATI-NewHW.dst_off_pitch);
outf(DST_OFF_PITCH, pATI-NewHW.src_off_pitch);
-xfree(pptNew2);
-xfree(pboxNew2);
-xfree(pptNew1);
-xfree(pboxNew1);
+free(pptNew2);
+free(pboxNew2);
+free(pptNew1);
+
[PATCH xf86-input-acecad v2] Fix type for default options.
InputDriverRec's default_options is char **, without const.
Fix build failure with CFLAGS=-Wall -Werror:
| CC acecad.lo
| cc1: warnings being treated as errors
| acecad.c:132: error: initialization from incompatible pointer type
Signed-off-by: Cyril Brulebois k...@debian.org
---
src/acecad.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Got confused while git stashing, the previous patch had static non-sense.
diff --git a/src/acecad.c b/src/acecad.c
index 6259f21..844141c 100644
--- a/src/acecad.c
+++ b/src/acecad.c
@@ -106,7 +106,7 @@
/* max number of input events to read in one read call */
#define MAX_EVENTS 50
-static const char *default_options[] =
+static char *default_options[] =
{
BaudRate, 9600,
StopBits, 1,
--
1.7.2.3
___
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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, Jan 19, 2011 at 11:53 AM, Roberto Branciforti rbb...@gmail.com wrote: XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls AC_PROG_C_C99. This sets gcc with -std=gnu99. If AC_PROG_CC macro is called afterwards, it resets CC to gcc. Signed-off-by: Roberto Branciforti rbb...@gmail.com --- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index f35eb91..6ef023a 100644 --- a/configure.ac +++ b/configure.ac @@ -43,7 +43,7 @@ XORG_DEFAULT_OPTIONS AM_CONFIG_HEADER(config.h) # checks for progs -AC_PROG_CC +#AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_SED This seems like more of a problem with the macros. I don't know why XORG_STRICT_OPTION doesn't just AC_REQUIRE AC_PROG_CC so that we don't get these kinds of issues. However, for this particular case I think it would be better if we just moved the XORG_DEFAULT_OPTIONS call below AC_PROG_CC. If we comment or remove AC_PROG_CC, then it becomes really unclear that we're getting it implicitly through XORG_DEFAULT_OPTIONS. -- Dan ___ 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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, 2011-01-19 at 12:51 -0800, Dan Nicholson wrote: This seems like more of a problem with the macros. I don't know why XORG_STRICT_OPTION doesn't just AC_REQUIRE AC_PROG_CC so that we don't get these kinds of issues. I have not found a way to avoid these issues. The last call wins. If C99 is invoked before AC_REQUIRE C89, C89 will win simply because it is not C99. They don't know about each other, even if some of the work they do is cached and reused by the other. However, for this particular case I think it would be better if we just moved the XORG_DEFAULT_OPTIONS call below AC_PROG_CC. The statements become order sensitive, which is hard to maintain, even when commented. The day will come where there will be a dead lock. If we comment or remove AC_PROG_CC, then it becomes really unclear that we're getting it implicitly through XORG_DEFAULT_OPTIONS. This is also true for any macro that is being invoked from XORG_DEFAULT_OPTIONS. The XORG_STRICT_OPTION was intended to enforce C99 by virtue of inclusion in configure.ac. It ceased to be optional once it got included in XORG_DEFAULT_OPTIONS. Other comments from reviewers so far indicate there is no objections to C99, with some pros and cons. The reason why AC_PROG_CC are removed is for the module to be compiled C99. If we find something better to do, it should be applied to all 240 modules, unless there is a reason to configure the modules with different compiler levels. To find out which version it is compiled with: grep ^CC= `find . -name config.log -type f -print` For a C99: CC='gcc -std=gnu99' signature.asc Description: This is a digitally signed message part ___ 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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, 2011-01-19 at 20:53 +0100, Roberto Branciforti wrote: XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls AC_PROG_C_C99. This sets gcc with -std=gnu99. If AC_PROG_CC macro is called afterwards, it resets CC to gcc. Signed-off-by: Roberto Branciforti rbb...@gmail.com --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index f35eb91..6ef023a 100644 --- a/configure.ac +++ b/configure.ac @@ -43,7 +43,7 @@ XORG_DEFAULT_OPTIONS AM_CONFIG_HEADER(config.h) # checks for progs -AC_PROG_CC +#AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_SED Reviewed-by: Gaetan Nadon mems...@videotron.ca Dan has some reservations, you may want to wait a bit. Feel free to verify my assertions, it's been a while since I tested these things. signature.asc Description: This is a digitally signed message part ___ 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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On 01/19/11 11:53 AM, Roberto Branciforti wrote: XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls AC_PROG_C_C99. This sets gcc with -std=gnu99. If AC_PROG_CC macro is called afterwards, it resets CC to gcc. Signed-off-by: Roberto Branciforti rbb...@gmail.com --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index f35eb91..6ef023a 100644 --- a/configure.ac +++ b/configure.ac @@ -43,7 +43,7 @@ XORG_DEFAULT_OPTIONS AM_CONFIG_HEADER(config.h) # checks for progs -AC_PROG_CC +#AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_SED We've been removing them completely in the other modules we've finished this in, not just commenting them out. -- -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: [PATCH xinput 0/3] Add different formats for --list option
On Wed, Jan 19, 2011 at 11:50:54AM +0100, Dirk Wallenstein wrote: On Tue, Jan 18, 2011 at 01:08:57PM +1000, Peter Hutterer wrote: When using XI2, the output of xinput list shows the device hierarchy including attachment, device type and a few others. This is useful for humans but hard to parse for scripts who usually only care about a device name or about the device ID. Add two more flags to xinput list to display name or id only. Cheers, Peter The new options are missing in the help output. With that addition For the series (all 4 of 3): Reviewed-by: Dirk Wallenstein hals...@t-online.de Tested-by: Dirk Wallenstein hals...@t-online.de added the help output and pushed, thanks. 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 inputproto] Add touch classes and events, bump to 2.1
On Fri, Jan 07, 2011 at 04:02:09PM +, Daniel Stone wrote: +∙ Driver DRV provides touch support from tracked device D: +⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for + each axis available on the device. +⊳ DRV parses D's device protocol and selects one touch sequence to be + emulated as pointer event. +⊳ DRV calls the respective input driver API with the touch sequence + data. The touch sequence emulating a pointer has the respective flag + set. DRV does not submit pointer data for any touchpoint. I was under the impression that the driver would be handling pointer events and touch events separately. This wording sounds like the server handles pointer emulation internally based on touch data. The current MT code in evdev has separate processing, so which way are we going with this? Honestly? I don't know. I'd be inclined to say that it'd be more robust to do it in the server, so we can get a better association between the touch and related pointer events, but certainly the trend in the kernel has been to post ABS_[XY] events as well as the MT events, so I'm not really sure. do pointer emulation for touch events in the server. be that through calling GPE from GetTouchEvents or other means. kernel-specifics such as ABS_X being posted in parallel with ABS_MT_POSITION_X should be filtered in the driver. 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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, Jan 19, 2011 at 1:25 PM, Gaetan Nadon mems...@videotron.ca wrote: On Wed, 2011-01-19 at 12:51 -0800, Dan Nicholson wrote: This seems like more of a problem with the macros. I don't know why XORG_STRICT_OPTION doesn't just AC_REQUIRE AC_PROG_CC so that we don't get these kinds of issues. I have not found a way to avoid these issues. The last call wins. If C99 is invoked before AC_REQUIRE C89, C89 will win simply because it is not C99. They don't know about each other, even if some of the work they do is cached and reused by the other. However, for this particular case I think it would be better if we just moved the XORG_DEFAULT_OPTIONS call below AC_PROG_CC. The statements become order sensitive, which is hard to maintain, even when commented. The day will come where there will be a dead lock. If we comment or remove AC_PROG_CC, then it becomes really unclear that we're getting it implicitly through XORG_DEFAULT_OPTIONS. This is also true for any macro that is being invoked from XORG_DEFAULT_OPTIONS. The XORG_STRICT_OPTION was intended to enforce C99 by virtue of inclusion in configure.ac. It ceased to be optional once it got included in XORG_DEFAULT_OPTIONS. Other comments from reviewers so far indicate there is no objections to C99, with some pros and cons. The reason why AC_PROG_CC are removed is for the module to be compiled C99. If we find something better to do, it should be applied to all 240 modules, unless there is a reason to configure the modules with different compiler levels. And if we later remove XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS (which isn't a crazy suggestion), then there is nothing calling AC_PROG_CC*. That's why I was suggesting to just move the XORG_DEFAULT_OPTIONS call later so that the original call is still there and it's not some implicit thing buried in another macro. To find out which version it is compiled with: grep ^CC= `find . -name config.log -type f -print` For a C99: CC='gcc -std=gnu99' We want to try to ensure that we get C99 if XORG_STRICT_OPTION is used. So, if we AC_REQUIRE([AC_PROG_CC]) before AC_REQUIRE([AC_PROG_CC_C99]) in XORG_STRICT_OPTION, then it should ensure the ordering, right? Or can you just keep calling them and the last one wins? I haven't checked. -- Dan ___ 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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wed, 19 Jan 2011, Dan Nicholson wrote: We want to try to ensure that we get C99 if XORG_STRICT_OPTION is used. So, if we AC_REQUIRE([AC_PROG_CC]) before AC_REQUIRE([AC_PROG_CC_C99]) in XORG_STRICT_OPTION, then it should ensure the ordering, right? Or can you just keep calling them and the last one wins? I haven't checked. AC_REQUIRE doesn't ensure any specific ordering, and has the additional drawback that the requisitioned macros may be substituted in a non-intuitive location relative to the call. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ 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 libXaw] Scrollbar.c: Add Btn4 Btn5 to default translations
Add default translations to handle mouse wheel events for moving the scrollbar. Signed-off-by: Roberto Branciforti rbb...@gmail.com --- src/Scrollbar.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/Scrollbar.c b/src/Scrollbar.c index 894a945..5e4fdcf 100644 --- a/src/Scrollbar.c +++ b/src/Scrollbar.c @@ -102,6 +102,8 @@ static char defaultTranslations[] = Btn1Down: StartScroll(Forward)\n Btn2Down: StartScroll(Continuous) MoveThumb() NotifyThumb()\n Btn3Down: StartScroll(Backward)\n +Btn4Down: StartScroll(Backward)\n +Btn5Down: StartScroll(Forward)\n Btn2Motion:MoveThumb() NotifyThumb()\n BtnUp: NotifyScroll(Proportional) EndScroll()\n; -- 1.6.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 2/2] libXft: remove AC_PROG_CC as it overrides AC_PROG_C_C99
On Wednesday 19 January 2011 22:33:35 Gaetan Nadon wrote: On Wed, 2011-01-19 at 20:53 +0100, Roberto Branciforti wrote: XORG_STRICT_OPTION from XORG_DEFAULT_OPTIONS calls AC_PROG_C_C99. This sets gcc with -std=gnu99. If AC_PROG_CC macro is called afterwards, it resets CC to gcc. Signed-off-by: Roberto Branciforti rbb...@gmail.com ... Reviewed-by: Gaetan Nadon mems...@videotron.ca Dan has some reservations, you may want to wait a bit. Feel free to verify my assertions, it's been a while since I tested these things. I'm not an autotool/m4 expert but I'll be happy to enable the --enable- strict-compilation without ends in an error for a valid C99 code. Roberto. ___ 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 v3 1/6] xf86/xv: Remove copy paste code.
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
xf86XVFillKeyHelperDrawable can be used to implement
xf86XVFillKeyHelper.
V2:
* Remove RegionTranslate that clobbered parameter region.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xv.c | 68 +++
1 files changed, 11 insertions(+), 57 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 016db1f..f1a87f1 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -1869,62 +1869,10 @@ xf86XVQueryImageAttributes(
format-id, width, height, pitches, offsets);
}
-
void
xf86XVFillKeyHelperDrawable (DrawablePtr pDraw, CARD32 key, RegionPtr
clipboxes)
{
ScreenPtr pScreen = pDraw-pScreen;
- WindowPtr pWin = (WindowPtr)pDraw;
- XF86XVWindowPtr pPriv = GET_XF86XV_WINDOW(pWin);
- GCPtr pGC = NULL;
- BoxPtr pbox = RegionRects(clipboxes);
- int i, nbox = RegionNumRects(clipboxes);
- xRectangle *rects;
-
- if(!xf86Screens[pScreen-myNum]-vtSema) return;
-
- if(pPriv)
- pGC = pPriv-pGC;
-
- if(!pGC) {
- int status;
- XID pval[2];
- pval[0] = key;
- pval[1] = IncludeInferiors;
- pGC = CreateGC(pDraw, GCForeground | GCSubwindowMode, pval, status,
- (XID)0, serverClient);
- if(!pGC) return;
- ValidateGC(pDraw, pGC);
- if (pPriv) pPriv-pGC = pGC;
- } else if (key != pGC-fgPixel){
- ChangeGCVal val;
- val.val = key;
- ChangeGC(NullClient, pGC, GCForeground, val);
- ValidateGC(pDraw, pGC);
- }
-
- RegionTranslate(clipboxes, -pDraw-x, -pDraw-y);
-
- rects = malloc(nbox * sizeof(xRectangle));
-
- for(i = 0; i nbox; i++, pbox++) {
- rects[i].x = pbox-x1;
- rects[i].y = pbox-y1;
- rects[i].width = pbox-x2 - pbox-x1;
- rects[i].height = pbox-y2 - pbox-y1;
- }
-
- (*pGC-ops-PolyFillRect)(pDraw, pGC, nbox, rects);
-
- if (!pPriv) FreeGC(pGC, 0);
-
- free(rects);
-}
-
-void
-xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key, RegionPtr clipboxes)
-{
- DrawablePtr root = pScreen-root-drawable;
ChangeGCVal pval[2];
BoxPtr pbox = RegionRects(clipboxes);
int i, nbox = RegionNumRects(clipboxes);
@@ -1933,28 +1881,34 @@ xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key,
RegionPtr clipboxes)
if(!xf86Screens[pScreen-myNum]-vtSema) return;
- gc = GetScratchGC(root-depth, pScreen);
+ gc = GetScratchGC(pDraw-depth, pScreen);
pval[0].val = key;
pval[1].val = IncludeInferiors;
(void) ChangeGC(NullClient, gc, GCForeground|GCSubwindowMode, pval);
- ValidateGC(root, gc);
+ ValidateGC(pDraw, gc);
rects = malloc(nbox * sizeof(xRectangle));
for(i = 0; i nbox; i++, pbox++)
{
- rects[i].x = pbox-x1;
- rects[i].y = pbox-y1;
+ rects[i].x = pbox-x1 - pDraw-x;
+ rects[i].y = pbox-y1 - pDraw-y;
rects[i].width = pbox-x2 - pbox-x1;
rects[i].height = pbox-y2 - pbox-y1;
}
- (*gc-ops-PolyFillRect)(root, gc, nbox, rects);
+ (*gc-ops-PolyFillRect)(pDraw, gc, nbox, rects);
free(rects);
FreeScratchGC (gc);
}
+void
+xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key, RegionPtr clipboxes)
+{
+xf86XVFillKeyHelperDrawable (pScreen-root-drawable, key, clipboxes);
+}
+
/* xf86XVClipVideoHelper -
Takes the dst box in standard X BoxRec form (top and left
--
1.7.0.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 v3 2/6] xf86/xv: Remove unused GC pointers
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xv.c | 10 --
hw/xfree86/common/xf86xvpriv.h |2 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index f1a87f1..6dcd497 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -280,8 +280,6 @@ xf86XVScreenInit(
pScrn = xf86Screens[pScreen-myNum];
- ScreenPriv-videoGC = NULL; /* for the helper */
-
ScreenPriv-DestroyWindow = pScreen-DestroyWindow;
ScreenPriv-WindowExposures = pScreen-WindowExposures;
ScreenPriv-ClipNotify = pScreen-ClipNotify;
@@ -1123,9 +1121,6 @@ xf86XVDestroyWindow(WindowPtr pWin)
pPriv-pDraw = NULL;
tmp = WinPriv;
- if(WinPriv-pGC) {
- FreeGC(WinPriv-pGC, 0);
- }
WinPriv = WinPriv-next;
free(tmp);
}
@@ -1232,11 +1227,6 @@ xf86XVCloseScreen(int i, ScreenPtr pScreen)
if(!ScreenPriv) return TRUE;
- if(ScreenPriv-videoGC) {
- FreeGC(ScreenPriv-videoGC, 0);
- ScreenPriv-videoGC = NULL;
- }
-
pScreen-DestroyWindow = ScreenPriv-DestroyWindow;
pScreen-WindowExposures = ScreenPriv-WindowExposures;
pScreen-ClipNotify = ScreenPriv-ClipNotify;
diff --git a/hw/xfree86/common/xf86xvpriv.h b/hw/xfree86/common/xf86xvpriv.h
index 88e7a0e..c667926 100644
--- a/hw/xfree86/common/xf86xvpriv.h
+++ b/hw/xfree86/common/xf86xvpriv.h
@@ -43,7 +43,6 @@ typedef struct {
void (*AdjustFrame)(int, int, int, int);
Bool (*EnterVT)(int, int);
void (*LeaveVT)(int, int);
- GCPtr videoGC;
xf86ModeSetProc *ModeSet;
} XF86XVScreenRec, *XF86XVScreenPtr;
@@ -82,7 +81,6 @@ typedef struct {
typedef struct _XF86XVWindowRec{
XvPortRecPrivatePtr PortRec;
struct _XF86XVWindowRec *next;
- GCPtr pGC;
} XF86XVWindowRec, *XF86XVWindowPtr;
#endif /* _XF86XVPRIV_H_ */
--
1.7.0.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 v3 3/6] xf86/xv: Remove unused variable from XvPortRecPrivate
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xvpriv.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86xvpriv.h b/hw/xfree86/common/xf86xvpriv.h
index c667926..4572218 100644
--- a/hw/xfree86/common/xf86xvpriv.h
+++ b/hw/xfree86/common/xf86xvpriv.h
@@ -72,7 +72,6 @@ typedef struct {
Bool FreeCompositeClip;
XvAdaptorRecPrivatePtr AdaptorRec;
XvStatus isOn;
- Bool moved;
int vid_x, vid_y, vid_w, vid_h;
int drw_x, drw_y, drw_w, drw_h;
DevUnion DevPriv;
--
1.7.0.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 v3 4/6] xf86/xv: Fill color key on expose
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
If window gets exposed but clipboxes doesn't change drivers would avoid
color key fill. This makes XResizeWindoco to lose colorkey if
background is painted.
To help drivers to avoid filling colorkey for each put server can
provide helper function if there is exposed areas. Server can subtract
exposed areas from filled region.
As a side effect we can avoid useless color key fills if window only
moves in screen without background fills.
v3:
* Change tracking to filled area to account for client initiated clip
changes
* Make overlaid XvPutImage behavior like textured XvPutImage or PutImage
* Make region dynamically allocated only when required.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xv.c | 66
hw/xfree86/common/xf86xv.h |7 +++-
hw/xfree86/common/xf86xvpriv.h |1 +
3 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 6dcd497..3960940 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -331,6 +331,8 @@ xf86XVFreeAdaptor(XvAdaptorPtr pAdaptor)
RegionDestroy(pPriv-clientClip);
if(pPriv-pCompositeClip pPriv-FreeCompositeClip)
RegionDestroy(pPriv-pCompositeClip);
+if (pPriv-ckeyFilled)
+ RegionDestroy(pPriv-ckeyFilled);
free(pPriv);
}
}
@@ -1016,7 +1018,6 @@ static void
xf86XVRemovePortFromWindow(WindowPtr pWin, XvPortRecPrivatePtr portPriv)
{
XF86XVWindowPtr winPriv, prevPriv = NULL;
-
winPriv = GET_XF86XV_WINDOW(pWin);
while(winPriv) {
@@ -1033,6 +1034,10 @@ xf86XVRemovePortFromWindow(WindowPtr pWin,
XvPortRecPrivatePtr portPriv)
winPriv = winPriv-next;
}
portPriv-pDraw = NULL;
+ if (portPriv-ckeyFilled) {
+ RegionDestroy(portPriv-ckeyFilled);
+ portPriv-ckeyFilled = NULL;
+ }
}
static void
@@ -1165,6 +1170,21 @@ xf86XVWindowExposures(WindowPtr pWin, RegionPtr reg1,
RegionPtr reg2)
if (!pPriv-type !pPriv-AdaptorRec-ReputImage)
visible = !AreasExposed;
+ /*
+ * Subtract exposed areas from overlaid image to match textured video
+ * behavior.
+ */
+ if (!pPriv-type pPriv-clientClip)
+ RegionSubtract(pPriv-clientClip, pPriv-clientClip, reg1);
+
+ if (visible pPriv-ckeyFilled) {
+RegionRec tmp;
+RegionNull(tmp);
+RegionCopy(tmp, reg1);
+RegionTranslate(tmp, pWin-drawable.x, pWin-drawable.y);
+RegionSubtract(pPriv-ckeyFilled, pPriv-ckeyFilled, tmp);
+ }
+
WinPriv = WinPriv-next;
xf86XVReputOrStopPort(pPriv, pWin, visible);
}
@@ -1859,13 +1879,47 @@ xf86XVQueryImageAttributes(
format-id, width, height, pitches, offsets);
}
+Bool
+xf86XVGetPortFillArea (DrawablePtr pDraw, pointer data, RegionPtr clipboxes,
RegionPtr fillboxes)
+{
+WindowPtr pWin = (WindowPtr)pDraw;
+XF86XVWindowPtr WinPriv = GET_XF86XV_WINDOW(pWin);
+XvPortRecPrivatePtr portPriv = NULL;
+
+while (WinPriv) {
+ XvPortRecPrivatePtr pPriv = WinPriv-PortRec;
+
+ if (data == pPriv-DevPriv.ptr) {
+ portPriv = pPriv;
+ break;
+ }
+
+ WinPriv = WinPriv-next;
+}
+
+if (!portPriv)
+ return FALSE;
+
+if (!portPriv-ckeyFilled)
+ portPriv-ckeyFilled = RegionCreate(NULL, 0);
+
+RegionSubtract(fillboxes, clipboxes, portPriv-ckeyFilled);
+
+if (!RegionNotEmpty(fillboxes))
+ return FALSE;
+
+RegionCopy(portPriv-ckeyFilled, clipboxes);
+
+return TRUE;
+}
+
void
-xf86XVFillKeyHelperDrawable (DrawablePtr pDraw, CARD32 key, RegionPtr
clipboxes)
+xf86XVFillKeyHelperDrawable (DrawablePtr pDraw, CARD32 key, RegionPtr
fillboxes)
{
ScreenPtr pScreen = pDraw-pScreen;
ChangeGCVal pval[2];
- BoxPtr pbox = RegionRects(clipboxes);
- int i, nbox = RegionNumRects(clipboxes);
+ BoxPtr pbox = RegionRects(fillboxes);
+ int i, nbox = RegionNumRects(fillboxes);
xRectangle *rects;
GCPtr gc;
@@ -1894,9 +1948,9 @@ xf86XVFillKeyHelperDrawable (DrawablePtr pDraw, CARD32
key, RegionPtr clipboxes)
}
void
-xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key, RegionPtr clipboxes)
+xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key, RegionPtr fillboxes)
{
-xf86XVFillKeyHelperDrawable (pScreen-root-drawable, key, clipboxes);
+xf86XVFillKeyHelperDrawable (pScreen-root-drawable, key, fillboxes);
}
/* xf86XVClipVideoHelper -
diff --git a/hw/xfree86/common/xf86xv.h b/hw/xfree86/common/xf86xv.h
index 47061fe..3243ccc 100644
--- a/hw/xfree86/common/xf86xv.h
+++ b/hw/xfree86/common/xf86xv.h
@@ -239,10 +239,13 @@ extern _X_EXPORT XF86VideoAdaptorPtr
xf86XVAllocateVideoAdaptorRec(ScrnInfoPtr p
extern _X_EXPORT void xf86XVFreeVideoAdaptorRec(XF86VideoAdaptorPtr ptr);
extern _X_EXPORT void
[PATCH v3 5/6] xf86/xv: Use PostValidateTree to do reput
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
ValidateTree calls first ClipNotify and later might call
WindowExposures. To avoid useless double reput ClipNotify delays reput
to WindowExposures or PostValidateTree.
PostValidatTree checks all ports if there is clip changes. On clip
changes reput is done to move or scale the overlay.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xv.c | 54 +--
hw/xfree86/common/xf86xvpriv.h |2 +
2 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 3960940..7d77e43 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -97,6 +97,7 @@ static int xf86XVQueryImageAttributes(ClientPtr, XvPortPtr,
XvImagePtr,
static Bool xf86XVDestroyWindow(WindowPtr pWin);
static void xf86XVWindowExposures(WindowPtr pWin, RegionPtr r1, RegionPtr r2);
+static void xf86XVPostValidateTree(WindowPtr pWin, WindowPtr pLayerWin, VTKind
kind);
static void xf86XVClipNotify(WindowPtr pWin, int dx, int dy);
/* ScrnInfoRec functions */
@@ -282,6 +283,7 @@ xf86XVScreenInit(
ScreenPriv-DestroyWindow = pScreen-DestroyWindow;
ScreenPriv-WindowExposures = pScreen-WindowExposures;
+ ScreenPriv-PostValidateTree = pScreen-PostValidateTree;
ScreenPriv-ClipNotify = pScreen-ClipNotify;
ScreenPriv-EnterVT = pScrn-EnterVT;
ScreenPriv-LeaveVT = pScrn-LeaveVT;
@@ -290,6 +292,7 @@ xf86XVScreenInit(
pScreen-DestroyWindow = xf86XVDestroyWindow;
pScreen-WindowExposures = xf86XVWindowExposures;
+ pScreen-PostValidateTree = xf86XVPostValidateTree;
pScreen-ClipNotify = xf86XVClipNotify;
pScrn-EnterVT = xf86XVEnterVT;
pScrn-LeaveVT = xf86XVLeaveVT;
@@ -1038,6 +1041,7 @@ xf86XVRemovePortFromWindow(WindowPtr pWin,
XvPortRecPrivatePtr portPriv)
RegionDestroy(portPriv-ckeyFilled);
portPriv-ckeyFilled = NULL;
}
+ portPriv-clipChanged = FALSE;
}
static void
@@ -1072,7 +1076,7 @@ xf86XVReputOrStopPort(XvPortRecPrivatePtr pPriv,
}
static void
-xf86XVReputOrStopAllPorts(ScrnInfoPtr pScrn)
+xf86XVReputOrStopAllPorts(ScrnInfoPtr pScrn, Bool onlyChanged)
{
ScreenPtr pScreen = pScrn-pScreen;
XvScreenPtr pxvs = GET_XV_SCREEN(pScreen);
@@ -1090,6 +1094,9 @@ xf86XVReputOrStopAllPorts(ScrnInfoPtr pScrn)
if (pPriv-isOn == XV_OFF || !pWin)
continue;
+ if (onlyChanged !pPriv-clipChanged)
+ continue;
+
visible = pWin-visibility == VisibilityUnobscured ||
pWin-visibility == VisibilityPartiallyObscured;
@@ -1101,6 +1108,8 @@ xf86XVReputOrStopAllPorts(ScrnInfoPtr pScrn)
visible = FALSE;
xf86XVReputOrStopPort(pPriv, pWin, visible);
+
+ pPriv-clipChanged = FALSE;
}
}
}
@@ -1139,6 +1148,30 @@ xf86XVDestroyWindow(WindowPtr pWin)
return ret;
}
+static void
+xf86XVPostValidateTree(WindowPtr pWin, WindowPtr pLayerWin, VTKind kind)
+{
+ScreenPtr pScreen;
+XF86XVScreenPtr ScreenPriv;
+ScrnInfoPtr pScrn;
+
+if (pWin)
+ pScreen = pWin-drawable.pScreen;
+else
+ pScreen = pLayerWin-drawable.pScreen;
+
+ScreenPriv = GET_XF86XV_SCREEN(pScreen);
+pScrn = xf86Screens[pScreen-myNum];
+
+xf86XVReputOrStopAllPorts(pScrn, TRUE);
+
+if (ScreenPriv-PostValidateTree) {
+ pScreen-PostValidateTree = ScreenPriv-PostValidateTree;
+ (*pScreen-PostValidateTree)(pWin, pLayerWin, kind);
+ ScreenPriv-PostValidateTree = pScreen-PostValidateTree;
+ pScreen-PostValidateTree = xf86XVPostValidateTree;
+}
+}
static void
xf86XVWindowExposures(WindowPtr pWin, RegionPtr reg1, RegionPtr reg2)
@@ -1187,10 +1220,11 @@ xf86XVWindowExposures(WindowPtr pWin, RegionPtr reg1,
RegionPtr reg2)
WinPriv = WinPriv-next;
xf86XVReputOrStopPort(pPriv, pWin, visible);
+
+ pPriv-clipChanged = FALSE;
}
}
-
static void
xf86XVClipNotify(WindowPtr pWin, int dx, int dy)
{
@@ -1200,9 +1234,6 @@ xf86XVClipNotify(WindowPtr pWin, int dx, int dy)
XvPortRecPrivatePtr pPriv;
while(WinPriv) {
- Bool visible = pWin-visibility == VisibilityUnobscured ||
- pWin-visibility == VisibilityPartiallyObscured;
-
pPriv = WinPriv-PortRec;
if(pPriv-pCompositeClip pPriv-FreeCompositeClip)
@@ -1214,15 +1245,9 @@ xf86XVClipNotify(WindowPtr pWin, int dx, int dy)
(*pPriv-AdaptorRec-ClipNotify)(pPriv-pScrn, pPriv-DevPriv.ptr,
pWin, dx, dy);
- /*
- * Stop and remove still/images if
- * ReputImage isn't supported.
- */
- if (!pPriv-type !pPriv-AdaptorRec-ReputImage)
- visible = FALSE;
+ pPriv-clipChanged = TRUE;
WinPriv = WinPriv-next;
- xf86XVReputOrStopPort(pPriv, pWin, visible);
}
if(ScreenPriv-ClipNotify) {
@@ -1249,6 +1274,7 @@ xf86XVCloseScreen(int i, ScreenPtr
[PATCH v3 6/6] xf86/xv: Only register PostValidateTree hook when there is work to do
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
If none of Xv ports were affected by window tree modifications we don't
want scan the port list. To avoid useless scanning of port list
PostValidateTree hook is only registered when ClipNotify was called for
any port.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/common/xf86xv.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 7d77e43..a9dde4d 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -100,6 +100,8 @@ static void xf86XVWindowExposures(WindowPtr pWin, RegionPtr
r1, RegionPtr r2);
static void xf86XVPostValidateTree(WindowPtr pWin, WindowPtr pLayerWin, VTKind
kind);
static void xf86XVClipNotify(WindowPtr pWin, int dx, int dy);
+#define PostValidateTreeUndefined ((PostValidateTreeProcPtr)-1)
+
/* ScrnInfoRec functions */
static Bool xf86XVEnterVT(int, int);
@@ -283,7 +285,7 @@ xf86XVScreenInit(
ScreenPriv-DestroyWindow = pScreen-DestroyWindow;
ScreenPriv-WindowExposures = pScreen-WindowExposures;
- ScreenPriv-PostValidateTree = pScreen-PostValidateTree;
+ ScreenPriv-PostValidateTree = PostValidateTreeUndefined;
ScreenPriv-ClipNotify = pScreen-ClipNotify;
ScreenPriv-EnterVT = pScrn-EnterVT;
ScreenPriv-LeaveVT = pScrn-LeaveVT;
@@ -292,7 +294,6 @@ xf86XVScreenInit(
pScreen-DestroyWindow = xf86XVDestroyWindow;
pScreen-WindowExposures = xf86XVWindowExposures;
- pScreen-PostValidateTree = xf86XVPostValidateTree;
pScreen-ClipNotify = xf86XVClipNotify;
pScrn-EnterVT = xf86XVEnterVT;
pScrn-LeaveVT = xf86XVLeaveVT;
@@ -1165,12 +1166,11 @@ xf86XVPostValidateTree(WindowPtr pWin, WindowPtr
pLayerWin, VTKind kind)
xf86XVReputOrStopAllPorts(pScrn, TRUE);
-if (ScreenPriv-PostValidateTree) {
- pScreen-PostValidateTree = ScreenPriv-PostValidateTree;
+pScreen-PostValidateTree = ScreenPriv-PostValidateTree;
+if (pScreen-PostValidateTree) {
(*pScreen-PostValidateTree)(pWin, pLayerWin, kind);
- ScreenPriv-PostValidateTree = pScreen-PostValidateTree;
- pScreen-PostValidateTree = xf86XVPostValidateTree;
}
+ScreenPriv-PostValidateTree = PostValidateTreeUndefined;
}
static void
@@ -1247,6 +1247,11 @@ xf86XVClipNotify(WindowPtr pWin, int dx, int dy)
pPriv-clipChanged = TRUE;
+ if (ScreenPriv-PostValidateTree == PostValidateTreeUndefined) {
+ScreenPriv-PostValidateTree = pScreen-PostValidateTree;
+pScreen-PostValidateTree = xf86XVPostValidateTree;
+ }
+
WinPriv = WinPriv-next;
}
@@ -1274,7 +1279,6 @@ xf86XVCloseScreen(int i, ScreenPtr pScreen)
pScreen-DestroyWindow = ScreenPriv-DestroyWindow;
pScreen-WindowExposures = ScreenPriv-WindowExposures;
- pScreen-PostValidateTree = ScreenPriv-PostValidateTree;
pScreen-ClipNotify = ScreenPriv-ClipNotify;
pScrn-EnterVT = ScreenPriv-EnterVT;
--
1.7.0.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 inputproto] Add touch classes and events, bump to 2.1
On Thu, Jan 20, 2011 at 07:52:54AM +1000, Peter Hutterer wrote: On Fri, Jan 07, 2011 at 04:02:09PM +, Daniel Stone wrote: I was under the impression that the driver would be handling pointer events and touch events separately. This wording sounds like the server handles pointer emulation internally based on touch data. The current MT code in evdev has separate processing, so which way are we going with this? Honestly? I don't know. I'd be inclined to say that it'd be more robust to do it in the server, so we can get a better association between the touch and related pointer events, but certainly the trend in the kernel has been to post ABS_[XY] events as well as the MT events, so I'm not really sure. do pointer emulation for touch events in the server. be that through calling GPE from GetTouchEvents or other means. Yeah, that's what we've come around to. More on that soon. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH (v5) 0/15] Multitouch take five
Hi all, Another round of multitouch patches ... this lot addresses all the review comments from the previous patchset, and seems to work quite reliably and consistently for me. It's a fairly large change, but the code is now a fair bit easier to understand and verify. After discussion with Chase, I removed[0] the TouchOwner flag and split TouchMotion into separate TouchMotion and TouchMotionUnowned events, as well as introducing a new TouchOwnership event which indicates that the receiver now owns the event. This involved a fairly large-scale change within the server to introduce the TouchOwnership event, but now means that all changes to the delivery list happen only in ProcessTouchOwnershipEvent. As a result, it seems we're a lot better about correctly sending TouchEnd events, et al: the main goal of this round was to ensure that every single client gets a TouchEnd event in every case, after the last touch event has been sent to it. Chase is currently working on defining pointer emulation semantics, and seems to have arrived at a workable solution. This will involve changing XIAllowTouchEvents to have three modes instead of two: accept, reject, and emulate pointer events. The idea is that pointer emulation doesn't happen by default, but only when a grab owner explicitly requests it, or it is the only touch currently active for that device, and there are no more applicable grabs or selections. Once a touch was set to pointer emulation, it would never return any touch events, and would only generate pointer events. He's going to work on that while I'm away at LCA and on holiday in Melbourne for a week after that, so I expect there will be a v6 in about three weeks. For now though, the volume of changes seemed to make v5 a sensible idea, even though it's not yet finalised. (That and the fact that testing will be fairly difficult while I'm away, so this patchset is at least known to work.) I've only attached the patches that Peter hasn't yet merged into his for-keith branch, but as always, the full set can be found at: git://people.freedesktop.org/~daniels/inputproto:multitouch-v5 git://people.freedesktop.org/~daniels/libXi:multitouch-v5 git://people.freedesktop.org/~daniels/xserver:multitouch-v5 git://people.freedesktop.org/~daniels/xf86-input-evdev:multitouch-v5 git://people.freedesktop.org/~daniels/xinput:multitouch-v5 I'll be doing development in the 'multitouch' branches of the above, so feel free to pull if you're curious, but don't necessarily expect it to be perfect. :) Again, evdev doesn't work with the Magic Mouse due to lacking the mixed abs/rel valuators patch, which I'll probably look at on the plane. If you hear of a Cathay Pacific flight crashing between London and Melbourne this weekend, then using Bluetooth on a flight was a bad idea. Cheers, Daniel [0]: It's not quite gone from the source yet - this will happen in v6 - and we don't currently send an XITouchOwnership event to the owner on TouchBegin. But, baby steps. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH (v5) inputproto 1/1] Add touch classes and events, bump to 2.1
Introduce multitouch support through a new TouchClass, as well as new
TouchBegin, TouchEnd and TouchMotion events. Bump to version 2.1.
Signed-off-by: Daniel Stone dan...@fooishbar.org
Co-authored-by: Chase Douglas chase.doug...@canonical.com
Co-authored-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
v5: Introduce separate TouchMotionUnowned and TouchOwnership events.
Elaborate a little on usecases.
XI2.h| 33 +-
XI2proto.h | 65 +-
XI2proto.txt | 395 --
configure.ac |2 +-
4 files changed, 479 insertions(+), 16 deletions(-)
diff --git a/XI2.h b/XI2.h
index 6ba1377..3f4d2c3 100644
--- a/XI2.h
+++ b/XI2.h
@@ -36,6 +36,7 @@
#define XI_2_Major 2
#define XI_2_Minor 0
+#define XI_2_1_Minor1
/* Property event flags */
#define XIPropertyDeleted 0
@@ -65,6 +66,7 @@
#define XIGrabtypeKeycode 1
#define XIGrabtypeEnter 2
#define XIGrabtypeFocusIn 3
+#define XIGrabtypeTouchBegin4
/* Passive grab modifier */
#define XIAnyModifier (1U 31)
@@ -79,6 +81,11 @@
#define XIAsyncPair 4
#define XISyncPair 5
+/* XIAllowTouchEvents bitmask event-modes */
+#define XITouchOwnerAccept (1 0)
+#define XITouchOwnerReject (1 1)
+#define XITouchNoPointerEmulation (1 2)
+
/* DeviceChangedEvent change reasons */
#define XISlaveSwitch 1
#define XIDeviceChange 2
@@ -113,15 +120,27 @@
#define XISlaveKeyboard 4
#define XIFloatingSlave 5
-/* Device classes */
+/* Device classes: classes that are not identical to Xi 1.x classes must be
+ * numbered starting from 8. */
#define XIKeyClass 0
#define XIButtonClass 1
#define XIValuatorClass 2
+#define XITouchClass8
+#define XITouchValuatorClass9
/* Device event flags (common) */
/* Device event flags (key events only) */
#define XIKeyRepeat (1 16)
/* Device event flags (pointer events only) */
+#define XITouchPointer (1 16)
+/* Device event flags (touch events only) */
+#define XITouchOwner(1 16)
+#define XITouchOwnerAccepted(1 17)
+#define XITouchPendingFinish(1 18)
+
+/* Touch modes */
+#define XIDirectTouch 1
+#define XIDependentTouch2
/* XI2 event mask macros */
#define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)3] |= (1
((event) 7)))
@@ -151,7 +170,12 @@
#define XI_RawButtonPress15
#define XI_RawButtonRelease 16
#define XI_RawMotion 17
-#define XI_LASTEVENT XI_RawMotion
+#define XI_TouchBegin18
+#define XI_TouchEnd 19
+#define XI_TouchOwnership20
+#define XI_TouchMotion 21
+#define XI_TouchMotionUnowned22
+#define XI_LASTEVENT XI_TouchMotionUnowned
/* 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. */
@@ -177,5 +201,10 @@
#define XI_RawButtonPressMask(1 XI_RawButtonPress)
#define XI_RawButtonReleaseMask (1 XI_RawButtonRelease)
#define XI_RawMotionMask (1 XI_RawMotion)
+#define XI_TouchBeginMask(1 XI_TouchBegin)
+#define XI_TouchEndMask (1 XI_TouchEnd)
+#define XI_TouchOwnershipChangedMask (1 XI_TouchOwnershipChanged)
+#define XI_TouchMotionMask (1 XI_TouchMotion)
+#define XI_TouchMotionUnownedMask(1 XI_TouchMotionUnowned)
#endif /* _XI2_H_ */
diff --git a/XI2proto.h b/XI2proto.h
index 84574a5..6a5280c 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -92,9 +92,10 @@
#define X_XIDeleteProperty 58
#define X_XIGetProperty 59
#define X_XIGetSelectedEvents 60
+#define X_XIAllowTouchEvents61
/** Number of XI requests */
-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
+#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1)
/** Number of XI2 events */
#define XI2EVENTS (XI_LASTEVENT + 1)
@@ -188,6 +189,31 @@ typedef struct {
uint16_tpad2;
} xXIValuatorInfo;
+/**
+ * Denotes multitouch capability on a device.
+ */
+typedef struct {
+uint16_ttype; /**
[PATCH (v5) libXi 1/1] Add multitouch support from Xi 2.1
Add support to libXi for touch events.
Signed-off-by: Daniel Stone dan...@fooishbar.org
Co-authored-by: Chase Douglas chase.doug...@canonical.com
---
v5: Added support for new TouchMotionUnowned and TouchOwnership events.
Fix a CopyCookie buglet where touch events wouldn't get copied at all.
configure.ac |4 +-
include/X11/extensions/XInput2.h | 60 +
src/XExtInt.c| 108 +-
src/XIAllowEvents.c | 24
src/XIPassiveGrab.c | 21 +++
5 files changed, 213 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0a4b384..173537a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT(libXi, 1.4.0,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXi)
+AC_INIT(libXi, 1.4.99.1,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXi)
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
@@ -24,7 +24,7 @@ AC_PROG_LIBTOOL
AC_PROG_SED
# Checks for pkg-config packages
-PKG_CHECK_MODULES(XI, [xproto = 7.0.13] [x11 = 1.2.99.1] [xextproto =
7.0.3] [xext = 1.0.99.1] [inputproto = 1.9.99.902])
+PKG_CHECK_MODULES(XI, [xproto = 7.0.13] [x11 = 1.2.99.1] [xextproto =
7.0.3] [xext = 1.0.99.1] [inputproto = 2.0.99.1])
# Check for xmlto and asciidoc for man page conversion
# (only needed by people building tarballs)
diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h
index e6c7b30..46b0162 100644
--- a/include/X11/extensions/XInput2.h
+++ b/include/X11/extensions/XInput2.h
@@ -135,6 +135,25 @@ typedef struct
typedef struct
{
+int type;
+int sourceid;
+int mode;
+int num_touches;
+} XITouchClassInfo;
+
+typedef struct
+{
+int type;
+int sourceid;
+int number;
+Atom label;
+double min;
+double max;
+int resolution;
+} XITouchValuatorClassInfo;
+
+typedef struct
+{
int deviceid;
char*name;
int use;
@@ -292,6 +311,21 @@ typedef struct {
int what;
} XIPropertyEvent;
+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;
+unsigned long touchid;
+int reason;
+unsigned long flags;
+} XITouchOwnershipEvent;
+
_XFUNCPROTOBEGIN
extern Bool XIQueryPointer(
@@ -415,6 +449,13 @@ extern Status XIAllowEvents(
Timetime
);
+extern Status XIAllowTouchEvents(
+Display*display,
+int deviceid,
+unsigned long touchid,
+int event_mode
+);
+
extern int XIGrabButton(
Display*display,
int deviceid,
@@ -466,6 +507,17 @@ extern int XIGrabFocusIn(
int num_modifiers,
XIGrabModifiers *modifiers_inout
);
+
+extern int XIGrabTouchBegin(
+Display*display,
+int deviceid,
+Window grab_window,
+int owner_events,
+XIEventMask *mask,
+int num_modifiers,
+XIGrabModifiers *modifiers_inout
+);
+
extern Status XIUngrabButton(
Display*display,
int deviceid,
@@ -500,6 +552,14 @@ extern Status XIUngrabFocusIn(
XIGrabModifiers *modifiers
);
+extern Status XIUngrabTouchBegin(
+Display*display,
+int deviceid,
+Window grab_window,
+int num_modifiers,
+XIGrabModifiers *modifiers
+);
+
extern Atom *XIListProperties(
Display*display,
diff --git a/src/XExtInt.c b/src/XExtInt.c
index f96e3ff..055bdf5 100644
--- a/src/XExtInt.c
+++ b/src/XExtInt.c
@@ -146,6 +146,9 @@ static int
wireToEnterLeave(xXIEnterEvent *in, XGenericEventCookie *cookie);
static int
wireToPropertyEvent(xXIPropertyEvent *in, XGenericEventCookie *cookie);
+static int
+wireToTouchOwnershipEvent(xXITouchOwnershipEvent *in,
+ XGenericEventCookie *cookie);
static /* const */ XEvent emptyevent;
@@ -268,7 +271,8 @@ static XExtensionVersion versions[] = { {XI_Absent, 0, 0},
XI_Add_DevicePresenceNotify_Minor},
{XI_Present, XI_Add_DeviceProperties_Major,
XI_Add_DeviceProperties_Minor},
-{XI_Present, XI_2_Major, XI_2_Minor}
+{XI_Present, XI_2_Major, XI_2_Minor},
+{XI_Present, XI_2_Major,
[PATCH (v5) xserver 1/8] Input: Add DeepestSpriteWin macro
Does what it says on the box: returns the deepest child window in a
given sprite's trace.
Signed-off-by: Daniel Stone dan...@fooishbar.org
---
v5: New.
dix/events.c |4 ++--
include/inputstr.h |3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 07f8b05..5f8ce39 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2174,7 +2174,7 @@ MaybeDeliverEventsToClient(WindowPtr pWin, xEvent
*pEvents,
static Window FindChildForEvent(SpritePtr pSprite, WindowPtr event)
{
-WindowPtr w = pSprite-spriteTrace[pSprite-spriteTraceGood-1];
+WindowPtr w = DeepestSpriteWin(pSprite);
Window child = None;
/* If the search ends up past the root should the child field be
@@ -2591,7 +2591,7 @@ XYToWindow(SpritePtr pSprite, int x, int y)
else
pWin = pWin-nextSib;
}
-return pSprite-spriteTrace[pSprite-spriteTraceGood-1];
+return DeepestSpriteWin(pSprite);
}
/**
diff --git a/include/inputstr.h b/include/inputstr.h
index b74ee04..8291577 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -244,6 +244,9 @@ typedef struct _SpriteRec {
} SpriteRec;
+#define DeepestSpriteWin(sprite) \
+((sprite)-spriteTrace[(sprite)-spriteTraceGood - 1])
+
typedef struct _KeyClassRec {
intsourceid;
CARD8 down[DOWN_LENGTH];
--
1.7.2.3
___
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 (v5) xserver 5/8] Input: Reorder AxisInfo elements
From: Chase Douglas chase.doug...@canonical.com
Reorder elements so they can be uniform with the upcoming TouchAxisInfo
elements required for coordinate scaling.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Daniel Stone dan...@fooishbar.org
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
v5: No changes.
include/inputstr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/inputstr.h b/include/inputstr.h
index 8291577..a19b9a9 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -257,11 +257,11 @@ typedef struct _KeyClassRec {
typedef struct _AxisInfo {
intresolution;
-intmin_resolution;
-intmax_resolution;
intmin_value;
intmax_value;
Atom label;
+intmin_resolution;
+intmax_resolution;
CARD8 mode;
} AxisInfo, *AxisInfoPtr;
--
1.7.2.3
___
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 (v5) xserver 2/8] Input: Make CheckPassiveGrabsOnWindow take InternalEvent
Previously, it only took DeviceEvents, but it would be much more useful
if it took InternalEvents. Any event that activates a grab must still
be a DeviceEvent, so put in a check to enforce this. Also fix a tiny
(but harmless) buglet where we would allocate too much space for the
frozen event.
Change all callers to make the appropriate casts.
Signed-off-by: Daniel Stone dan...@fooishbar.org
---
v5: New.
dix/events.c | 76 +++--
include/dix.h |2 +-
2 files changed, 53 insertions(+), 25 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 5f8ce39..dfe938b 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2629,7 +2629,8 @@ ActivateFocusInGrab(DeviceIntPtr dev, WindowPtr old,
WindowPtr win)
event.deviceid = dev-id;
event.sourceid = dev-id;
event.detail.button = 0;
-rc = (CheckPassiveGrabsOnWindow(win, dev, event, FALSE, TRUE) != NULL);
+rc = (CheckPassiveGrabsOnWindow(win, dev, (InternalEvent *) event, FALSE,
+TRUE) != NULL);
if (rc)
DoEnterLeaveEvents(dev, dev-id, old, win, XINotifyPassiveUngrab);
return rc;
@@ -2666,7 +2667,8 @@ ActivateEnterGrab(DeviceIntPtr dev, WindowPtr old,
WindowPtr win)
event.deviceid = dev-id;
event.sourceid = dev-id;
event.detail.button = 0;
-rc = (CheckPassiveGrabsOnWindow(win, dev, event, FALSE, TRUE) != NULL);
+rc = (CheckPassiveGrabsOnWindow(win, dev, (InternalEvent *) event, FALSE,
+TRUE) != NULL);
if (rc)
DoEnterLeaveEvents(dev, dev-id, old, win, XINotifyPassiveGrab);
return rc;
@@ -3353,7 +3355,7 @@ GrabPtr
CheckPassiveGrabsOnWindow(
WindowPtr pWin,
DeviceIntPtr device,
-DeviceEvent *event,
+InternalEvent *event,
BOOL checkCore,
BOOL activate)
{
@@ -3370,9 +3372,22 @@ CheckPassiveGrabsOnWindow(
return NULL;
/* Fill out the grab details, but leave the type for later before
* comparing */
+switch (event-any.type)
+{
+case ET_KeyPress:
+case ET_KeyRelease:
+tempGrab.detail.exact = event-device_event.detail.key;
+break;
+case ET_ButtonPress:
+case ET_ButtonRelease:
+tempGrab.detail.exact = event-device_event.detail.button;
+break;
+default:
+tempGrab.detail.exact = 0;
+break;
+}
tempGrab.window = pWin;
tempGrab.device = device;
-tempGrab.detail.exact = event-detail.key;
tempGrab.detail.pMask = NULL;
tempGrab.modifiersDetail.pMask = NULL;
tempGrab.next = NULL;
@@ -3380,6 +3395,9 @@ CheckPassiveGrabsOnWindow(
{
DeviceIntPtrgdev;
XkbSrvInfoPtr xkbi = NULL;
+ int rc, count = 0;
+ xEvent *xE = NULL;
+ xEvent core;
gdev= grab-modifierDevice;
if (grab-grabtype == GRABTYPE_CORE)
@@ -3405,16 +3423,15 @@ CheckPassiveGrabsOnWindow(
tempGrab.modifiersDetail.exact = xkbi ? xkbi-state.grab_mods : 0;
/* Check for XI2 and XI grabs first */
-tempGrab.type = GetXI2Type((InternalEvent*)event);
+tempGrab.type = GetXI2Type(event);
tempGrab.grabtype = GRABTYPE_XI2;
if (GrabMatchesSecond(tempGrab, grab, FALSE))
match = XI2_MATCH;
-tempGrab.detail.exact = event-detail.key;
if (!match)
{
tempGrab.grabtype = GRABTYPE_XI;
-if ((tempGrab.type = GetXIType((InternalEvent*)event))
+if ((tempGrab.type = GetXIType(event))
(GrabMatchesSecond(tempGrab, grab, FALSE)))
match = XI_MATCH;
}
@@ -3423,7 +3440,7 @@ CheckPassiveGrabsOnWindow(
if (!match checkCore)
{
tempGrab.grabtype = GRABTYPE_CORE;
-if ((tempGrab.type = GetCoreType((InternalEvent*)event))
+if ((tempGrab.type = GetCoreType(event))
(GrabMatchesSecond(tempGrab, grab, TRUE)))
match = CORE_MATCH;
}
@@ -3432,12 +3449,6 @@ CheckPassiveGrabsOnWindow(
(grab-confineTo-realized
BorderSizeNotEmpty(device, grab-confineTo
{
-int rc, count = 0;
-xEvent *xE = NULL;
-xEvent core;
-
-event-corestate = 0x1f00;
-event-corestate |= tempGrab.modifiersDetail.exact (~0x1f00);
grabinfo = device-deviceGrab;
/* In some cases a passive core grab may exist, but the client
* already has a core grab on some other device. In this case we
@@ -3483,38 +3494,53 @@ CheckPassiveGrabsOnWindow(
if (!activate)
return grab;
+else if (!GetXIType(event) !GetCoreType(event))
+FatalError(Event type %d in CheckPassiveGrabsOnWindow is
+neither XI 1.x nor core\n, event-any.type);
+
+/* The only consumers of corestate are Xi 1.x
[PATCH (v5) xserver 6/8] Input: Add flags to DeviceEvent
Add a flags member which will be copied wholesale into the resultant xXIDeviceEvent. Signed-off-by: Daniel Stone dan...@fooishbar.org Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Chase Douglas chase.doug...@canonical.com --- v5: No changes. dix/eventconvert.c |1 + include/eventstr.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/dix/eventconvert.c b/dix/eventconvert.c index 7b894f0..76d9a3e 100644 --- a/dix/eventconvert.c +++ b/dix/eventconvert.c @@ -576,6 +576,7 @@ eventToDeviceEvent(DeviceEvent *ev, xEvent **xi) xde-root_x = FP1616(ev-root_x, ev-root_x_frac); xde-root_y = FP1616(ev-root_y, ev-root_y_frac); +xde-flags = ev-flags; if (ev-key_repeat) xde-flags |= XIKeyRepeat; diff --git a/include/eventstr.h b/include/eventstr.h index 377cceb..e1f5003 100644 --- a/include/eventstr.h +++ b/include/eventstr.h @@ -117,6 +117,7 @@ struct _DeviceEvent Window root; /** Root window of the event */ int corestate;/** Core key/button state BEFORE the event */ int key_repeat; /** Internally-generated key repeat event */ +uint32_t flags; /** Flags to be copied into the generated event */ }; -- 1.7.2.3 ___ 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 (v5) xserver 4/8] Input: Bump input major ABI for multitouch
Signed-off-by: Daniel Stone dan...@fooishbar.org
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Chase Douglas chase.doug...@canonical.com
---
v5: No changes.
hw/xfree86/common/xf86Module.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
index 609819b..5c159fa 100644
--- a/hw/xfree86/common/xf86Module.h
+++ b/hw/xfree86/common/xf86Module.h
@@ -83,7 +83,7 @@ typedef enum {
*/
#define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4)
#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(9, 0)
-#define ABI_XINPUT_VERSION SET_ABI_VERSION(12, 1)
+#define ABI_XINPUT_VERSION SET_ABI_VERSION(13, 0)
#define ABI_EXTENSION_VERSION SET_ABI_VERSION(5, 0)
#define ABI_FONT_VERSION SET_ABI_VERSION(0, 6)
--
1.7.2.3
___
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 8/8] Test: Input: Add touch tests
Add tests for:
* checking basic functionality of BeginTouchPoint,
FindTouchPoint*, and EndTouchPoint
* ensuring all touch event types match each other in
GrabMatchesSecond
* ensuring all touch events are selected together, or not at all, in
XISelectEvents (this test authored by Chase Douglas)
* ensuring EventToXI2 is predictable between runs
* validating TouchBegin, TouchMotion, TouchMotionUnowned, TouchEnd,
and TouchOwnership protocol conversion
Signed-off-by: Daniel Stone dan...@fooishbar.org
Reviewed-by: Chase Douglas chase.doug...@canonical.com
---
v5: Added tests for TouchMotionUnowned and TouchOwnership as well.
Make BeginTouchPoint/FindTouchPoint*/EndTouchPoint tests slightly more
comprehensive.
test/input.c | 169 +++-
test/xi2/protocol-eventconvert.c | 114 -
test/xi2/protocol-xiselectevents.c | 64 ++
3 files changed, 345 insertions(+), 2 deletions(-)
diff --git a/test/input.c b/test/input.c
index 879e14f..21b4c8d 100644
--- a/test/input.c
+++ b/test/input.c
@@ -277,6 +277,11 @@ static void dix_event_to_core_conversion(void)
dix_event_to_core_fail(ET_ProximityOut + 1, BadImplementation);
dix_event_to_core_fail(ET_ProximityIn, BadMatch);
dix_event_to_core_fail(ET_ProximityOut, BadMatch);
+dix_event_to_core_fail(ET_TouchBegin, BadMatch);
+dix_event_to_core_fail(ET_TouchMotion, BadMatch);
+dix_event_to_core_fail(ET_TouchMotionUnowned, BadMatch);
+dix_event_to_core_fail(ET_TouchOwnership, BadMatch);
+dix_event_to_core_fail(ET_TouchEnd, BadMatch);
dix_event_to_core(ET_KeyPress);
dix_event_to_core(ET_KeyRelease);
@@ -285,6 +290,34 @@ static void dix_event_to_core_conversion(void)
dix_event_to_core(ET_Motion);
}
+static void dix_event_to_xi2_conversion(void)
+{
+DeviceEvent ev;
+xXIDeviceEvent *xi2, *xi2_flags;
+int rc;
+
+memset(ev, 0, sizeof(ev));
+
+ev.header = 0xFF;
+ev.length = sizeof(DeviceEvent);
+ev.type = ET_TouchBegin;
+
+rc = EventToXI2((InternalEvent*)ev, (xEvent**)xi2);
+g_assert(rc == Success);
+g_assert(xi2-type == GenericEvent);
+g_assert(xi2-evtype == XI_TouchBegin);
+g_assert(xi2-flags == 0);
+
+ev.flags= XITouchOwner;
+rc = EventToXI2((InternalEvent*)ev, (xEvent**)xi2_flags);
+g_assert(rc == Success);
+g_assert(xi2_flags-type == GenericEvent);
+g_assert(xi2_flags-evtype == XI_TouchBegin);
+g_assert(xi2_flags-flags == XITouchOwner);
+xi2_flags-flags = 0;
+g_assert(memcmp(xi2, xi2_flags, sizeof(*xi2)) == 0);
+}
+
static void xi2_struct_sizes(void)
{
#define compare(req) \
@@ -674,6 +707,38 @@ static void dix_grab_matching(void)
g_assert(rc == TRUE);
rc = GrabMatchesSecond(b, a, FALSE);
g_assert(rc == TRUE);
+
+/* All touch grabs must match a TouchBegin grab. */
+a.grabtype = GRABTYPE_XI2;
+b.grabtype = GRABTYPE_XI2;
+a.type = XI_TouchBegin;
+b.type = XI_TouchMotion;
+a.detail.exact = 0;
+b.detail.exact = 0;
+a.modifiersDetail.exact = 0;
+b.modifiersDetail.exact = 0;
+rc = GrabMatchesSecond(a, b, FALSE);
+g_assert(rc == TRUE);
+rc = GrabMatchesSecond(b, a, FALSE);
+g_assert(rc == TRUE);
+
+b.type = XI_TouchMotionUnowned;
+rc = GrabMatchesSecond(a, b, FALSE);
+g_assert(rc == TRUE);
+rc = GrabMatchesSecond(b, a, FALSE);
+g_assert(rc == TRUE);
+
+b.type = XI_TouchOwnership;
+rc = GrabMatchesSecond(a, b, FALSE);
+g_assert(rc == TRUE);
+rc = GrabMatchesSecond(b, a, FALSE);
+g_assert(rc == TRUE);
+
+b.type = XI_TouchEnd;
+rc = GrabMatchesSecond(a, b, FALSE);
+g_assert(rc == TRUE);
+rc = GrabMatchesSecond(b, a, FALSE);
+g_assert(rc == TRUE);
}
static void test_bits_to_byte(int i)
@@ -1061,6 +1126,105 @@ static void include_bit_test_macros(void)
}
}
+static void touch_create(void)
+{
+DeviceIntRec dev;
+TouchClassRec touch;
+TouchPointInfoRec touches[2];
+TouchPointInfoPtr ti;
+
+memset(dev, 0, sizeof(dev));
+memset(touch, 0, sizeof(touch));
+memset(touches, 0, sizeof(*touches) * 2);
+touch.touches = touches;
+touch.num_touches = 2;
+touch.num_axes = 2;
+touch.next_client_id = 1;
+dev.touch = touch;
+
+/* Make sure we get a valid touchpoint back. */
+ti = BeginTouchPoint(dev, 0xdeadbeef);
+g_assert(ti);
+g_assert(ti-active == TRUE);
+g_assert(ti-ddx_id == 0xdeadbeef);
+g_assert(ti-client_id != 0);
+g_assert(ti-pending_finish == 0);
+g_assert(ti-num_listeners == 0);
+g_assert(ti-num_grabs == 0);
+g_assert(ti-sprite.spriteTraceGood == 0);
+}
+
+static void touch_find_point(void)
+{
+DeviceIntRec dev;
+TouchClassRec touch;
+TouchPointInfoRec touches[2];
+TouchPointInfoPtr create_ret, find_ret;
+
+memset(dev, 0, sizeof(dev));
+
[PATCH (v5) xserver 3/8] Input: Simply CheckPassiveGrabsOnWindow loop
Instead of a mega never-ending if branch with no else, just continue
to the next iteration of the loop if the conditions aren't met - pretty
much entirely reindentation.
Signed-off-by: Daniel Stone dan...@fooishbar.org
---
v5: New.
dix/events.c | 209 -
1 files changed, 103 insertions(+), 106 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index dfe938b..38e9a08 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3445,129 +3445,126 @@ CheckPassiveGrabsOnWindow(
match = CORE_MATCH;
}
-if (match (!grab-confineTo ||
-(grab-confineTo-realized
- BorderSizeNotEmpty(device, grab-confineTo
- {
-grabinfo = device-deviceGrab;
-/* In some cases a passive core grab may exist, but the client
- * already has a core grab on some other device. In this case we
- * must not get the grab, otherwise we may never ungrab the
- * device.
- */
-
-if (grab-grabtype == GRABTYPE_CORE)
+if (!match || (grab-confineTo
+ (!grab-confineTo-realized ||
+!BorderSizeNotEmpty(device, grab-confineTo
+continue;
+
+grabinfo = device-deviceGrab;
+/* In some cases a passive core grab may exist, but the client
+ * already has a core grab on some other device. In this case we
+ * must not get the grab, otherwise we may never ungrab the
+ * device.
+ */
+
+if (grab-grabtype == GRABTYPE_CORE)
+{
+DeviceIntPtr other;
+BOOL interfering = FALSE;
+
+/* A passive grab may have been created for a different device
+ than it is assigned to at this point in time.
+ Update the grab's device and modifier device to reflect the
+ current state.
+ Since XGrabDeviceButton requires to specify the
+ modifierDevice explicitly, we don't override this choice.
+ */
+if (tempGrab.type GenericEvent)
{
-DeviceIntPtr other;
-BOOL interfering = FALSE;
-
-/* A passive grab may have been created for a different device
- than it is assigned to at this point in time.
- Update the grab's device and modifier device to reflect the
- current state.
- Since XGrabDeviceButton requires to specify the
- modifierDevice explicitly, we don't override this choice.
- */
-if (tempGrab.type GenericEvent)
-{
-grab-device = device;
-grab-modifierDevice = GetPairedDevice(device);
-}
+grab-device = device;
+grab-modifierDevice = GetPairedDevice(device);
+}
-for (other = inputInfo.devices; other; other = other-next)
+for (other = inputInfo.devices; other; other = other-next)
+{
+GrabPtr othergrab = other-deviceGrab.grab;
+if (othergrab othergrab-grabtype == GRABTYPE_CORE
+SameClient(grab, rClient(othergrab))
+((IsPointerDevice(grab-device)
+ IsPointerDevice(othergrab-device)) ||
+ (IsKeyboardDevice(grab-device)
+ IsKeyboardDevice(othergrab-device
{
-GrabPtr othergrab = other-deviceGrab.grab;
-if (othergrab othergrab-grabtype == GRABTYPE_CORE
-SameClient(grab, rClient(othergrab))
-((IsPointerDevice(grab-device)
- IsPointerDevice(othergrab-device)) ||
- (IsKeyboardDevice(grab-device)
- IsKeyboardDevice(othergrab-device
-{
-interfering = TRUE;
-break;
-}
+interfering = TRUE;
+break;
}
-if (interfering)
-continue;
}
+if (interfering)
+continue;
+}
-if (!activate)
-return grab;
-else if (!GetXIType(event) !GetCoreType(event))
-FatalError(Event type %d in CheckPassiveGrabsOnWindow is
-neither XI 1.x nor core\n, event-any.type);
+if (!activate)
+return grab;
+else if (!GetXIType(event) !GetCoreType(event))
+FatalError(Event type %d in CheckPassiveGrabsForWindow is neither
+XI 1.x nor core\n, event-any.type);
-/* The only consumers of corestate are Xi 1.x and
[PATCH (v5) evdev 4/4] Ensure touchpad events are always processed with MT
From: Chase Douglas chase.doug...@canonical.com
Without this change, an MT touchpad in relative mode could end a touch
while not resetting the oldMask used to calculate relative values. This
fix allows a Magic Trackpad to behave as a relative mode device again.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
v5: No changes other than fixing conflicts.
src/evdev.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index fd810c8..4a9375b 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -714,8 +714,9 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo, struct
input_event *ev)
else {
map = pEvdev-axis_map[ev-code];
valuator_mask_set(pEvdev-mask, map, value);
-pEvdev-abs_queued = 1;
}
+
+pEvdev-abs_queued = 1;
}
/**
--
1.7.2.3
___
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 (v5) evdev 3/4] Use MTDev for multitouch devices
From: Chase Douglas chase.doug...@canonical.com
MTDev translates all multitouch devices to the slotted evdev protocol.
This provides a clean and uniform interface and reduces message handling
inside the input module and X.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
v5: No changes other than fixing conflicts.
configure.ac|3 +++
src/Makefile.am |1 +
src/evdev.c | 41 ++---
src/evdev.h |5 +
4 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 02ab67a..d968b22 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,6 +56,9 @@ AC_ARG_ENABLE(multitouch,
if test x$MULTITOUCH = xyes; then
AC_DEFINE(MULTITOUCH, 1, [Enable experimental multitouch code])
+
+# Obtain compiler/linker options for mtdev
+PKG_CHECK_MODULES(MTDEV, mtdev)
fi
# Define a configure option for an alternate input module directory
diff --git a/src/Makefile.am b/src/Makefile.am
index a5c89ac..b8d0dd9 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -30,6 +30,7 @@ AM_CPPFLAGS =-I$(top_srcdir)/include
@DRIVER_NAME@_drv_la_LTLIBRARIES = @DRIVER_NAME@_drv.la
@DRIVER_NAME@_drv_la_LDFLAGS = -module -avoid-version
+@DRIVER_NAME@_drv_la_LIBADD = $(MTDEV_LIBS)
@DRIVER_NAME@_drv_ladir = @inputdir@
@DRIVER_NAME@_drv_la_SOURCES = @DRIVER_NAME@.c \
diff --git a/src/evdev.c b/src/evdev.c
index 32d9109..fd810c8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -934,7 +934,17 @@ EvdevReadInput(InputInfoPtr pInfo)
while (len == sizeof(ev))
{
-len = read(pInfo-fd, ev, sizeof(ev));
+#ifdef MULTITOUCH
+EvdevPtr pEvdev = pInfo-private;
+
+if (pEvdev-mtdev)
+len = mtdev_get(pEvdev-mtdev, pInfo-fd, ev, NUM_EVENTS) *
+sizeof(struct input_event);
+else
+len = read(pInfo-fd, ev, sizeof(ev));
+#else
+len = read(pInfo-fd, ev, sizeof(ev));
+#endif
if (len = 0)
{
if (errno == ENODEV) /* May happen after resume */
@@ -1457,8 +1467,8 @@ EvdevAddAbsClass(DeviceIntPtr device)
int mode = pEvdev-flags EVDEV_TOUCHPAD ?
XIDependentTouch : XIDirectTouch;
-if (pEvdev-absinfo[ABS_MT_SLOT].maximum 0)
-num_touches = pEvdev-absinfo[ABS_MT_SLOT].maximum;
+if (pEvdev-mtdev-caps.slot.maximum 0)
+num_touches = pEvdev-mtdev-caps.slot.maximum;
if (!InitTouchClassDeviceStruct(device, num_touches, mode,
num_mt_axes)) {
@@ -1566,8 +1576,10 @@ out:
free(pEvdev-mtMask);
pEvdev-mtMask = NULL;
for (i = 0; i EVDEV_MAXQUEUE; i++)
+{
free(pEvdev-queue[i].touchMask);
pEvdev-queue[i].touchMask = NULL;
+}
#endif
free(pEvdev-mask);
pEvdev-mask = NULL;
@@ -1961,6 +1973,8 @@ EvdevProc(DeviceIntPtr device, int what)
free(pEvdev-mtMask);
for (i = 0; i EVDEV_MAXQUEUE; i++)
free(pEvdev-queue[i].touchMask);
+if (pEvdev-mtdev)
+mtdev_close(pEvdev-mtdev);
#endif
EvdevRemoveDevice(pInfo);
pEvdev-min_maj = 0;
@@ -2337,6 +2351,16 @@ EvdevOpenDevice(InputInfoPtr pInfo)
pEvdev-device = device;
xf86Msg(X_CONFIG, %s: Device: \%s\\n, pInfo-name, device);
+
+#ifdef MULTITOUCH
+pEvdev-mtdev = malloc(sizeof(struct mtdev));
+if (!pEvdev-mtdev)
+{
+xf86Msg(X_ERROR, %s: Couldn't allocate mtdev structure\n,
+pInfo-name);
+return BadAlloc;
+}
+#endif
}
if (pInfo-fd 0)
@@ -2351,6 +2375,17 @@ EvdevOpenDevice(InputInfoPtr pInfo)
}
}
+#ifdef MULTITOUCH
+if (mtdev_open(pEvdev-mtdev, pInfo-fd) == 0)
+pEvdev-cur_slot = pEvdev-mtdev-caps.slot.value;
+else {
+free(pEvdev-mtdev);
+pEvdev-mtdev = NULL;
+xf86Msg(X_ERROR, %s: Couldn't open mtdev device\n, pInfo-name);
+return FALSE;
+}
+#endif
+
/* Check major/minor of device node to avoid adding duplicate devices. */
pEvdev-min_maj = EvdevGetMajorMinor(pInfo);
if (EvdevIsDuplicate(pInfo))
diff --git a/src/evdev.h b/src/evdev.h
index 62619dd..3fbf407 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -39,6 +39,10 @@
#include xf86_OSproc.h
#include xkbstr.h
+#ifdef MULTITOUCH
+#include mtdev.h
+#endif
+
#ifndef EV_CNT /* linux 2.6.23 kernels and earlier lack _CNT defines */
#define EV_CNT (EV_MAX+1)
#endif
@@ -140,6 +144,7 @@ typedef struct {
int cur_slot;
BOOL close_slot;
BOOL open_slot;
+struct mtdev *mtdev;
#endif
int flags;
--
1.7.2.3
___
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 (v5) evdev 1/4] Add support for masked valuators
From: Chase Douglas chase.doug...@canonical.com
With the X server now supporting masked valuators for XI2, enable
support in X evdev.
This kills backwards compatibility with X Input ABI 12
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
v5: No changes other than fixing conflicts.
src/emuWheel.c |5 +-
src/evdev.c| 199 +++
src/evdev.h|6 +-
3 files changed, 118 insertions(+), 92 deletions(-)
diff --git a/src/emuWheel.c b/src/emuWheel.c
index 9a53211..c8683d9 100644
--- a/src/emuWheel.c
+++ b/src/emuWheel.c
@@ -120,8 +120,9 @@ EvdevWheelEmuFilterMotion(InputInfoPtr pInfo, struct
input_event *pEv)
/* We don't want to intercept real mouse wheel events */
if(pEv-type == EV_ABS) {
- oldValue = pEvdev-vals[pEvdev-axis_map[pEv-code]];
- pEvdev-vals[pEvdev-axis_map[pEv-code]] = value;
+ int axis = pEvdev-axis_map[pEv-code];
+ oldValue = valuator_mask_get(pEvdev-mask, axis);
+ valuator_mask_set(pEvdev-mask, axis, value);
value -= oldValue; /* make value into a differential measurement */
}
diff --git a/src/evdev.c b/src/evdev.c
index 45873c1..393f443 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -368,41 +368,41 @@ EvdevQueueButtonClicks(InputInfoPtr pInfo, int button,
int count)
}
}
-#define ABS_X_VALUE 0x1
-#define ABS_Y_VALUE 0x2
-#define ABS_VALUE 0x4
/**
- * Take the valuators and process them accordingly.
+ * Take the valuators and process them accordingly
*/
static void
-EvdevProcessValuators(InputInfoPtr pInfo, int v[MAX_VALUATORS], int *num_v,
- int *first_v)
+EvdevProcessValuators(InputInfoPtr pInfo)
{
int tmp;
EvdevPtr pEvdev = pInfo-private;
-*num_v = *first_v = 0;
-
/* convert to relative motion for touchpads */
if (pEvdev-abs_queued (pEvdev-flags EVDEV_RELATIVE_MODE)) {
if (pEvdev-in_proximity) {
-if (pEvdev-old_vals[0] != -1)
-pEvdev-delta[REL_X] = pEvdev-vals[0] - pEvdev-old_vals[0];
-if (pEvdev-old_vals[1] != -1)
-pEvdev-delta[REL_Y] = pEvdev-vals[1] - pEvdev-old_vals[1];
-if (pEvdev-abs_queued ABS_X_VALUE)
-pEvdev-old_vals[0] = pEvdev-vals[0];
-if (pEvdev-abs_queued ABS_Y_VALUE)
-pEvdev-old_vals[1] = pEvdev-vals[1];
+if (valuator_mask_isset(pEvdev-mask, 0)
+valuator_mask_isset(pEvdev-oldMask, 0))
+pEvdev-delta[REL_X] = valuator_mask_get(pEvdev-mask, 0) -
+ valuator_mask_get(pEvdev-oldMask, 0);
+if (valuator_mask_isset(pEvdev-mask, 1)
+valuator_mask_isset(pEvdev-oldMask, 1))
+pEvdev-delta[REL_Y] = valuator_mask_get(pEvdev-mask, 1) -
+ valuator_mask_get(pEvdev-oldMask, 1);
+if (valuator_mask_isset(pEvdev-mask, 0))
+valuator_mask_set(pEvdev-oldMask, 0,
+ valuator_mask_get(pEvdev-mask, 0));
+if (valuator_mask_isset(pEvdev-mask, 1))
+valuator_mask_set(pEvdev-oldMask, 1,
+ valuator_mask_get(pEvdev-mask, 1));
} else {
-pEvdev-old_vals[0] = pEvdev-old_vals[1] = -1;
+valuator_mask_zero(pEvdev-oldMask);
}
+valuator_mask_zero(pEvdev-mask);
pEvdev-abs_queued = 0;
pEvdev-rel_queued = 1;
}
if (pEvdev-rel_queued) {
-int first = REL_CNT, last = -1;
int i;
if (pEvdev-swap_axes) {
@@ -419,19 +419,7 @@ EvdevProcessValuators(InputInfoPtr pInfo, int
v[MAX_VALUATORS], int *num_v,
{
int map = pEvdev-axis_map[i];
if (pEvdev-delta[i] map != -1)
-{
-v[map] = pEvdev-delta[i];
-if (map first)
-first = map;
-if (map last)
-last = map;
-}
-}
-
-if (last = 0)
-{
-*num_v = (last - first + 1);
-*first_v = first;
+valuator_mask_set(pEvdev-mask, map, pEvdev-delta[i]);
}
}
/*
@@ -444,46 +432,43 @@ EvdevProcessValuators(InputInfoPtr pInfo, int
v[MAX_VALUATORS], int *num_v,
* just works.
*/
else if (pEvdev-abs_queued pEvdev-in_proximity) {
-memcpy(v, pEvdev-vals, sizeof(int) * pEvdev-num_vals);
+int unswapped_x = valuator_mask_get(pEvdev-mask, 0);
+int unswapped_y = valuator_mask_get(pEvdev-mask, 1);
+int i;
-if (pEvdev-swap_axes) {
-int tmp = v[0];
-v[0] = xf86ScaleAxis(v[1],
-pEvdev-absinfo[ABS_X].maximum,
-pEvdev-absinfo[ABS_X].minimum,
-pEvdev-absinfo[ABS_Y].maximum,
-
[PATCH (v5) evdev 2/4] Add experimental XI 2.1 multitouch support
From: Chase Douglas chase.doug...@canonical.com
This multitouch addition only supports slotted MT evdev protocol
devices. Support must be enabled at configure time using
--enable-multitouch.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
v5: Fixed merge conflicts.
Updated to new xf86PostTouchEvent API, including explicitly tracking
touchpoint creation and destruction, rather than relying on the server to
do it for us.
Removed mt_slot_map, as we no longer need to hand the server monotonic
touch IDs: it does that for us.
configure.ac | 11 +++
src/evdev.c | 217 +-
src/evdev.h | 25 ++-
3 files changed, 233 insertions(+), 20 deletions(-)
diff --git a/configure.ac b/configure.ac
index 887021c..02ab67a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,6 +47,17 @@ XORG_DEFAULT_OPTIONS
# Obtain compiler/linker options from server and required extensions
PKG_CHECK_MODULES(XORG, xorg-server xproto inputproto)
+# Whether to include support for experimental XI 2.1 multitouch
+AC_ARG_ENABLE(multitouch,
+ AC_HELP_STRING([--enable-multitouch],
+ [Enable experimental XI 2.1 multitouch support
[[default: disabled]]]),
+ [MULTITOUCH=$enableval],
+ [MULTITOUCH=no])
+
+if test x$MULTITOUCH = xyes; then
+AC_DEFINE(MULTITOUCH, 1, [Enable experimental multitouch code])
+fi
+
# Define a configure option for an alternate input module directory
AC_ARG_WITH(xorg-module-dir,
AC_HELP_STRING([--with-xorg-module-dir=DIR],
diff --git a/src/evdev.c b/src/evdev.c
index 393f443..32d9109 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -87,6 +87,14 @@
#define MODEFLAG 8
#define COMPOSEFLAG16
+#ifndef ABS_MT_SLOT
+#define ABS_MT_SLOT 0x2f
+#endif
+
+#ifndef ABS_MT_TRACKING_ID
+#define ABS_MT_TRACKING_ID 0x39
+#endif
+
static char *evdevDefaults[] = {
XkbRules, evdev,
XkbModel, evdev,
@@ -317,7 +325,7 @@ EvdevQueueKbdEvent(InputInfoPtr pInfo, struct input_event
*ev, int value)
if ((pQueue = EvdevNextInQueue(pInfo)))
{
pQueue-type = EV_QUEUE_KEY;
-pQueue-key = code;
+pQueue-detail.key = code;
pQueue-val = value;
}
}
@@ -330,7 +338,7 @@ EvdevQueueButtonEvent(InputInfoPtr pInfo, int button, int
value)
if ((pQueue = EvdevNextInQueue(pInfo)))
{
pQueue-type = EV_QUEUE_BTN;
-pQueue-key = button;
+pQueue-detail.key = button;
pQueue-val = value;
}
}
@@ -342,11 +350,27 @@ EvdevQueueProximityEvent(InputInfoPtr pInfo, int value)
if ((pQueue = EvdevNextInQueue(pInfo)))
{
pQueue-type = EV_QUEUE_PROXIMITY;
-pQueue-key = 0;
+pQueue-detail.key = 0;
pQueue-val = value;
}
}
+#ifdef MULTITOUCH
+void
+EvdevQueueTouchEvent(InputInfoPtr pInfo, unsigned int touch, ValuatorMask
*mask,
+ uint16_t evtype)
+{
+EventQueuePtr pQueue;
+if ((pQueue = EvdevNextInQueue(pInfo)))
+{
+pQueue-type = EV_QUEUE_TOUCH;
+pQueue-detail.touch = touch;
+valuator_mask_copy(pQueue-touchMask, mask);
+pQueue-val = evtype;
+}
+}
+#endif
+
/**
* Post button event right here, right now.
* Interface for MB emulation since these need to post immediately.
@@ -615,6 +639,53 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo, struct
input_event *ev)
}
}
+#ifdef MULTITOUCH
+static void
+EvdevProcessTouch(InputInfoPtr pInfo)
+{
+EvdevPtr pEvdev = pInfo-private;
+
+if (pEvdev-cur_slot 0 || !pEvdev-mtMask)
+return;
+
+if (pEvdev-close_slot) {
+EvdevQueueTouchEvent(pInfo, pEvdev-cur_slot, pEvdev-mtMask,
+ XI_TouchEnd);
+pEvdev-close_slot = 0;
+} else {
+EvdevQueueTouchEvent(pInfo, pEvdev-cur_slot, pEvdev-mtMask,
+ pEvdev-open_slot ? XI_TouchBegin :
+ XI_TouchMotion);
+pEvdev-open_slot = 0;
+}
+
+valuator_mask_zero(pEvdev-mtMask);
+}
+
+static void
+EvdevProcessTouchEvent(InputInfoPtr pInfo, struct input_event *ev)
+{
+EvdevPtr pEvdev = pInfo-private;
+int map;
+
+if (ev-code == ABS_MT_SLOT) {
+EvdevProcessTouch(pInfo);
+pEvdev-cur_slot = ev-value;
+} else if (ev-code == ABS_MT_TRACKING_ID) {
+if (ev-value = 0)
+pEvdev-open_slot = 1;
+else
+pEvdev-close_slot = 1;
+} else {
+map = pEvdev-axis_map[ev-code] - pEvdev-num_vals;
+valuator_mask_set(pEvdev-mtMask, map, ev-value);
+}
+}
+#else
+#define EvdevProcessTouch(pInfo)
+#define EvdevProcessTouchEvent(pInfo, ev)
+#endif /* MULTITOUCH */
+
/**
* Take the absolute motion input event and process it accordingly.
*/
@@ -638,9 +709,13 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo, struct
input_event *ev)
if
