Re: Multitouch followup: gesture recognition?
On Fri, Apr 02, 2010 at 10:52:28AM +0200, Florian Echtler wrote:
> > >>> 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.
> > >> Which is why a declarative approach is OK for that. It's the dynamics
> > >> that make it harder. More specificially, the dynamic part of your
> > >> formalism likely needs tailored requests.
> > > The reason for this being that the special client won't be notified of
> > > property changes on other client windows, correct?
> > Not quite, the sgc could probably register for prop changes. By
> > 'dynamics' I was referring to cancelling a gesture or other gesture
> > state feedback a client may want to send. Props aren't good for that,
> > but requests are.
> > In requests, you're free to define semantics, whereas props are limited
> > and quite racy.
> OK, I see. I'll probably stay with properties for the first attempt (the
> protocol used in my userspace lib doesn't require any such realtime callbacks
> right now). I'll probably blatantly ignore _any_ performance-related
> issues in the prototype, just to get a general feel for the problem.
>
> > >> If you want to try a special client, it's therefore sensible to divide
> > >> your requests and events into route-through (client -> special gesture
> > >> client or sgc -> client) and server-processed (server->sgc or sgc->
> > >> server), if possible.
> > > As far as I understand the architecture, everything except the plain
> > > input events would be just routed through the server between the two
> > > clients. In fact, I guess that after defining some custom events in
> > Yes, part of the idea is that the server provides only the
> > infrastructure. Routing, simple state tracking, somesuch.
> Good - seems I've finally understood that part :-)
>
> > > inputproto, it should be possible to send them through
> > > XSend{Extension}Event?
> > At first glance it looks suitable, but I'm not convinced it is
> > appropriate. You'll want the server to select which clients get events,
> > as is done with Xi event masks. This way, the gesture client doesn't
> > need to know about all the windows out there.
> > Also, I recall Xi2 and Xi1 (XSendExtensionEvent) shouldn't be mixed.
> I've had a brief look at the code in libXi, and AFAICT there's nothing
> to prevent this from working with any custom event, as long as
> _XiEventToWire is adapted, too. Peter, maybe you could comment on this?
XSendExtensionEvent should work with XI2 events though I'm pretty sure at
the moment it doesn't. Still, there's no particular reason why it can't work
other than that the code is missing.
In regards to not mixing events, I discourage clients from using XI1 and XI2
events though it's basically allowed. XSendExtensionEvent is mainly a
mechanism to get events re-sent (though these events are ignored by many
clients) and thus doesn't fall into this category of "mixing" events.
> > > // select motion events for entire screen
> > > XIEventMask mask;
> > > mask.deviceid = XIAllDevices;
> > > mask.mask_len = XIMaskLen( XI_LASTEVENT );
> > > mask.mask = (unsigned char*)calloc( mask.mask_len, sizeof(char) );
> > >
> > > XISetMask( mask.mask, XI_Motion );
> > > XISetMask( mask.mask, XI_ButtonPress );
> > > XISetMask( mask.mask, XI_ButtonRelease );
> > >
> > > XISelectEvents( display, DefaultRootWindow(display), &mask, 1 );
> > > free( mask.mask );
> > >
> > > to capture all XInput events, however, I believe that's also quite
> > > flawed. What other options exist?
> > To me it seems sane.
I don't think it's a future-proof approach. This approach only works because
there are no other clients that make extensive use of SD events. Once you
have multiple clients, especially those that grab/ungrab SDs as they see fit
the approach above will be troublesome. Unfortunately, it's the only
approach possible at this point for solutions that aren't integrated into
the receiving client.
grabs are generally a problem if you consider to have the gesture-client a
different client. I don't think that would work particularly well, either it
has to be in the receiving client or in the server itself.
> > This replication of all input is one of the reasons for the 'special' in
> > 'special gesture client'. Whatever it shall be it should probably be a
> > part of Xi2. What leads you to think the above is flawed ?
> The main reason why this code isn't yet sufficient IMHO is that I
> haven't yet found out how to get some additional data from the received
> events, particularly
> a) which client window the event is actually targeted at and
> b) what the position in window-relative coordinates is.
>
> These are probably related, can you give me a hint how to retrieve this
> information?
you can't, not with the above approach. The client window is filled in as
the event is delivered, in your
Re: GSoC Idea: Adding support for DMX screens to dix
I Just want to say I won't be able to apply for GSoC this summer as other things have come up. I'll probably work on the X video driver which renders to an X screen though in any spare time I have over the summer. If someone else wants to feel free to use any of my ideas for your own GSoC application, or work on any independently. These are some features I'd really like to see make it into X. They would eliminate a lot of redundant code and add some cool new functionality. Thanks, Cody Maloney On Tue, Mar 30, 2010 at 3:41 PM, Cody Maloney wrote: > Thanks for your comments. I'll probably submit a proposal for both > pieces you broke it into, although I'd lean towards the graphics > hotplugging (specifically writing patches to add the necessary new > hooks to the porting layer, as well as patches to implement the hooks > in the xfree86 backend). If I end up with time left in the summer > after implementing the hooks, then I'd work implementing the udev > hooks. > > Thanks, > Cody Maloney > > On Mon, Mar 29, 2010 at 12:32 PM, Jamey Sharp wrote: >> 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. >> >> >> >> 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
Software cursor broken with several X screens
The DC code is broken for setups with several screens. Devs only have one pSave pixmap and there's no code to thrash them like p[Save|Restore]GC. That means if you have two X screens and force SW cursor on both, the server will end up passing a bunch of CopyAreas with mismatching screens to the driver, which can fail horribly if the driver does a good job abstracting screens away from each other. The GC thrashing code looks a bit clunky in the first place. Can we just have an array with numScreens elements for the per-device GCs and pixmaps? Thanks, - Pierre-Loup ___ 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 evdev] When building against server 1.8, install 00-evdev.conf.
On Mon, Apr 5, 2010 at 4:18 PM, Peter Hutterer wrote: > On Thu, Apr 01, 2010 at 10:56:27AM -0700, Dan Nicholson wrote: >> On Wed, Mar 31, 2010 at 6:22 PM, Alan Coopersmith >> wrote: >> > Dan Nicholson wrote: >> >> Not quite. The hal backend ignores any devices that don't have the >> >> input.x11_driver key set. We could change that, but it might be better >> >> to keep this behavior for consistency. >> > >> > So right now, if I start up Xorg from git master on OpenSolaris, where >> > we still use HAL since I haven't had a chance to code up the replacement >> > code yet, it finds the devices fine via the HAL .fdi file shipped with >> > Xorg that maps them to the kbd & mouse driver - is there anything we need >> > to do to stick with this for 1.8? Will any of the settings in the current >> > config/x11-input.fdi be moved into xorg.conf.d files? Should they? >> >> If you're using the hal backend, you don't have to change anything. >> The options are still imported from the fdi. What gets tricky is when >> you start mixing the fdi and InputClass settings. Since Peter and I >> decided that the InputClass settings should take precedence over the >> options passed in by the backend, you could have legitimate fdi >> settings dropped. The case I think would bite you is where a user has >> a custom fdi file setting the driver to synaptics and then you have a >> generic InputClass that sets it back to mouse. I don't really know the >> best way to handle that besides porting the existing fdi files to >> xorg.conf.d files. > > yeah, that's what we had to tell our users too - change HAL files to > xorg.conf.d and move on. HAL is using xml files so there's the option of > creating xslt-based conversion tools to aid with that process. Actually, I was going to take a stab at converting this script: http://cgit.freedesktop.org/~teuf/media-player-info/tree/tools/fdi2mpi.py to outputting InputClass sections. -- 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 evdev] When building against server 1.8, install 00-evdev.conf.
On Thu, Apr 01, 2010 at 10:56:27AM -0700, Dan Nicholson wrote: > On Wed, Mar 31, 2010 at 6:22 PM, Alan Coopersmith > wrote: > > Dan Nicholson wrote: > >> Not quite. The hal backend ignores any devices that don't have the > >> input.x11_driver key set. We could change that, but it might be better > >> to keep this behavior for consistency. > > > > So right now, if I start up Xorg from git master on OpenSolaris, where > > we still use HAL since I haven't had a chance to code up the replacement > > code yet, it finds the devices fine via the HAL .fdi file shipped with > > Xorg that maps them to the kbd & mouse driver - is there anything we need > > to do to stick with this for 1.8? Will any of the settings in the current > > config/x11-input.fdi be moved into xorg.conf.d files? Should they? > > If you're using the hal backend, you don't have to change anything. > The options are still imported from the fdi. What gets tricky is when > you start mixing the fdi and InputClass settings. Since Peter and I > decided that the InputClass settings should take precedence over the > options passed in by the backend, you could have legitimate fdi > settings dropped. The case I think would bite you is where a user has > a custom fdi file setting the driver to synaptics and then you have a > generic InputClass that sets it back to mouse. I don't really know the > best way to handle that besides porting the existing fdi files to > xorg.conf.d files. yeah, that's what we had to tell our users too - change HAL files to xorg.conf.d and move on. HAL is using xml files so there's the option of creating xslt-based conversion tools to aid with that process. 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 xfree86] Don't keep a pointer to a possibly freed cursor when changing screens, preventing a crash in xf86CursorEnableDisableFBAccess() trying to restore it.
On Fri, Apr 02, 2010 at 12:48:21PM -0700, Pierre-Loup A. Griffais wrote: > Signed-off-by: Pierre-Loup A. Griffais > --- > hw/xfree86/ramdac/xf86Cursor.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c > index 7f23d9e..f5f0873 100644 > --- a/hw/xfree86/ramdac/xf86Cursor.c > +++ b/hw/xfree86/ramdac/xf86Cursor.c > @@ -312,6 +312,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen, > CursorPtr pCurs, > xf86SetCursor(pScreen, NullCursor, x, y); > ScreenPriv->isUp = FALSE; > } > +ScreenPriv->CurrentCursor = NullCursor; > return; > } > Reviewed-by: Peter Hutterer merged into my tree, 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] dix: be more verbose when we run out of opcodes
On Mon, Mar 15, 2010 at 11:13:06AM -0300, 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
>
>
> From c54afc8805dbc9482a1b6c8b85caf0aad2820fe9 Mon Sep 17 00:00:00 2001
> 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);
> return((ExtensionEntry *) NULL);
> +}
>
> ext = xalloc(sizeof(ExtensionEntry));
> if (!ext)
> --
> 1.6.4.4
Merged, thank you.
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
libxf86config no longer usable
Hi, commit e1165632bdfbd720889ed1adf5f7ab338032c0ee has added a call to xf86CheckBoolOption to Layout.c but this function (obviously) does not end up in libxf86config since it's not in .../parser but in .../common/xf86Option.c so linking against libxf86config (if installed as possible via configure --enable-install-libxf86config) will end up with: undefined symbol: xf86CheckBoolOption I just can't come up with a clean idea how to solve this ... -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (r...@novell.com,r...@suse.de,bugfin...@t-online.de) -- Linux MacBookRudi.suse.de 2.6.33-6-desktop #1 SMP PREEMPT 2010-02-25 20:06:12 +0100 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ___ 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] XGE: Don't reserve an extension event
On Tue, Mar 30, 2010 at 11:01:09AM -0700, Aaron Plattner wrote: > The Generic Event Extension extension uses the "GenericEvent" core event > type, so it doesn't need to also reserve an extension event. > > Signed-off-by: Aaron Plattner > --- > ge.h|4 +--- > geproto.txt | 11 ++- > 2 files changed, 7 insertions(+), 8 deletions(-) > > diff --git a/ge.h b/ge.h > index 6521698..aca1d8a 100644 > --- a/ge.h > +++ b/ge.h > @@ -47,9 +47,7 @@ > * > */ > > -#define X_GenericEvent0 > - > -#define GENumberEvents(X_GenericEvent + 1) > +#define GENumberEvents0 > > /* > * > diff --git a/geproto.txt b/geproto.txt > index 654cd0f..1054def 100644 > --- a/geproto.txt > +++ b/geproto.txt > @@ -5,7 +5,7 @@ > > 1. Introduction > 2. Extension Initialization > -3. Extension Events > +3. Events > 4. Notes > > _ > @@ -47,14 +47,15 @@ The name of this extension is "Generic Event Extension" > > As of version 1.0, no other requests are provided by this extension. > _ > -3. Extension Events > +3. Events > > -GE defines a single event, to be used by all extensions. The event's > structure > -is similar to a reply. > +GE defines a single event, to be used by all extensions. The event's > structure > +is similar to a reply. This is a core protocol event, ID 35, and is not > itself > +an extension event. > > ┌─── > GenericEvent > - type: BYTE; always GenericEvent > + type: BYTE; always GenericEvent (35) > extension: CARD8; extension offset > sequenceNumber: CARD16 low 16 bits of request seq. number > length: CARD32 length > -- > 1.6.3.3 Reviewed-by: Peter Hutterer Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] doc: specify 1.6.1 as the minimum version for doxygen.
Older versions generate filenames that are different from the ones listed in the Makefile. Reviewed-by: Jeremy Huddleston Signed-off-by: Gaetan Nadon --- configure.ac |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 591d2b4..a76eda3 100644 --- a/configure.ac +++ b/configure.ac @@ -34,10 +34,10 @@ AM_MAINTAINER_MODE # Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.5 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.5) + [m4_fatal([must install xorg-macros 1.6 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.6) XORG_DEFAULT_OPTIONS -XORG_WITH_DOXYGEN +XORG_WITH_DOXYGEN(1.6.1) m4_ifndef([XORG_FONT_MACROS_VERSION], [m4_fatal([must install fontutil 1.1 or later before running autoconf/autogen])]) XORG_FONT_MACROS_VERSION(1.1) -- 1.6.0.4 Transfering to release management, to be applied to git master ___ 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] Remove deprecated "nv" driver from autoconfiguration list
On Fri, 2010-04-02 at 00:27 +0200, Mark Kettenis wrote: > > From: Adam Jackson > > Date: Thu, 01 Apr 2010 14:19:37 -0400 > > On Wed, 2010-03-31 at 23:18 +0200, Mark Kettenis wrote: > > > The vesa driver only works on i386/amd64. Where does this leave users > > > of other architectures? Quite a few PowerPC Mac's have nvidia hardware. > > > > There's no deep reason for this to be true. nvidia cards with PC BIOSes > > would work fine under x86emu, assuming we emulate enough of the system > > ROM calls. And nv card BIOSes tend not to call system ROM services that > > much. > > Well, I was thinking specifically about the origional graphics > hardware that shipped with these machines, which will have an Open > Firmware ROM. nouveau supports those, I'm reasonably sure. If it doesn't, Linux also has offb for Open Firmware devices. Your OS may vary. - 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: [Mesa3d-dev] Emergency Mesa 7.8.1 release coming this Monday.
On Sun, 04 Apr 2010 16:54:45 -0700 Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > All, > > Over the weekend I was alerted that some values in Mesa's glxext.h do > not match the values in the OpenGL registry. Specifically, the value of > GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK is wrong both in name and in value. > I am going to fix this by syncing the official version of glxext.h from > the Khronos website. In the mean time please do not distribute or use > the copy of glxext.h in Mesa. Use version 27 or later from the > OpenGL.org website: > > http://www.opengl.org/registry/api/glxext.h > > I won't have time to make the release until Monday morning PDT. Sorry about that, now I know I shouldn't have edited that files. For future reference those creating new extensions should: - add temporary values to glx.h with an 'X' appended to indicate a temporary value (e.g. INTELX_swap_event) - never edit glxext.h - remove the temp values once the updated glxext.h arrives from the registry Is that all Ian? 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] configure: introduce --{enable, disable}-syscall-clock
On Fri, 2010-04-02 at 11:13 -1000, Eric Anholt wrote: > On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson wrote: > > 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. > > At the moment, clock_gettime() is the only reason I can't get Mesa off > of libpthread. Before a bunch of ugly hacking in libdrm, the overhead > From pthreads presence was around 10% CPU time on CPU-bound apps on > i965. These days it's down to a few percent. I'm not sure you're blaming the right piece of the world there. If you're referring to: commit 0d7ad7e43ca212b1e9f16cd18f36493cab455e61 Author: Eric Anholt Date: Tue Oct 20 14:19:38 2009 -0700 intel: Only call clock_gettime once per unreference_final. then I'm pretty sure the overhead there was calling clock_gettime at all. The implementation doesn't have any interaction with thread support. Compare runtimes from: http://people.freedesktop.org/~ajax/syscall/ Pretty sure you'll find them to be just about identical. > It seems to me like the real problem is that clock_gettime() isn't in > glibc without the pthreads cost. Perhaps someone could look into that > instead of hacking around it in its consumers? The clock_gettime() implementation is in librt because that's where all the POSIX realtime stuff lives. Moving it into glibc wouldn't be especially difficult, though you'd need to get the symbol versioning right. - 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 4/4] xfree86: Fix reference to SGML entities
On Thu, 2010-03-25 at 03:46 -0500, Yaakov (Cygwin/X) wrote: > From: Yaakov Selkowitz > > XORG_CHECK_LINUXDOC sets the SGML search path to the parent of X11/defs.ent. > > Signed-off-by: Yaakov Selkowitz > --- > hw/xfree86/doc/sgml/DESIGN.sgml |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/xfree86/doc/sgml/DESIGN.sgml b/hw/xfree86/doc/sgml/DESIGN.sgml > index 5beff65..e95df79 100644 > --- a/hw/xfree86/doc/sgml/DESIGN.sgml > +++ b/hw/xfree86/doc/sgml/DESIGN.sgml > @@ -1,5 +1,5 @@ > - %defs; > + %defs; > > > Tested-by: Gaetan Nadon 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:macros] doc: add XORG_CHECK_SGML_DOCTOOLS to detect xorg-sgml-doctools
On Thu, Mar 25, 2010 at 4:12 PM, Yaakov (Cygwin/X) wrote: > From: Yaakov Selkowitz > > Trying to find X11/defs.ent with AC_CHECK_FILE does not work when > cross-compiling, and the check assumed that xorg-sgml-doctools is > installed to the same prefix which need not always be the case. > > xorg-sgml-doctools 1.4 provides a pkg-config file which we can use > instead, fixing both those cases. This macro is provided in util-macros > instead of with xorg-sgml-doctools, otherwise the latter would become a > hard dependency just to run autoreconf. > > Signed-off-by: Yaakov Selkowitz > --- > xorg-macros.m4.in | 54 > 1 files changed, 33 insertions(+), 21 deletions(-) > > diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in > index 055c83e..916b472 100644 > --- a/xorg-macros.m4.in > +++ b/xorg-macros.m4.in > @@ -178,6 +178,31 @@ AC_SUBST([DRIVER_MAN_DIR]) > AC_SUBST([ADMIN_MAN_DIR]) > ]) # XORG_MANPAGE_SECTIONS > > +# XORG_CHECK_SGML_DOCTOOLS > +# > +# Minimum version: 1.7.0 > +# > +# Defines the variable XORG_SGML_PATH containing the location of X11/defs.ent > +# provided by xorg-sgml-doctools, if installed. > +AC_DEFUN([XORG_CHECK_SGML_DOCTOOLS],[ > +AC_MSG_CHECKING([for X.Org SGML entities]) > +XORG_SGML_PATH= > +PKG_CHECK_EXISTS([xorg-sgml-doctools], This should take an optional version number as an argument in case you need newer doctools or something. I think all it would take is this: PKG_CHECK_EXISTS([xorg-sgml-doctools] m4_ifval([$1], [ >= $1]), ... -- 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:macros] doc: add XORG_CHECK_SGML_DOCTOOLS to detect xorg-sgml-doctools
On Sun, 2010-04-04 at 13:23 -0500, Yaakov (Cygwin/X) wrote: > On 2010-04-03 09:59, Gaetan Nadon wrote: > > On Fri, 2010-04-02 at 13:12 -0500, Yaakov (Cygwin/X) wrote: > >> To implement this we need to: > >> > >> 1) Push these commits to doctools and macros. > >> 2) Version bump and release doctools-1.4. > >> 3) Version bump and release macros-1.7.0. > >> > >> Who shall do this, and when? > >> > > I am available to do any/all of these tasks (after the week-end). I > > usually take care of macros. > > I'll let you layout the "release plan". > > I have pushed the commits to doctools and macros. Could you handle the > version bumps and releases for both modules at your convenience? Will do. > > > Yaakov > Cygwin/X > ___ > 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 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
