From: Justin Dou justin@intel.com
The calling for allocate_or_reuse_buffer may fail due to some reason, e.g. out
of memory.
If the buffers[] were not initialized to be NULL, the following err_out may try
to access an illegal memory, which will cause X crash afterward.
Reviewed-by: Kristian
On Sun, Nov 28, 2010 at 9:46 AM, Jan Engelhardt jeng...@medozas.de wrote:
The following changes since commit f94a64cc08b47cdbfdfea5b5756340246fc391ed:
Link with -no-undefined (2010-10-26 14:11:38 -0400)
Thanks, those all look good, pulled and pushed.
Kristian
are available in the git
On Mon, Aug 2, 2010 at 2:36 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 2 Aug 2010 11:29:55 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Here's the other approach for fixing damage vs flush client. In writing the
commit message, it certainly does feel like damage should just
2010/8/2 Keith Packard kei...@keithp.com:
On Mon, 2 Aug 2010 19:58:47 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
And if I don't have to touch low level protocol code, I'd
rather not.
Scaredy cat.
Oh, I'm mostly just lazy. Cleaning up X code that works isn't my kind of fun
On Sun, Aug 1, 2010 at 3:20 PM, Keith Packard kei...@keithp.com wrote:
On Sun, 1 Aug 2010 14:39:46 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Before this gets drowned out in janitorial patches... Keith, do you
want a pull request for this and the damageext patch? Did you have
have
2010/8/2 Keith Packard kei...@keithp.com:
On Mon, 2 Aug 2010 08:24:04 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
On Sun, Aug 1, 2010 at 3:20 PM, Keith Packard kei...@keithp.com wrote:
On Sun, 1 Aug 2010 14:39:46 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Before this gets
to the client buffer before the
driver sees the rendering request, but wants to make sure that once the
output buffer is flushed, all the rendering has been submitted.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
Here's the other approach for fixing damage vs flush client. In writing
On Mon, Aug 2, 2010 at 2:36 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 2 Aug 2010 11:29:55 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Here's the other approach for fixing damage vs flush client. In writing the
commit message, it certainly does feel like damage should just
Before this gets drowned out in janitorial patches... Keith, do you
want a pull request for this and the damageext patch? Did you have
have a look at the damage change?
Kristian
2010/7/29 Kristian Høgsberg k...@bitplanet.net:
We were missing the callback in a couple of places. Drivers may use
This case was missing and could cause corruption if we flush damage events
to a client before the driver gets to submit the rendering from the
callback chain.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
os/io.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
2010/7/29 Dave Airlie airl...@gmail.com:
Also, there is one more call to FlushClient in CloseDownConnection; any
reason we shouldn't be invoking the FlushCallback there too? More from a
sense of completeness than a chance that it's going to actually matter.
Yes, that sounds fine. And I just
even seen the rendering
request. Reporting damage events after the rendering fixes this
corner case and better corresponds with how we expect this to work.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
damageext/damageext.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
We were missing the callback in a couple of places. Drivers may use
the flush callback to submit batched up rendering before events (for
example, damage events) are sent out, to ensure that the rendering
has happend when the client receives the event.
Signed-off-by: Kristian Høgsberg k
Here is dri2proto version 2.3. This release adds an event designed by
Francisco Jerez to let the server notify clients when the buffers
associated with a drawable become invalid. This can happen when the
drawable is resized or when DRI2SwapBuffer exchanges front and back
buffers.
Francisco
Here is dri2proto version 2.3. This release adds an event designed by
Francisco Jerez to let the server notify clients when the buffers
associated with a drawable become invalid. This can happen when the
drawable is resized or when DRI2SwapBuffer exchanges front and back
buffers.
Francisco
.
Francisco Jerez (1):
nouveau: Update some nouveau_class.h definitions from renouveau.xml.
Julien Cristau (1):
Only install libdrm_intel.pc if we build libdrm_intel
Kristian Høgsberg (18):
Add support for vblank events
Add makefile rule to copy headers from kernel tree
by a server release.
Julien Cristau (1):
Distribute the protocol documentation
Kristian Høgsberg (1):
Bump to 2.0 and release
Paulo Cesar Pereira de Andrade (1):
Janitor: Correct make distcheck and dont distribute autogen.sh
git tag: dri2proto-2.0
http://xorg.freedesktop.org/archive
by a server release.
Julien Cristau (1):
Distribute the protocol documentation
Kristian Høgsberg (1):
Bump to 2.0 and release
Paulo Cesar Pereira de Andrade (1):
Janitor: Correct make distcheck and dont distribute autogen.sh
git tag: dri2proto-2.0
http://xorg.freedesktop.org/archive
Ok, here's a quick follow on release to 2.4.6 to fix an embarrasing
build problem in the test suite when libudev is not available.
Kristian
Dave Airlie (1):
drm: fix test makefile
Kristian Høgsberg (3):
test: Makefile.am grammar nazi
test: Avoid recursive dependency
On Wed, Mar 25, 2009 at 10:21:51AM -0700, Jesse Barnes wrote:
In trying to track down the memory leak in 20704, I found that the DRI2
drawable destroy routine doesn't seem to get called when new drawables
are created and old ones destroyed (as in the glViewport case in the
bug).
Ok, sorry for
2009/4/1 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-03-30 at 13:04 +0800, Shuang He wrote:
Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
The leak is (as you pointed out before) because we NULL the pDraw
On Sat, Feb 28, 2009 at 12:21 AM, Eric Anholt e...@anholt.net wrote:
...
I think the problem here was the DRI2 tiling fix, which was great for
the 915-class 3D performance regression but bad for 915-class 2D. I've
pushed a fix to master that should help. If it does, I'll try to get a
2.6.3
On Sun, Feb 8, 2009 at 7:00 AM, Eric Anholt e...@anholt.net wrote:
With trying to match depths so that you didn't end up with a depth 24
fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth
24 X visual, which angered other applications. But in fixing that, the
On Mon, Jan 26, 2009 at 7:41 PM, Alex Deucher alexdeuc...@gmail.com wrote:
AMD is pleased to announce the release of a 3D register reference
guide for Radeon 6xx/7xx chips.
The guide will be available in the usual places:
http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf
and
On Wed, Jan 21, 2009 at 11:14 AM, Vasily Khoruzhick anars...@gmail.com wrote:
Hi, with mesa from git 3D is not hardware accellerated anymore on gma950,
glxinfo | grep rend
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
LIBGL_DEBUG=1 glxgears
libGL error: dlopen
Here's the 1.99.3 release of dri2proto, required by xserver master and 1.6.
cheers,
Kristian
Kristian Høgsberg (3):
Add protocol documentation, update to DRI2CopyRegion request.
Bump version to 1.99.2.
Bump to 1.99.3 and back out the value bitmask from the CopyRegion
request
Hi,
Here's a quick, last-minute note on the state of DRI2 before I take
off for 2 weeks of vacation. I just pushed the updated protocol+docs
to dri2proto and updated mesa, xserver and the dri2 branch of
xf86-video-intel with the corresponding changes. What's implemented
here is the lowest level
27 matches
Mail list logo
