[PATCH x11proto] Xfuncproto: add _X_NONNULL
Signed-off-by: Jeff Smith --- Xfuncproto.h.in |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Xfuncproto.h.in b/Xfuncproto.h.in index 96a585c..be3e052 100644 --- a/Xfuncproto.h.in +++ b/Xfuncproto.h.in @@ -123,4 +123,10 @@ in this Software without prior written authorization from The Open Group. # define _X_NORETURN #endif /* GNUC */ +#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 303) +# define _X_NONNULL(x) __attribute__((nonnull(x))) +#else /* not gcc >= 3.3 */ +# define _X_NONNULL +#endif + #endif /* _XFUNCPROTO_H_ */ -- 1.6.0.6 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: GSoC Idea: Adding support for DMX screens to dix
On Mon, Mar 29, 2010 at 12:10 PM, Cody Maloney wrote: > Currently the DMX X server works well enough to get display walls up > and running. What I'd like to do is make it so that from a running X > server you can dynamically add and remove DMX screens, without the > need of the seperate DMX proxy server. This would be useful for > instance to setup/use network screens/projectors. In addition, over it > could move to replace the dmx X server which would mean that dmx would > always be up to date with modern extensions. I'm not sure how feasible > it is to add it to dix, and if there's a lot of work that needs to be > done before it could happen (Removing MAXSCREENS?). Awesome. I've only glanced over what's needed for this, but it's something I'd like to see happen. It seems to me that there are two substantial projects here, and I think they're completely independent. For one thing, I don't think there's currently an X.org video driver that does what Xephyr or Xnest do, and I'd love to see one. Preferably implemented using XCB, of course. ;-) If we had such a driver, would that be enough to replace Xdmx with a static xorg.conf? I'd guess the Xinerama implementation should take care of most of the work, but maybe it needs more? The other piece I see is screen hotplug. It would be broadly useful to be able to add and remove screens from a running X server--not just for dynamic DMX, but also for USB video peripherals and other hotpluggable devices. For that to be most useful, yes, MAXSCREENS should die, but I think you can treat that as yet another project. I suspect either of those projects alone is easily big enough for GSoC--possibly too big. A narrow focus is important. Jamey ___ 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] configure: introduce --{enable, disable}-syscall-clock
Tiago Vignatti wrote: > Some systems might not want to link against rt and pthread libraries simply to > implement monotonic clock, inside GetTimeInMillis(). For those, use a direct > syscall instead. > > This patch keeps the new syscall version disabled by default - therefore not > changing the original behaviour of the xserver build. > > The main concern was regarding some eventual performance degradation when not > going through optimized code in C library, or because syscall is varargs > based. That's actually my secondary concern - my primary concern is that on most non-Linux systems, the system libraries are the public, stable, supported, documented interface, and syscall() is a private implementation detail to those, which applications are strongly discouraged from calling directly. There's also the question of whether you know the right syscall arguments to use for every single kernel that Xorg runs on - though it appears SYS_clock_gettime is common to at least Linux & Solaris, I haven't checked any of the BSD's, Cygwin, or MacOS X. (Perhaps wrapping a #ifdef SYS_clock_gettime around the #define after you've included syscall.h would provide a little more safety there.) I don't object to having it as a special case for embedded systems which really need to avoid the small linker overhead, but don't want to make Xorg less portable, stable and debuggable on general-purpose OS'es. -- -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
GSoC Idea: Adding support for DMX screens to dix
Hi, Currently the DMX X server works well enough to get display walls up and running. What I'd like to do is make it so that from a running X server you can dynamically add and remove DMX screens, without the need of the seperate DMX proxy server. This would be useful for instance to setup/use network screens/projectors. In addition, over it could move to replace the dmx X server which would mean that dmx would always be up to date with modern extensions. I'm not sure how feasible it is to add it to dix, and if there's a lot of work that needs to be done before it could happen (Removing MAXSCREENS?). Sincerely, Cody Maloney ___ 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: We're over the extension event limit -- what are we going to do about it?
On Mon, 2010-03-29 at 09:35 -0700, Jeremy Huddleston wrote: > On Mar 29, 2010, at 08:23, Adam Jackson wrote: > > We could pretty easily bump DGA to major version 3, encode events with > > GE, and require newer client-side libs that translate back for ABI. > > After all, if you're using it _and_ you've updated your server, you can > > update your client libs too. It'd be slightly gross - for maximal ABI > > compat the client libs would want to lie about the protocol major > > version number, in case old games check for == 2 - but then DGA is > > pretty gross all around. > > What's keeping DGA on life-support these days? I thought there was > one last reason to keep it around, and XI2 was supposed to be the one > to put the nail in that puppy's coffin. Wouldn't it just be easier to > punt DGA in 1.9? A bunch of old apps use it for input events. You'd like to keep _something_ around for that. I'd be pretty sad if my Quake3 binaries stopped working. Faking it in the client-side library is certainly one way of doing it. - 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] configure: introduce --{enable, disable}-syscall-clock
On Mon, 2010-03-29 at 11:02 -0700, Alan Coopersmith wrote:
> Tiago Vignatti wrote:
> > Some systems might not want to link against rt and pthread libraries simply
> > to
> > implement monotonic clock, inside GetTimeInMillis(). For those, use a direct
> > syscall instead.
> >
> > This patch keeps the new syscall version disabled by default - therefore not
> > changing the original behaviour of the xserver build.
> >
> > The main concern was regarding some eventual performance degradation when
> > not
> > going through optimized code in C library, or because syscall is varargs
> > based.
>
> That's actually my secondary concern - my primary concern is that on most
> non-Linux systems, the system libraries are the public, stable, supported,
> documented interface, and syscall() is a private implementation detail to
> those, which applications are strongly discouraged from calling directly.
Yeah, it's not really something I want Linux to default to using either.
I mean, we're going to want input threads, so slicing off librt just
because it pulls in libpthread is a bit temporary. And Mesa's GLX
support pulls in pthreads already, so the class of device where this
applies is pretty thin.
atropine:~% size /lib/lib{rt,pthread}.so.?
textdata bss dec hex filename
27358 624 212 281946e22 /lib/librt.so.1
88930 8808352 98162 17f72 /lib/libpthread.so.0
14 dirty pages just isn't that much. I suspect even cursory examination
of heap usage would find worse offenses. It's fine as a
microöptimization, but that's about it.
- 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: [PULL] Bugzilla triage, take two
On Mon, Mar 29, 2010 at 11:54 AM, Keith Packard wrote: > On Fri, 26 Mar 2010 15:10:49 -0700, Corbin Simpson > wrote: > >> Corbin Simpson (1): >> dix: Fix a small potential memory leak in ProcRotateProperties. >> (#25216) > > No. ProcRotateProperties already frees props and saved in the out: > path. For reviewers -- please look at the code and not just the patch; > this patch looks 'obviously' correct until you see the surrounding code. Okay, will NAK the bug. >> Evgeny M. Zubok (1): >> xfree86: Change VBE version early-out to 1.2. (#22672) > > Please just post individual patches when they're small and independent > like this. I don't want to cherry-pick patches. Okay, will do that next time. Thanks for putting up with me! ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Bugzilla triage, take two
On Fri, 26 Mar 2010 15:10:49 -0700, Corbin Simpson wrote: > Corbin Simpson (1): > dix: Fix a small potential memory leak in ProcRotateProperties. (#25216) No. ProcRotateProperties already frees props and saved in the out: path. For reviewers -- please look at the code and not just the patch; this patch looks 'obviously' correct until you see the surrounding code. > Evgeny M. Zubok (1): > xfree86: Change VBE version early-out to 1.2. (#22672) Please just post individual patches when they're small and independent like this. I don't want to cherry-pick patches. -- keith.pack...@intel.com pgp2CqDCYyxCL.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
[PATCH v2] configure: introduce --{enable, disable}-syscall-clock
Some Linux systems might not want to link against rt and pthread libraries
simply to implement monotonic clock, inside GetTimeInMillis(). For those, use
a direct syscall instead. This is discouraged if someone doesn't know what's
doing.
This patch keeps the new syscall version disabled by default - therefore not
changing the original behaviour of the xserver build.
The main concern was regarding some eventual performance degradation when not
going through optimized code in C library, or because syscall is varargs
based. The simple program bellow (kudos to Adam Jackson) performs equally in
the practice, for both syscall and C library implementation, when executed in
several architectures:
#ifdef SYSCALL_MONOTONIC_CLOCK
#define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b)
#endif
int main(void) {
int i;
struct timespec tp;
for (i = 0; i < 1e7; i++)
clock_gettime(CLOCK_MONOTONIC, &tp);
return 0;
}
Signed-off-by: Tiago Vignatti
---
changes since v1 (kudos to alanc):
- added a description on configure.ac mentioning that only Linux support
syscall monotonic clock
- a conditional was set on os/utils.c (or should be inside configure.ac?) to
let only Linux falls in that code, thus providing more safety.
- changed the bit commit message warning about the private implementation of
syscall().
Myself, ajax, alanc and others discussed already on IRC about the performance
degradation. We all ran the program above, obtaining equally results within
different environments.
I guess also one will like to work out a bit the autoconf code. It's gigantic
and confusing! But lets work on it in another patch instead :)
I'd like to point that I'll work on the other alanc's suggestion, to improve
the current configure mess. I'll probably set up a --enable-embedded option
which will cover all bunch of other options that we currently have concerning
embedded environments. But will be in another patch...
configure.ac| 11 ++-
include/dix-config.h.in |3 +++
os/utils.c |5 +
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a6b058d..b1003dc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -632,6 +632,10 @@ AC_ARG_ENABLE(xaa,
AS_HELP_STRING([--enable-xaa], [Build XAA (defa
AC_ARG_ENABLE(vgahw, AS_HELP_STRING([--enable-vgahw], [Build Xorg
with vga access (default: enabled)]), [VGAHW=$enableval], [VGAHW=yes])
AC_ARG_ENABLE(vbe,AS_HELP_STRING([--enable-vbe], [Build Xorg with
VBE module (default: enabled)]), [VBE=$enableval], [VBE=yes])
AC_ARG_ENABLE(int10-module, AS_HELP_STRING([--enable-int10-module], [Build
Xorg with int10 module (default: enabled)]), [INT10MODULE=$enableval],
[INT10MODULE=yes])
+dnl clock_gettime() uses rt library and some systems might not want to link
+dnl against it, so the alternative is to use syscall directly. This is
+dnl discouraged if someone doesn't know what's doing.
+AC_ARG_ENABLE(syscall-clock,AS_HELP_STRING([--enable-syscall-clock], [Use
syscall to build monotonic clock instead C library based version. This option
is supported only in Linux (default: disabled)]), [SYSCALL_CLOCK=$enableval],
[SYSCALL_CLOCK=no])
dnl DDXes.
AC_ARG_ENABLE(xorg, AS_HELP_STRING([--enable-xorg], [Build
Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto])
@@ -912,7 +916,12 @@ AC_MSG_RESULT([$MONOTONIC_CLOCK])
if test "x$MONOTONIC_CLOCK" = xyes; then
AC_DEFINE(MONOTONIC_CLOCK, 1, [Have monotonic clock from clock_gettime()])
-LIBS="$LIBS $CLOCK_LIBS"
+if test "x$SYSCALL_CLOCK" = xyes; then
+AC_DEFINE(SYSCALL_MONOTONIC_CLOCK, 1,
+[Use syscall based monotonic clock])
+else
+LIBS="$LIBS $CLOCK_LIBS"
+fi
fi
AM_CONDITIONAL(XV, [test "x$XV" = xyes])
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 32e88d9..1fd6310 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -402,6 +402,9 @@
/* Have a monotonic clock from clock_gettime() */
#undef MONOTONIC_CLOCK
+/* Have a monotonic clock from a direct syscall */
+#undef SYSCALL_MONOTONIC_CLOCK
+
/* Define to 1 if the DTrace Xserver provider probes should be built in */
#undef XSERVER_DTRACE
diff --git a/os/utils.c b/os/utils.c
index 5a5a203..be51bcb 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -124,6 +124,11 @@ __stdcall unsigned long GetTickCount(void);
#include "picture.h"
#endif
+#if defined (SYSCALL_MONOTONIC_CLOCK) && defined(linux)
+#include
+#define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b)
+#endif
+
Bool noTestExtensions;
#ifdef COMPOSITE
Bool noCompositeExtension = FALSE;
--
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] configure: introduce --{enable, disable}-syscall-clock
On Mon, Mar 29, 2010 at 07:17:11PM +0200, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some systems might not want to link against rt and pthread libraries simply to
> implement monotonic clock, inside GetTimeInMillis(). For those, use a direct
> syscall instead.
>
> This patch keeps the new syscall version disabled by default - therefore not
> changing the original behaviour of the xserver build.
>
> The main concern was regarding some eventual performance degradation when not
> going through optimized code in C library, or because syscall is varargs
> based. The simple program bellow (kudos to Adam Jackson) performs equally in
> the practice, for both syscall and C library implementation, when executed in
> several architectures:
oops, I should insert something like this snip in this part of the mini-program:
#ifdef SYSCALL_MONOTONIC_CLOCK
#define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b)
#endif
>
> int main(void) {
> int i;
> struct timespec tp;
>
> for (i = 0; i < 1e7; i++)
> clock_gettime(CLOCK_MONOTONIC, &tp);
>
> return 0;
> }
>
> Signed-off-by: Tiago Vignatti
> ---
> Myself, ajax, alanc and others discussed already on IRC about the performance
> degradation. We all ran the program above, obtaining equally results within
> different environments.
>
> Besides, I think I could use AC_CHECK_FUNC(syscall) to check in fact if the
> call exists, but I thought that would be too much. Or not?
>
> I guess also one will like to work out a bit the autoconf code. It's gigantic
> and confusing! But lets work on it in another patch instead :)
>
>
> configure.ac| 10 +-
> include/dix-config.h.in |3 +++
> os/utils.c |5 +
> 3 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index a6b058d..8f42c60 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -632,6 +632,9 @@ AC_ARG_ENABLE(xaa,
> AS_HELP_STRING([--enable-xaa], [Build XAA (defa
> AC_ARG_ENABLE(vgahw, AS_HELP_STRING([--enable-vgahw], [Build Xorg
> with vga access (default: enabled)]), [VGAHW=$enableval], [VGAHW=yes])
> AC_ARG_ENABLE(vbe,AS_HELP_STRING([--enable-vbe], [Build Xorg
> with VBE module (default: enabled)]), [VBE=$enableval], [VBE=yes])
> AC_ARG_ENABLE(int10-module, AS_HELP_STRING([--enable-int10-module],
> [Build Xorg with int10 module (default: enabled)]), [INT10MODULE=$enableval],
> [INT10MODULE=yes])
> +dnl clock_gettime() uses rt library and some systems might not want to link
> +dnl against it, so the alternative is to use syscall directly.
> +AC_ARG_ENABLE(syscall-clock,AS_HELP_STRING([--enable-syscall-clock],
> [Use syscall to build monotonic clock instead C library based version
> (default: disabled)]), [SYSCALL_CLOCK=$enableval], [SYSCALL_CLOCK=no])
>
> dnl DDXes.
> AC_ARG_ENABLE(xorg,AS_HELP_STRING([--enable-xorg], [Build
> Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto])
> @@ -912,7 +915,12 @@ AC_MSG_RESULT([$MONOTONIC_CLOCK])
>
> if test "x$MONOTONIC_CLOCK" = xyes; then
> AC_DEFINE(MONOTONIC_CLOCK, 1, [Have monotonic clock from
> clock_gettime()])
> -LIBS="$LIBS $CLOCK_LIBS"
> +if test "x$SYSCALL_CLOCK" = xyes; then
> +AC_DEFINE(SYSCALL_MONOTONIC_CLOCK, 1,
> +[Use syscall based monotonic clock])
> +else
> +LIBS="$LIBS $CLOCK_LIBS"
> +fi
> fi
>
> AM_CONDITIONAL(XV, [test "x$XV" = xyes])
> diff --git a/include/dix-config.h.in b/include/dix-config.h.in
> index 32e88d9..1fd6310 100644
> --- a/include/dix-config.h.in
> +++ b/include/dix-config.h.in
> @@ -402,6 +402,9 @@
> /* Have a monotonic clock from clock_gettime() */
> #undef MONOTONIC_CLOCK
>
> +/* Have a monotonic clock from a direct syscall */
> +#undef SYSCALL_MONOTONIC_CLOCK
> +
> /* Define to 1 if the DTrace Xserver provider probes should be built in */
> #undef XSERVER_DTRACE
>
> diff --git a/os/utils.c b/os/utils.c
> index 5a5a203..a13ba3f 100644
> --- a/os/utils.c
> +++ b/os/utils.c
> @@ -124,6 +124,11 @@ __stdcall unsigned long GetTickCount(void);
> #include "picture.h"
> #endif
>
> +#ifdef SYSCALL_MONOTONIC_CLOCK
> +#include
> +#define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b)
> +#endif
> +
> Bool noTestExtensions;
> #ifdef COMPOSITE
> Bool noCompositeExtension = FALSE;
> --
> 1.6.0.4
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: be more verbose when we run out of opcodes
On Mon, Mar 29, 2010 at 10:40:50AM -0700, Paulo Zanoni wrote:
> Is is too late for 1.8?
>
> (pinging since we're talking about the number of events in another thread)
Thanks for reminding me about this, Paulo. The change attached to your
previous patch
Acked-by: Aaron Plattner
> On Mon, Mar 15, 2010 at 11:13 AM, Paulo Ricardo Zanoni
> wrote:
> > Em Sex, 2010-03-12 às 23:06 +0100, Julien Cristau escreveu:
> >> On Fri, Mar 12, 2010 at 12:01:41 -0300, Paulo Ricardo Zanoni wrote:
> >>
> >> > From: Paulo Ricardo Zanoni
> >> > Date: Thu, 11 Mar 2010 14:28:18 -0300
> >> > Subject: [PATCH] dix: be more verbose when we run out of opcodes
> >> >
> >> > If we run out of opcodes, nothing is print on the log, making the
> >> > problem hard to debug. In the current Xserver, if you enable some
> >> > extensions like multibuffer (+2 events) and use nvidia binary driver (+5
> >> > events) you can run out of opcode numbers.
> >> >
> >> > Signed-off-by: Paulo Ricardo Zanoni
> >> > ---
> >> > dix/extension.c | 5 -
> >> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/dix/extension.c b/dix/extension.c
> >> > index fb83af1..30dc313 100644
> >> > --- a/dix/extension.c
> >> > +++ b/dix/extension.c
> >> > @@ -83,8 +83,11 @@ AddExtension(char *name, int NumEvents, int NumErrors,
> >> > if (!MainProc || !SwappedMainProc || !MinorOpcodeProc)
> >> > return((ExtensionEntry *) NULL);
> >> > if ((lastEvent + NumEvents > LAST_EVENT) ||
> >> > - (unsigned)(lastError + NumErrors > LAST_ERROR))
> >> > + (unsigned)(lastError + NumErrors > LAST_ERROR)) {
> >> > + LogMessage(X_ERROR, "Not enabling extension %s: maximum number of "
> >> > + "events or errors exceeded.\n", name);
> >>
> >> funky whitespace on the LogMessage (not the same as the return below).
> >
> > I'm not sure if this is what you meant, but the attached version
> > replaces tabs with whitespaces. It applies fine with
> > --whitespace=error-all
> >
> > Btw, the whole file is not consistent about the usage of whitespaces or
> > tabs... Open it with vim and do "set list listchars=tab:>_" to see the
> > result. In most of the cases, tab is used when possible.
> >
> >
> >>
> >> > return((ExtensionEntry *) NULL);
> >> > + }
> >> >
> >> > ext = xalloc(sizeof(ExtensionEntry));
> >> > if (!ext)
> >>
> >> With that fixed,
> >> Reviewed-by: Julien Cristau
> >>
> >> 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
> >
>
>
>
> --
> Paulo R. Zanoni
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: be more verbose when we run out of opcodes
Is is too late for 1.8?
(pinging since we're talking about the number of events in another thread)
On Mon, Mar 15, 2010 at 11:13 AM, Paulo Ricardo Zanoni
wrote:
> Em Sex, 2010-03-12 às 23:06 +0100, Julien Cristau escreveu:
>> On Fri, Mar 12, 2010 at 12:01:41 -0300, Paulo Ricardo Zanoni wrote:
>>
>> > From: Paulo Ricardo Zanoni
>> > Date: Thu, 11 Mar 2010 14:28:18 -0300
>> > Subject: [PATCH] dix: be more verbose when we run out of opcodes
>> >
>> > If we run out of opcodes, nothing is print on the log, making the
>> > problem hard to debug. In the current Xserver, if you enable some
>> > extensions like multibuffer (+2 events) and use nvidia binary driver (+5
>> > events) you can run out of opcode numbers.
>> >
>> > Signed-off-by: Paulo Ricardo Zanoni
>> > ---
>> > dix/extension.c | 5 -
>> > 1 files changed, 4 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/dix/extension.c b/dix/extension.c
>> > index fb83af1..30dc313 100644
>> > --- a/dix/extension.c
>> > +++ b/dix/extension.c
>> > @@ -83,8 +83,11 @@ AddExtension(char *name, int NumEvents, int NumErrors,
>> > if (!MainProc || !SwappedMainProc || !MinorOpcodeProc)
>> > return((ExtensionEntry *) NULL);
>> > if ((lastEvent + NumEvents > LAST_EVENT) ||
>> > - (unsigned)(lastError + NumErrors > LAST_ERROR))
>> > + (unsigned)(lastError + NumErrors > LAST_ERROR)) {
>> > + LogMessage(X_ERROR, "Not enabling extension %s: maximum number of "
>> > + "events or errors exceeded.\n", name);
>>
>> funky whitespace on the LogMessage (not the same as the return below).
>
> I'm not sure if this is what you meant, but the attached version
> replaces tabs with whitespaces. It applies fine with
> --whitespace=error-all
>
> Btw, the whole file is not consistent about the usage of whitespaces or
> tabs... Open it with vim and do "set list listchars=tab:>_" to see the
> result. In most of the cases, tab is used when possible.
>
>
>>
>> > return((ExtensionEntry *) NULL);
>> > + }
>> >
>> > ext = xalloc(sizeof(ExtensionEntry));
>> > if (!ext)
>>
>> With that fixed,
>> Reviewed-by: Julien Cristau
>>
>> 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
>
--
Paulo R. Zanoni
___
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] configure: introduce --{enable, disable}-syscall-clock
Some systems might not want to link against rt and pthread libraries simply to
implement monotonic clock, inside GetTimeInMillis(). For those, use a direct
syscall instead.
This patch keeps the new syscall version disabled by default - therefore not
changing the original behaviour of the xserver build.
The main concern was regarding some eventual performance degradation when not
going through optimized code in C library, or because syscall is varargs
based. The simple program bellow (kudos to Adam Jackson) performs equally in
the practice, for both syscall and C library implementation, when executed in
several architectures:
int main(void) {
int i;
struct timespec tp;
for (i = 0; i < 1e7; i++)
clock_gettime(CLOCK_MONOTONIC, &tp);
return 0;
}
Signed-off-by: Tiago Vignatti
---
Myself, ajax, alanc and others discussed already on IRC about the performance
degradation. We all ran the program above, obtaining equally results within
different environments.
Besides, I think I could use AC_CHECK_FUNC(syscall) to check in fact if the
call exists, but I thought that would be too much. Or not?
I guess also one will like to work out a bit the autoconf code. It's gigantic
and confusing! But lets work on it in another patch instead :)
configure.ac| 10 +-
include/dix-config.h.in |3 +++
os/utils.c |5 +
3 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a6b058d..8f42c60 100644
--- a/configure.ac
+++ b/configure.ac
@@ -632,6 +632,9 @@ AC_ARG_ENABLE(xaa,
AS_HELP_STRING([--enable-xaa], [Build XAA (defa
AC_ARG_ENABLE(vgahw, AS_HELP_STRING([--enable-vgahw], [Build Xorg
with vga access (default: enabled)]), [VGAHW=$enableval], [VGAHW=yes])
AC_ARG_ENABLE(vbe,AS_HELP_STRING([--enable-vbe], [Build Xorg with
VBE module (default: enabled)]), [VBE=$enableval], [VBE=yes])
AC_ARG_ENABLE(int10-module, AS_HELP_STRING([--enable-int10-module], [Build
Xorg with int10 module (default: enabled)]), [INT10MODULE=$enableval],
[INT10MODULE=yes])
+dnl clock_gettime() uses rt library and some systems might not want to link
+dnl against it, so the alternative is to use syscall directly.
+AC_ARG_ENABLE(syscall-clock,AS_HELP_STRING([--enable-syscall-clock], [Use
syscall to build monotonic clock instead C library based version (default:
disabled)]), [SYSCALL_CLOCK=$enableval], [SYSCALL_CLOCK=no])
dnl DDXes.
AC_ARG_ENABLE(xorg, AS_HELP_STRING([--enable-xorg], [Build
Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto])
@@ -912,7 +915,12 @@ AC_MSG_RESULT([$MONOTONIC_CLOCK])
if test "x$MONOTONIC_CLOCK" = xyes; then
AC_DEFINE(MONOTONIC_CLOCK, 1, [Have monotonic clock from clock_gettime()])
-LIBS="$LIBS $CLOCK_LIBS"
+if test "x$SYSCALL_CLOCK" = xyes; then
+AC_DEFINE(SYSCALL_MONOTONIC_CLOCK, 1,
+[Use syscall based monotonic clock])
+else
+LIBS="$LIBS $CLOCK_LIBS"
+fi
fi
AM_CONDITIONAL(XV, [test "x$XV" = xyes])
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 32e88d9..1fd6310 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -402,6 +402,9 @@
/* Have a monotonic clock from clock_gettime() */
#undef MONOTONIC_CLOCK
+/* Have a monotonic clock from a direct syscall */
+#undef SYSCALL_MONOTONIC_CLOCK
+
/* Define to 1 if the DTrace Xserver provider probes should be built in */
#undef XSERVER_DTRACE
diff --git a/os/utils.c b/os/utils.c
index 5a5a203..a13ba3f 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -124,6 +124,11 @@ __stdcall unsigned long GetTickCount(void);
#include "picture.h"
#endif
+#ifdef SYSCALL_MONOTONIC_CLOCK
+#include
+#define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b)
+#endif
+
Bool noTestExtensions;
#ifdef COMPOSITE
Bool noCompositeExtension = FALSE;
--
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: DRI2 fixes
On Mon, 22 Mar 2010 15:03:30 -0700 Jesse Barnes wrote: > This is a collection of fixes from my personal server tree targeting the > 1.8 release. They're mostly small fixes, but they fix a few important > (i.e. common) cases with the new protocol code. > > Please review; I'll make any necessary changes, add the Reviewed-by > tags, and push to Keith. Ok, just updated my tree (master branch at git://people.freedesktop.org/~jbarnes/xserver) with the reviewed-by tags after some testing. Please pull it, hopefully into 1.8 since it fixes some ugly bugs (e.g. handling MSC counts in the past w/o hanging), or into 1.8.1 if you've already done with 1.8. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/3] Add vroot.h.
On Mon, Mar 29, 2010 at 12:06:36 +1100, Daniel Stone wrote: > > +/**Permission to use, copy, modify, and distribute this software and > > **/ > > +/**its documentation for any purpose and without fee is hereby > > **/ > > +/**granted, provided that the above copyright notice appear in all > > **/ > > +/**copies and that both that copyright notice and this permis- > > **/ > > +/**sion notice appear in supporting documentation, and that the > > **/ > > +/**name of Solbourne not be used in advertising > > **/ > > +/**in publicity pertaining to distribution of the software without > > **/ > > +/**specific, written prior permission. > > **/ > > The 'without fee' bit is the problem: they've not given you permission > to use/copy/modify/distribute in exchange for money. > hmm? All it's saying is they're not asking you for money in exchange for the permission to use/copy/modify/distribute, AIUI. 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: We're over the extension event limit -- what are we going to do about it?
On Mar 29, 2010, at 08:23, Adam Jackson wrote: > We could pretty easily bump DGA to major version 3, encode events with > GE, and require newer client-side libs that translate back for ABI. > After all, if you're using it _and_ you've updated your server, you can > update your client libs too. It'd be slightly gross - for maximal ABI > compat the client libs would want to lie about the protocol major > version number, in case old games check for == 2 - but then DGA is > pretty gross all around. What's keeping DGA on life-support these days? I thought there was one last reason to keep it around, and XI2 was supposed to be the one to put the nail in that puppy's coffin. Wouldn't it just be easier to punt DGA in 1.9? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL (updated again)] 4 patches from XQuartz
On Sun, 2010-03-28 at 15:49 -0700, Jeremy Huddleston wrote: > Sorry, we need one more. A small regression was found in our > release-candidate, and this fixes it. > > I think this should be the last PULL request from XQuartz before 1.8 ships. > > > The following changes since commit 579715f830fbbca9e1ecb17dc18176132f5969e7: > Rami Ylimaki (1): > os: Prevent backtrace from being stopped in noreturn functions. > > are available in the git repository at: > > git://anongit.freedesktop.org/~jeremyhu/xserver master > > Jeremy Huddleston (4): > XQuartz: Workaround weird key data reported on some layouts > GLX: Remove a redundant initialization This does claim to be generated code, but I don't believe that's been true in a while. I think Ian had a plan for this? > darwin: Generate crash reports on FatalError() > XQuartz: Re-query dixScreenOrigins as the value could've changed. Acked-by: Adam Jackson - 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: We're over the extension event limit -- what are we going to do about it?
On Sun, 2010-03-28 at 17:07 -0700, Aaron Plattner wrote: > 1. Move the new DRI2 extension events to the Generic Event Extension. > >This is the cleanest solution because DRI2 is the extension that changed >to put it over the limit. Also, the code is brand new and has not been >in an official release yet, so hopefully it's being used in the fewest >places. Not a bad idea in any event. (rimshot) > 2. Drop some other extension with events that nobody uses. > >I'm sure we'll argue endlessly about which extension to remove. Well, on a pre-DRI2 machine: % xdpyinfo -queryExtensions | grep base.event | sed -e 's/(.*event:/@/' -e 's/[,)].*//' | sort -n -k2 -t @ MIT-SCREEN-SAVER @ 64 XFree86-DGA @ 65 XVideo @ 72 Generic Event Extension @ 74 SHAPE @ 75 MIT-SHM @ 76 XInputExtension @ 77 SYNC @ 94 XKEYBOARD @ 96 XFIXES @ 97 RANDR @ 99 DAMAGE @ 101 GLX @ 102 SGI-GLX @ 102 Ignoring GLX (which wants to be GLX2 someday anyway), XI and DGA are the greedy ones. DGA's event encoding is shockingly stupid. It just translates events up from the core space into DGA space. But: /* Event names. Used in "type" field in XEvent structures. Not to be confused with event masks above. They start from 2 because 0 and 1 are reserved in the protocol for errors and replies. */ #define KeyPress2 #define KeyRelease 3 #define ButtonPress 4 #define ButtonRelease 5 #define MotionNotify6 So it requests 7 events, and then 0 and 1 never get used. Headdesk. We could pretty easily bump DGA to major version 3, encode events with GE, and require newer client-side libs that translate back for ABI. After all, if you're using it _and_ you've updated your server, you can update your client libs too. It'd be slightly gross - for maximal ABI compat the client libs would want to lie about the protocol major version number, in case old games check for == 2 - but then DGA is pretty gross all around. > 3. Decrease EXTENSION_EVENT_BASE from 64 to LASTEvent+1. > >I don't know the protocol well enough to know if that's even allowed, >and we'd have to audit some code to make sure it doesn't have any (event >>= 64 ==> extension) assumptions. The core protocol spec enforces this, sadly. We could fix it, but it'd require bumping the core protocol to 11.1, and hiding low-event-numbered extensions from 11.0 clients. - 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
Smooth scrolling
Sorry, just realised xorg-devel would be more fitting for my request... Hi, I'd like to make a proposal for mouse wheel handling. Today's pointer devices often have the capability to get more resolution on the mouse wheel velocity than the old click-by-click wheels. For example, for an IBM TrackPoint user the EmulateWheel option is very nice, but it's very disconcerting to see the screen move 3 lines at a time instead of one smooth motion. Same behaviour with mouse wheel emulation on touchpads. I know that there are attempts to correct this on the client side (i.e. Firefox smooth-scrolling) but because of the missing resolution in Xinput events the clickety-feel remains. I'm ready to put considerate effort into this issue, I just need someone with experience to tell me where to start. I see two ways of improving the resolution: 1) Just send more axis up/down button events This would break compability. Old software just expecting a few button "ticks" would suddenly scroll wildly. 2) Provide additional axis events with true resolution I realize that the GUI frameworks would also need work to make them use the new interface. Thank you, Max Schwarz ___ 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: Multitouch followup: gesture recognition?
Hi Florian, Can you point me to any arch stuff you've been reading? I'm trying to organize X documentation and wanna get everything possible that's useful to folks. thanks, Matt On Mon, Mar 29, 2010 at 4:08 PM, Florian Echtler wrote: > Hi again, I've been reading some background stuff on the X architecture, > so maybe I now have a better understanding of what we are actually > talking about: > >> > On one hand, I agree. But I believe that this problem is exactly what my >> > formalism solves. By a) allowing applications to customize gestures and >> > b) restricting them to certain screen regions (*), this isn't a >> > contradiction anymore. E.g. what's a zoom gesture to the first app on >> Which of course means the extension needs to transport the necessary >> information, or describe other means of transport (e.g. the props I >> mentioned, though as Peter pointed out, they're not good for live >> communication). >> This seems essential to your approach, so the feasibility of a server >> extension (oranything else, but a extension incurs overhead) depends a >> fair bit on the dynamics of your gesture customization. > Just specifying what gestures a specific window would be interested in > wouldn't usually be "live", would it? That's something defined at > creation time and maybe changed occasionally over the lifetime, but not > constantly. > >> > (*) whether these should be XWindows or something different, I don't >> > know yet. Is there an extension that allows arbitrary shapes for >> > XWindow objects, particularly with respect to input capture? >> the Shape extension does that. >> Yes, except you don't want to use it, because it would throw in far >> too many round trips, some of which might be delayed for ridiculously >> long periods of time, even while new events continue to be delivered. >> So, you basically want to keep it all in-client unless it's absolutely >> strictly necessary to do otherwise. > Hm, this might be a problem in the long run. The classical tricks for > dealing with non-rectangular UI objects (capturing and bubbling) > probably are not going to work here, as gestures can't easily be split > back into discrete input events. > >> > Let me try to summarize the possible approaches: >> > >> > 1. a pure userspace library which just converts gestures locally for one >> > specific client without knowledge of others (this is more or less what >> > Qt or libTISCH do right now, though in different ways) >> > >> > 2. a special client like a WM which intercepts input events and passes >> > additional gesture events to other clients (possible, but with some >> > caveats I haven't yet understood fully) >> > >> > 3. a separate server extension in its own right (possible, also with >> > some potential traps) >> > >> > 4. a patch to libXi using the X Generic Event Extension (same as 3, but >> > fastest to hack together and doesn't require any changes to the server.) >> > >> > Would you agree with that summary? >> I don't get what 4 might be. 2 and 3 aren't really alternatives, but >> different aspects of a server-side implementation. The special client >> can make the server deliver events, it can't do that itself. So it needs >> an appropriate own server extension or additional Xinput requests to >> facilitate delivery. Which you want libXi wrappers for. >> >> So whether a special client detects gestures or the server itself, the >> server needs to deliver events, and the client needs to be able to >> receive them. This is where XGE and libXi kick in. > Okay, it seems I'm slowly getting it. Please have a look at the attached > PDF - this should illustrate the combination of 2/4, correct? (the > normal Xinput events should probably be duplicated to the clients in the > classical manner). > > Yours, Florian > -- > 0666 - Filemode of the Beast > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Fix x86emu builds when using non-gnu compilers
On Tue, Mar 23, 2010 at 02:03:53AM +0100, ext Alan Coopersmith wrote: > Before this fix, the u64 type would not be defined, causing > x86emu/sys.c to fail to build: > "sys.c", line 102: syntax error before or at: ldq_u > "sys.c", line 102: syntax error before or at: * > > Since 64-bit types are now required by x86emu, assumes all platforms > either have a 64-bit long or a 64-bit long long (defined by C99). > > Signed-off-by: Alan Coopersmith > Acked-by: Adam Jackson > Acked-by: Matt Turner > --- Compiled-by: Tiago Vignatti (on ARM architecture, emulated by Scratchbox2). Watching the other replies from Keith, I've seen he's not so enthusiastic with the idea of not use stdint.h. Anyway, if this patch arrives on xserver, I'll be pushing to my libx86 tree either. Thanks, 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] OS: Add some noreturn and printf compiler attributes where appropriate
ext Mark Kettenis wrote: Given the fact that the "noreturn" attribute makes GCC generate code that makes debugging hard (see the recent discussion about adding some arm-specific compiler flags as a countermeasure), it's probably best to keep its usage to the absolute minimum. ___ 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 True, currently everything is fine if the "noreturn" function is defined in os/log.c, because that is compiled with "-mapcs-frame". The patch introduces the following change: -extern _X_EXPORT void OsAbort (void); +extern _X_EXPORT void OsAbort (void) _noreturn_attribute; OsAbort is defined in os/utils.c so some changes are needed to prevent problems with ARM. 1. Move OsAbort to os/log.c. 2. Or add os/utils.c to the list of files compiled with "-mapcs-frame" in os/Makefile.am. 3. Or remove the noreturn attribute for OsAbort. -- Rami ___ 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: Multitouch followup: gesture recognition?
Hi again, I've been reading some background stuff on the X architecture, so maybe I now have a better understanding of what we are actually talking about: > > On one hand, I agree. But I believe that this problem is exactly what my > > formalism solves. By a) allowing applications to customize gestures and > > b) restricting them to certain screen regions (*), this isn't a > > contradiction anymore. E.g. what's a zoom gesture to the first app on > Which of course means the extension needs to transport the necessary > information, or describe other means of transport (e.g. the props I > mentioned, though as Peter pointed out, they're not good for live > communication). > This seems essential to your approach, so the feasibility of a server > extension (oranything else, but a extension incurs overhead) depends a > fair bit on the dynamics of your gesture customization. Just specifying what gestures a specific window would be interested in wouldn't usually be "live", would it? That's something defined at creation time and maybe changed occasionally over the lifetime, but not constantly. > > (*) whether these should be XWindows or something different, I don't > > know yet. Is there an extension that allows arbitrary shapes for > > XWindow objects, particularly with respect to input capture? > the Shape extension does that. > Yes, except you don't want to use it, because it would throw in far > too many round trips, some of which might be delayed for ridiculously > long periods of time, even while new events continue to be delivered. > So, you basically want to keep it all in-client unless it's absolutely > strictly necessary to do otherwise. Hm, this might be a problem in the long run. The classical tricks for dealing with non-rectangular UI objects (capturing and bubbling) probably are not going to work here, as gestures can't easily be split back into discrete input events. > > Let me try to summarize the possible approaches: > > > > 1. a pure userspace library which just converts gestures locally for one > > specific client without knowledge of others (this is more or less what > > Qt or libTISCH do right now, though in different ways) > > > > 2. a special client like a WM which intercepts input events and passes > > additional gesture events to other clients (possible, but with some > > caveats I haven't yet understood fully) > > > > 3. a separate server extension in its own right (possible, also with > > some potential traps) > > > > 4. a patch to libXi using the X Generic Event Extension (same as 3, but > > fastest to hack together and doesn't require any changes to the server.) > > > > Would you agree with that summary? > I don't get what 4 might be. 2 and 3 aren't really alternatives, but > different aspects of a server-side implementation. The special client > can make the server deliver events, it can't do that itself. So it needs > an appropriate own server extension or additional Xinput requests to > facilitate delivery. Which you want libXi wrappers for. > > So whether a special client detects gestures or the server itself, the > server needs to deliver events, and the client needs to be able to > receive them. This is where XGE and libXi kick in. Okay, it seems I'm slowly getting it. Please have a look at the attached PDF - this should illustrate the combination of 2/4, correct? (the normal Xinput events should probably be duplicated to the clients in the classical manner). Yours, Florian -- 0666 - Filemode of the Beast variant2-4.pdf Description: Adobe PDF document ___ 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
