On Thu, 30 Sep 2010 13:18:20 +0300, Adrian Bunk wrote:
> With libtool 2.2.10 the difference in build time is so small
> (< 5% with -j8 builds) that it isn't worth having this hack.
>
> Signed-off-by: Adrian Bunk
Applied.
c7e4222..a769f4c master -> master
--
keith.pack...@intel.com
pgpG
From: Trevor Woerner
Put all the logic to handle the NOQUIT (-n) mode into one location.
Signed-off-by: Trevor Woerner
---
build.sh | 97 +
1 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/build.sh b/build.sh
index 7
From: Trevor Woerner
Place into one location the logic to decide what to do with regards to
the following build modes: LISTONLY, RESUME, and BUILD_ONE.
Signed-off-by: Trevor Woerner
---
build.sh | 66 +++--
1 files changed, 38 insertion
Also of note... My G5 took an hour and a half just to 'make install'
with these changes. It looks like it's redoing some things in 'make
install' that it already did in 'make':
http://tinderbox.x.org/builds/2010-09-30-0022/
On Sep 29, 2010, at 09:31, Alan Coopersmith wrote:
Matt Dew wrote
On Thu, 2010-09-30 at 17:26 -0400, Trevor Woerner wrote:
> From: Trevor Woerner
>
> Place into one location the logic to decide what to do with regards to
> the following build modes: LISTONLY, RESUME, NOQUIT, and BUILD_ONE.
>
> Signed-off-by: Trevor Woerner
> ---
> build.sh | 163
>
On Thu, 2010-09-30 at 17:26 -0400, Trevor Woerner wrote:
> From: Trevor Woerner
>
> I would like to see the module/component title appear
> before the configuration/clone step.
>
> Signed-off-by: Trevor Woerner
> ---
> build.sh |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
On Thu, 2010-09-30 at 17:25 -0400, Trevor Woerner wrote:
> From: Trevor Woerner
>
> When reviewing a build log or watching a build, it is easier to see
> which
> module/component is being processed at arbitrary points if a clear,
> visual
> separation exists between the processing of each module
Adam Jackson wrote:
> On Tue, 2010-09-28 at 23:00 +0200, Mark Kettenis wrote:
>> Of course the same problem exists with SIGIO. After realizing how
>> much code was run from the SIGIO signal handler, and the VGA arbiter
>> issues related to that we decided to disable SIGIO on OpenBSD
>> (encouraged
Le 28/09/2010 17:16, Adam Jackson a écrit :
> It's correct but it's exactly as ridiculous as the original. How's this
> instead:
♥ !
Although...
> --- a/hw/xfree86/vbe/vbe.c
> +++ b/hw/xfree86/vbe/vbe.c
> @@ -529,67 +529,7 @@ VBEGetModeInfo(vbeInfoPtr pVbe, int mode)
>
> block = calloc(s
From: Trevor Woerner
Signed-off-by: Trevor Woerner
---
build.sh | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/build.sh b/build.sh
index a427b57..6c63cc5 100755
--- a/build.sh
+++ b/build.sh
@@ -1033,21 +1033,27 @@ date
if [ X"$nonexistent_components" != X
From: Trevor Woerner
Don't allow the "git clone" to succeed if a partial clone occurs
(i.e. hangup).
Signed-off-by: Trevor Woerner
---
build.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build.sh b/build.sh
index ae7d34e..a427b57 100755
--- a/build.sh
+++ b/build
From: Trevor Woerner
Only if cloning succeeds, set SRCDIR and CONFCMD. If SRCDIR is later
discovered the be empty the module can't be processed.
Signed-off-by: Trevor Woerner
---
build.sh | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/build.sh b/build.sh
i
From: Trevor Woerner
Offset case options so they are visually at a different level than
the actions they cause. Adjust them to match the existing case
statements in the main body of the script.
Signed-off-by: Trevor Woerner
---
build.sh | 10 +-
1 files changed, 5 insertions(+), 5 de
From: Trevor Woerner
Return early so large portions of code do not need to be indented.
Signed-off-by: Trevor Woerner
---
build.sh | 115 --
1 files changed, 59 insertions(+), 56 deletions(-)
diff --git a/build.sh b/build.sh
index 5
From: Trevor Woerner
Provide preconditions for some of the functions in build.sh script.
Signed-off-by: Trevor Woerner
---
build.sh | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 07cdea0..5be2337 100755
--- a/build.sh
+++ b/build.
From: Trevor Woerner
Provide explanations of functioning and behaviour for some of the functions
in build.sh script.
Signed-off-by: Trevor Woerner
---
build.sh | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 2bfc
From: Trevor Woerner
Place into one location the logic to decide what to do with regards to
the following build modes: LISTONLY, RESUME, NOQUIT, and BUILD_ONE.
Signed-off-by: Trevor Woerner
---
build.sh | 163 --
1 files changed, 116
From: Trevor Woerner
I would like to see the module/component title appear
before the configuration/clone step.
Signed-off-by: Trevor Woerner
---
build.sh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build.sh b/build.sh
index f73142c..3a57561 100755
--- a/build.s
From: Trevor Woerner
When reviewing a build log or watching a build, it is easier to see which
module/component is being processed at arbitrary points if a clear, visual
separation exists between the processing of each module/component.
Signed-off-by: Trevor Woerner
---
build.sh | 18 +++
From: Trevor Woerner
Hi everyone,
I've created a bunch of cleanup patches that I'm hoping will be considered
for the modular build script. I believe they make working with the script,
and using it, nicer.
Trevor Woerner (10):
Provide visual separation between modules.
Provide earlier module
On Tue, Aug 17, 2010 at 1:08 AM, Bartosz Brachaczek
wrote:
> 2010/8/17 Peter Hutterer :
>> Devices that send motion events with valuators other than x/y get core
>> motion events with unchanged x/y coordinates. This confuses some
>> applications.
>>
>> If the DeviceEvent does not have the x/y valu
On Thu, Sep 30, 2010 at 08:59:46PM +0200, Luc Verhaegen wrote:
>...
> How about if this sort of strategy was actively applied: changes from
> which the release manager assumes that they will break driver will be
> withheld until this fear is proven wrong or until the issues are
> solved/patches
2010/9/30 Rami Ylimäki :
> XNextEvent may call _XReadEvents and XSync calls _XReply. If XNextEvent is
> called before XSync from a different thread and there are no events, this
> may happen. It's a bug in Xlib implementation. Search for "FIXME" in
> http://cgit.freedesktop.org/xorg/lib/libX11/tree
On Thu, Sep 30, 2010 at 08:49:39PM +0200, Luc Verhaegen wrote:
> On Thu, Sep 30, 2010 at 01:51:27PM -0400, Adam Jackson wrote:
>
> > > > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote:
>
> > > > > As we learned on XDS, this sort of, what others would call, basic
> > > > > diligence, like
On Thu, Sep 30, 2010 at 01:51:27PM -0400, Adam Jackson wrote:
> > > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote:
> > > > As we learned on XDS, this sort of, what others would call, basic
> > > > diligence, like testing some graphics drivers first, would only be
> > > > reserved for d
2010/9/30 Julien Cristau :
> On Thu, Sep 30, 2010 at 17:44:23 +0200, Francesco Abbate wrote:
>
>> I will be grateful if I could have at least some hints. Thank you very
>> much in advance.
>
> Did you try the libxcb patch suggested by Peter?
Well, I've tried the patch of Peter and it did not chang
On Thu, 2010-09-30 at 16:11 +0200, Luc Verhaegen wrote:
> On Thu, Sep 30, 2010 at 09:52:30AM -0400, Adam Jackson wrote:
> > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote:
> > > As we learned on XDS, this sort of, what others would call, basic
> > > diligence, like testing some graphics dr
On 09/30/2010 06:44 PM, Francesco Abbate wrote:
What happens is that the secondary thread blocks during the XSync
operation until the main thread receive some events.
Hi,
XNextEvent may call _XReadEvents and XSync calls _XReply. If XNextEvent
is called before XSync from a different thread a
Good riddance.
Reviewed-by: Jeremy Huddleston
On Sep 30, 2010, at 03:18, Adrian Bunk wrote:
> With libtool 2.2.10 the difference in build time is so small
> (< 5% with -j8 builds) that it isn't worth having this hack.
>
> Signed-off-by: Adrian Bunk
>
> ---
> Makefile.am |2 -
> configure
On Thu, 2010-09-30 at 17:44 +0200, Francesco Abbate wrote:
> ...Xlib. What I would like to understand is if the
> technique that I'm using with the two threads is actually correct or
> not.
Xlib is not designed to be thread-safe. You should make Xlib calls from
only one thread, or ensure that use
On Thu, Sep 30, 2010 at 17:44:23 +0200, Francesco Abbate wrote:
> I will be grateful if I could have at least some hints. Thank you very
> much in advance.
Did you try the libxcb patch suggested by Peter?
Cheers,
Julien
___
xorg-devel@lists.x.org: X.Or
Hi all,
I don't really want to bother you guys, I know that you have all very
important developments ongoing. Actually I don't ask you to help me
about this particular problem that I've found with the snapshot
release of the Xserver/Xlib. What I would like to understand is if the
technique that I'
On Thu, Sep 30, 2010 at 08:49:55AM -0300, Otavio Salvador wrote:
> On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote:
> > On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
> >
> >> Agree.
> >> But that will revert totally 5/29/2010 patch.
> >>
> > It will be exactly equivalent to th
On Thu, 2010-09-30 at 15:49 +0800, Huang, FrankR wrote:
> So we can keep the current git code with no change.
You can, but the code is still _wrong_. Wrong wrong wrong. Your
hardware has real constraints; you have finite memory bandwidth, and
finite DAC speed, and finite CRTC addressibility. If
On Thu, Sep 30, 2010 at 09:52:30AM -0400, Adam Jackson wrote:
> On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote:
>
> > As we learned on XDS, this sort of, what others would call, basic
> > diligence, like testing some graphics drivers first, would only be
> > reserved for drivers which wo
On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote:
> As we learned on XDS, this sort of, what others would call, basic
> diligence, like testing some graphics drivers first, would only be
> reserved for drivers which would've been merged back into the server
> tree.
You're putting words i
On Thu, Sep 30, 2010 at 3:18 AM, Adrian Bunk wrote:
> With libtool 2.2.10 the difference in build time is so small
> (< 5% with -j8 builds) that it isn't worth having this hack.
>
> Signed-off-by: Adrian Bunk
Reviewed-by: Dan Nicholson
___
xorg-devel@
On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote:
> On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
>
>> Agree.
>> But that will revert totally 5/29/2010 patch.
>>
> It will be exactly equivalent to the current code. So no.
It is not equivalent.
--
Otavio Salvador
On Thu, Sep 30, 2010 at 01:18:20PM +0300, Adrian Bunk wrote:
> With libtool 2.2.10 the difference in build time is so small
> (< 5% with -j8 builds) that it isn't worth having this hack.
>
> Signed-off-by: Adrian Bunk
Reviewed-by: Daniel Stone
signature.asc
Description: Digital signature
With libtool 2.2.10 the difference in build time is so small
(< 5% with -j8 builds) that it isn't worth having this hack.
Signed-off-by: Adrian Bunk
---
Makefile.am |2 -
configure.ac |1 -
m4/dolt.m4 | 181 --
3 files changed,
Agree.
But that will revert totally 5/29/2010 patch.
Thanks,
Frank
> -Original Message-
> From: Julien Cristau [mailto:jcris...@debian.org]
> Sent: 2010?9?30? 14:28
> To: Huang, FrankR
> Cc: Geode Mailing List; q-f...@iki.fi; xorg-devel@lists.x.org
> Subject: Re: xf86-video-geode: Chang
So we can keep the current git code with no change.
> -Original Message-
> From: Julien Cristau [mailto:jcris...@debian.org]
> Sent: 2010?9?30? 15:47
> To: Huang, FrankR
> Cc: Otavio Salvador; Geode Mailing List; q-f...@iki.fi; xorg-
> de...@lists.x.org
> Subject: Re: xf86-video-geode: Cha
On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
> Agree.
> But that will revert totally 5/29/2010 patch.
>
It will be exactly equivalent to the current code. So no.
Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: h
Done. Thanks.
5b64f85..4d2542a server-1.9-branch -> server-1.9-branch
This will likely be what gets tagged as 1.9.1rc1 on Friday. If anyone has
anything else before then, please drop me a line.
On Sep 29, 2010, at 11:11, Adam Jackson wrote:
> Jeremy, please pull this from this branch. F
44 matches
Mail list logo
