Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=14731
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/common/xf86VidMode.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86VidMode.c b/hw/xfree86/common/xf86VidMode.c
index
On Mon, 24 Jan 2011 11:20:12 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=14731
Having just hit this myself, I'd like to get this trivial patch reviewed
and included in the rc. :)
-Chris
--
Chris Wilson, Intel Open Source
extension enabled for this screen?'
Which is obviously a separate question from whether there are any modes
available.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
when run indirectly over a local socket.
Which serves as a nice reminder not to do this.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
glx/indirect_table.c |9 ++---
glx/indirect_table.h | 13 +
glx/indirect_util.c | 24
glx/indirect_util.h
buffer. But at
least test could be repeated in-depend on desktop around the test.
Having the ability to optionallyrun x11perf against a pixmap would also be
useful.
End of bikeshedding,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, 16 Dec 2010 15:55:42 +0100, Michel Dänzer mic...@daenzer.net wrote:
[ Dropping dri-devel list as this seems strictly an xserver issue ]
On Fre, 2010-12-10 at 14:49 +0100, Michel Dänzer wrote:
On Fre, 2010-12-10 at 13:38 +, Chris Wilson wrote:
Although there may be more
.
This fixes segmentation faults on affected systems.
Signed-off-by: Forest Bond forest.b...@rapidrollout.com
Pushed, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http
Window still holds a pointer to the old Screen
Pixmap!
One solution is to use the NULL WindowPrivate to imply an indirect
reference to the Screen Pixmap, and perform the redirection every time
we query the Pixmap for a Window.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
fb/fb.h
On Thu, 31 Mar 2011 15:21:42 +1000, Dave Airlie airl...@gmail.com wrote:
uxa: left as an exercise for the reader.
What's the best method for checking at compile time which functions to
implement? Just XORG_CURRENT_VERSION?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
As FreeScratchPixmapHeader is called when the resource backing the
scratch pixmap becomes no longer accessible, it is vital that the ddx is
notified in order to serialise any access it has to that resource.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
dix/pixmap.c |2 ++
1 files
Some DDX may be sensitive to the ordering and could conceivably continue
to use the memory freed before FreeScratchPixmapHeader is called.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/xaa/xaaOffscreen.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff
, and the driver would fail to insert the correct barriers on
the backing resource. That resource would then be reused by the Xserver,
leading to rampant memory corruption as the GPU flushed it write caches
at some point in the future and overwriting random structures.
Signed-off-by: Chris Wilson ch...@chris
) is
that the two pixmaps are no longer the same size.
I was just hoping for too much from the interfaces called SetScreenPixmap
and SetWindowPixmap.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org
On Wed, 20 Apr 2011 09:08:24 -0400, Søren Sandmann sandm...@cs.au.dk wrote:
From: Søren Sandmann Pedersen s...@redhat.com
Nothing uses them.
UXA uses the unrealize hook to get notifications of when to remove items
from the glyph cache.
-Chris
--
Chris Wilson, Intel Open Source Technology
If the driver tracks the contents of scratch pixmaps, it needs to be
informed when they are finalized. I previously suggested adding a
miModifyPixmapHeader() call to FreeScratchPixmapHeader() so that the
driver can notice that the data pointer changed. This is the
alternative approach of simply
Some DDX may be sensitive to the ordering and could conceivably continue
to use the memory freed before FreeScratchPixmapHeader is called.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/xaa/xaaOffscreen.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff
the ABI version as well.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
dix/dispatch.c |1 -
dix/main.c |4 +--
dix/pixmap.c | 58
fb/fbpixmap.c |2 +-
hw
a failure path, just defer the free until the end.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/common/xf86xvmc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86xvmc.c b/hw/xfree86/common/xf86xvmc.c
index e6464a5..f9249fb 100644
If the driver uses the Pixmap to track GPU objects associated with
transient data structures like scratch Pixmaps, then it needs to be
notified when the resource is released. Currently, that notification is
only performed when the scratch Pixmap is reused - too late. One
solution, is to add a
-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Xext/shm.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/Xext/shm.c b/Xext/shm.c
index b08af82..c6a3aee 100644
--- a/Xext/shm.c
+++ b/Xext/shm.c
@@ -1018,18 +1018,10 @@ static PixmapPtr
fbShmCreatePixmap
Some DDX may be sensitive to the ordering and could conceivably continue
to use the memory freed before FreeScratchPixmapHeader is called.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/xaa/xaaOffscreen.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/shadowfb/shadow.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/shadowfb/shadow.c b/hw/xfree86/shadowfb/shadow.c
index 5cc476a..46d481b 100644
--- a/hw/xfree86/shadowfb/shadow.c
+++ b/hw
the ABI version as well.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
dix/dispatch.c |1 -
dix/main.c |4 +--
dix/pixmap.c | 58
fb/fbpixmap.c |2 +-
hw
On Sun, 05 Jun 2011 22:48:59 -0700, Keith Packard kei...@keithp.com wrote:
On Mon, 6 Jun 2011 06:36:07 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
In order for the driver to be notified of when the resource backing the
scratch pixmap becomes no longer accessible, it needs
.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Kristian Høgsberg k...@bitplanet.net
---
hw/xfree86/dri2/dri2.c | 51 +--
hw/xfree86/dri2/dri2.h | 12 ++-
2 files changed, 47 insertions(+), 16
.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Kristian Høgsberg k...@bitplanet.net
---
Sigh... I broke the patch with a last minute name change. Please pretend
you never saw the previous patch.
Thanks,
-Chris
---
hw/xfree86/dri2/dri2.c | 47
During unwind following an error when attempting to a load a module, we
attempt to call dlclose on a potentially NULL handle. This is a
side-effect of removing the abstraction layer in ab7f057.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: ab7f057ce9df4e905b12cebc1e587b9a7f200418
During unwind following an error when attempting to a load a module, we
attempt to call dlclose on a potentially NULL handle. This is a
side-effect of removing the abstraction layer in ab7f057.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Adam Jackson a...@redhat.com
---
hw/xfree86
In ab7f057 LoaderOpen was changed to return a NULL pointer instead of -1
in case of failure. However, one callsite was overlooked during the
conversion.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Adam Jackson a...@redhat.com
---
hw/xfree86/loader/loadmod.c |2 +-
1 files
because height=0 and it crashes at the bottom of the loop
because it tries to XDestroyImage(NULL).
And I thought I had covered my bases by looking at the combinations
of formats offered by the Xorg.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
of blend and composite that I tested with
windows both larger and smaller than num_src.
Cheers,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
On Wed, 1 Dec 2010 13:57:15 -0800, Aaron Plattner aplatt...@nvidia.com wrote:
On Wed, Dec 01, 2010 at 01:47:47PM -0800, Chris Wilson wrote:
On Wed, 1 Dec 2010 13:06:47 -0800, Aaron Plattner aplatt...@nvidia.com
wrote:
This series causes a segmentation fault in blend_test because the loop
be pretty useless for me
to try to review these changes...
Anyone else care about jhbuild these days?
I use it and the xorg.modules on my boxes to rebuild the stack.
But I think Cyril just volunteered to maintain it. ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Although there may be more than one resource handles pointing to the
Drawable, we only want to destroy it once and only reference the
resource which may have just been deleted on the first instance.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kristian Høgsberg k...@bitplanet.net
Cc
://bugs.freedesktop.org/show_bug.cgi?id=28181
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Michel Dänzer daen...@vmware.com
---
glx/glxcmds.c | 23 +++
glx/glxdrawable.h |3 +++
glx/glxext.c | 15 ++-
3 files changed
All the callers were already checking for failure, except that
createSourcePicture() itself was failing to check whether it
successfully allocated the Picture.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
render/picture.c |4
1 files changed, 4 insertions(+), 0 deletions
On Wed, 14 Dec 2011 19:37:26 +0100, Julien Cristau jcris...@debian.org wrote:
On Wed, Dec 14, 2011 at 15:55:22 +, Chris Wilson wrote:
All the callers were already checking for failure, except that
createSourcePicture() itself was failing to check whether it
successfully allocated
;
That comment is quite annoying and does not make those macros any less
opaque. How about:
pGCPriv-ops = pDamage; /* a non-NULL value to enable damage tracking
and fixed up in the epilogue to the appropriate
wrapped ops */
-Chris
--
Chris Wilson
with
commit 429a36f7481b9bfd5ed137642d2916d69a713557
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Fri Dec 9 09:54:12 2011 +
uxa: Fix clip processing for uxa_fill_spans()
Fixes regression from e0066e77e026b0dd0daa0c3765473c7d63aa6753
(uxa: Simplify Composite solid
more render paths and so not only looks
less ungainly but also benefits from EXA much more. GTK3 further favours
EXA.
But it is difficult nigh impossible to go from gtkperf to determining
impact upon application usability. However, th
that.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
CopyRegion request.
v2: Only invalidate the drawable on the behest of the backend, so that
existing behaviour of not invalidating for async blit copies is
preserved, suggested by Simon Farnsworh. And rebase for the intervening
12 months since v1.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/modes/xf86RandR12.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index d5031a2..b383197 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes
(rrscreen.c:475)
==22787==by 0x513852: ProcRRDispatch (randr.c:493)
==22787==by 0x4346DB: Dispatch (dispatch.c:439)
==22787==by 0x4256E4: main (main.c:287)
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36108
Signed-off-by: Chris
On Fri, 16 Mar 2012 08:45:38 -0700, Aaron Plattner aplatt...@nvidia.com wrote:
On 03/16/2012 04:39 AM, Chris Wilson wrote:
+randrp-pointerX = randrp-pointerY = 0; /* keep valgrind quiet */
I don't think the comment is necessary, since initializing all the
fields is standard good
Thanks, I had already applied the first patch after your IRC warning,
so many thanks for the second patch which I have now pushed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http
/show_bug.cgi?id=36108
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/common/xf86.h |2 ++
hw/xfree86/modes/xf86Crtc.c|6 +++---
hw/xfree86/modes/xf86Modes.c | 11 +++
hw/xfree86/modes/xf86RandR12.c |2 +-
4 files changed, 17 insertions(+), 4
-by: Nick Bowler nbow...@draconx.ca
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
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
On Wed, 30 May 2012 14:25:40 -0700, Keith Packard kei...@keithp.com wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
+extern _X_EXPORT void
+xf86InternMode(DisplayModePtr intern, const DisplayModeRec * pMode);
The name doesn't seem very descriptive to me -- what is 'Intern'
supposed
);
+ return I830EnterVT_copy(scrn, TRUE);
We only want to copy the initial fb on startup not on every VT switch,
right?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
I was playing some more with flipping pixmaps in the pageflip handler and
found a couple of issues with the way DRI2 revokes all the buffers after
the Pixmap is swapped on a Window.
Please review, thanks.
-Chris
___
xorg-devel@lists.x.org: X.Org
was causing the DRI2 buffers to be
revoked, resulting in a massive increase in aperture thrashing - the
exact opposite of what pageflipping is supposed to achieve - under a
composting window manager.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@nokia.com
Cc: Dave
.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Ville Syrjälä ville.syrj...@nokia.com
Cc: Dave Airlie airl...@redhat.com
Cc: Michel Dänzer mic...@daenzer.net
---
hw/xfree86/dri2/dri2.c | 48
If the drawable size remained the same, the application can continue to
reuse the same back and auxiliary buffers, but will need the new name
for the Pixmap.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@nokia.com
Cc: Dave Airlie airl...@redhat.com
Cc
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@nokia.com
Cc: Dave Airlie airl...@redhat.com
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Michel Dänzer mic...@daenzer.net
---
hw/xfree86/dri2/dri2.c | 23
... Then I just applied the same patch to master.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
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
://bugs.freedesktop.org/show_bug.cgi?id=37700
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
dix/resource.c | 32
include/resource.h |6 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/dix/resource.c b/dix/resource.c
index eb9f049
On Mon, 11 Jul 2011 08:25:26 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Mon, 11 Jul 2011 15:56:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Another variant on the FreeResource theme. The purpose of this is to
free the exactly matching
started using the Resource database to track
outstanding swaps...
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/dri2/dri2.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 561237d..535078a
The driver is at liberty to modify the Screen Pixmap, for example if it
creates a new ordinary Pixmap for use as a shadow scanout buffer, and so
the cached registration of the damage may become stale and lead to an
eventual crash.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw
-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/modes/xf86Rotate.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86Rotate.c b/hw/xfree86/modes/xf86Rotate.c
index da8a8f4..ebf93d3 100644
--- a/hw/xfree86/modes/xf86Rotate.c
+++ b/hw/xfree86
On Thu, 25 Aug 2011 07:10:40 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Thu, 25 Aug 2011 14:46:07 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The driver is at liberty to modify the Screen Pixmap, for example if it
creates a new ordinary Pixmap
On Thu, 25 Aug 2011 17:26:20 +0300, Pauli Nieminen suok...@gmail.com wrote:
On Thu, Aug 25, 2011 at 2:50 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
@@ -1227,8 +1236,6 @@ DRI2Setup(pointer module, pointer opts, int *errmaj,
int *errmin)
 {
  static Bool setupDone = FALSE
started using the Resource database to track
outstanding swaps...
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
v2: Try registering the RESTYPE from InitExtensions().
---
hw/xfree86/dri2/dri2.c| 14 --
hw/xfree86/dri2/dri2ext.c |3 +++
2 files changed, 15 insertions
On Thu, 25 Aug 2011 08:02:32 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Thu, 25 Aug 2011 15:36:09 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
We've been fixing bugs in the Xserver ever since we started using
a shadow pixmap and resizing upon
Failure to clear the filter results us in attempting to use the stale
pointers after server reset.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/modes/xf86Rotate.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/modes/xf86Rotate.c b
needlessly bumping the
ABI, we move the existing copy implementations to mipict.c and assign
those by default. To notify the ddx that the new entry points are
available, we introduce PICTURE_SCREEN_VERSION.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
render/mipict.c | 61
On Sun, 04 Sep 2011 09:57:32 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Sun, 4 Sep 2011 17:34:08 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rather than perform an intermediate copy and expand the strip and the
fan into a triangle list (thereby
the
browser when all that is lacking is the protocol for describing paths
and operations upon them. :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
us a thing or
two about the DRM infrastructure and what it might look like in a year
or two as more SoC gradually become mainline?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http
indicated that this was
entirely due to the extra buffer copying of the intermediate data but I
suspect a loss of parallelism also hurt.
As a proof-of-principle, not too shabby ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel
The move of the PCI device id probing into a separate file neglected to
return the number of found devices, and so the PCI devices were being
overwritten by the default entries for vesa and fbdev.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Tiago Vignatti tiago.vigna...@nokia.com
Cc
The move of the PCI device id probing into a separate file neglected to
return the number of found devices, and so the PCI devices were being
overwritten by the default entries for vesa and fbdev.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Tiago Vignatti tiago.vigna...@nokia.com
Cc
On Sat, 29 May 2010 12:20:30 +0200, Michel Dänzer mic...@daenzer.net wrote:
On Sam, 2010-05-29 at 02:42 -0700, Chris Wilson wrote:
commit 44d45d3fa56f121ce89ffe5b28beb48be01a95df
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sat May 29 10:39:28 2010 +0100
dri: Use size
On Sat, 29 May 2010 13:03:40 +0200, Michel Dänzer mic...@daenzer.net wrote:
On Sam, 2010-05-29 at 11:47 +0100, Chris Wilson wrote:
On Sat, 29 May 2010 12:20:30 +0200, Michel Dänzer mic...@daenzer.net
wrote:
On Sam, 2010-05-29 at 02:42 -0700, Chris Wilson wrote:
commit
Some paranoid defense to more easily catch should not happen conditions
from within gdb.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
pixman/pixman-access.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/pixman/pixman-access.c b/pixman/pixman-access.c
On 31 May 2010 19:00:43 +0200, Soeren Sandmann sandm...@daimi.au.dk wrote:
(But please also copy pix...@lists.freedesktop.org
on pixman patches).
My apologies, I had forgotten entirely about the separate list for pixman!
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
Hi Marco,
as you seem to be the very first user of conical gradients, do you mind
presenting your use case? It looks like we should be extending gradients to
cover type 6/7 in the near future, and we may as well expose conical
gradients in the Cairo API at the same time.
-ickle
--
Chris Wilson
During a SwapBuffers request, we may end up querying an unknown drawable
outside of an active context, and so need to report this error prior to
attempting to dereference the NULL context.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kristian Høgsberg k...@bitplanet.net
---
glx
Fixes:
Bug 27313 - random X11 crash (SIGSEGV) when rendering firefox in pixman/intel
https://bugs.freedesktop.org/show_bug.cgi?id=27313
As pixman does not guard against a fill request outside of the buffer,
we must be be careful and trim oversized fills.
Signed-off-by: Chris Wilson ch
Fixes:
Bug 27313 - random X11 crash (SIGSEGV) when rendering firefox in pixman/intel
https://bugs.freedesktop.org/show_bug.cgi?id=27313
As pixman does not guard against a fill request outside of the buffer,
we must be be careful and trim oversized fills.
Signed-off-by: Chris Wilson ch
On 02 Jul 2010 17:19:18 +0200, Soeren Sandmann sandm...@daimi.au.dk wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
Fixes:
Bug 27313 - random X11 crash (SIGSEGV) when rendering firefox in
pixman/intel
https://bugs.freedesktop.org/show_bug.cgi?id=27313
As pixman does
Wilson ch...@chris-wilson.co.uk
--
Chris Wilson, Intel Open Source Technology Centre
___
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
?
--
Chris Wilson, Intel Open Source Technology Centre
___
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
, as
there is only one.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
Thanks for the explanation.
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http
From memory, I think this is just a bit of idiocacy in the driver
inappropriately using a GL type, i.e. for a variable unconnected with
any of the GL interfaces.
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org
world) between the kernel and X over valid modes.
References:
Bug 23833 - X uses different refresh rate to that set by kernel module
https://bugs.freedesktop.org/show_bug.cgi?id=23833
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/modes/xf86Crtc.c | 264
SEGV during XFixesGetCursorImage()
https://bugs.freedesktop.org/show_bug.cgi?id=18451
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Xext/xace.c | 170 +++
hw/xfree86/modes/xf86Crtc.c |8 ++-
2 files changed, 82 insertions
SEGV during XFixesGetCursorImage()
https://bugs.freedesktop.org/show_bug.cgi?id=18451
v2: Drop the unrelated hunk that snuck in when ammending the commit
message.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Xext/xace.c | 170
-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Julien Cristau jcris...@debian.org
---
hw/xfree86/modes/xf86RandR12.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 043ceee..c17b5fa 100644
--- a/hw
As with xf86SwitchMode(), if the driver modifies the Screen pixmap header
in the course of resizing the framebuffer, this change needs to be
propagated to the ScrnInfo-pixmapPrivate or else the pixmap header will
be overwritten by xf86EnableDisableFBAccess().
Signed-off-by: Chris Wilson ch
Earlier I sent a couple of patches that fixed an issue I encounter when
the driver adjusted details of the ScreenPixmap during resize. Keith saw
that the second patch was just furthering the misery of
ScrnInfo-pixmapPrivate and suggested that it would be easier to remove it
than to continue to
-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Julien Cristau jcris...@debian.org
Tested-by: Julien Cristau jcris...@debian.org
Cc: Keith Packard kei...@keithp.com
Reviewed-by: Keith Packard kei...@keithp.com
---
hw/xfree86/modes/xf86RandR12.c |3 ++-
1 files changed, 2 insertions(+), 1
As with xf86SwitchMode(), if the driver modifies the Screen pixmap header
in the course of resizing the framebuffer, this change needs to be
propagated to the ScrnInfo-pixmapPrivate or else the pixmap header will
be overwritten by xf86EnableDisableFBAccess().
Signed-off-by: Chris Wilson ch
ScrnInfo-pixmapPrivate only existed in order to catch invalid access to
the framebuffer by making the backing data NULL across the VT switch.
This was causing more confusion in the higher layers during mode setting
without any real benefit, so remove it.
Signed-off-by: Chris Wilson ch...@chris
On Thu, 23 Sep 2010 09:04:11 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
Now that is starting to look familiar ;-)
Reported-by: Julien Cristau jcris...@debian.org
Tested-by: Chris Wilson ch...@chris-wilson.co.uk
--
Chris Wilson
A third iteration of the patches to fix a couple of segfaults should
the driver tweak the root pixmap whilst resizing the framebuffer. In
this iteration, the removal of the pixmapPrivate is squashed with the
workaround as nobody argued for its continued existence.
Please review and test!
-Chris
-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Julien Cristau jcris...@debian.org
Tested-by: Julien Cristau jcris...@debian.org
Cc: Keith Packard kei...@keithp.com
Reviewed-by: Keith Packard kei...@keithp.com
---
hw/xfree86/modes/xf86RandR12.c |3 ++-
1 files changed, 2 insertions(+), 1
ScrnInfo-pixmapPrivate only existed in order to catch invalid access to
the framebuffer by making the backing data NULL across the VT switch.
This was causing more confusion in the higher layers during mode setting
without any real benefit, so remove it.
Signed-off-by: Chris Wilson ch...@chris
() as well.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Julien Cristau jcris...@debian.org
Cc: Andrew Guertin li...@dolphinling.net
---
hw/xfree86/common/xf86Helper.c | 11
hw/xfree86/common/xf86str.h|1 -
hw/xfree86/modes/xf86RandR12.c |9 ---
hw/xfree86/shadowfb
modes for explicitly enabled outputs (and skip the
probing for explicitly disabled outputs).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Keith Packard kei...@keithp.com
Cc: Dave Airlie airl...@redhat.com
---
hw/xfree86/modes/xf86Crtc.c | 38 --
1
1 - 100 of 375 matches
Mail list logo
