On Thu, Jul 5, 2012 at 8:38 PM, HacKurx hack...@gmail.com wrote:
Hello,
Can you help me?
I cannot use 120Hz on my Samsung 2233RZ with nouveau.
My xorg.conf :
https://forums.gentoo.org/viewtopic-t-929124.html
Thanks
Best regards,
HacKurx
www.hackurx.info
1680x1050x0.0 218.59 1680
1728 1760 1840 1050 1053 1059 1080 +hsync +vsync (118.8 kHz e)
[ 428.160] (II) NOUVEAU(0): Modeline 1680x1050x0.0 198.72 1680
1728 1760 1840 1050 1053 1059 1080 +hsync +vsync (108.0 kHz e)
Thanks
2012/7/5 Maarten Maathuis madman2...@gmail.com:
On Thu, Jul 5
On Sun, Jan 27, 2013 at 2:31 PM, prudhvi raj prudhvira...@gmail.com wrote:
In Xorg-1.12.0, in a random scenario Xorg server crashes in
damageRegionProcessPending (DrawablePtr pDrawable)
{src/miext/damage/damage.c} when the (*pDamage-damageMarker) call is made.
/* submit damage marker whenever
Have you attempted to locate libX11.so in your filesystem?
On Mon, Mar 16, 2015 at 11:13 AM, Roy Schofield r...@caistor.net wrote:
Hi,
Grateful for some help and/or assistance with X11 configuration on
LinuxMint 17 Cinnamon.
I have just upgraded from Linuxmint 16 Petra to LinuxMint 17
- Not sure if it was causing problems, but you never know.
Reviewed-by: Michel Dänzer mic...@daenzer.net
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_driver.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/exa/exa_driver.c b/exa/exa_driver.c
index
Reviewed-by: Michel Dänzer mic...@daenzer.net
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 8adf847..a4e294a 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -421,7 +421,8
...@daenzer.net
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index fb47151..4f49905 100644
--- a/exa
On Thu, Jan 27, 2011 at 8:40 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead to (annoyingly) high latencies, because you
have to wait for the block handler.
- You need a driver that doesn't directly access the front
On Wed, Feb 2, 2011 at 11:55 PM, Keith Packard kei...@keithp.com wrote:
On Sun, 30 Jan 2011 14:06:14 +0100, Maarten Maathuis madman2...@gmail.com
wrote:
- Not sure if it was causing problems, but you never know.
Reviewed-by: Michel Dänzer mic...@daenzer.net
Signed-off-by: Maarten Maathuis
2011/2/7 Michel Dänzer mic...@daenzer.net:
On Mon, 2011-02-07 at 09:34 +0100, Maarten Maathuis wrote:
On Wed, Feb 2, 2011 at 11:55 PM, Keith Packard kei...@keithp.com wrote:
On Sun, 30 Jan 2011 14:06:14 +0100, Maarten Maathuis
madman2...@gmail.com wrote:
- Not sure if it was causing
On Mon, Feb 7, 2011 at 7:10 PM, Jeremy Huddleston jerem...@apple.com wrote:
On Feb 7, 2011, at 09:24, Maarten Maathuis wrote:
2011/2/7 Michel Dänzer mic...@daenzer.net:
On Mon, 2011-02-07 at 09:34 +0100, Maarten Maathuis wrote:
On Wed, Feb 2, 2011 at 11:55 PM, Keith Packard kei...@keithp.com
- It turns out that part of the problem was actually on the driver side.
- The performance loss is not worth the small visual improvement.
- This should ensure low latency at low throughput.
- Performance loss seems less than 10% instead of the previous 33%.
Signed-off-by: Maarten Maathuis
On Wed, Feb 9, 2011 at 9:09 PM, Maarten Maathuis madman2...@gmail.com wrote:
- It turns out that part of the problem was actually on the driver side.
- The performance loss is not worth the small visual improvement.
- This should ensure low latency at low throughput.
- Performance loss seems
deferred_mixed_pixmap to NULL, because
exaDoMigration_mixed will handle that.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c |6 +-
exa/exa_migration_mixed.c | 26 --
exa/exa_priv.h|1 +
3 files changed, 22 insertions(+), 11
deferred_mixed_pixmap to NULL, because
exaDoMigration_mixed will handle that.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c |6 +-
exa/exa_migration_mixed.c | 24 +++-
exa/exa_priv.h|1 +
3 files changed, 21 insertions(+), 10
2011/2/10 Michel Dänzer mic...@daenzer.net:
On Don, 2011-02-10 at 20:15 +0100, Maarten Maathuis wrote:
- It turns out that part of the problem was actually on the driver side.
- The performance loss is not worth the small visual improvement.
- This should ensure low latency at low throughput
how badly.
Ok, upon further review, it seems that this patch:
Author: Maarten Maathuis madman2...@gmail.com 2008-12-17 07:56:26
Committer: Maarten Maathuis madman2...@gmail.com 2008-12-17 08:03:12
Parent: 1556815d34cecb4b4b62d2a4ce813b1435a937ec (Cygwin/X: Initialize
On Fri, Feb 11, 2011 at 7:53 PM, Keith Packard kei...@keithp.com wrote:
On Fri, 11 Feb 2011 13:16:38 +0100, Maarten Maathuis madman2...@gmail.com
wrote:
2011/2/11 Keith Packard kei...@keithp.com:
I'll admit i wasn't thinking about odd visuals when i did this and
at the time the review
On Fri, Feb 11, 2011 at 8:02 PM, Keith Packard kei...@keithp.com wrote:
On Fri, 11 Feb 2011 20:00:13 +0100, Maarten Maathuis madman2...@gmail.com
wrote:
There are dynamic colormaps?
Shocking, I know. Does seem like drivers should feel free to remove
non-TrueColor support at this point
2011/2/11 Maarten Maathuis madman2...@gmail.com:
2011/2/11 Michel Dänzer mic...@daenzer.net:
On Don, 2011-02-10 at 20:44 +0100, Maarten Maathuis wrote:
2011/2/10 Michel Dänzer mic...@daenzer.net:
On Don, 2011-02-10 at 20:15 +0100, Maarten Maathuis wrote:
- It turns out that part
on someone else's computer.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 17 -
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..fb47151 100644
--- a/exa
2011/3/26 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
The latter calls the former, let's cut the middle man and eliminate a branch
in a hot path.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_priv.h | 7 +++
1 files changed, 3
On Mon, Mar 28, 2011 at 4:40 PM, Soeren Sandmann sandm...@cs.au.dk wrote:
Michel Dänzer mic...@daenzer.net writes:
On Mon, 2011-03-28 at 11:47 -0400, Søren Sandmann wrote:
From: Søren Sandmann Pedersen s...@redhat.com
These calls no longer go through the miComposite(),
I can't seem to find
On Tue, Nov 23, 2010 at 4:27 PM, Luc Verhaegen l...@skynet.be wrote:
On Tue, Nov 23, 2010 at 10:25:33AM -0500, Gaetan Nadon wrote:
On Tue, 2010-11-23 at 13:57 +0100, Luc Verhaegen wrote:
It is clear that this is not a normal security breach, as this
commit is
fully in line with the
On Wed, Nov 24, 2010 at 11:03 AM, Tim Beaulen tbsc...@gmail.com wrote:
Luc,
I completely agree with you.
___
x...@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info:
On Thu, Dec 2, 2010 at 10:48 AM, fancy fang fancyfl...@gmail.com wrote:
Dear all,
In xserver 1.9.0, there is an access array to cache previous
results to reduce cost. Howver, this optimization would modify the original
index and give the wrong index to driver PrepareAccess. Also,
- exa classic and mixed don't always access the driver pixmap.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c|3 ++-
exa/exa_driver.c |2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 8adf847..4790bfa 100644
Only tested against a mixed driver.
On Thu, Dec 9, 2010 at 9:17 PM, Maarten Maathuis madman2...@gmail.com wrote:
- exa classic and mixed don't always access the driver pixmap.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 3 ++-
exa/exa_driver.c | 2
2010/12/10 Michel Dänzer mic...@daenzer.net:
On Don, 2010-12-09 at 21:17 +0100, Maarten Maathuis wrote:
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead to (annoyingly) high latencies, because you
have to wait for the block handler.
Doesn't this decrease
Again only tested against 1.9.2.901.
On Mon, Dec 13, 2010 at 7:42 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead to (annoyingly) high latencies, because you
have to wait for the block handler.
- You need a driver
- Not sure if it was causing problems, but you never know.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_driver.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/exa/exa_driver.c b/exa/exa_driver.c
index a913cfb..b9903d1 100644
--- a/exa/exa_driver.c
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 8adf847..a4e294a 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -421,7 +421,8 @@ exaFinishAccess(DrawablePtr pDrawable, int index
poorly to unexpected latency IMO.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index fb47151..4f49905 100644
--- a/exa
2010/12/14 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-13 at 19:42 +0100, Maarten Maathuis wrote:
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead to (annoyingly) high latencies, because you
have to wait for the block handler.
- You need a driver that doesn't
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote:
2010/12/14 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-13 at 19:42 +0100, Maarten Maathuis wrote:
- Apps like xterm can trigger a lot of fallback rendering.
- This can lead
2010/12/20 Maarten Maathuis madman2...@gmail.com:
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote:
2010/12/14 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-13 at 19:42 +0100, Maarten Maathuis wrote:
- Apps like xterm can trigger
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:54 +0100, Maarten Maathuis wrote:
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote:
2010/12/14 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-13 at 19:42 +0100
2011/1/18 Maarten Maathuis madman2...@gmail.com:
2011/1/18 Michel Dänzer mic...@daenzer.net:
On Mon, 2011-01-17 at 21:45 +0100, Maarten Maathuis wrote:
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:54 +0100, Maarten Maathuis wrote:
2010/12/20 Michel Dänzer mic
2011/1/18 Maarten Maathuis madman2...@gmail.com:
2011/1/18 Maarten Maathuis madman2...@gmail.com:
2011/1/18 Michel Dänzer mic...@daenzer.net:
On Mon, 2011-01-17 at 21:45 +0100, Maarten Maathuis wrote:
2010/12/20 Michel Dänzer mic...@daenzer.net:
On Mon, 2010-12-20 at 15:54 +0100, Maarten
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3 patches.
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 4f49905..c0c730d 100644
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text are still not shown fluently (the impression that some pieces
are never drawn). This is on top of the previous 3
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 18:29 +0100, Maarten Maathuis wrote:
2011/1/19 Michel Dänzer mic...@daenzer.net:
On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote:
This is it, 10 ms a short time and even with this value large amounts
of text
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap unconditionally, it
should be a no-op in most cases anyway.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c
This should be exa/mixed instead of exa.
On Thu, Feb 11, 2010 at 7:05 PM, Maarten Maathuis madman2...@gmail.com wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap unconditionally
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling this, Maarten!
On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap
One possibility would be to put exaDoMigration with src with preg on
the deferred pixmap list, i haven't tested this, but i could try this
evening or tomorrow.
Maarten.
2010/2/11 Maarten Maathuis madman2...@gmail.com:
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps with preg are incomplete (in the gpu pixmap), so also put them
on the deferred pixmap list.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 31
This is the other way to do it.
On Fri, Feb 12, 2010 at 7:02 PM, Maarten Maathuis madman2...@gmail.com wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps with preg are incomplete (in the gpu pixmap), so also put
them
2010/2/15 Michel Dänzer mic...@daenzer.net:
On Thu, 2010-02-11 at 20:06 +0100, Maarten Maathuis wrote:
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling this, Maarten!
On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used
.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 6816e6c..d200917 100644
--- a/exa/exa_migration_mixed.c
+++ b
.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_migration_mixed.c | 48
1 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa
I don't mind, i just thought this was preferred. I did gave you the
final sign-off, to indicate you were the final author.
2010/2/17 Michel Dänzer mic...@daenzer.net:
On Tue, 2010-02-16 at 22:55 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory
Both patches are functional on their own, Michel's patch just makes it prettier.
2010/2/17 Dave Airlie airl...@gmail.com:
2010/2/17 Michel Dänzer mic...@daenzer.net:
On Tue, 2010-02-16 at 22:55 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory
On Fri, May 18, 2012 at 1:17 PM, Michal Suchanek hramr...@gmail.com wrote:
On 18 May 2012 12:40, Peter Hutterer peter.hutte...@who-t.net wrote:
On 18/05/12 19:26 , Michal Suchanek wrote:
On 18 May 2012 01:14, Peter Huttererpeter.hutte...@who-t.net wrote:
On Thu, May 17, 2012 at 10:39:55AM
On Fri, May 18, 2012 at 5:56 PM, Michal Suchanek hramr...@gmail.com wrote:
On 18 May 2012 17:38, Maarten Maathuis madman2...@gmail.com wrote:
I think that a tool that allows you to see diffs in a web interface
and do point-and-click defect submission would never hurt. As long as
it doesn't
On Mon, Feb 14, 2011 at 1:45 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Fri, 11 Feb 2011 20:27:22 +0100
From: Maarten Maathuis madman2...@gmail.com
On Fri, Feb 11, 2011 at 8:02 PM, Keith Packard kei...@keithp.com wrote:
On Fri, 11 Feb 2011 20:00:13 +0100, Maarten Maathuis
On Tue, Nov 29, 2011 at 2:33 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Hi,
I am moving the thread EXA performance problem from xorg to xorg-devel and
hope to get some help here.
To sum up the problem: We use an application that displays vector pictures.
We use it mostly to
On Tue, Nov 29, 2011 at 11:29 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Am 29.11.2011 23:19, schrieb Maarten Maathuis:
On Tue, Nov 29, 2011 at 2:33 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Hi,
I am moving the thread EXA performance problem from xorg
On Wed, Jun 9, 2010 at 3:49 AM, Cui, Hunk hunk@amd.com wrote:
Hi, all,
About the exaGetPixmapOffset function in exa.c, please see below,
In Xserver 1.6.4 version, describe as:
static _X_INLINE void*
ExaGetPixmapAddress(PixmapPtr p)
{
ExaPixmapPriv(p);
if
radeon_legacy_allocate_memory does then you'll see it
does this.
Thanks,
Hunk Cui
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Wednesday, June 09, 2010 10:29 AM
To: Cui, Hunk
Cc: xorg-devel@lists.x.org; Maarten Maathuis
Subject: Re: Who can explain the diff between Xserver
, the judge
will not come into existence.
You can try it. If not come into existence. The fb_ptr address value
is 0x0.
How are you allocating rotatedData?
Thanks,
Hunk Cui
-Original Message-
From: Maarten Maathuis [mailto:madman2...@gmail.com]
Sent: Wednesday, June 09, 2010
driver, and it's all a bit confusing. This will
have to wait until (at least) this evening.
Thanks
Hunk Cui
-Original Message-
From: Maarten Maathuis [mailto:madman2...@gmail.com]
Sent: Wednesday, June 09, 2010 6:16 PM
To: Cui, Hunk
Cc: xorg-devel@lists.x.org; Huang, FrankR; Writer
/src/radeon_legacy_memory.c#n50
for appropriate arguments and usage. The offset is relative to memory
base.
The same is true for the video overlay, gx_video seems to be using
exaOffscreenAlloc already.
Thanks,
Hunk Cui
-Original Message-
From: Maarten Maathuis [mailto:madman2
so far is just a hack that will never be added.
If you confuse in this explain, I can provide a chart about the memory
allocate.
Thanks,
Hunk Cui
-Original Message-
From: Maarten Maathuis [mailto:madman2...@gmail.com]
Sent: Sunday, June 13, 2010 6:08 PM
To: Cui, Hunk
To: Maarten Maathuis
Cc: Cui, Hunk; xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org
Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7
version about the ExaGetPixmapAddress?
On Son, 2010-06-13 at 16:10 +0200, Maarten Maathuis wrote:
2010/6/13 Cui, Hunk hunk
-Original Message-
From: Maarten Maathuis [mailto:madman2...@gmail.com]
Sent: Tuesday, June 15, 2010 3:54 AM
To: Cui, Hunk
Cc: Michel Dänzer; xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org
Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7
version about
2010/6/22 Cui, Hunk hunk@amd.com:
Hi, Maarten,
Please see below:
1). Can you explain ExaOffscreenDefragment - prev-offset? When do the
rotate operation, where is triggered this function and what is the
prev-offset value?
I think ExaOffscreenDefragment is triggered from the
Acked-by: Maarten Maathuis madman2...@gmail.com
2010/7/13 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Previously we assumed every pixmap destroyed during a software fallback was
also created during a software fallback and had access prepared, but that's
On Thu, Aug 12, 2010 at 12:15 PM, Cui, Hunk hunk@amd.com wrote:
Hi, Alex,
In xf86-video-geode:
lx_video.c - LXCopyPlanar function, some codes make me confuse,
(
http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_vid
eo.c#n224 )
YSrcPitch = (width +
On Sat, Feb 14, 2009 at 2:28 PM, Michel Dänzer mic...@daenzer.net wrote:
+/* Try to prevent source valid region from growing too many rects */
+if (REGION_NUM_RECTS(pValidSrc) 10)
+ REGION_SUBTRACT(pScreen, pValidSrc, pValidSrc, pValidDst);
You're removing the valid dst region
Maybe remove the smallest rects, but i think i get your point. It just
seemed odd at first, now i see you're just using a convient area to
remove.
Maarten.
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
+ * as valid is a natural defragmention of the region.
I've fixed this typo locally.
Maarten.
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
- This includes properly handling the framebuffer.
---
exa/exa.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 994a67a..b0a26e9 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -424,6 +424,13 @@ exaModifyPixmapHeader(PixmapPtr
---
exa/exa.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 17d75d2..7501b65 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -607,10 +607,11 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
PixmapPtr pPixmap =
- Cleanup wrapping too.
---
exa/exa.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 7501b65..81c874b 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -933,6 +933,8 @@ exaCloseScreen(int i, ScreenPtr pScreen)
unwrap(pExaScr, pScreen,
---
exa/exa_migration.c | 28 +---
1 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/exa/exa_migration.c b/exa/exa_migration.c
index 8b91150..e7c73f8 100644
--- a/exa/exa_migration.c
+++ b/exa/exa_migration.c
@@ -52,7 +52,10 @@ exaPixmapIsPinned (PixmapPtr
---
exa/exa_unaccel.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d16ecf7..4279c87 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -405,7 +405,7 @@ ExaCheckComposite (CARD8 op,
if
The reason for this entire patchset was to make everything more
strict.
That's okay in principle, but note that e.g. we only wrap CreatePixmap
(and allocate an ExaPixmapPriv) if the driver sets the
EXA_OFFSCREEN_PIXMAPS flag...
How that does that work anyway, acceleration without
On Sun, Mar 1, 2009 at 12:18 PM, Maarten Maathuis madman2...@gmail.com wrote:
lx_driver.c and gx_driver.c set the flag.
The question now is, is the mode even useful?
Maarten.
Correction is !OFFSCREEN_PIXMAPS useful?
Sorry for not replying to the list (again).
Maarten
---
exa/exa.c | 53 +++--
exa/exa.h |5 +
2 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index f4fba57..95f101f 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -450,15 +450,28 @@
---
exa/exa.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 95f101f..37b7f74 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -629,10 +629,14 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
PixmapPtr pPixmap =
It seems that sometimes (around VT switch) something undesirable does
happen (the FatalError is triggered), will have to do some more
hunting to see where it's coming from.
Maarten.
___
xorg-devel mailing list
xorg-devel@lists.x.org
- This includes properly handling the framebuffer.
---
exa/exa.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 994a67a..f4fba57 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -73,8 +73,9 @@ unsigned long
---
exa/exa.c | 76
exa/exa.h |5 +++
exa/exa_priv.h |4 +++
3 files changed, 69 insertions(+), 16 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index f4fba57..f935d38 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -450,15
---
exa/exa_unaccel.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d16ecf7..4279c87 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -405,7 +405,7 @@ ExaCheckComposite (CARD8 op,
if
Forgot to send to list (again :-( ).
-- Forwarded message --
From: Maarten Maathuis madman2...@gmail.com
Date: Tue, Mar 3, 2009 at 2:10 PM
Subject: Re: [PATCH 2/6] exa: increase/rework safety checks in
Prepare/FinishAccess.
To: Michel Dänzer mic...@daenzer.net
On Tue, Mar 3
On Tue, Mar 3, 2009 at 9:12 AM, Michel Dänzer mic...@daenzer.net wrote:
I don't see any explanation what the serious issue in
exaChangeWindowAttributes was.
fbChangeWindowAttributes can cause a switch of pixmap (much like
fbValidateGC), so you need to trap Destroy and Create pixmap, in order
It would be really nice if you would put information like this in your
commit messages so that people looking at the history can determine
the reason for the commit.
After Michel's question i updated the commit message to contain more
information. A few updated patches will be posted shortly.
- And make some fatal for a debug build.
---
exa/exa_migration.c | 42 +++---
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/exa/exa_migration.c b/exa/exa_migration.c
index 8b91150..95a 100644
--- a/exa/exa_migration.c
+++
- fbChangeWindowAttributes can create pixmaps (and access them) without use
preparing access.
- Also handle the destroyed pixmaps by finishing them first.
- Switch to DEST indices again in exaCreatePixmapWithPrepare, because they are
obviously being rendered to.
- Also avoid calling FinishAccess
---
exa/exa.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 7145e12..3fcb3e2 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -585,6 +585,8 @@ ExaDoPrepareAccess(DrawablePtr pDrawable, int index)
if (index = EXA_PREPARE_AUX_DEST
---
exa/exa.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 7145e12..3fcb3e2 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -585,6 +585,8 @@ ExaDoPrepareAccess(DrawablePtr pDrawable, int index)
if (index = EXA_PREPARE_AUX_DEST
---
exa/exa.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 3fcb3e2..ecb2117 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -258,9 +258,9 @@ exaSetFbPitch(ExaScreenPrivPtr pExaScr, ExaPixmapPrivPtr
pExaPixmap,
int w, int h, int
2009/3/19 Michel Dänzer mic...@daenzer.net:
On Don, 2009-03-19 at 19:10 +0100, Maarten Maathuis wrote:
- /* Is this the framebuffer (for classic exa)? */
- if (pPixData pPixData == pExaScr-info-memoryBase) {
- pExaPixmap-fb_ptr = pPixData;
- pExaPixmap-fb_pitch
+ if ((CARD8 *)pPixData = pExaScr-info-memoryBase
+ (CARD8 *)pPixData (pExaScr-info-memoryBase +
pExaScr-info-memorySize)) {
(pExaScr-info-memoryBase + pExaScr-info-memorySize) could wrap
around to 0, in which case the latter check would always fail.
I don't
---
exa/exa.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index ecb2117..a8e5374 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -427,11 +427,19 @@ exaModifyPixmapHeader(PixmapPtr pPixmap, int width, int
height, int depth,
---
xkb/xkbLEDs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index c61296b..a70ac84 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -643,7 +643,7 @@ XkbCopySrvLedInfo( DeviceIntPtrfrom,
else
sli_new-fb.lf =
http://bugs.freedesktop.org/show_bug.cgi?id=20756
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
- Some image viewers (eog, gqview) trigger the CopyArea path of Xext/shm.c
- I'm not aware of any bad path that wouldn't like UTS and trigger this code.
- I don't think the boxes need to be clipped to src dimensions.
---
exa/exa_accel.c | 67
I think Xv is meant to also work for overlays, which obviously won't
work on a pixmap. Maybe it's a safety so application developers don't
do anything stupid.
Maarten.
On Fri, Apr 10, 2009 at 11:30 AM, Yuan Austin shengquan.y...@gmail.com wrote:
On Thu, Apr 2, 2009 at 3:59 PM, Shengquan Yuan
1 - 100 of 187 matches
Mail list logo
