This logic was needed in older kernels that sometimes gave error messages
after coming back from resume (2.6.27 release kernels). I haven't seen any
log files that needed this reopen timer in a long time, suggesting that need
for it is gone.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
libX11 ModMap.c believes that GetModifierMapping can never return an error
Xserver devices.c believes that GetModifierMapping can return an error if
the ModMap couldn't be generated
According to the protocol document I have, libX11 is right, so adjust the
server to send back an empty modmap if
On Mon, 2009-10-19 at 15:02 -0400, Zack Rusin wrote:
On Monday 19 October 2009 08:58:22 Michel Dänzer wrote:
On Fri, 2009-10-16 at 00:29 +0100, ja...@vmware.com wrote:
From: Zack Rusin za...@vmware.com
This fixes the component alpha fallback in exa. I'm not sure which
branches this
On Tue, Oct 20, 2009 at 04:40:09PM +0900, Keith Packard wrote:
Excerpts from Peter Hutterer's message of Tue Oct 20 15:17:20 +0900 2009:
This logic was needed in older kernels that sometimes gave error messages
after coming back from resume (2.6.27 release kernels). I haven't seen any
log
Hello,
Thanks for looking into this!
2009/10/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-10-12 at 20:12 +0100, Renato Caldas wrote:
Hello,
First of all, I'm not subscribed to this list, so please include my
e-mail in the CC.
When using (trying to use...), kicad I managed to get
Excerpts from Peter Hutterer's message of Tue Oct 20 21:38:11 +0900 2009:
The reason it exists is solely the issue mentioned above and it has been the
source of a few bugs, some of them quite hard to debug. Most recently 23048
which took quite a while to triage. The reopen logic complicates
2009/10/20 Renato Caldas seventhguard...@gmail.com:
Hello,
Thanks for looking into this!
2009/10/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-10-12 at 20:12 +0100, Renato Caldas wrote:
Hello,
First of all, I'm not subscribed to this list, so please include my
e-mail in the CC.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/modes/xf86Crtc.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 506fbb9..7ea0a28 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++
xcb-util isn't currently in tinderbox xorg.modules but is now a dependency of
xlsclients
xcb-util doesn't build when srcdir != builddir
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Also add xcb-util
---
xorg.modules |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/xorg.modules b/xorg.modules
index eecfb63..4f051b2 100644
--- a/xorg.modules
+++ b/xorg.modules
@@ -28,6 +28,10 @@
branch repo=git.freedesktop.org module=xcb/libxcb
Hi,
Dont we still need the parenthesis in the recent libXaw change?
http://lists.freedesktop.org/archives/xorg-commit/2009-October/023796.html
--- ./src/save_AsciiSrc.c 2009-10-20 16:29:07.0 +0100
+++ ./src/AsciiSrc.c2009-10-20 16:34:55.0 +0100
@@ -1292,7 +1292,7 @@
-Original Message-
From: Colin Harrison [mailto:colin.harri...@virgin.net]
Sent: 20 October 2009 17:34
To: 'xorg-devel@lists.x.org'
Subject: PATCH Lost parenthesis in a recent libXaw change
Hi,
Dont we still need the parenthesis in the recent libXaw change?
Good catch - I only compiled with Sun cc before committing, which
doesn't issue this warning (relying on it's associated lint
program for that level of checking), and it's clear the original
contributor didn't compile his suggested patch with any compiler
before submitting, since his patch was
Signed-off-by: Adam Jackson a...@redhat.com
---
glx/glxdriswrast.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index 44f658f..20f9f90 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdriswrast.c
@@ -510,6 +510,9 @@
This allows you to set these environment variables to choose which
binary to
use rather than searching $PATH
Signed-off-by: Jeremy Huddleston jerem...@freedesktop.org
---
configure.ac |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index
I think xcb-util should also be put in the xorg-libs meta module as
well.
With that change,
Signed-off-by: Jeremy Huddleston jerem...@apple.com
On Oct 20, 2009, at 10:17, Jon TURNEY wrote:
Also add xcb-util
---
xorg.modules |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
On 20/10/2009 14:28, Jeremy Huddleston wrote:
+AC_ARG_VAR([GROFF], [Path to the 'groff' executable])
Perhaps this should be [Path to a groff executable that supports -ms],
since that is a specific issue that we want to check for (see my patch
from last night).
Yaakov
Cygwin/X
On 20/10/2009 14:34, Dan Nicholson wrote:
I'm pretty sure AC_PATH_PROG{,S} already check the environment
variables. What AC_ARG_VAR does is put a blurb in the --help output
and allow you to pass it on the command line. E.g., ./configure
GROFF=/foo/groff. Is that what you want?
Yes. The groff
On Oct 20, 2009, at 12:34, Dan Nicholson wrote:
I'm pretty sure AC_PATH_PROG{,S} already check the environment
variables. What AC_ARG_VAR does is put a blurb in the --help output
and allow you to pass it on the command line. E.g., ./configure
GROFF=/foo/groff. Is that what you want?
Yes.
On Tue, Oct 20, 2009 at 12:38 PM, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
On 20/10/2009 14:34, Dan Nicholson wrote:
I'm pretty sure AC_PATH_PROG{,S} already check the environment
variables. What AC_ARG_VAR does is put a blurb in the --help output
and allow you to pass it on
On Tue, Oct 20, 2009 at 12:40 PM, Jeremy Huddleston jerem...@apple.com wrote:
On Oct 20, 2009, at 12:34, Dan Nicholson wrote:
I'm pretty sure AC_PATH_PROG{,S} already check the environment
variables. What AC_ARG_VAR does is put a blurb in the --help output
and allow you to pass it on the
On Oct 20, 2009, at 12:44, Dan Nicholson wrote:
On Tue, Oct 20, 2009 at 12:38 PM, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
On 20/10/2009 14:34, Dan Nicholson wrote:
I'm pretty sure AC_PATH_PROG{,S} already check the environment
variables. What AC_ARG_VAR does is put a blurb
On 20/10/2009 14:44, Dan Nicholson wrote:
What I'm saying is that AC_PATH_PROGS already respects
GROFF=/foo/groff in the environment. AC_ARG_VAR means you can also
pass that on the command line to configure. Is that necessary or does
the existing support in AC_PATH_PROGS work (please check)?
And if strnlen isn't available? ...
http://tinderbox.x.org/builds/2009-10-20-0042/logs/xlsclients/#build
On Oct 19, 2009, at 18:41, Jamey Sharp wrote:
configure.ac |6
xlsclients.c | 524 ++
+
2 files changed, 430 insertions(+), 100
Jeremy Huddleston wrote:
And if strnlen isn't available? ...
I must have misread the docs. I thought autoconf was supposed to
generate strnlen when it isn't available.
Could somebody with better knowledge of auto* than I have please take a
look at this?
Thanks,
Peter Harris
--
On Tuesday 20 October 2009 07:25:02 Michel Dänzer wrote:
On Mon, 2009-10-19 at 15:02 -0400, Zack Rusin wrote:
On Monday 19 October 2009 08:58:22 Michel Dänzer wrote:
On Fri, 2009-10-16 at 00:29 +0100, ja...@vmware.com wrote:
From: Zack Rusin za...@vmware.com
This fixes the
On Tue, Oct 20, 2009 at 17:58:58 -0400, Peter Harris wrote:
Jeremy Huddleston wrote:
And if strnlen isn't available? ...
I must have misread the docs. I thought autoconf was supposed to
generate strnlen when it isn't available.
Could somebody with better knowledge of auto* than I have
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
First introduce something like 'pixman_init' function. Right now CPU type
detection is done on the first call to the function. It introduces some
minor overhead by having an extra pointer check on each function call.
Another problem is
On Tue, 2009-10-20 at 14:48 -0700, Jeremy Huddleston wrote:
Here it was removed from pixman yesterday:
http://cgit.freedesktop.org/pixman/commit/?id=9bcfc0ac547277d3a3f4e5ff0922450566ad8be8
Thanks. Pixman also does not specify AM_MAINTAINER_MODE, so it is
consistent. The maintainer mode is
Introduces 'u' format character, which behaves like 's', but leaves
UTF-8 encoding intact.
Property value is checked for UTF-8 validity according to RFC 3629.
If invalid, an error string is printed, followed by the string formatted
using 's'. ie:
PROP(UTF8_STRING) = Invalid UTF-8 string:
On 20/10/2009 17:42, Jeremy Huddleston wrote:
I'm not sure what magic to put in xlsclients.c to conditionally include
strnlen.h ... anybody want to chime in about that bit? This at least gets
it building with warning: implicit declaration of function .strnlen.
Incremental patch attached.
Keith,
Please pull from
git://people.freedesktop.org/~whot/xserver.git master
The majority of the log is made up by the removal of the dmx doxygen
generation from git (this is now auto-generated). A net removal of some
4 lines from the repo.
Another larger chunk is the removal of Xsdl.
On 19/10/2009 20:41, Jamey Sharp wrote:
commit 1839eabbdd697039a264fe7ebb3f4d26f08ddabe
Author: Peter Harrisphar...@opentext.com
Date: Mon Oct 19 18:21:26 2009 -0700
Rewrite xlsclients to use XCB, avoiding many (many) round trips
This is generating several warnings:
CC
This is C99, right? If so, I don't think it's acceptable.
On Oct 20, 2009, at 18:56, Yaakov (Cygwin/X) wrote:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
xcb_atom_t and xcb_window_t are both typedef'd as uint32_t.
Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
I noticed an INSTALL file in xlsclients and libXvMC today, and it was
quite annoying to work around since 'autoreconf -fvi' replaces it and
git wants to commit it. Should these files even be in git? Can I
nuke them for the betterment of humanity and since they get created by
autoreconf
On 20/10/2009 22:13, Jeremy Huddleston wrote:
This is C99, right? If so, I don't think it's acceptable.
XORG_STRICT_OPTION, which is part of XORG_DEFAULT_OPTIONS, calls
AC_PROG_CC_C99.
Yaakov
Cygwin/X
___
xorg-devel mailing list
36 matches
Mail list logo
