Re: X Gesture Extension protocol - draft proposal v1
On Mon, 2010-08-16 at 22:27 +0200, Simon Thum wrote: Am 16.08.2010 21:41, schrieb Chase Douglas: Also, we think that there's a case to be made for environmental gestures that should override gestures recognized by clients. This is provided by the mutual exclusion flag when selecting for events. Again, this wouldn't be possible without integrating it into the X propagation mechanism. I like it, if only because it resembles what I described on the list earlier that year :) The protocol's probably tricky to get race-free, but surely worth it. I'll have a more thorough look at it this week. I'm cc'ing florian in case he's still working on the issue. Here's the old discussion: http://lists.x.org/archives/xorg-devel/2010-March/006388.html Thanks for mentioning, Simon - I'm very excited to see this, it's really quite similar to my own work. Douglas, allow me to point you to my thesis from last year at http://mediatum2.ub.tum.de/node?id=796958 Chapter 3 in particular deals with very similar issues, I'd be happy if you could give it a quick glance and tell me about your opinion. Or did you already read it? The similiarities, as I said, are quite striking :-) There also is a cross-platform implementation of my concepts available at http://tisch.sf.net/ and https://launchpad.net/~floe/+archive/libtisch . One thing I would suggest as a future extension is something along the lines of less monolithic gestures, i.e. compose them out of still smaller primitives such as number of fingers, held time, pressure, distance change, angle change etc. etc. Florian ___ 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] XOpenDisplay: save the correct display_name value
The X Test Suite's XDisplayString test checks the invariant
XDisplayString(XOpenDisplay(str)) == str. The XCB-based XOpenDisplay violates
this invariant by expanding str to the canonical form host:display.scrn
(unless HAVE_LAUNCHD is set and it starts with /tmp/launch). E.g., this
expands :1 to :1.0:
400|26 1 1 19:26:41|IC Start
200|26 1 19:26:41|TP Start
520|26 1 00032625 1 1|VSW5TESTSUITE PURPOSE 1
520|26 1 00032625 1 2|Assertion XDisplayString-1.(A)
520|26 1 00032625 1 3|A call to XDisplayString returns the string that was
used
520|26 1 00032625 1 4|as the argument to the XOpenDisplay call that returned
the
520|26 1 00032625 1 5|value used as the display argument.
520|26 1 00032625 1 6|METH: Open a connection using XOpenDisplay.
520|26 1 00032625 1 7|METH: Obtain the display string using XDisplayString.
520|26 1 00032625 1 8|METH: Verify that the value of the string is the
parameter used in XOpenDisplay.
520|26 1 00032625 1 9|METH: Close the display using XCloseDisplay.
520|26 1 00032625 1 10|REPORT: XDisplayString() returned :1.0 instead of
:1.
220|26 1 1 19:26:41|FAIL
410|26 1 1 19:26:41|IC End
Fix this by deleting all of the code to construct the canonical path and just
stash a copy of the original display_name in dpy-display_name.
Delete the now unused HAVE_LAUNCHD macro and code to set it.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
---
I don't really know whether this is the correct fix, but XTS clearly
expects XDisplayString to return exactly the same string that was passed
into XOpenDisplay:
if(strcmp(rdispstr, config.display) != 0) {
report(%s() returned \%s\ instead of \%s\., TestName, rdispstr,
config.display);
FAIL;
However, this behavior has been in Xlib for a long time and it seems like
some application might rely on it. As an alternative, I could update the
test to allow XDisplayString to tack on a screen number if the original
display string didn't have one, but the man page does say,
The DisplayString macro returns the string that was passed to
XOpenDisplay when the current display was opened.
Jeremy, you seem to the be the most familiar with launchd. Does this
change seem okay to you? Since this change stops appending the screen
number all the time, it seems like it should be a no-op for the launchd
case.
configure.ac | 11 ---
src/OpenDis.c | 20 ++--
src/Xxcbint.h |2 +-
src/xcb_disp.c | 18 ++
4 files changed, 13 insertions(+), 38 deletions(-)
diff --git a/configure.ac b/configure.ac
index efdbe4d..6e6bd9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -255,17 +255,6 @@ AC_SUBST(WCHAR32)
AM_CONDITIONAL(OS2, test x$os2 = xtrue)
-AC_ARG_WITH(launchd, AS_HELP_STRING([--with-launchd], [Build with support for
Apple's launchd (default: auto)]), [LAUNCHD=$withval], [LAUNCHD=auto])
-if test x$LAUNCHD = xauto; then
- unset LAUNCHD
- AC_CHECK_PROG(LAUNCHD, [launchd], [yes], [no],
[$PATH$PATH_SEPARATOR/sbin])
-fi
-
-if test x$LAUNCHD = xyes ; then
- AC_DEFINE(HAVE_LAUNCHD, 1, [launchd support available])
- AC_DEFINE(TRANS_REOPEN, 1, [launchd support available])
-fi
-
AC_ARG_ENABLE(xthreads,
AC_HELP_STRING([--disable-xthreads],
[Disable Xlib support for Multithreading]),
diff --git a/src/OpenDis.c b/src/OpenDis.c
index 8de9556..e568a30 100644
--- a/src/OpenDis.c
+++ b/src/OpenDis.c
@@ -69,7 +69,6 @@ XOpenDisplay (
int j, k; /* random iterator indexes */
char *display_name; /* pointer to display name */
char *setup = NULL; /* memory allocated at startup */
- char *fullname = NULL; /* expanded name of display */
int iscreen;/* screen number */
xConnSetupPrefix prefix;/* prefix information */
int vendorlen; /* length of vendor string */
@@ -117,13 +116,17 @@ XOpenDisplay (
return(NULL);
}
+ if ((dpy-display_name = strdup(display_name)) == NULL) {
+ OutOfMemory(dpy);
+ return(NULL);
+ }
+
/*
* Call the Connect routine to get the transport connection object.
- * If NULL is returned, the connection failed. The connect routine
- * will set fullname to point to the expanded name.
+ * If NULL is returned, the connection failed.
*/
- if(!_XConnectXCB(dpy, display, fullname, iscreen)) {
+ if(!_XConnectXCB(dpy, display, iscreen)) {
/* Try falling back on other transports if no transport
specified */
const char *slash = strrchr(display_name, '/');
if(slash == NULL) {
@@ -135,14 +138,13 @@ XOpenDisplay (
if(buf) {
for(s = protocols; buf *s; s++) {
snprintf(buf, buf_size, %s/%s, *s,
display_name);
-
Re: X Gesture Extension protocol - draft proposal v1
On Tue, 2010-08-17 at 08:31 +0200, Florian Echtler wrote: On Mon, 2010-08-16 at 22:27 +0200, Simon Thum wrote: Am 16.08.2010 21:41, schrieb Chase Douglas: Also, we think that there's a case to be made for environmental gestures that should override gestures recognized by clients. This is provided by the mutual exclusion flag when selecting for events. Again, this wouldn't be possible without integrating it into the X propagation mechanism. I like it, if only because it resembles what I described on the list earlier that year :) The protocol's probably tricky to get race-free, but surely worth it. I'll have a more thorough look at it this week. I'm cc'ing florian in case he's still working on the issue. Here's the old discussion: http://lists.x.org/archives/xorg-devel/2010-March/006388.html Thanks for mentioning, Simon - I'm very excited to see this, it's really quite similar to my own work. Douglas, allow me to point you to my thesis from last year at http://mediatum2.ub.tum.de/node?id=796958 Chapter 3 in particular deals with very similar issues, I'd be happy if you could give it a quick glance and tell me about your opinion. Or did you already read it? The similiarities, as I said, are quite striking :-) There also is a cross-platform implementation of my concepts available at http://tisch.sf.net/ and https://launchpad.net/~floe/+archive/libtisch . One thing I would suggest as a future extension is something along the lines of less monolithic gestures, i.e. compose them out of still smaller primitives such as number of fingers, held time, pressure, distance change, angle change etc. etc. Florian, I haven't seen your research before, so I just read through it. It's pretty uncanny how similar our thoughts are about the design. I hope that means we are both on the right track! As for gesture composition, I think the gestures you and I have outlined (move, rotate, pinch, tap) should cover all uses. Can you explain in more detail what you mean by composing gestures out of still smaller primitives? It sounds to me like you might be talking about defining boundaries for gesture recognition initiation, as in a rotation will be recognized after x degrees. If so, I think splitting the gesture engine out from X and making it a separate client helps facilitate research of this, as people can play with other engine designs and parameters. If we find that initiation parameters should be settable by each application, we could extend the protocol for it. I'm hesitant to do so now without evidence that we need it though. Thanks, -- Chase ___ 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] dix: Provide means to determine server startup time easily.
It is useful to provide a way to determine server initialization time for testers. For example, this patch makes it easy for testers to verify that the recent xkbcomp modifications have a positive effect on server startup time on boot. Signed-off-by: Rami Ylimäki rami.ylim...@vincit.fi --- dix/globals.c |5 + dix/main.c|8 include/globals.h |3 +++ 3 files changed, 16 insertions(+), 0 deletions(-) diff --git a/dix/globals.c b/dix/globals.c index b128569..43742a7 100644 --- a/dix/globals.c +++ b/dix/globals.c @@ -86,6 +86,11 @@ long maxBigRequestSize = MAX_BIG_REQUEST_SIZE; unsigned long globalSerialNumber = 0; unsigned long serverGeneration = 0; +/* when X server started initializing itself */ +CARD32 ServerStartTime = 0; +/* when X server was ready to handle clients */ +CARD32 ServerReadyTime = 0; + /* these next four are initialized in main.c */ CARD32 ScreenSaverTime; CARD32 ScreenSaverInterval; diff --git a/dix/main.c b/dix/main.c index 5c46dc1..84232b4 100644 --- a/dix/main.c +++ b/dix/main.c @@ -137,6 +137,8 @@ int main(int argc, char *argv[], char *envp[]) inti; HWEventQueueType alwaysCheckForInput[2]; +ServerStartTime = GetTimeInMillis(); + display = 0; InitRegions(); @@ -284,6 +286,12 @@ int main(int argc, char *argv[], char *envp[]) pthread_mutex_unlock(serverInitCompleteMutex); #endif + ServerReadyTime = GetTimeInMillis(); + LogMessage(X_INFO, Server initialized in %lu.%.3lu seconds (%lu.%.3lu - %lu.%.3lu)\n, + (ServerReadyTime - ServerStartTime) / 1000, (ServerReadyTime - ServerStartTime) % 1000, + ServerStartTime / 1000, ServerStartTime % 1000, + ServerReadyTime / 1000, ServerReadyTime % 1000); + NotifyParentProcess(); Dispatch(); diff --git a/include/globals.h b/include/globals.h index 8b80a65..28932a6 100644 --- a/include/globals.h +++ b/include/globals.h @@ -6,6 +6,9 @@ /* Global X server variables that are visible to mi, dix, os, and ddx */ +extern _X_EXPORT CARD32 ServerStartTime; +extern _X_EXPORT CARD32 ServerReadyTime; + extern _X_EXPORT CARD32 defaultScreenSaverTime; extern _X_EXPORT CARD32 defaultScreenSaverInterval; extern _X_EXPORT CARD32 ScreenSaverTime; -- 1.6.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] dix: Provide means to determine server startup time easily.
On Tue, Aug 17, 2010 at 04:40:02PM +0200, ext Rami Ylimäki wrote: It is useful to provide a way to determine server initialization time for testers. For example, this patch makes it easy for testers to verify that the recent xkbcomp modifications have a positive effect on server startup time on boot. Signed-off-by: Rami Ylimäki rami.ylim...@vincit.fi --- dix/globals.c |5 + dix/main.c|8 include/globals.h |3 +++ 3 files changed, 16 insertions(+), 0 deletions(-) diff --git a/dix/globals.c b/dix/globals.c index b128569..43742a7 100644 --- a/dix/globals.c +++ b/dix/globals.c @@ -86,6 +86,11 @@ long maxBigRequestSize = MAX_BIG_REQUEST_SIZE; unsigned long globalSerialNumber = 0; unsigned long serverGeneration = 0; +/* when X server started initializing itself */ +CARD32 ServerStartTime = 0; +/* when X server was ready to handle clients */ +CARD32 ServerReadyTime = 0; + /* these next four are initialized in main.c */ CARD32 ScreenSaverTime; CARD32 ScreenSaverInterval; diff --git a/dix/main.c b/dix/main.c index 5c46dc1..84232b4 100644 --- a/dix/main.c +++ b/dix/main.c @@ -137,6 +137,8 @@ int main(int argc, char *argv[], char *envp[]) int i; HWEventQueueType alwaysCheckForInput[2]; +ServerStartTime = GetTimeInMillis(); + display = 0; InitRegions(); @@ -284,6 +286,12 @@ int main(int argc, char *argv[], char *envp[]) pthread_mutex_unlock(serverInitCompleteMutex); #endif + ServerReadyTime = GetTimeInMillis(); + LogMessage(X_INFO, Server initialized in %lu.%.3lu seconds (%lu.%.3lu - %lu.%.3lu)\n, +(ServerReadyTime - ServerStartTime) / 1000, (ServerReadyTime - ServerStartTime) % 1000, +ServerStartTime / 1000, ServerStartTime % 1000, +ServerReadyTime / 1000, ServerReadyTime % 1000); + NotifyParentProcess(); Dispatch(); diff --git a/include/globals.h b/include/globals.h index 8b80a65..28932a6 100644 --- a/include/globals.h +++ b/include/globals.h @@ -6,6 +6,9 @@ /* Global X server variables that are visible to mi, dix, os, and ddx */ +extern _X_EXPORT CARD32 ServerStartTime; +extern _X_EXPORT CARD32 ServerReadyTime; + extern _X_EXPORT CARD32 defaultScreenSaverTime; extern _X_EXPORT CARD32 defaultScreenSaverInterval; extern _X_EXPORT CARD32 ScreenSaverTime; why don't squash the global variables inside main.c, Rami? Also, instead LogMessage I think DebugF is a better candidate here. Cheers, Tiago ___ 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: Provide means to determine server startup time easily.
Tiago Vignatti wrote: why don't squash the global variables inside main.c, Rami? Yeah, globals.c globale.h should be for variables that need to be globally visible, not those that could be static to a single source file. -- -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
Rendering benchmark
Hi all, who can help me to find a recent benchmark of rendering performance of Cairo Vs QGraphicsView backends ? This one made by Zack is very old now : http://zrusin.blogspot.com/2006/10/benchmarks.html Thanks ! ik. ___ 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
lack of standardization on X11 (was Re: X Gesture Extension protocol - draft proposal v1)
(starting a new thread to not mess with the things) On Tue, Aug 17, 2010 at 01:41:17AM +0200, ext Chase Douglas wrote: On Tue, 2010-08-17 at 09:05 +1000, Dave Airlie wrote: On Tue, Aug 17, 2010 at 1:13 AM, Chase Douglas chase.doug...@canonical.com wrote: The X Gesture Extension Version 1.0 Are you shipping v1 in Ubuntu already? if so how are you going to deal with incompatible v1 if someone thinks X.org should ship with this. We're shipping with what I would call 0.5 in Ubuntu 10.10. This protocol proposal is a result of the issues we found in our current implementation. One of the benefits to write any protocol in stone is because a plenty of use cases was thought for while, which theoretically could be used by lot of application and consumers. Everyone knows that we're not using X core protocol anymore and we're abusing its extensibility feature. In MeeGo + QT 4.7 we're using around 15% of the core protocol only. This all means we can play and juggle with the protocol for anyone needs, adding and killing X extensions. Now, the major problem is that we start to have a bunch of different applications, each one using X differently. Ubuntu 10.10 employing one way to do gesture, Ubuntu 11 another one, MeeGo another one and so on. That's silly! We should be using the same basis set of system applications instead. We're lacking standard. To ensure we have as little protocol incompatibility as possible, we have not published the maverick protocol publicly. Chase, I don't think your extension is doing something wrong at all. I'm just trying to call some attention about where we're going if we keep doing this extension juggling. Something we need to think about. Tiago ___ 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 xextproto 1/4] Document changes in XSync version 3.1
Apologies for the slow review here... On Thu, 2010-08-12 at 16:40 -0700, James Jones wrote: para -The extension adds functionCounter/function and -functionAlarm/function to the set of resources managed by the +The extension adds functionCounter/function, functionAlarm/function, +and functionFence/function to the set of resources managed by the server. A counter has a 64-bit integer value that may be increased or decreased by client requests or by the server internally. A client can block by sending an Await request that waits until one of a set of synchronization -conditions, called TRIGGERs, becomes TRUE. +conditions, called TRIGGERs, becomes TRUE. A fence has two possible states: +triggered and not triggered. Client requests can put the fence in either of +these states. A client can block until one of a set of fences becomes +triggered by sending an AwaitFence request. /para I feel like this whole section wants a rewrite, since Alarms aren't discussed until much later. Would be worthwhile if doing so to note that Fences are explicitly bound to a screen (though I wouldn't insist on it to get this merged). And on that subject... +para +The functionCreateFence/function request allows a client to create a +functionFence/function that can be triggered and reset using +functionTriggerFence/function and functionResetFence/function +requests, respectively. The functionTriggerFence/function request changes +the fence's state only after all previous rendering commands affecting objects +owned by the given fence's screen have completed. +/para I'm a little unclear on _why_ they're bound to screens. What semantics does that imply? The only reason I can imagine wanting to do so in the protocol is if the server itself would ever trigger a Fence on a Drawable, because then you'd need to wire the Fence to the right ScreenRec. But it seems like that should never happen for client-created Fences, only for server-created Fences. - ajax 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 xextproto 1/4] Document changes in XSync version 3.1
On Tue, Aug 17, 2010 at 02:49:41PM -0700, Adam Jackson wrote: Apologies for the slow review here... On Thu, 2010-08-12 at 16:40 -0700, James Jones wrote: para -The extension adds functionCounter/function and -functionAlarm/function to the set of resources managed by the +The extension adds functionCounter/function, functionAlarm/function, +and functionFence/function to the set of resources managed by the server. A counter has a 64-bit integer value that may be increased or decreased by client requests or by the server internally. A client can block by sending an Await request that waits until one of a set of synchronization -conditions, called TRIGGERs, becomes TRUE. +conditions, called TRIGGERs, becomes TRUE. A fence has two possible states: +triggered and not triggered. Client requests can put the fence in either of +these states. A client can block until one of a set of fences becomes +triggered by sending an AwaitFence request. /para I feel like this whole section wants a rewrite, since Alarms aren't discussed until much later. Would be worthwhile if doing so to note that Fences are explicitly bound to a screen (though I wouldn't insist on it to get this merged). And on that subject... +para +The functionCreateFence/function request allows a client to create a +functionFence/function that can be triggered and reset using +functionTriggerFence/function and functionResetFence/function +requests, respectively. The functionTriggerFence/function request changes +the fence's state only after all previous rendering commands affecting objects +owned by the given fence's screen have completed. +/para I'm a little unclear on _why_ they're bound to screens. What semantics does that imply? The only reason I can imagine wanting to do so in the protocol is if the server itself would ever trigger a Fence on a Drawable, because then you'd need to wire the Fence to the right ScreenRec. But it seems like that should never happen for client-created Fences, only for server-created Fences. James, correct me if I'm wrong, but I don't think the server ever creates fences on its own; they're *all* client-created. Fences trigger when the rendering for the corresponding X screen is done, for requests that were processed before the triggering request. Rendering could still be pending on other screens, and there could be later rendering queued on the same screen for later requests. The idea is that a client creates a Fence on a given X screen, binds it to an OpenGL sync object using a to-be-created GLX extension, then in response to an XDamageNotify, sends DamageSubtractAndTrigger, tells OpenGL to wait for the corresponding OpenGL side of the fence, and then performs the rendering using OpenGL. This makes the GL wait (on the GPU, ideally) for the X rendering on that screen to finish without making the client itself wait on the CPU. ___ 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: lack of standardization on X11 (was Re: X Gesture Extension protocol - draft proposal v1)
On Tue, Aug 17, 2010 at 06:31:54PM +0300, Tiago Vignatti wrote: (starting a new thread to not mess with the things) On Tue, Aug 17, 2010 at 01:41:17AM +0200, ext Chase Douglas wrote: On Tue, 2010-08-17 at 09:05 +1000, Dave Airlie wrote: On Tue, Aug 17, 2010 at 1:13 AM, Chase Douglas chase.doug...@canonical.com wrote: The X Gesture Extension Version 1.0 Are you shipping v1 in Ubuntu already? if so how are you going to deal with incompatible v1 if someone thinks X.org should ship with this. We're shipping with what I would call 0.5 in Ubuntu 10.10. This protocol proposal is a result of the issues we found in our current implementation. One of the benefits to write any protocol in stone is because a plenty of use cases was thought for while, which theoretically could be used by lot of application and consumers. Everyone knows that we're not using X core protocol anymore and we're abusing its extensibility feature. In MeeGo + QT 4.7 we're using around 15% of the core protocol only. This all means we can play and juggle with the protocol for anyone needs, adding and killing X extensions. abusing? i'd call it using, it's the whole point of extensions. and using 15% of a protocol that's in part designed around graphics hardware over two decades old is still a pretty high number... Now, the major problem is that we start to have a bunch of different applications, each one using X differently. Ubuntu 10.10 employing one way to do gesture, Ubuntu 11 another one, MeeGo another one and so on. That's silly! We should be using the same basis set of system applications instead. We're lacking standard. To ensure we have as little protocol incompatibility as possible, we have not published the maverick protocol publicly. Chase, I don't think your extension is doing something wrong at all. I'm just trying to call some attention about where we're going if we keep doing this extension juggling. Something we need to think about. As somebody who's written an extension to input-related things I can tell you that until you start using it (both with devices and from applications), any proposed extension must be questioned anyway. So at some point you will just have to implement it and throw it out into the wild. I don't think 1.0 is a good version number to begin with but really, it's just a number. 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 xextproto 1/4] Document changes in XSync version 3.1
On Tuesday 17 August 2010 15:01:53 Aaron Plattner wrote: On Tue, Aug 17, 2010 at 02:49:41PM -0700, Adam Jackson wrote: Apologies for the slow review here... No worries. Thanks for taking the time. On Thu, 2010-08-12 at 16:40 -0700, James Jones wrote: para -The extension adds functionCounter/function and -functionAlarm/function to the set of resources managed by the +The extension adds functionCounter/function, functionAlarm/function, +and functionFence/function to the set of resources managed by the server. A counter has a 64-bit integer value that may be increased or decreased by client requests or by the server internally. A client can block by sending an Await request that waits until one of a set of synchronization -conditions, called TRIGGERs, becomes TRUE. +conditions, called TRIGGERs, becomes TRUE. A fence has two possible states: +triggered and not triggered. Client requests can put the fence in either of +these states. A client can block until one of a set of fences becomes +triggered by sending an AwaitFence request. /para I feel like this whole section wants a rewrite, since Alarms aren't discussed until much later. Would be worthwhile if doing so to note that Fences are explicitly bound to a screen (though I wouldn't insist on it to get this merged). And on that subject... +para +The functionCreateFence/function request allows a client to create a +functionFence/function that can be triggered and reset using +functionTriggerFence/function and functionResetFence/function +requests, respectively. The functionTriggerFence/function request changes +the fence's state only after all previous rendering commands affecting objects +owned by the given fence's screen have completed. +/para I'm a little unclear on _why_ they're bound to screens. What semantics does that imply? The only reason I can imagine wanting to do so in the protocol is if the server itself would ever trigger a Fence on a Drawable, because then you'd need to wire the Fence to the right ScreenRec. But it seems like that should never happen for client-created Fences, only for server-created Fences. James, correct me if I'm wrong, but I don't think the server ever creates fences on its own; they're *all* client-created. Fences trigger when the rendering for the corresponding X screen is done, for requests that were processed before the triggering request. Rendering could still be pending on other screens, and there could be later rendering queued on the same screen for later requests. Aaron's correct. I chose to give the key fence operations a defined ordering with respect to rendering operations from all clients on a given screen. To do so, I needed to associate a screen with a fence. That could either be done at creation time, or trigger/other operation time. Creation time is the only way to implement these such that they're reasonable to push down to a GPU, and/or import to other APIs like OpenGL sync objects. More background: X requests from one client execute in a defined order only with respect to other requests from that client. The X Sync extension provides synchronization across clients, but the existing X sync extension mechanisms assume all X operations complete instantaneously, or at least in the order in which X processes them. This assumption breaks down when direct rendering clients are rendering out-of-band with respect to X rendering, or even if an X driver has multiple rendering backends, say one per client or one per screen, that process commands simultaneously or in an undefined order with respect to each other. Specifying that fence triggers complete after all previous requests from the triggering client is too fine-grained, and not really that useful of an operation anyway since they are meant to be used to synchronize multiple clients. Server-wide seemed too coarse-grained. The operations fence syncs are meant to synchronize are rendering operations. All X rendering operations (I'm sure someone is going to correct me with an exception here) operate on per-screen objects. The wrapping mechanisms the DDX uses to expose driver hooks are mostly per-screen. Hence, it made sense to make the fence objects screen-specific as well. I'll make another pass and try to capture more of the above in the spec, in addition to making more intrusive updates to the sections you reference above. I'll send those out when I send out the xserver changes. I tried a few directions with the server code, and feel the current spec/implementation fell out most naturally from the existing architecture, so having the code to look at side-by-side with the proto patches might help. If anyone wants to get ahead of me, the latest xserver changes are available on my github repos at http://github.com/cubanismo/xserver/tree/fence_sync The idea is that a
How to use the structure of 'pScreen-pScratchPixmap' ? ( in Xserver code )
Hi, guys, I want to ask some question, by part of Xserver code, http://cgit.freedesktop.org/xorg/xserver/tree/dix/pixmap.c#n58 - Line 59 pScreen-pScratchPixmap = NULL; why do this operation? Any body knows? In our xf86-video-geode driver, I just go to inverted mode rotation and back to normal, and afterwards various icons are gone, so I want to know what destination about http://cgit.freedesktop.org/xorg/xserver/tree/dix/pixmap.c#n58 - Line 59 pScreen-pScratchPixmap = NULL; because it is main point. When go to inverted mode rotation, pScreen-pScratchPixmap = NULL in GetScratchPixmapHeader function ( http://cgit.freedesktop.org/xorg/xserver/tree/dix/pixmap.c#n53 ), after come back to normal, pScreen-pScratchPixmap = pPixmap in FreeScratchPixmapHeader function (http://cgit.freedesktop.org/xorg/xserver/tree/dix/pixmap.c#n76 ), I want to know the root reason. I wish someone would help. Thanks, Hunk Cui ___ 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
