On Thu, Sep 12, 2013 at 1:21 PM, Ross Burton wrote:
> Signed-off-by: Ross Burton
>
If I'm reading this correctly this will cause the build to fail if
you don't give it the disable flag if xatracker is missing?
I'm on the fence if we want this, is this a problem you have
run into?
Cheers, Jako
Hi,
On 12 September 2013 07:37, Chris Wilson wrote:
> The approach taken in this patch is to first only enable VGA arbitration
> for drivers that require VGA resources. This is detected by moving the
> initialisation from the common xf86 code to the vgaHW module. This is
> strictly an ABI break a
On Thu, Sep 12, 2013 at 12:37:44PM +0100, Chris Wilson wrote:
> Presently, we wrap every single operation on every driver if the kernel
> reports that there is more than one VGA capable device in the system.
> This is irrespective of whether VGA is being used by any driver, and
> causes a significa
On Thu, Sep 12, 2013 at 12:04:14PM -0400, Adam Jackson wrote:
> ... unless you explicitly disabled it with -bs on the command line, or
> with the corresponding thing in xorg.conf.
>
> Signed-off-by: Adam Jackson
> ---
> composite/compinit.c | 9 +
> hw/xfree86/common/xf86Helper
On Thu, Sep 12, 2013 at 12:04:15PM -0400, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> composite/compinit.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/composite/compinit.c b/composite/compinit.c
> index 2001c8a..7f8d7cb 100644
> --- a/composite/comp
On Thu, Sep 12, 2013 at 12:04:13PM -0400, Adam Jackson wrote:
> Since we're using RedirectAutomatic to do this, we don't actually
> preserve contents when unmapped.
>
> Signed-off-by: Adam Jackson
> ---
> dix/window.c | 2 +-
> hw/xfree86/common/xf86Helper.c | 2 +-
> 2 files c
On Thu, Sep 12, 2013 at 11:55:57PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2013 at 12:37:44PM +0100, Chris Wilson wrote:
> > Presently, we wrap every single operation on every driver if the kernel
> > reports that there is more than one VGA capable device in the system.
> > This is irrespecti
On 09/11/2013 10:55 PM, Bart Massey wrote:
Well now I feel bad; I thought we had discussed this before and
everyone was OK with it. I should revert that patch now, I guess? My
sincere apologies for being premature.
For the record, though, I totally and vehemently disagree with the
"bad style" ar
For the series,
Reviewed-by: Peter Harris
One minor bikeshed-coloured nit:
On 2013-09-12 12:04, Adam Jackson wrote:
> compRedirectWindow(serverClient, pWin,
> CompositeRedirectAutomatic);
> pWin->backStorage = (pointer) (intptr_t) 1;
> -}
> -else {
> +
On Thu, Sep 12, 2013 at 6:19 AM, Mouse wrote:
>>> Whenever possible, variables should be declared at point of first
>>> assignment, so that it is clear that they have been initialized.
>
> There's nothing that says a top-of-block declaration can't include an
> initializer (to a dummy value if nece
For the series:
Reviewed-by: Jasper St. Pierre
On Thu, Sep 12, 2013 at 12:04 PM, Adam Jackson wrote:
> Since we're using RedirectAutomatic to do this, we don't actually
> preserve contents when unmapped.
>
> Signed-off-by: Adam Jackson
> ---
> dix/window.c | 2 +-
> hw/xfr
On Wed, 2013-09-11 at 17:16 -0700, Alan Coopersmith wrote:
> git grep shows nothing #include it either, and it's contents simply duplicate
> the DamageExtensionInit() prototype that's now been added to include/extinit.h
> by commit a1d41e311c21eb66.
>
> It looks like Daniels removed that line fro
Signed-off-by: Adam Jackson
---
composite/compinit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/composite/compinit.c b/composite/compinit.c
index 2001c8a..7f8d7cb 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -116,10 +116,10 @@ compChangeWindowAttrib
... unless you explicitly disabled it with -bs on the command line, or
with the corresponding thing in xorg.conf.
Signed-off-by: Adam Jackson
---
composite/compinit.c | 9 +
hw/xfree86/common/xf86Helper.c | 5 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git
Since we're using RedirectAutomatic to do this, we don't actually
preserve contents when unmapped.
Signed-off-by: Adam Jackson
---
dix/window.c | 2 +-
hw/xfree86/common/xf86Helper.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/window.c b/dix/windo
Hello,
On 14 July 2013 18:31, Daniel Stone wrote:
> Hi,
>
> On 14 July 2013 17:17, Mark Kettenis wrote:
>>> Make XOpenDisplay always call XInitThreads when opening a display, thus
>>> guarding it against possible disaster scenarios like calling
>>> XOpenDisplay without XInitThreads, then passing
>> Won't this break running two X servers on the same machine, where
>> both of them require VGA access?
> It still respects VT switching. I'm not entirely clear how you would
> run two *VGA* xservers simultaneously otherwise.
Two framebuffers? Or is there something about VGA that makes that
imp
>> Whenever possible, variables should be declared at point of first
>> assignment, so that it is clear that they have been initialized.
There's nothing that says a top-of-block declaration can't include an
initializer (to a dummy value if necessary).
>> I know of no plausible SE case for declari
Mouse writes:
>> The one bit I would like to have is declarations in for/while loops,
>> such as
>>
>> for (int i = 0; i < MAXSCREENS; i++)
>
> I wish I knew more about the spec. If that's equivalent to
>
> int i;
> for (i=0;i
> then I don't like it any better. But if i goes ou
Bart Massey writes:
> Well now I feel bad; I thought we had discussed this before and
> everyone was OK with it. I should revert that patch now, I guess? My
> sincere apologies for being premature.
Well, considering that it's already used in many places and that at
least X server specifies some
Alan Coopersmith writes:
> On 09/11/13 08:52 PM, Daniel Stone wrote:
>> Hi,
>>
>> On 11 September 2013 17:31, Mark Kettenis wrote:
From: Alan Coopersmith
Pushing the patch is easy - determining if it's our consensus to change
the X.Org coding style to allow this is the hard part.
On Thu, Sep 12, 2013 at 02:09:20PM +0200, Mark Kettenis wrote:
> > From: Chris Wilson
> > Date: Thu, 12 Sep 2013 12:37:44 +0100
> >
> > Presently, we wrap every single operation on every driver if the kernel
> > reports that there is more than one VGA capable device in the system.
> > This is irr
> From: Chris Wilson
> Date: Thu, 12 Sep 2013 12:37:44 +0100
>
> Presently, we wrap every single operation on every driver if the kernel
> reports that there is more than one VGA capable device in the system.
> This is irrespective of whether VGA is being used by any driver, and
> causes a signif
Presently, we wrap every single operation on every driver if the kernel
reports that there is more than one VGA capable device in the system.
This is irrespective of whether VGA is being used by any driver, and
causes a significant performance impact (4-5x) for CPU bound operations.
The approach t
Signed-off-by: Ross Burton
---
configure.ac | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/configure.ac b/configure.ac
index dccfb27..5fc34fb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,11 +85,6 @@ PKG_CHECK_EXISTS([xorg-server >= 1
I'm reverting it because I shouldn't have committed it without some
kind of consensus from X devs. If somebody else wants to champion it,
they're welcome. --Bart
On Thu, Sep 12, 2013 at 1:35 AM, Arnaud Fontaine wrote:
> Bart Massey writes:
>
>> You're right, of course. There is a small cost asso
Bart Massey writes:
> You're right, of course. There is a small cost associated with
> learning to read code written in a new style. Usually when I'm reading
> code, I find that I'm as interested in knowing what value a variable
> might hold as I am in its type, and I'm happy if I don't have to
>
You're right, of course. There is a small cost associated with
learning to read code written in a new style. Usually when I'm reading
code, I find that I'm as interested in knowing what value a variable
might hold as I am in its type, and I'm happy if I don't have to
scroll back too far for the loc
> From: Bart Massey
> Date: Wed, 11 Sep 2013 23:49:06 -0700
>
> I'm talking about a programming convention that is supported by the
> existing C language, has no associated cost, complexity or difficulty,
> does not make significant semantic or syntactic change to programs, is
> easy to learn, an
29 matches
Mail list logo
