[PATCH] dri2: Don't throw an error on glXSwapBuffers() when single-buffered.
This fixes piglit glx-swap-singlebuffer (but not glx-swap-pixmap,
which hits a BadMatch elsewhere that I haven't tracked down), and the
original bug report of glean clipFlat, which was trying to do exactly
this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32589
---
hw/xfree86/dri2/dri2.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 9ca378f..571f7cf 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -802,9 +802,23 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
if (pPriv-buffers[i]-attachment == DRI2BufferBackLeft)
pSrcBuffer = (DRI2BufferPtr) pPriv-buffers[i];
}
-if (pSrcBuffer == NULL || pDestBuffer == NULL) {
+
+/* From the GLX 1.4 specification page 34 (page 40 of the PDF):
+ *
+ * This operation is a no-op if draw was created with a
+ * non-double-buffered GLXFBConfig, or if draw is a GLXPixmap.
+ *
+ * We interpret this as anything with no backbuffer does nothing
+ * for glXSwapBuffers(). See piglit glx-swap-pixmap and
+ * glx-swap-singlebuffer.
+ */
+if (pSrcBuffer == NULL) {
+ return Success;
+}
+
+if (pDestBuffer == NULL) {
xf86DrvMsg(pScreen-myNum, X_ERROR,
- [DRI2] %s: drawable has no back or front?\n, __func__);
+ [DRI2] %s: drawable has no front?\n, __func__);
return BadDrawable;
}
--
1.7.5.1
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: [PATCH] dri2: Don't throw an error on glXSwapBuffers() when single-buffered.
On Thu, 2 Jun 2011 01:16:33 +0300, Ville Syrjälä syrj...@sci.fi wrote:
On Wed, Jun 01, 2011 at 02:49:03PM -0700, Eric Anholt wrote:
This fixes piglit glx-swap-singlebuffer (but not glx-swap-pixmap,
which hits a BadMatch elsewhere that I haven't tracked down), and the
original bug report of glean clipFlat, which was trying to do exactly
this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32589
---
hw/xfree86/dri2/dri2.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 9ca378f..571f7cf 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -802,9 +802,23 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
if (pPriv-buffers[i]-attachment == DRI2BufferBackLeft)
pSrcBuffer = (DRI2BufferPtr) pPriv-buffers[i];
}
-if (pSrcBuffer == NULL || pDestBuffer == NULL) {
+
+/* From the GLX 1.4 specification page 34 (page 40 of the PDF):
+ *
+ * This operation is a no-op if draw was created with a
+ * non-double-buffered GLXFBConfig, or if draw is a GLXPixmap.
+ *
+ * We interpret this as anything with no backbuffer does nothing
+ * for glXSwapBuffers(). See piglit glx-swap-pixmap and
+ * glx-swap-singlebuffer.
+ */
Shouldn't this be handled in some GLX code? Doing it client side would
also avoid the pointless X request.
This is a client doing something stupid that we don't care to optimize.
I also don't trust the client to have an accurate representation of the
current set of attached buffers in the case of drawable sharing (that
unfortunate feature of GLX that makes everything about it painful).
And, this ErrorF was clearly I dunno what should happen here, think
about it when you get the message. We hit it, and I think this is the
correct response (do nothing) for any case where there is no backbuffer
present.
pgpY5BpEBTMwA.pgp
Description: PGP signature
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[PATCH] Update DRI2 requests and replies for version 1.3.
--- Here's the actual patch I meant to send. What should we do about SwapComplete? src/dri2.xml | 97 - 1 files changed, 95 insertions(+), 2 deletions(-) diff --git a/src/dri2.xml b/src/dri2.xml index dbd43f8..9bcde4f 100644 --- a/src/dri2.xml +++ b/src/dri2.xml @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=utf-8? !-- Copyright (C) 2005 Jeremy Kolb. -Copyright © 2009 Intel Corporation +Copyright © 2009-2011 Intel Corporation All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy @@ -28,7 +28,7 @@ authorization from the authors. -- xcb header=dri2 extension-xname=DRI2 extension-name=DRI2 - major-version=1 minor-version=1 + major-version=1 minor-version=3 importxproto/import enum name=Attachment @@ -46,6 +46,7 @@ authorization from the authors. enum name=DriverType item name=DRI / +item name=VDPAU / /enum !-- Types -- @@ -163,4 +164,96 @@ authorization from the authors. /list /reply /request + + request name=SwapBuffers opcode=8 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_msc_hi / +field type=CARD32 name=target_msc_lo / +field type=CARD32 name=divisor_hi / +field type=CARD32 name=divisor_lo / +field type=CARD32 name=remainder_hi / +field type=CARD32 name=remainder_lo / +reply + pad bytes=1 / + field type=CARD32 name=swap_hi / + field type=CARD32 name=swap_lo / +/reply + /request + + request name=GetMSC opcode=9 +field type=DRAWABLE name=drawable / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=WaitMSC opcode=10 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_msc_hi / +field type=CARD32 name=target_msc_lo / +field type=CARD32 name=divisor_hi / +field type=CARD32 name=divisor_lo / +field type=CARD32 name=remainder_hi / +field type=CARD32 name=remainder_lo / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=WaitSBC opcode=11 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_sbc_hi / +field type=CARD32 name=target_sbc_lo / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=SwapInterval opcode=12 +field type=DRAWABLE name=drawable / +field type=CARD32 name=interval / +reply + pad bytes=1 / + field type=CARD32 name=swap_hi / + field type=CARD32 name=swap_lo / +/reply + /request + + !-- Events -- + + event name=BufferSwapComplete number=0 +pad bytes=1 / +field type=CARD16 name=event_type / +field type=DRAWABLE name=drawable / +field type=CARD32 name=ust_hi / +field type=CARD32 name=ust_lo / +field type=CARD32 name=msc_hi / +field type=CARD32 name=msc_lo / +field type=CARD32 name=sbc_hi / +field type=CARD32 name=sbc_lo / + /event + + event name=InvalidateBuffers number=1 +pad bytes=1 / +field type=DRAWABLE name=drawable / + /event + /xcb -- 1.7.4.4 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH] Update DRI2 requests and replies for version 1.3.
--- src/dri2.xml | 75 +- 1 files changed, 74 insertions(+), 1 deletions(-) diff --git a/src/dri2.xml b/src/dri2.xml index dbd43f8..70c569d 100644 --- a/src/dri2.xml +++ b/src/dri2.xml @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=utf-8? !-- Copyright (C) 2005 Jeremy Kolb. -Copyright © 2009 Intel Corporation +Copyright © 2009-2010 Intel Corporation All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy @@ -163,4 +163,77 @@ authorization from the authors. /list /reply /request + + request name=SwapBuffers opcode=8 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_msc_hi / +field type=CARD32 name=target_msc_lo / +field type=CARD32 name=divisor_hi / +field type=CARD32 name=divisor_lo / +field type=CARD32 name=remainder_hi / +field type=CARD32 name=remainder_lo / +reply + pad bytes=1 / + field type=CARD32 name=swap_hi / + field type=CARD32 name=swap_lo / +/reply + /request + + request name=GetMSC opcode=9 +field type=DRAWABLE name=drawable / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=WaitMSC opcode=10 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_msc_hi / +field type=CARD32 name=target_msc_lo / +field type=CARD32 name=divisor_hi / +field type=CARD32 name=divisor_lo / +field type=CARD32 name=remainder_hi / +field type=CARD32 name=remainder_lo / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=WaitSBC opcode=11 +field type=DRAWABLE name=drawable / +field type=CARD32 name=target_sbc_hi / +field type=CARD32 name=target_sbc_lo / +reply + pad bytes=1 / + field type=CARD32 name=ust_hi / + field type=CARD32 name=ust_lo / + field type=CARD32 name=msc_hi / + field type=CARD32 name=msc_lo / + field type=CARD32 name=sbc_hi / + field type=CARD32 name=sbc_lo / +/reply + /request + + request name=SwapInterval opcode=12 +field type=DRAWABLE name=drawable / +field type=CARD32 name=interval / +reply + pad bytes=1 / + field type=CARD32 name=swap_hi / + field type=CARD32 name=swap_lo / +/reply + /request + /xcb -- 1.7.4.4 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH 1/2] Explicitly state padding in the BufferSwapComplete event struct.
---
dri2proto.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/dri2proto.h b/dri2proto.h
index 9708a4a..a01c908 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -290,6 +290,7 @@ typedef struct {
CARD8 pad;
CARD16 sequenceNumber B16;
CARD16 event_type B16;
+CARD16 pad2 B16;
CARD32 drawable B32;
CARD32 ust_hi B32;
CARD32 ust_lo B32;
--
1.7.4.4
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[PATCH 2/2] Attempt to make the protocol spec text reflect reality.
This was done by comparing dri2proto.h to dri2proto.txt, with some confirmation from looking at what the server was doing. --- dri2proto.txt | 39 +-- 1 files changed, 9 insertions(+), 30 deletions(-) diff --git a/dri2proto.txt b/dri2proto.txt index dc46e58..5fb7c74 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -654,7 +654,7 @@ A.2 Protocol Requests ┌─── DRI2GetBuffers 1 CARD8 major opcode - 1 3 DRI2 opcode + 1 5 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 n number of attachments @@ -674,7 +674,7 @@ A.2 Protocol Requests ┌─── DRI2CopyRegion 1 CARD8 major opcode - 1 4 DRI2 opcode + 1 6 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 REGION region @@ -691,7 +691,7 @@ A.2 Protocol Requests ┌─── DRI2GetBuffersWithFormat 1 CARD8 major opcode - 1 3 DRI2 opcode + 1 7 DRI2 opcode 2 3 length 4 DRAWABLEdrawable 4 n number of attachments @@ -711,28 +711,7 @@ A.2 Protocol Requests ┌─── DRI2SwapBuffers 1 CARD8 major opcode - 1 7 DRI2 opcode - 2 8 length - 4 DRAWABLEdrawable - ▶ - 1 1 Reply -1 unused - 2 CARD16 sequence number - 4 0 reply length - 4 CARD32 buffer count - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 4 CARD32 unused - 5n LISTofDRI2BUFFERbuffers -└─── - -┌─── -DRI2SwapBuffers - 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 8 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 target_msc_hi @@ -748,13 +727,12 @@ A.2 Protocol Requests 4 0 reply length 4 CARD32 swap_hi 4 CARD32 swap_lo - 5n LISTofDRI2BUFFERbuffers └─── ┌─── DRI2GetMSC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 9 DRI2 opcode 2 8 length 4 DRAWABLEdrawable ▶ @@ -773,7 +751,7 @@ A.2 Protocol Requests ┌─── DRI2WaitMSC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 10 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 target_msc_hi @@ -798,7 +776,7 @@ A.2 Protocol Requests ┌─── DRI2WaitSBC 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 11 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 swap_hi @@ -819,7 +797,7 @@ A.2 Protocol Requests ┌─── DRI2SwapInterval 1 CARD8 major opcode - 1 7 DRI2 opcode + 1 12 DRI2 opcode 2 8 length 4 DRAWABLEdrawable 4 CARD32 interval @@ -837,6 +815,7 @@ DRI2_InvalidateBuffers events. 1 CARD8 extension 2 CARD16 sequenceNumber 2 CARD16 event_type + 2 CARD16 unused 4 DRAWABLEdrawable 4 CARD32 ust_hi 4 CARD32 ust_lo -- 1.7.4.4 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address:
Re: [Xcb] [PATCH] Update DRI2 requests and replies for version 1.3.
On Tue, 26 Apr 2011 20:12:12 +0200, Julien Cristau jcris...@debian.org wrote: On Tue, Apr 26, 2011 at 10:39:02 -0700, Eric Anholt wrote: --- src/dri2.xml | 75 +- 1 files changed, 74 insertions(+), 1 deletions(-) diff --git a/src/dri2.xml b/src/dri2.xml index dbd43f8..70c569d 100644 --- a/src/dri2.xml +++ b/src/dri2.xml @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=utf-8? !-- Copyright (C) 2005 Jeremy Kolb. -Copyright © 2009 Intel Corporation +Copyright © 2009-2010 Intel Corporation All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy missing minor-version bump in the xcb tag [...] I notice the events aren't added. Which is probably just as well, since DRI2BufferSwapComplete still needs to be fixed anyway. Err, looks like I sent out the patch from before the commit --amend. Sorry for wasting time there, as it was really the lack of invalidate event that prompted this. What's up with DRI2BufferSwapComplete? pgpO2sdZ6LPmb.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libdrm 2.4.21
Getting new intel API out the door. The two major changes: 1) media ring support on kernel 2.6.35 for doing media decode on G45+ 2) Reduced memory allocation for BO cached objects -- saves about 1/4 of the graphics memory on workloads I tested on Ironlake and 945GM. Alan Coopersmith (2): Make libkms build default OS-dependent Correct the Solaris definitions of atomic_add atomic_dec Ben Skeggs (1): nouveau: stop shipping nouveau_class.h Chris Wilson (6): intel: Use the correct size when allocating reloc_target_info array intel: We don't need to take the bufmgr lock whilst mapping. intel: query whether a buffer is reusable. Revert intel: We don't need to take the bufmgr lock whilst mapping. intel: Don't change tiling mode unless the kernel reports success. intel: Convert to untiled pitches if surface is too large for tiling. Daniel Stone (1): libkms: Fix include paths Eric Anholt (7): intel_bufmgr_fake: fix compile warning. Enable silent automake rules. Allow a buffer to point at itself and still get relocs. intel: Add more intermediate sizes of cache buckets between powers of 2. intel: Fix several other paths for buffers pointing at themselves. Fix radeon distcheck. Bump version to 2.4.21 for release. Jerome Glisse (1): drm/radeon: add new cs command stream dumping facilities Jesse Barnes (2): tests: add new vblank test add vbltest to .gitignore Jonathan Callen (1): Only build tests in make check Kristian Høgsberg (2): Revert Fix pkgconfig includes for /usr/include/drm Pull in new kernel headers Marek Olšák (1): radeon: use the const qualifier in radeon_cs_write_table Michel Dänzer (1): vbltest: Doesn't need intel stuff. Zou Nan hai (1): intel: Add support for kernel multi-ringbuffer API. git tag: 2.4.21 http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.bz2 MD5: 273ed9dad986e3a931649f3d8762ff74 libdrm-2.4.21.tar.bz2 SHA1: be7754008424a12e01ab0f0da3deb8de13ad2f0c libdrm-2.4.21.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.gz MD5: 65a04d1a70b666971fb9e0fb64118a96 libdrm-2.4.21.tar.gz SHA1: 021c01d82e562ac658cc4b3ba5f599e6e52a2559 libdrm-2.4.21.tar.gz pgplOemDGUWtE.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: i915 interlaced display, again
On Tue, 25 May 2010 18:41:46 +0200, Krzysztof Halasa k...@pm.waw.pl wrote: Hi, Now that the non-KMS support is gone, the following patches implement interlaced mode display on i915 and similar hardware. Tested on i915 + analog VGA, it would be worth checking if newer chips (and which ones) still support interlaced mode. The patches don't change the clock limits (minimums), i.e. they alone won't make it output 720x576 PAL no 720x480 NTSC, but they will work with modes like 1080i etc. (including GLX and textured Xvideo, not sure about the overlay). Comments? Applied the kernel side. Thanks! pgpu7CXh5aJwk.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Regression in 1461b31e40a3e44f6327199d23cf2ab70d8f5176
As of this commit GL has become unreliable on my Intel system: commit 1461b31e40a3e44f6327199d23cf2ab70d8f5176 Author: Pauli Nieminen ext-pauli.niemi...@nokia.com Date: Fri May 14 16:25:43 2010 +0300 dri2: Fix xserver crash if dri2 buffer allocation fails. If driver fails to allocate memory for dri2 buffer server would crash in send_buffers_reply. Solution is to handle the allocation failure and return BadAlloc to client. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com Reviewed-by: Michel Dänzer mic...@daenzer.net Reviewed-by: Kristian Høgsberg k...@bitplanet.net Signed-off-by: Keith Packard kei...@keithp.com I'm getting bad rendering and BadDrawable at swapbuffers time frequently in piglit testcases. I reverted it and tested that removing it did fix things. Grab glsl-fs-exp2, for example, and resize it under metacity, and you should see the app die in short order. Xorg.0.log mentions: [271530.104] (EE) intel(0): [DRI2] DRI2SwapBuffers: drawable has no back or front? which is not the case in a working server. pgp2dWqL8T46d.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GSoC: KMSifying cirrus?
On Wed, 24 Mar 2010 00:02:20 -0400, Daniel Gnoutcheff dan...@gnoutcheff.name wrote: Hello all! I'm planing to apply for GSoC, and Xorg is one of the projects I'm considering. I see that KMS a non-KMSed driver is on the ideas list. One of the ideas I'm considering is the KMSification of the cirrus driver (at least the alpine half of it). Would there be any interest in such a project? Cirrus cards are kind of obsolete, but I suppose *would* be nice to have one more KMS driver, perhaps a relatively simple one that could be an easy-to-follow model for other KMSification efforts. I've got a real CL-GD-5446 to do some testing with, and I've spent a bit of time tracking/testing/exploring the git repos for the kernel and for various xorg projects, so I do have a tiny head start there. More generally, I'm interested in *anything* that will help the free desktop succeed. :) So I'm choosing projects primarily on the basis of what I'm best prepared to take on, and where I can be most helpful. Thanks for any feedback! Sounds like a fun project, and doable. I'd just recommend that you reduce the scope slightly from a full KMS driver to an unaccelerated KMS driver -- there's going to be a lot of typing and bugfixing before you even get a picture on the screen. Once you've got an unaccelerated KMS driver, there are a couple of trees out there for X drivers that sit on KMS that you could take advantage of to get a desktop up and running, without having to worry about rearchitecting an existing 2D driver. I think there would be a lot of value beyond just cirrus users in having an unaccelerated KMS example driver -- plenty of (old) hardware out there that could have much nicer linux support using KMS if people saw it was easy to build, since most older accelerators aren't that interesting today. pgpCL0ZpxMP3U.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libdrm 2.4.19
New version for new Intel API that we're about to start using in Mesa. Eric Anholt (8): intel: Add initial support for Sandybridge, and clean up the #defines. intel: Use an integer for chipset generation instead of many conditionals. intel: add a comment about tiled buffer alloc height alignment from Mesa. intel: Fix typo in conversion from IS_GEN to bufmgr_gem-gen. intel: Don't tile-align pitch for untiled buffers. intel: Don't enable execbuf2 fenced relocs unless we have execbuf2. intel: Update the needs_fence flag of buffers on the validate list. Increment version to 2.4.19 for release. Francisco Jerez (1): nouveau: Update nouveau_class.h. Jakob Bornecrantz (4): vmwgfx: Update kernel header libkms: Add missing include file to libkms source libkms: Enable by default libkms: Use a standard version number Jesse Barnes (1): libdrm/intel: execbuf2 support Maarten Maathuis (1): nouveau: make sure initial kalloc for user bo ends up in the right place Marcin Kościelnicki (6): Add config.h macro HAVE_NOUVEAU libkms/intel: Throw out unused intel_bo fields. libkms/nouveau: Add support tests: Add nouveau to list of supported modules. tests: vrefresh is actually not * 1000. tests/modetest: Don't get_props on a connector after freeing it. Marek Olšák (1): radeon: add square-tiling flag Patrice Mandin (2): nv30: update for front/back stencil inversion nv30: update for 8 texture units git tag: 2.4.19 http://dri.freedesktop.org/libdrm/libdrm-2.4.19.tar.bz2 MD5: c2699b5d8ebc9e47fb56da15f460107f libdrm-2.4.19.tar.bz2 SHA1: fc6a7ae552d8f2000962bf833d72e286781081c9 libdrm-2.4.19.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.19.tar.gz MD5: 58829058201ce526d137d36f8bf7bcde libdrm-2.4.19.tar.gz SHA1: 0283c976054c0d954e2bf69c5edaf614ae2cdf00 libdrm-2.4.19.tar.gz pgp5jj0yt2LSt.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] intel-gpu-tools 1.0.2
Arjan van de Ven (1): intel_gpu_top:print a visual clue on how big a certain use is Ben Gamari (5): Add register writing tool add realloc bits to URB_FENCE decoding Fix gs_fence output in URB_FENCE output Add CONSTANT_BUFFER decoding Add CS_USB_STATE decoding Carl Worth (2): Fix error message for case of kernel prior to 2.6.30 Print unmatched opcode value for all 3D UNKNOWN messages Chris Wilson (2): Add gem_fence_thrash test dump: Minor typo Eric Anholt (18): intel_gpu_top: Print GPU clock information, which seems interesting. Make the precentage bars fit in 80 columns. Add the acthd to the GPU dump. Correctly flag the acthd when it points within a packet. Add more 965 INSTDONE bits. Oops, fix up printed hw offset since the HEAD pointer fixup intel_gpu_dump: Add details on URB_FENCE. intel_gpu_dump: Use the correct IPEHR on pre-965. intel_gpu_top: Move instdone bit definitions to lib to share with _dump. intel_gpu_dump: Add instdone register values and decoding. .gitignore: catch up to intel_reg_write addition Add a manpage for intel_reg_write intel_gpu_dump: Fix decode for LOAD_STATE_IMMEDIATE_1 with S8 set. Add INSTDONE bits for 830-865. intel_gpu_dump: Add IPEIR and PGTBL_ER to output. intel_gpu_dump: Parse LOAD_STATE_IMMEDIATE_2 for 830. intel_gpu_dump: Don't pretend we understand vertex formats on 8xx. Bump to 1.0.2 for release. Jesse Barnes (1): Four new tests for error handling Robert Bragg (4): Revert intel_gpu_top:print a visual clue on how big a certain use is Increases the sample frequency from 100/sec to 10,000/sec Adds unicode bars for quickly visualizing the busy percentages A pedantic addition of a format string to a printf call Xiang, Haihao (3): Fix the length of CONSTANT_BUFFER CS FENCE in URB_FENCE is 11-bits wide Add support for new chips git tag: 1.0.2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.2.tar.bz2 MD5: 52e33b6895cfe8b6c3e8dac79e8c05e8 intel-gpu-tools-1.0.2.tar.bz2 SHA1: 8f6b5ddc1d74892797c28b39e47fe308c3ccecb8 intel-gpu-tools-1.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.2.tar.gz MD5: 81e4de7fc11cea3559a4bcc064f70d40 intel-gpu-tools-1.0.2.tar.gz SHA1: a9db75765c513ca1cdbc6080ddabf369a84431bb intel-gpu-tools-1.0.2.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libdrm 2.4.13
New release for a function I should have exposed from libdrm a long time ago. It lets us fix ARB_oq support, and I needed it for ARB_map_buffer_range. Alex Deucher (3): Add R600_SCRATCH_REG_OFFSET to radeon_drm.h Add RADEON_INIT_R600_CP too radeon: pull in z pipe changes from kernel Anssi Hannula (1): link libdrm_intel with -lrt for new use of clock_gettime(). Ben Skeggs (6): nouveau: drm api 0.0.15, update object header, remove fake bo support nouveau: user buffers need to be mappable nouveau: don't overwrite user-specified bo size needlessly nouveau: for the moment, assert if we exceed some reloc limits nouveau: support for copy-less pushbuf ioctl nouveau: fix a thinko in copyless pushbuf ioctl Christoph Brill (1): Filter radeon pkgconfig file as do intel and nouveau Dave Airlie (4): radeon: don't map/unmap explicitly. libdrm_radeon: add tiling support radeon: fix GTT writing space check radeon: fix bo wait at map time. Eric Anholt (2): Add drm_intel_bo_busy to query whether mapping a BO would block. Bump to version 2.4.13 for release. Jakob Bornecrantz (1): Kill last remnant of replacefb ioctl Maarten Maathuis (1): libdrm/nouveau: unmap before ufree means nvbo-sysmem != NULL, which inbalances cpu_prep/cpu_finish Michel Dänzer (2): libdrm_radeon: Always wait for BO idle in bo_map. Revert libdrm_radeon: Always wait for BO idle in bo_map. Pauli Nieminen (4): libdrm/radeon: Update head of linked list not to point freed memory. libdrm_radeon: Fix loops so that compiler can optimize them. libdrm_radeon: Optimize copy of table to cs buffer with specialized call. radeon: add support for busy/domain check interface. git tag: libdrm-2.4.13 http://dri.freedesktop.org/libdrm/libdrm-2.4.13.tar.bz2 MD5: 10c92b718476239f401d9515636ca623 libdrm-2.4.13.tar.bz2 SHA1: 0d3065d8521fca97239ce4aecbc81dc08d07de7d libdrm-2.4.13.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.13.tar.gz MD5: 0c81fbb79d3ec50896c609b736f442db libdrm-2.4.13.tar.gz SHA1: df82ead09f0a2075f8ec2c08cca6a63bc837afdd libdrm-2.4.13.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Intel i915 / GEM throttling / 2.6.31-rc
On Mon, 2009-08-03 at 17:20 +0200, Sven Arvidsson wrote: On Mon, 2009-08-03 at 16:58 +0200, Michał Kazior wrote: Since the inclusion of a GEM throttling commit [1] to the 2.6.31 release candidate I started to have serious issues using 3D acceleration. [...] Are you guys aware of this issue ? Any other thoughts ? Eric Anholt posted a patch on the mesa3d-dev list, which seems to be made for use with the new throttling behaviour. I don't think it has been commited yet though? http://www.nabble.com/-PATCH--intel%3A-Use-a-new-DRI2-extension-to-throttle-the-number-of-outstanding-frames.-td24609475.html Yeah, review was you're working too hard, do this simpler thing. I hadn't gotten around to writing it yet. commit 0828579a658af01a64b5e699175dc9bbbedcd685 Author: Eric Anholt e...@anholt.net Date: Tue Jul 21 11:23:18 2009 -0700 intel: Wait on the last swapbuffers to complete before queuing a new one. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: 2 commits - src/drmmode_display.c src/i830_exa.c src/i830.h src/i830_memory.c src/i830_video.c
On Wed, 2009-05-20 at 08:20 +0200, Michel Dänzer wrote:
On Tue, 2009-05-19 at 10:09 -0700, Eric Anholt wrote:
commit 34660fd2df5d61b77ed7041d32ac29053fc94f5a
Author: Eric Anholt e...@anholt.net
Date: Fri May 15 23:21:05 2009 -0700
Only sync XV to vblank when drawing to the frontbuffer.
This fixes emitting syncs to random pipes with boxes bigger than that
pipe's vertical, leading to GPU hangs.
Bug #21738
diff --git a/src/i830_video.c b/src/i830_video.c
index 1c3a5b7..6fec8ff 100644
--- a/src/i830_video.c
+++ b/src/i830_video.c
@@ -2495,13 +2495,15 @@ I830PutImage(ScrnInfoPtr pScrn,
if (sync) {
BoxPtr box;
int y1, y2;
-int pipe, event, load_scan_lines_pipe;
-
- if (pI830-use_drm_mode)
- pipe = drmmode_get_pipe_from_crtc_id(pI830-bufmgr, crtc);
- else {
- I830CrtcPrivatePtr intel_crtc = crtc-driver_private;
- pipe = intel_crtc-pipe;
+ int pipe = -1, event, load_scan_lines_pipe;
+
+ if (pPixmap != pScreen-GetScreenPixmap(pScreen)) {
+ if (pI830-use_drm_mode)
+ pipe = drmmode_get_pipe_from_crtc_id(pI830-bufmgr, crtc);
+ else {
+ I830CrtcPrivatePtr intel_crtc = crtc-driver_private;
+ pipe = intel_crtc-pipe;
+ }
This seems to do the opposite of what the commit message says, i.e. only
sync when not drawing to the front buffer.
Thanks. Somehow both keithp and I missed it.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [intel] 'Virtual' parameter to go away?
On Thu, 2009-05-21 at 15:29 +0200, Andreas Schildbach wrote: Hi everyone, some months ago, there was the idea to remove the (need of a) 'Virtual' parameter in the Display SubSection of the intel driver. What are the current plans? In the spirit of Xorg.conf-free auto-configuration, it would be very nice if this parameter was not needed (or would default to the maximum possible size for the hardware - e.g. 2048 x 2048 on an i915). Already done with UXA+DRI2: anh...@gaiman:anholt/src/linux-2.6% xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192 VGA1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ 1280x1024 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 640x48072.8 75.0 66.7 60.0 720x40070.1 640x35070.1 LVDS1 connected (normal left inverted right x axis y axis) 1280x800 60.0 + TV1 disconnected (normal left inverted right x axis y axis) -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] intel-gpu-tools 1.0.1
This release was inspired by going to roll a debian package for intel-gpu-tools and realizing I had no manpages. Whoops. And since I was in the directory, I decided to clean up some things that were bothering me about intel_gpu_dump output. Eric Anholt (6): Add gem_largeobject to ignore. Add manpages for all installed binaries. Add decode of dest buffer variables (destination format) Add decode of gen4 PIPE_CONTROL intel_gpu_dump: Stop decoding batchbuffers after MI_BATCH_BUFFER_END. Bump version to 1.0.1 for release. Jesse Barnes (1): tests: add large object test git tag: 1.0.1 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.1.tar.bz2 MD5: 37ed6e410de3e4d0e6e98634643f575c intel-gpu-tools-1.0.1.tar.bz2 SHA1: a457dcabf1546d6c348b1687297d3dfd1385924f intel-gpu-tools-1.0.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.1.tar.gz MD5: a34fbf58b4dea15df7b4e9917ddcc716 intel-gpu-tools-1.0.1.tar.gz SHA1: 524b173dc7f40ed5236cb15e354ba6c14339a970 intel-gpu-tools-1.0.1.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] intel-gpu-tools 1.0.1
This release was inspired by going to roll a debian package for intel-gpu-tools and realizing I had no manpages. Whoops. And since I was in the directory, I decided to clean up some things that were bothering me about intel_gpu_dump output. Eric Anholt (6): Add gem_largeobject to ignore. Add manpages for all installed binaries. Add decode of dest buffer variables (destination format) Add decode of gen4 PIPE_CONTROL intel_gpu_dump: Stop decoding batchbuffers after MI_BATCH_BUFFER_END. Bump version to 1.0.1 for release. Jesse Barnes (1): tests: add large object test git tag: 1.0.1 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.1.tar.bz2 MD5: 37ed6e410de3e4d0e6e98634643f575c intel-gpu-tools-1.0.1.tar.bz2 SHA1: a457dcabf1546d6c348b1687297d3dfd1385924f intel-gpu-tools-1.0.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.1.tar.gz MD5: a34fbf58b4dea15df7b4e9917ddcc716 intel-gpu-tools-1.0.1.tar.gz SHA1: 524b173dc7f40ed5236cb15e354ba6c14339a970 intel-gpu-tools-1.0.1.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libdrm 2.4.11
Two releases in one, so twice the usual tiny amount of changes. Both of the new libdrm_intel interfaces enable KMS fixes in the Intel 2D driver. Alan Coopersmith (2): Delete extra libdrm_lists.h line after libdrm_la_SOURCES in libdrm/Makefile.am Use C99 versions of __FUNCTION__ __volatile__ when not building with gcc Ben Skeggs (2): nouveau: store bo handle in public struct in bo_ref_handle nouveau: write posting got lost somewhere, bring it back Carl Worth (1): Add new drm_intel_get_pipe_from_crtc_id function. Danny Tholen (1): nouveau: fix ppc for swab changes in Linux 2.6.29 Dave Airlie (1): libdrm/mode: align subpixel results Jesse Barnes (1): intel: NULL fake bo block when freeing in evict_all Keith Packard (4): libdrm/intel: assert that clients are using bo refcounting correctly libdrm/intel: add drm_intel_bo_disable_reuse api Bump to version 2.4.10 to mark addition of drm_intel_bo_disable_reuse libdrm/intel: Make get_pipe_from_crtc_id per-bufmgr. Return -1 on failure. Stuart Bennett (1): nouveau: backlight compat fix git tag: libdrm-2.4.11 http://dri.freedesktop.org/libdrm/libdrm-2.4.11.tar.bz2 MD5: e0e66fae165d0b665b61e9516bf33ade libdrm-2.4.11.tar.bz2 SHA1: fcf8626a3d2d8c800cfe6c50431ef12ebe872fbf libdrm-2.4.11.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.11.tar.gz MD5: 52876bc2ee8cb23ad417abd8da5653da libdrm-2.4.11.tar.gz SHA1: 3b24b3b2d7dd35ab16abc06ce80e9c86c59979ed libdrm-2.4.11.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] intel-gpu-tools 1.0
This little package is an amalgamation of a few things: - miscellaneous userland tools that don't really fit into the 2D driver tree - standalone regression tests for the DRM (make check) - microbenchmarks of the DRM for kernel performance regression testing By far the most popular tool here is intel_gpu_dump (thanks cworth!), which can be run when your GPU is hung with KMS to produce a log of a bunch of interesting information for submitting bug reports. We'll hopefully be hooking this up to a kerneloops style submission daemon soon. intel_gpu_top also gives you information on a few performance bits for graphical apps, useful for pairing with sysprof+top. The intel_regdumper tool didn't make it into this release, since I want to get it rewritten when I move it over. Carl Worth (6): Add Eric's batchbuffer-decode code Add very preliminary intel_gpu_dump program Add example command for mounting debugfs intel_gpu_dump: Mention filename in error message intel_gpu_dump: Give a nicer message for missing batchbuffer-dumping code intel_gpu_dump: Use asprintf instead of a static-sized array Eric Anholt (27): Initial import of intel-graphics-tools with some microbenchmarks. Add notes about running things as root. Fix project name/version for distfiles. Add the tests we want from libdrm. Add intel_stepping from the 2D driver. intel_stepping: Add G45 and GM45. Port intel_idle from 2D driver as intel_gpu_top with a better interface. intel_gpu_top: Add more 965 bits. readme fixups rename project tests/: warning fixes Move i810_reg.h to lib/intel_reg.h and get it disted. Add intel_chipset.h to fix dist. intel_upload_blit_*: Fix reporting and generate junk instead of using random. Add a couple of other intel_upload_blit_large variants for comparison. Add a regression test for tiled object blitting. Add a test for pread after blitting to an object. Add a test for reading tiled objects with pread. Fix warning about assert in intel_batchbuffer.h intel_gpu_dump: Get the devid so we can decode correctly on gen4. intel_gpu_dump: Decode the GTT offset of batchbuffers. intel_gpu_dump: Dump ring, batch, and head/tail info when given the directory. intel_gpu_dump: Add no-arguments automatic mode, and clean up comments. Add a test to try to fill the ring. intel_gpu_top: Add ring information. .gitignore libtool junk Fix distcheck git tag: 1.0 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.tar.bz2 MD5: 05c301d9ea2ea7db923fe1c4066d32ec intel-gpu-tools-1.0.tar.bz2 SHA1: d2a6070a504658a40c40735b7819593dbf3d9c42 intel-gpu-tools-1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.tar.gz MD5: fa363e7b4f0e6290b92a151d433238e9 intel-gpu-tools-1.0.tar.gz SHA1: 9efc2f2daf6a52f5211be8e791f043bf0459653c intel-gpu-tools-1.0.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] intel-gpu-tools 1.0
This little package is an amalgamation of a few things: - miscellaneous userland tools that don't really fit into the 2D driver tree - standalone regression tests for the DRM (make check) - microbenchmarks of the DRM for kernel performance regression testing By far the most popular tool here is intel_gpu_dump (thanks cworth!), which can be run when your GPU is hung with KMS to produce a log of a bunch of interesting information for submitting bug reports. We'll hopefully be hooking this up to a kerneloops style submission daemon soon. intel_gpu_top also gives you information on a few performance bits for graphical apps, useful for pairing with sysprof+top. The intel_regdumper tool didn't make it into this release, since I want to get it rewritten when I move it over. Carl Worth (6): Add Eric's batchbuffer-decode code Add very preliminary intel_gpu_dump program Add example command for mounting debugfs intel_gpu_dump: Mention filename in error message intel_gpu_dump: Give a nicer message for missing batchbuffer-dumping code intel_gpu_dump: Use asprintf instead of a static-sized array Eric Anholt (27): Initial import of intel-graphics-tools with some microbenchmarks. Add notes about running things as root. Fix project name/version for distfiles. Add the tests we want from libdrm. Add intel_stepping from the 2D driver. intel_stepping: Add G45 and GM45. Port intel_idle from 2D driver as intel_gpu_top with a better interface. intel_gpu_top: Add more 965 bits. readme fixups rename project tests/: warning fixes Move i810_reg.h to lib/intel_reg.h and get it disted. Add intel_chipset.h to fix dist. intel_upload_blit_*: Fix reporting and generate junk instead of using random. Add a couple of other intel_upload_blit_large variants for comparison. Add a regression test for tiled object blitting. Add a test for pread after blitting to an object. Add a test for reading tiled objects with pread. Fix warning about assert in intel_batchbuffer.h intel_gpu_dump: Get the devid so we can decode correctly on gen4. intel_gpu_dump: Decode the GTT offset of batchbuffers. intel_gpu_dump: Dump ring, batch, and head/tail info when given the directory. intel_gpu_dump: Add no-arguments automatic mode, and clean up comments. Add a test to try to fill the ring. intel_gpu_top: Add ring information. .gitignore libtool junk Fix distcheck git tag: 1.0 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.tar.bz2 MD5: 05c301d9ea2ea7db923fe1c4066d32ec intel-gpu-tools-1.0.tar.bz2 SHA1: d2a6070a504658a40c40735b7819593dbf3d9c42 intel-gpu-tools-1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/intel-gpu-tools-1.0.tar.gz MD5: fa363e7b4f0e6290b92a151d433238e9 intel-gpu-tools-1.0.tar.gz SHA1: 9efc2f2daf6a52f5211be8e791f043bf0459653c intel-gpu-tools-1.0.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: VSync
On Tue, 2009-04-21 at 18:26 +0200, Olaf Ruppert wrote: On Tue, Apr 21, 2009 at 3:56 PM, Joakim Plate elu...@ecce.se wrote: Just make sure you glFinish() before you wait for the vsync. Otherwise the call to swap buffers take too long. I've seen this with SwapInterval extensions too. I tried all permutations of glFinish, drm-vsync and glXSwapBuffers. I enabled vblank_interrupt in i830_dri.c I compiled the drm_intel kernel, installed xorg-video-intel, mesa, etc. packages from debian unstable. No luck. I think I look at wrong problem. Maybe the probed modes are wrong. I will check that tomorow. I'm frustrated. All these boards are useless for me when there is no way to remove the tearing. And it seems like I am the only one with this problem. OK. If you're using GLX_SGI_video_sync and it's failing, there are two likely causes: - You're using DRI2 and we haven't done vblank-synced swapping for DRI2 yet. We were trying to come up with a decent way to support it, and we now think we have. Please hold on for a couple weeks. - You're using DRI1 and it's syncing to the wrong CRTC when you have two CRTCs enabled. You may want to play with glsync (a trivial demo app in mesa/progs/xdemos) on an idle machine to make sure it's ever working. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: VSync
On Mon, 2009-04-20 at 18:13 +0200, Olaf Ruppert wrote:
On Mon, Apr 20, 2009 at 4:41 PM, Olaf Ruppert
I believe they turn off interrupts on vblank to save power.
O.K. I checked that. I get the vblank interrupt.
But it does not help, here is the code:
static void swap(void)
{
static char * device = /dev/dri/card0;
static int fd = 0;
drm_wait_vblank_t blank;
int r = -1;
if (!fd) {
fd = open(device, O_RDWR);
if (fd 0)
die (dri: Could not open device);
}
blank.request.type = _DRM_VBLANK_RELATIVE;
blank.request.sequence = 1;
do {
r = ioctl(fd, DRM_IOCTL_WAIT_VBLANK, blank);
blank.request.type = ~_DRM_VBLANK_RELATIVE;
} while (r errno == EINTR);
if (r)
die(vsync failed);
glXSwapBuffers(dpy,stage);
}
If you're doing GL, why aren't you just using GLX_SGI_video_sync?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/4] Fix unused var warning from pci cleanups.
---
hw/xfree86/os-support/bus/linuxPci.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/os-support/bus/linuxPci.c
b/hw/xfree86/os-support/bus/linuxPci.c
index a60df25..e210fa1 100644
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -69,8 +69,6 @@ static pointer DomainMmappedIO[MAX_DOMAINS];
void
linuxPciInit(void)
{
-struct stat st;
-
memset(DomainMmappedIO, 0, sizeof(DomainMmappedIO));
}
--
1.6.2.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
shave support for xserver
Some of those VENDOR_* defines are already in other headers. I don't really care where they live or what they're called, but it does seem like quite a mess how they're sprinkled about right now (a subset in dix-config.h, some copies for xorg ddx only, the whole set now in version-config.h). Is VENDOR_MAN_* even used anywhere? Does anyone else care about what these defines look like? Also, with the cleaned up logs, there are some glaring errors. Mostly in input, though it's hard to tell signal from noise with the mieqEnqueue change that looks like it's only half done (since the callers are passing the old struct in all the time), and all the deprecation warnings about lookups. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/4] Move contributed m4 to a subdir so we can more easily update contributions.
---
Makefile.am |1 +
acinclude.m4| 227 ---
m4/ac_define_dir.m4 | 49 +++
m4/dolt.m4 | 178
4 files changed, 228 insertions(+), 227 deletions(-)
delete mode 100644 acinclude.m4
create mode 100644 m4/ac_define_dir.m4
create mode 100644 m4/dolt.m4
diff --git a/Makefile.am b/Makefile.am
index f5ab8a5..dea6fa4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,4 +1,5 @@
AUTOMAKE_OPTIONS=dist-bzip2 foreign nostdinc
+ACLOCAL_AMFLAGS = -I m4
if COMPOSITE
COMPOSITE_DIR=composite
diff --git a/acinclude.m4 b/acinclude.m4
deleted file mode 100644
index c3e36f8..000
--- a/acinclude.m4
+++ /dev/null
@@ -1,227 +0,0 @@
-dnl dolt, a replacement for libtool
-dnl Copyright © 2007-2008 Josh Triplett j...@freedesktop.org
-dnl Copying and distribution of this file, with or without modification,
-dnl are permitted in any medium without royalty provided the copyright
-dnl notice and this notice are preserved.
-dnl
-dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
-dnl Optionally, copy this file into acinclude.m4, to avoid the need to have it
-dnl installed when running autoconf on your project.
-
-AC_DEFUN([DOLT], [
-AC_REQUIRE([AC_CANONICAL_HOST])
-# dolt, a replacement for libtool
-# Josh Triplett j...@freedesktop.org
-AC_PATH_PROG(DOLT_BASH, bash)
-AC_MSG_CHECKING([if dolt supports this host])
-dolt_supported=yes
-if test x$DOLT_BASH = x; then
-dolt_supported=no
-fi
-if test x$GCC != xyes; then
-dolt_supported=no
-fi
-case $host in
-i?86-*-linux*|x86_64-*-linux*|powerpc-*-linux* \
-|amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*)
-pic_options='-fPIC'
-;;
-i?86-apple-darwin*)
-pic_options='-fno-common'
-;;
-*)
-dolt_supported=no
-;;
-esac
-if test x$dolt_supported = xno ; then
-AC_MSG_RESULT([no, falling back to libtool])
-LTCOMPILE='$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(COMPILE)'
-LTCXXCOMPILE='$(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(CXXCOMPILE)'
-else
-AC_MSG_RESULT([yes, replacing libtool])
-
-dnl Start writing out doltcompile.
-cat __DOLTCOMPILE__EOF__ doltcompile
-#!$DOLT_BASH
-__DOLTCOMPILE__EOF__
-cat '__DOLTCOMPILE__EOF__' doltcompile
-args=($[]@)
-for ((arg=0; arg${#args@:@@@:@}; arg++)) ; do
-if test x${args@:@$arg@:@} = x-o ; then
-objarg=$((arg+1))
-break
-fi
-done
-if test x$objarg = x ; then
-echo 'Error: no -o on compiler command line' 12
-exit 1
-fi
-lo=${args@:@$objarg@:@}
-obj=${lo%.lo}
-if test x$lo = x$obj ; then
-echo Error: libtool object file name \$lo\ does not end in .lo 12
-exit 1
-fi
-objbase=${obj##*/}
-__DOLTCOMPILE__EOF__
-
-dnl Write out shared compilation code.
-if test x$enable_shared = xyes; then
-cat '__DOLTCOMPILE__EOF__' doltcompile
-libobjdir=${obj%$objbase}.libs
-if test ! -d $libobjdir ; then
-mkdir_out=$(mkdir $libobjdir 21)
-mkdir_ret=$?
-if test $mkdir_ret -ne 0 test ! -d $libobjdir ; then
- echo $mkdir_out 12
-exit $mkdir_ret
-fi
-fi
-pic_object=$libobjdir/$objbase.o
-args@:@$objarg@:@=$pic_object
-__DOLTCOMPILE__EOF__
-cat __DOLTCOMPILE__EOF__ doltcompile
-\${args@:@@@:@} $pic_options -DPIC || exit \$?
-__DOLTCOMPILE__EOF__
-fi
-
-dnl Write out static compilation code.
-dnl Avoid duplicate compiler output if also building shared objects.
-if test x$enable_static = xyes; then
-cat '__DOLTCOMPILE__EOF__' doltcompile
-non_pic_object=$obj.o
-args@:@$objarg@:@=$non_pic_object
-__DOLTCOMPILE__EOF__
-if test x$enable_shared = xyes; then
-cat '__DOLTCOMPILE__EOF__' doltcompile
-${args@:@@@:@} /dev/null 21 || exit $?
-__DOLTCOMPILE__EOF__
-else
-cat '__DOLTCOMPILE__EOF__' doltcompile
-${args@:@@@:@} || exit $?
-__DOLTCOMPILE__EOF__
-fi
-fi
-
-dnl Write out the code to write the .lo file.
-dnl The second line of the .lo file must match ^# Generated by .*libtool
-cat '__DOLTCOMPILE__EOF__' doltcompile
-{
-echo # $lo - a libtool object file
-echo # Generated by doltcompile, not libtool
-__DOLTCOMPILE__EOF__
-
-if test x$enable_shared = xyes; then
-cat '__DOLTCOMPILE__EOF__' doltcompile
-echo pic_object='.libs/${objbase}.o'
-__DOLTCOMPILE__EOF__
-else
-cat '__DOLTCOMPILE__EOF__' doltcompile
-echo pic_object=none
-__DOLTCOMPILE__EOF__
-fi
-
-if test x$enable_static = xyes; then
-cat '__DOLTCOMPILE__EOF__' doltcompile
-echo non_pic_object='${objbase}.o'
-__DOLTCOMPILE__EOF__
-else
-cat '__DOLTCOMPILE__EOF__' doltcompile
-echo non_pic_object=none
-__DOLTCOMPILE__EOF__
-fi
-
-cat '__DOLTCOMPILE__EOF__' doltcompile
-} $lo
-__DOLTCOMPILE__EOF__
-
-dnl Done writing out doltcompile; substitute it for libtool compilation.
-chmod +x doltcompile
-LTCOMPILE='$(top_builddir)/doltcompile
[PATCH 3/4] Add shave so that we can see the steaming piles of warnings generated.
The old style output can be reenabled for build system debugging using
make V=1, or --disable-shave at configure time.
---
.gitignore |2 +
configure.ac |7 +
m4/shave.m4 | 73 +++
shave-libtool.in | 69 +
shave.in | 76 ++
5 files changed, 227 insertions(+), 0 deletions(-)
create mode 100644 m4/shave.m4
create mode 100644 shave-libtool.in
create mode 100644 shave.in
diff --git a/.gitignore b/.gitignore
index df9006a..3fb73f0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,8 @@ install-sh
libtool
ltmain.sh
missing
+shave
+shave-libtool
TAGS
tags
cscope*
diff --git a/configure.ac b/configure.ac
index 81481dc..5d0d3fd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,6 +32,11 @@ AC_CONFIG_SRCDIR([Makefile.am])
AM_INIT_AUTOMAKE([dist-bzip2 foreign])
AM_MAINTAINER_MODE
+AC_CONFIG_FILES([
+ shave
+ shave-libtool
+])
+
# Require xorg-macros version 1.2.0 or newer for XORG_CHANGELOG and
# XORG_CWARNFLAGS
m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or
later before running autoconf/autogen])])
@@ -1878,6 +1883,8 @@ AC_SUBST([prefix])
XORG_MANPAGE_SECTIONS
XORG_CHANGELOG
+SHAVE_INIT([.], [enable])
+
AC_OUTPUT([
Makefile
glx/Makefile
diff --git a/m4/shave.m4 b/m4/shave.m4
new file mode 100644
index 000..0c2c9f5
--- /dev/null
+++ b/m4/shave.m4
@@ -0,0 +1,73 @@
+dnl Make automake/libtool output more friendly to humans
+dnl
+dnl SHAVE_INIT([shavedir],[default_mode])
+dnl
+dnl shavedir: the directory where the shave scripts are, it defaults to
+dnl $(top_builddir)
+dnl default_mode: (enable|disable) default shave mode. This parameter
+dnl controls shave's behaviour when no option has been
+dnl given to configure. It defaults to disable.
+dnl
+dnl * SHAVE_INIT should be called late in your configure.(ac|in) file (just
+dnl before AC_CONFIG_FILE/AC_OUTPUT is perfect. This macro rewrites CC and
+dnl LIBTOOL, you don't want the configure tests to have these variables
+dnl re-defined.
+dnl * This macro requires GNU make's -s option.
+
+AC_DEFUN([_SHAVE_ARG_ENABLE],
+[
+ AC_ARG_ENABLE([shave],
+AS_HELP_STRING(
+ [--enable-shave],
+ [use shave to make the build pretty [[default=$1]]]),,
+ [enable_shave=$1]
+)
+])
+
+AC_DEFUN([SHAVE_INIT],
+[
+ dnl you can tweak the default value of enable_shave
+ m4_if([$2], [enable], [_SHAVE_ARG_ENABLE(yes)], [_SHAVE_ARG_ENABLE(no)])
+
+ if test x$enable_shave = xyes; then
+dnl where can we find the shave scripts?
+m4_if([$1],,
+ [shavedir=$ac_pwd],
+ [shavedir=$ac_pwd/$1])
+AC_SUBST(shavedir)
+
+dnl make is now quiet
+AC_SUBST([MAKEFLAGS], [-s])
+AC_SUBST([AM_MAKEFLAGS], ['`test -z $V echo -s`'])
+
+dnl we need sed
+AC_CHECK_PROG(SED,sed,sed,false)
+
+dnl substitute libtool
+SHAVE_SAVED_LIBTOOL=$LIBTOOL
+LIBTOOL=${SHELL} ${shavedir}/shave-libtool '${SHAVE_SAVED_LIBTOOL}'
+AC_SUBST(LIBTOOL)
+
+dnl substitute cc/cxx
+SHAVE_SAVED_CC=$CC
+SHAVE_SAVED_CXX=$CXX
+SHAVE_SAVED_FC=$FC
+SHAVE_SAVED_F77=$F77
+CC=${SHELL} ${shavedir}/shave cc ${SHAVE_SAVED_CC}
+CXX=${SHELL} ${shavedir}/shave cxx ${SHAVE_SAVED_CXX}
+FC=${SHELL} ${shavedir}/shave fc ${SHAVE_SAVED_FC}
+F77=${SHELL} ${shavedir}/shave f77 ${SHAVE_SAVED_F77}
+AC_SUBST(CC)
+AC_SUBST(CXX)
+AC_SUBST(FC)
+AC_SUBST(F77)
+
+V=@
+ else
+V=1
+ fi
+ Q='$(V:1=)'
+ AC_SUBST(V)
+ AC_SUBST(Q)
+])
+
diff --git a/shave-libtool.in b/shave-libtool.in
new file mode 100644
index 000..1f3a720
--- /dev/null
+++ b/shave-libtool.in
@@ -0,0 +1,69 @@
+#!/bin/sh
+
+# we need sed
+s...@sed@
+if test -z $SED ; then
+SED=sed
+fi
+
+lt_unmangle ()
+{
+ last_result=`echo $1 | $SED -e 's#.libs/##' -e 's#[0-9a-zA-Z_\-\.]*_la-##'`
+}
+
+# the real libtool to use
+LIBTOOL=$1
+shift
+
+# if 1, don't print anything, the underlaying wrapper will do it
+pass_though=0
+
+# scan the arguments, keep the right ones for libtool, and discover the mode
+preserved_args=
+while test $# -gt 0; do
+opt=$1
+shift
+
+case $opt in
+--mode=*)
+mode=`echo $opt | $SED -e 's/[-_a-zA-Z0-9]*=//'`
+preserved_args=$preserved_args $opt
+;;
+-o)
+lt_output=$1
+preserved_args=$preserved_args $opt
+ ;;
+*)
+preserved_args=$preserved_args $opt
+;;
+ esac
+done
+
+case $mode in
+compile)
+# shave will be called and print the actual CC/CXX/LINK line
+preserved_args=$preserved_args --shave-mode=$mode
+pass_though=1
+;;
+link)
+preserved_args=$preserved_args --shave-mode=$mode
+Q= LINK
+;;
+*)
+# let's u
+# echo *** libtool: Unimplemented mode: $mode, fill a bug report
+;;
+esac
+
+lt_unmangle $lt_output
Re: [Intel-gfx] Bad Commit
On Tue, 2009-04-07 at 09:49 +0800, Fu Michael wrote: Mike Lothian wrote: Could commit: drm/i915: Use LVDS config in Driver feature BDB for integrated LVDS check ed356c1946edc4017799de0371ef229bffa5e72c Be removed from the drm-intel-next branch please It caused KMS to break for me on my Intel(R) Mobile Intel GM45 Express Chipset It's rare to see this bits are invalid for a new platform such as GM45 based platform. What's the specific model of your machine? The code's been removed from the branch for a while, anyway. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel Ooops with i945
On Tue, 2009-03-10 at 13:57 +0100, Tino Keitel wrote: Hi, yesterday I tried again to get something usable out of the Intel 2.6.x driver on my Mac mini Core Duo with i945. So I installed the latest git versions of the kernel, drm and mesa, Intel driver 2.6.3 with UXA enabled and a pre-1.6 version of the Xserver, and got a kernel ooops: We've had a few reports of this oops at this point, but never found a way to reproduce it. Can you? [drm] Initialized drm 1.1.0 20060810 pci :00:02.0: setting latency timer to 64 i2c-adapter i2c-1: unable to read EDID block. pci :00:02.0: DVI-D-1: no EDID data [drm] TV-10: set mode NTSC 480i 0 [drm:drm_helper_initial_config] *ERROR* connectors have no modes, using standard modes allocated 800x600 fb: 0x00fdf000, bo f5f22c40 fb0: inteldrmfb frame buffer device registered panic notifier [drm] Initialized i915 1.6.0 20080730 on minor 0 [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1 i2c-adapter i2c-1: unable to read EDID block. pci :00:02.0: DVI-D-1: no EDID data [drm] TV-10: set mode NTSC 480i 0 i2c-adapter i2c-1: unable to read EDID block. pci :00:02.0: DVI-D-1: no EDID data [drm] TMDS-8: set mode 800x600 18 [drm] TV-10: set mode 800x600 19 BUG: unable to handle kernel paging request at 9bf8 IP: [f82d5f08] i915_gem_flush+0xd8/0x130 [i915] *pde = Oops: 0002 [#1] SMP last sysfs file: /sys/devices/pci:00/:00:1e.0/:03:03.0/resource Modules linked in: i915 drm dm_mod firewire_sbp2 snd_hda_codec_idt snd_hda_intel firewire_ohci firewire_core snd_hda_codec usblp crc_itu_t snd_pcm snd_timer snd_page_alloc sky2 Pid: 28163, comm: Xorg Not tainted (2.6.29-rc7-00102-g7a203f3 #3) Macmini1,1 EIP: 0060:[f82d5f08] EFLAGS: 00213216 CPU: 0 EIP is at i915_gem_flush+0xd8/0x130 [i915] EAX: 9bf8 EBX: 0001 ECX: 9bfc EDX: 9c00 ESI: 0204 EDI: f5d07000 EBP: f5f35e0c ESP: f5f35df8 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process Xorg (pid: 28163, ti=f5f34000 task=f5cb1820 task.ti=f5f34000) Stack: 0008 f697b400 f697b400 0008 0001 f5f35ec4 f82d8f3c f6272580 f5f35e6c c016d240 ea7a1b78 0063 0001 c057e840 f60688c0 f6b65500 f697b400 f5c2d520 f697b414 f5c2d640 f5c2d5a0 0001 Call Trace: [f82d8f3c] ? i915_gem_execbuffer+0xd1c/0xd40 [i915] [c016d240] ? handle_mm_fault+0xf0/0x560 [c0414db8] ? mutex_unlock+0x8/0x10 [c0293d25] ? copy_from_user+0x35/0x130 [f827d318] ? drm_ioctl+0xe8/0x2f0 [drm] [c0144fc3] ? getnstimeofday+0x53/0x120 [f82d8220] ? i915_gem_execbuffer+0x0/0xd40 [i915] [c018aaa1] ? vfs_ioctl+0x71/0x80 [c018af42] ? do_vfs_ioctl+0x72/0x5a0 [c01483b2] ? tick_handle_oneshot_broadcast+0xd2/0x110 [c017ef82] ? vfs_write+0x102/0x140 [c017e4a0] ? do_sync_write+0x0/0x110 [c018b4a9] ? sys_ioctl+0x39/0x70 [c0103445] ? sysenter_do_call+0x12/0x25 [c041] ? init_centaur+0x1cf/0x2b6 Code: f0 66 90 89 f0 83 c8 02 f6 45 ec 10 0f 45 f0 83 7f 20 07 7e 4e 8b 57 1c 8b 4f 14 8b 5f 0c 8d 04 11 83 c2 04 21 da 01 d1 83 c2 04 89 30 21 da c7 01 00 00 00 00 8b 47 08 89 57 1c 83 6f 20 08 05 EIP: [f82d5f08] i915_gem_flush+0xd8/0x130 [i915] SS:ESP 0068:f5f35df8 ---[ end trace 8f654121df941966 ]--- Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel - Dithering on a 6 bit panel
On Tue, 2009-03-03 at 23:57 +, James Legg wrote: Hello, I have an Asus X58L laptop, which has Intel GM965 graphics. The framebuffer configurations reported by glxinfo all have 8 bits for each of the colour channels. However, the output looks like 6 bits with static 2 by 2 spatial dithering. Assuming the display is actually 6 bits, is there any way I can get temporal dithering? Yeah, your panel is likely only 6 bits. I've never seen any knobs for better dithering. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Tiling on i915-class hardware
On Thu, 2009-03-05 at 23:33 +0200, Vasily Khoruzhick wrote: On Thursday 05 March 2009 10:12:11 you wrote: Hi, I've just tested i915 tiling in 2 ram configurations: 512mb, single channel: tiling works perfectly, no performance issues with tiling enabled 512mb + 512mb dual channel interleaved: When tiling is enabled it introduces performance regression, when I enable tiling 3D performance is low. With tiling disabled I hit this bug: http://bugs.freedesktop.org/show_bug.cgi?id=19738 So, the problem exists at least for configurations with 2 memory modules in dual channel interleaved mode, and it doesn't exist in single channel mode. I can provide any additional info if you need. Regards Vasily Ok, I've traced a little bit i915_gem_detect_bit_6_swizzle() and found out that my memory controller configuration is one with bit 17 XORed in; cite from i915_gem_tiling.c comments: * When bit 17 is XORed in, we simply refuse to tile at all. Bit * 17 is not just a page offset, so as we page an objet out and back in, * individual pages in it will have different bit 17 addresses, resulting in * each 64 bytes being swapped with its neighbor! So as far as I understand it's a reason why tiling is not working on my hardware (945gm, with 2 memory modules, each one is 512mb). Is there any way to disable XORing/do anything to get full 3D performance? No, your BIOS sets it up, and it's a property of your northbridge. We've got a plan for a workaround, but it's a bit complicated and not done yet. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.6.3
This is an easy one: two bugfixes for regressions in the last release. One broke initialization with UXA and DRI1, and the other made pixmap allocation on i915 take insane amounts of memory. Eric Anholt (3): Disable fb resizing for DRI1-only server so that DRI1 can initialize. Only allocate pixmaps aligned for tiling when requested by DRI2 GetBuffers. Bump version to 2.6.3. git tag: 2.6.3 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.3.tar.bz2 MD5: 440c014bbd3072b5d379fe1bdb861918 xf86-video-intel-2.6.3.tar.bz2 SHA1: 96fe7e8b804ab8833b1d462f99c08be29bb9e283 xf86-video-intel-2.6.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.3.tar.gz MD5: 34aa5b8de881baaf85f223cb55f39496 xf86-video-intel-2.6.3.tar.gz SHA1: 466731f2dd1984900b1c2556a0f0e13b1e6ddc5b xf86-video-intel-2.6.3.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.2
On Mon, 2009-03-02 at 14:29 +0200, Vasily Khoruzhick wrote: On Sunday 01 March 2009 13:40:16 Vasily Khoruzhick wrote: Thanks, fix works for me (no more memory leakage) :) Btw, it seems that it's a fix of catalyst, not of the real leak: after ~24h of usage 398mb of swap is used. lsof | grep drm mm object | wc -l shows 700, is it OK? Yes. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.2
On Wed, 2009-02-25 at 19:13 +0100, Brice Goglin wrote: Eric Anholt wrote: On Wed, 2009-02-25 at 14:10 +0100, Jacek Luczak wrote: this release is totally unusable while running in UXA. System eats lot of memory, including swapping. Is this that, reported earlier, ,,memory leak''? As a result X are really slow and lot of lockups occur (everything freeze for a few seconds). At the end I can't even switch to text console, but system reacts on power button and it goes down successfully. With EXA there's no such issue: total system memory usage around 40%, no lockups. If it's not know issue I will try to bisect it down. -Jacek -- Details: 1. X.Org X Server 1.5.99.903 (1.6.0 RC 3) 2. Linux Kernel 2.6.29-rc6 Can you give me exact steps to reproduce this leak? Same problem here with libdrm 2.4.5, intel 2.6.2, Xserver 1.6-rc2, Mesa 7.3 on Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) Nothing specific needed to reproduce the problem, just use X :) As soon as I start a big application such as firefox ou thunderbird, my 1GB RAM is entirely used after a couple seconds and the system becomes vey slow. Only downgrade intel to 2.6.1 = 200MB used, no problem. 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 out soon. commit 5bfd73cd31ba197a62f549cdbad1a1270b571027 Author: Eric Anholt e...@anholt.net Date: Fri Feb 27 19:09:49 2009 -0800 Only allocate pixmaps aligned for tiling when requested by DRI2 GetBuffers. This saves massive quantities of memory on pre-965 since the DRI2 tiling enable caused the minimum size of any pixmap to be 1MB. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.2
On Wed, 2009-02-25 at 13:20 +0100, Khashayar Naderehvandi wrote: On Tue, Feb 24, 2009 at 11:46 PM, Eric Anholt e...@anholt.net wrote: Here comes a pretty significant bugfix release for the 2.6 2D series. The goal of this release is to get out the major fixes for GEM and KMS that we think we've pounded on enough to be stable -- certainly more stable than previously. Notable fixes include a significant BO memory usage reduction (which many have suffered from with compositing), textured XV suppor twith KMS, and rotation support with KMS. Some infrequent failure to render/xv with GEM on 965 (dmesg warnings about being unable to bind objects) should also be fixed. But perhaps the exciting thing for most people will be the dynamic front buffer allocation. We nearly slipped this into 2.6.0, but decided that it was just a little too new. Well, turns out it was actually in good shape, and it's time to get it out there. You'll need UXA to do this. I'm having problems compiling this release on my machine. The error I see is the following: ../../src/i830_memory.c: In function ‘i830_allocator_init’: ../../src/i830_memory.c:542: error: ‘I915_SETPARAM_NUM_USED_FENCES’ undeclared (first use in this function) ../../src/i830_memory.c:542: error: (Each undeclared identifier is reported only once ../../src/i830_memory.c:542: error: for each function it appears in.) This is on ubuntu jaunty with the following stack xorg server: 1.5.99.902 mesa: 7.4 branch updated as of today (Feb 25th) libdrm 2.4.5 Any suggestions? You need the kernel headers corresponding to the libdrm you have installed. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.6.2
On Wed, 2009-02-25 at 14:10 +0100, Jacek Luczak wrote: Eric Anholt pisze: Here comes a pretty significant bugfix release for the 2.6 2D series. The goal of this release is to get out the major fixes for GEM and KMS that we think we've pounded on enough to be stable -- certainly more stable than previously. Notable fixes include a significant BO memory usage reduction (which many have suffered from with compositing), textured XV suppor twith KMS, and rotation support with KMS. Some infrequent failure to render/xv with GEM on 965 (dmesg warnings about being unable to bind objects) should also be fixed. But perhaps the exciting thing for most people will be the dynamic front buffer allocation. We nearly slipped this into 2.6.0, but decided that it was just a little too new. Well, turns out it was actually in good shape, and it's time to get it out there. You'll need UXA to do this. Hi Eric, this release is totally unusable while running in UXA. System eats lot of memory, including swapping. Is this that, reported earlier, ,,memory leak''? As a result X are really slow and lot of lockups occur (everything freeze for a few seconds). At the end I can't even switch to text console, but system reacts on power button and it goes down successfully. With EXA there's no such issue: total system memory usage around 40%, no lockups. If it's not know issue I will try to bisect it down. -Jacek -- Details: 1. X.Org X Server 1.5.99.903 (1.6.0 RC 3) 2. Linux Kernel 2.6.29-rc6 Can you give me exact steps to reproduce this leak? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.6.2
Here comes a pretty significant bugfix release for the 2.6 2D series. The goal of this release is to get out the major fixes for GEM and KMS that we think we've pounded on enough to be stable -- certainly more stable than previously. Notable fixes include a significant BO memory usage reduction (which many have suffered from with compositing), textured XV suppor twith KMS, and rotation support with KMS. Some infrequent failure to render/xv with GEM on 965 (dmesg warnings about being unable to bind objects) should also be fixed. But perhaps the exciting thing for most people will be the dynamic front buffer allocation. We nearly slipped this into 2.6.0, but decided that it was just a little too new. Well, turns out it was actually in good shape, and it's time to get it out there. You'll need UXA to do this. Bill Nottingham (1): Quirk MSI IM-945GSE-A LVDS, TV outputs. Eric Anholt (23): Remove logical context setup. Fix compile failure after 45f45c73469f1bd46a1b6fb206f2e9e5e4fd66b3 warning fix. Move 965 video setup to a separate function so we can move it around. Do check_aperture_space and batch_start_atomic for i965 video. Move i965 render state bo setup back to prepare_composite. Use intel_emit_reloc from video to prettify 965 render bind_bo setup. Move filter computation from emit_batch_header to prepare_composite. i965: Pull check_aperture out to a separate function and make it dtrt. Move i965 render transform setup from emit_composite_state to prepare_composite. Move i965 render vb setup to use time, and decouple state emit from it. Use drm_intel_bo_subdata to put render vb data in. Fix build with server 1.4. Remove 965 render wm scratch space, which was just unused. Move 965 render unit state to BOs. Move i965 render kernels to BOs. Move i965 render sampler state to BOs. Don't forget the new state bos in check_aperture. dri2: Use modesetting's master fd instead of opening our own non-master. uxa: Ask for BOs ready for rendering for pixmaps. Don't do AdjustFrame in KMS mode. Fix distcheck from drmmode_display.h deletion. Bump version to 2.6.2 for release. Helge Bahmann (1): Move disable_render_standby to EnterVT instead of startup. Jesse Barnes (2): Fixup bogus VBT modes when detected Support tiled back/depth on 915-class hardware with DRI2. Keith Packard (3): Make i830_allocate_memory take tiling parameters. Resize framebuffer on screen size change (requires UXA and DRI2) Assign rotation memory dri_bo to rotation pixmap. Kristian Høgsberg (12): Implement front buffer resize for KMS. Fix last-minute cleanup that broke the patch. Un-revert the I915_SETPARAM_NUM_USED_FENCES commit reverted by accident. Fix front buffer memset() for non-KMS case. KMS: Hook up crtc::gamma_set. Make Xv used a buffer object instead of i830_memory. Dont allocate overlay registers in KMS mode. Fix i915 textured video to work with the i830_memory - bo change. Access the Xv buffer through the GTT for the non-KMS case. KMS: Hook up rotated shadow buffers. KMS: Fix bug that prevented EDID data from getting propagated. Update kms to work with drmModeModeInfo API update. Ma Ling (1): Don't disable vga centering bit. Vincent Mussard (1): quirk for AOpen MP45 Zhenyu Wang (1): TV quirk for HP Compaq nx6310 git tag: 2.6.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.2.tar.bz2 MD5: c171bb4175cfcea2662079ef20ee2020 xf86-video-intel-2.6.2.tar.bz2 SHA1: 8da19bf6c66fa66d42eedae322ee98397ee58397 xf86-video-intel-2.6.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.2.tar.gz MD5: 9db24b22c07d0a356388414ae7c3e7f1 xf86-video-intel-2.6.2.tar.gz SHA1: 403da992f9352f4f2ee8ad13b392c47cc897bb91 xf86-video-intel-2.6.2.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] try to make release.sh support version-only tags.
We're sick of typing xf86-video-intel-whatever in the Intel driver, but the
script doesn't like our tags. This change nearly fixes that, but errors out
and hasn't been tested for module-version tags. Perhaps someone else could
clean it up.
---
release.sh | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/release.sh b/release.sh
index 73e8c7f..0383a12 100755
--- a/release.sh
+++ b/release.sh
@@ -102,10 +102,20 @@ done
tarball_dir=$(dirname $(find . -name config.status))
module=${tag_current%-*}
-version=${tag_current##*-}
-tarbz2=$tag_current.tar.bz2
-targz=$tag_current.tar.gz
-announce=$tarball_dir/$tag_current.announce
+if [ x$module = x$tag_current ]; then
+# version-number-only tag.
+pwd=`pwd`
+module=`basename $pwd`
+version=$tag_current
+else
+# module-and-version style tag
+version=${tag_current##*-}
+fi
+
+modulever=$module-$version
+tarbz2=$modulever.tar.bz2
+targz=$modulever.tar.gz
+announce=$tarball_dir/$modulever.announce
echo checking parameters
if ! [ -f $tarball_dir/$tarbz2 ] ||
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
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
pickFBconfigs code for minimal also could end up breaking GLX visuals if
the same FBconfig was chosen for more than one X visual.
We have no reason to not expose as many visuals as possible, but the old
all mode didn't match any existing X visuals to GLX visuals, so normal
GL apps didn't work at all.
Instead, replace it with a simple combination of the two modes: Create GLX
visuals by picking unique FBconfigs with as many features as possible for
each X visual in order. Then, for all remaining FBconfigs that are
appropriate for display, add a corresponding X and GLX visual.
This gets all applications (even ones that aren't smart enough to do FBconfigs)
get all the options to get the visual configuration they want. The only
potential downside is that the composite ARGB visual is unique and gets a
nearly full-featured GLX visual (except that the root visual might have taken
the tastiest FBconfig), which means that a dumb compositing manager could
waste resources. Write compositing managers using FBconfigs instead, please.
---
glx/glxscreens.c | 233 +--
glx/glxserver.h|2 -
hw/xfree86/dixmods/glxmodule.c | 15 ---
3 files changed, 78 insertions(+), 172 deletions(-)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 2c8432e..2656355 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -242,44 +242,6 @@ GLint glxConvertToXVisualType(int visualType)
? x_visual_types[ visualType - GLX_TRUE_COLOR ] : -1;
}
-
-static void
-filterOutNativeConfigs(__GLXscreen *pGlxScreen)
-{
-__GLXconfig *m, *next, **last;
-ScreenPtr pScreen = pGlxScreen-pScreen;
-int i, depth;
-
-last = pGlxScreen-fbconfigs;
-for (m = pGlxScreen-fbconfigs; m != NULL; m = next) {
- next = m-next;
- depth = m-redBits + m-blueBits + m-greenBits;
-
- for (i = 0; i pScreen-numVisuals; i++) {
- if (pScreen-visuals[i].nplanes == depth) {
- *last = m;
- last = m-next;
- break;
- }
- }
-}
-
-*last = NULL;
-}
-
-static XID
-findVisualForConfig(ScreenPtr pScreen, __GLXconfig *m)
-{
-int i;
-
-for (i = 0; i pScreen-numVisuals; i++) {
- if (glxConvertToXVisualType(m-visualType) == pScreen-visuals[i].class)
- return pScreen-visuals[i].vid;
-}
-
-return 0;
-}
-
/* This code inspired by composite/compinit.c. We could move this to
* mi/ and share it with composite.*/
@@ -387,125 +349,52 @@ initGlxVisual(VisualPtr visual, __GLXconfig *config)
visual-offsetBlue = findFirstSet(config-blueMask);
}
-typedef struct {
-GLboolean doubleBuffer;
-GLboolean depthBuffer;
-GLboolean stencilBuffer;
-} FBConfigTemplateRec, *FBConfigTemplatePtr;
-
static __GLXconfig *
-pickFBConfig(__GLXscreen *pGlxScreen, FBConfigTemplatePtr template,
-VisualPtr visual)
+pickFBConfig(__GLXscreen *pGlxScreen, VisualPtr visual)
{
-__GLXconfig *config;
+__GLXconfig *best = NULL, *config;
+int best_score;
for (config = pGlxScreen-fbconfigs; config != NULL; config =
config-next) {
+ int score = 0;
+
if (config-redMask != visual-redMask ||
config-greenMask != visual-greenMask ||
- config-blueMask != visual-blueMask ||
- config-rgbBits != visual-nplanes)
+ config-blueMask != visual-blueMask)
continue;
if (config-visualRating != GLX_NONE)
continue;
if (glxConvertToXVisualType(config-visualType) != visual-class)
continue;
- if ((config-doubleBufferMode 0) != template-doubleBuffer)
- continue;
- if ((config-depthBits 0) != template-depthBuffer)
+ /* If it's the 32-bit RGBA visual, demand a 32-bit fbconfig. */
+ if (visual-nplanes == 32 config-rgbBits != 32)
continue;
- if ((config-stencilBits 0) != template-stencilBuffer)
- continue;
-
- return config;
-}
-
-return NULL;
-}
-
-static void
-addMinimalSet(__GLXscreen *pGlxScreen)
-{
-__GLXconfig *config;
-VisualPtr visuals;
-int i, j;
-FBConfigTemplateRec best = { GL_TRUE, GL_TRUE, GL_TRUE };
-FBConfigTemplateRec good = { GL_TRUE, GL_TRUE, GL_FALSE };
-FBConfigTemplateRec minimal = { GL_FALSE, GL_FALSE, GL_FALSE };
-
-pGlxScreen-visuals = xcalloc(pGlxScreen-pScreen-numVisuals,
- sizeof (__GLXconfig *));
-if (pGlxScreen-visuals == NULL) {
- ErrorF(Failed to allocate for minimal set of GLX visuals\n);
- return;
-}
-
-visuals = pGlxScreen-pScreen-visuals;
-for (i = 0, j = 0; i pGlxScreen-pScreen-numVisuals; i++) {
- if (visuals[i].nplanes == 32)
- config =
Re: xserver: Branch 'master' - 5 commits
On Mon, 2009-02-02 at 11:20 +0100, Michel Dänzer wrote: On Sun, 2009-02-01 at 09:26 -0800, Eric Anholt wrote: commit 29b3b88dc744f4919c6709747ddb7baac47486c5 Author: Pierre Willenbrock pie...@pirsoft.de Date: Fri Jan 30 21:16:48 2009 -0800 Prevent double unref of glxdrawables Found by valgrind. Bug #18917. diff --git a/glx/glxcmds.c b/glx/glxcmds.c index af52672..33954ee 100644 --- a/glx/glxcmds.c +++ b/glx/glxcmds.c @@ -146,6 +146,8 @@ __glXContextDestroy(__GLXcontext *context) __glXUnrefDrawable(context-drawPriv); if (context-readPriv) __glXUnrefDrawable(context-readPriv); + context-drawPriv = NULL; + context-readPriv = NULL; } __glXFlushContextCache(); } @@ -621,6 +623,8 @@ DoMakeCurrent(__GLXclientState *cl, __glXUnrefDrawable(prevglxc-drawPriv); if (prevglxc-readPriv) __glXUnrefDrawable(prevglxc-readPriv); + prevglxc-drawPriv = NULL; + prevglxc-readPriv = NULL; } } diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index 30308ad..40352b4 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -3159,9 +3159,6 @@ xf86_crtc_supports_gamma(ScrnInfoPtr pScrn) xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn); xf86CrtcPtr crtc; - if (!xf86_config) - return FALSE; - if (xf86_config-num_crtc == 0) return FALSE; crtc = xf86_config-crtc[0]; The last hunk looks unrelated. This was noted on IRC as well. It should have been amended into the crtc_supports_gamma vs DRI1 fix, but wasn't. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: drm+intel error messages drm:i915_getparam conflicting memory types
On Mon, 2009-02-02 at 21:15 +, Colin Guthrie wrote: Hi, This is on a 2.6.27 kernel still as .28 is really not working for me just now with graphics stuff... trying to get more info there. Is there anything that seems obviously wrong? Col Feb 2 20:27:55 jimmy klogd: [drm:i915_getparam] *ERROR* Unknown parameter 5 Things will be slow because your kernel is old. Feb 2 20:27:56 jimmy klogd: X:3601 conflicting memory types d000-e000 write-combining-uncached-minus Things may be slow because your kernel is old. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (xserver)
On Fri, 2009-01-23 at 10:26 +1100, Daniel Stone wrote: On Thu, Jan 22, 2009 at 10:08:04AM -0500, Chris Ball wrote: Keyboard.c: In function 'xnestKeyboardProc': Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from incompatible pointer type Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts' Keyboard.c:178: warning: implicit declaration of function 'XkbInitKeyboardDeviceStruct' Keyboard.c:178: warning: nested extern declaration of 'XkbInitKeyboardDeviceStruct' Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from incompatible pointer type Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from incompatible pointer type5B Keyboard.c:122: warning: unused variable 'j' Keyboard.c:117: warning: unused variable 'modifier_keymap' Keyboard.c: In function 'xnestUpdateModifierState': Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state' Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state' Yeah, Xnest and Xdmx are broken, sorry. That being said, we've talked a lot about just deleting Xnest in favour of Xephyr: anyone got any compelling counter-arguments? Pretty sure the compelling argument was that Xnest would pass through requests so that you got acceleration from your host server. Except that it doesn't support modern extensions, so you get no acceleration and clients shaking their fists at you instead. I haven't heard of any use for it as a debugging platform, either. Nuke away, in my opinion. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.6.1
Here comes a point release to fix some nasty bits that slipped out in 2.6.0. Most important is the stability fix for 915 render/video versus DRI2. But it's also got some useful fixes for KMS -- VT switching should no longer hang, and the kernel fb layer deciding it's dpms time shouldn't leave you with the wrong thing after you come back. We've still got some issues with 965 DRI2 versus render/video, and 8xx-class in general. Hopefully we can fix up something for them soon. (965 fixes are in master, but I don't want to see it get into stable until it's had a lot of testing. That's some really dodgy code.) Eric Anholt (4): Re-emit i915 composite setup when the batchbuffer wraps. Protect i915 textured video against batchbuffer wrapping. Fix invarient state emits for DRI2 (do it per batch, since there's no lock). Bump version to 2.6.1. Jesse Barnes (2): Tear down batchbuffers unconditionally on LeaveVT Don't run in KD_TEXT mode even with KMS Kshitij Kulshreshtha (1): Support sysfs backlight control for Sony laptops in xf86-video-intel git tag: xf86-video-intel-2.6.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.1.tar.bz2 MD5: 8e0319666c2b5adf668da619f2c61a54 xf86-video-intel-2.6.1.tar.bz2 SHA1: c4d3fff72771c71eab152660be1fb33af679c06e xf86-video-intel-2.6.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.1.tar.gz MD5: 1b7cff08d425d4233c24c92fa8599b4f xf86-video-intel-2.6.1.tar.gz SHA1: 38a69b3628490fd4292723cd659c6c571b62d2c6 xf86-video-intel-2.6.1.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.6.1
Here comes a point release to fix some nasty bits that slipped out in 2.6.0. Most important is the stability fix for 915 render/video versus DRI2. But it's also got some useful fixes for KMS -- VT switching should no longer hang, and the kernel fb layer deciding it's dpms time shouldn't leave you with the wrong thing after you come back. We've still got some issues with 965 DRI2 versus render/video, and 8xx-class in general. Hopefully we can fix up something for them soon. (965 fixes are in master, but I don't want to see it get into stable until it's had a lot of testing. That's some really dodgy code.) Eric Anholt (4): Re-emit i915 composite setup when the batchbuffer wraps. Protect i915 textured video against batchbuffer wrapping. Fix invarient state emits for DRI2 (do it per batch, since there's no lock). Bump version to 2.6.1. Jesse Barnes (2): Tear down batchbuffers unconditionally on LeaveVT Don't run in KD_TEXT mode even with KMS Kshitij Kulshreshtha (1): Support sysfs backlight control for Sony laptops in xf86-video-intel git tag: xf86-video-intel-2.6.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.1.tar.bz2 MD5: 8e0319666c2b5adf668da619f2c61a54 xf86-video-intel-2.6.1.tar.bz2 SHA1: c4d3fff72771c71eab152660be1fb33af679c06e xf86-video-intel-2.6.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.1.tar.gz MD5: 1b7cff08d425d4233c24c92fa8599b4f xf86-video-intel-2.6.1.tar.gz SHA1: 38a69b3628490fd4292723cd659c6c571b62d2c6 xf86-video-intel-2.6.1.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libdrm 2.4.4
Another day, another new libdrm. We wanted to get the waitvblank workarounds out into the world, and it's got some build fixes from the non-linux folks as well. Ben Skeggs (1): nv50: ack nsource to prevent continuous protection fault irqs Dave Airlie (1): radeon: only write irq regs if irq is enabled Eric Anholt (2): intel: Retry pin ioctl on -EINTR. bump version to 2.4.4 Jesse Barnes (4): Remove executable from modeprint test dir libdrm: add timeout handling to drmWaitVBlank libdrm: only check for vblank timeout if we caught EINTR libdrm: add autoconf check for clock_gettime Owain G. Ainsworth (2): Remove drmModeReplaceFb after it was removed from the kernel. Don't use DRM_BO_FLAG_NO_MOVE in bufmgr fake. It's a ttm flag. Robert Noland (1): [FreeBSD] Fix build on FreeBSD after modesetting import. git tag: libdrm-2.4.4 http://dri.freedesktop.org/libdrm/libdrm-2.4.4.tar.bz2 MD5: c183ee614b25f61ea325d57882a2fab2 libdrm-2.4.4.tar.bz2 SHA1: 5da1a685d2028168e87c6e2855fb7cca00a02aed libdrm-2.4.4.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.4.tar.gz MD5: b83c65c87329127ab1e714c661a7f8b9 libdrm-2.4.4.tar.gz SHA1: 4b904e4eafc368d9f1b827a7439fc80a41746cb3 libdrm-2.4.4.tar.gz -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
On Thu, 2009-01-08 at 11:40 +0200, Vasily Khoruzhick wrote: On Thursday 08 January 2009 10:04:55 Zhenyu Wang wrote: Disable DRI2 buffer tiling on non-965, as those need fence regs for 2D blits. Will it be supported in future? I've got a rough plan of what to do to get tiling back pre-965. It'll depend on KMS most likely. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] XFree86: Xv: Add ClipNotify helper
On Mon, 2009-01-05 at 11:38 +0200, Daniel Stone wrote:
Add a ClipNotify helper that lets the driver know about changes in the
clipping of an Xv backing drawable. This is useful for drivers that
cannot implement more than a single bounding box.
Note: this is an ABI bump, since drivers are doing
malloc(sizeof(XF86VideoAdaptorRec) + sizeof(myprivate))
No opinion either way.
Signed-off-by: Daniel Stone daniel.st...@collabora.co.uk
---
hw/xfree86/common/xf86xv.c |4
hw/xfree86/common/xf86xv.h |3 +++
hw/xfree86/common/xf86xvpriv.h |1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 85b13d3..abbe033 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -1123,6 +1123,10 @@ xf86XVClipNotify(WindowPtr pWin, int dx, int dy)
pPriv-pCompositeClip = NULL;
+ if (pPriv-AdaptorRec-ClipNotify)
+(*pPriv-AdaptorRec-ClipNotify)(pPriv-pScrn, pPriv-DevPriv.ptr,
+ pWin, dx, dy);
+
/* Stop everything except images, but stop them too if the
window isn't visible. But we only remove the images. */
diff --git a/hw/xfree86/common/xf86xv.h b/hw/xfree86/common/xf86xv.h
index e98c423..c3db6cc 100644
--- a/hw/xfree86/common/xf86xv.h
+++ b/hw/xfree86/common/xf86xv.h
@@ -112,6 +112,8 @@ typedef int (* ReputImageFuncPtr)( ScrnInfoPtr pScrn,
short drw_x, short drw_y,
typedef int (*QueryImageAttributesFuncPtr)(ScrnInfoPtr pScrn,
int image, unsigned short *width, unsigned short *height,
int *pitches, int *offsets);
+typedef void (*ClipNotifyFuncPtr)(ScrnInfoPtr pScrn, pointer data,
+ WindowPtr window, int dx, int dy);
typedef enum {
XV_OFF,
@@ -165,6 +167,7 @@ typedef struct {
PutImageFuncPtr PutImage;
ReputImageFuncPtr ReputImage;
QueryImageAttributesFuncPtr QueryImageAttributes;
+ ClipNotifyFuncPtr ClipNotify;
} XF86VideoAdaptorRec, *XF86VideoAdaptorPtr;
typedef struct {
diff --git a/hw/xfree86/common/xf86xvpriv.h b/hw/xfree86/common/xf86xvpriv.h
index 761fc3a..7623d29 100644
--- a/hw/xfree86/common/xf86xvpriv.h
+++ b/hw/xfree86/common/xf86xvpriv.h
@@ -59,6 +59,7 @@ typedef struct {
PutImageFuncPtr PutImage;
ReputImageFuncPtr ReputImage;
QueryImageAttributesFuncPtr QueryImageAttributes;
+ ClipNotifyFuncPtr ClipNotify;
} XvAdaptorRecPrivate, *XvAdaptorRecPrivatePtr;
typedef struct {
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [intel] 10...@60hz on an intel G45 chipset
On Tue, 2009-01-06 at 15:12 +0100, strawks wrote: Hi all, I have a G45 chipset working fine at 10...@50hz but i can't get it to work at 60Hz. The X says : Not using mode 10...@60 (mode clock too high) My modeline is defined as follow (obtained with cvt -vr 1920 1080 60) : ModeLine 10...@60 173.00 1920 2048 2248 2576 1080 1083 1088 1120 I don't really need it but just curious if I missed something (maybe a bad modeline for this card?) or is it just not supported by the driver (the chipset does support 10...@60hz, win32 uses this mode by default, as reported by my TV). That's a non-reduced mode you produced, which is too high of a clock. Try cvt -v -r 1920 1080 60 -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: KMS with Xorg on G45 failing
On Tue, 2009-01-06 at 22:35 +, Mike Lothian wrote: Hi there Thought I'd send in some info about Xorg with a KMS kernel, libdrm and xf86-video-intel I've attached my dmesg and Xorg.0.log The only outputs are LVDS 15 screen an a disconnected VGA out and HDMI connectors I'll quite happily submit a bug but thought the code was a little too new to harp on about especially if this is a known issue The segfault should be fixed as of: commit 342120be0956bfc12822d1ffbfbd8aaabf3e922f Author: Eric Anholt e...@anholt.net Date: Mon Jan 5 23:21:07 2009 -0800 Fix pin leakage with EXA GTT-mapping shortcut, and crash with UXA on KMS. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Fwd: Re: Intel + GEM + suspend - fail]
On Mon, 2009-01-05 at 21:51 +0100, Adam Lantos wrote: hello, I've investigated my issue a little more: kernel: vanilla 2.6.28 + tuxonice + linux-phc + thinkpad-acpi mesa, libdrm, xorg-server, xf86-video-intel git master (last built a few days ago) -EXA behaves fine -UXA w/ twm is fine -UXA w/ enlightenment wm crashes on vt switch, acpi resume and hibernation resume xorg.conf is the default one, but with Option AccelMethod UXA. Thanks for the dmesg info. That bug is fixed in the kernel patch series I should be pushing out today. here are the last kernel messages after vt switching [drm] Initialized i915 1.6.0 20080730 on minor 0 [ cut here ] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:2714! invalid opcode: [#1] PREEMPT last sysfs file: /sys/class/power_supply/BAT0/energy_full Modules linked in: i915 drm ieee80211_crypt_ccmp snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device hdaps input_polldev snd_intel8x0 pcmcia snd_ac97_codec ac97_bus snd_pcm ipw2200 8250_pci yenta_socket ehci_hcd tg3 snd_timer uhci_hcd 8250_pnp rsrc_nonstatic snd ieee80211 8250 pcmcia_core usbcore ieee80211_crypt serial_core libphy snd_page_alloc intel_agp agpgart thinkpad_acpi rfkill backlight led_class Pid: 6477, comm: X Not tainted (2.6.28-nibbler #1) 1867W6T EIP: 0060:[f833d252] EFLAGS: 00013297 CPU: 0 EIP is at i915_gem_entervt_ioctl+0x4b2/0x4d0 [i915] EAX: f65ace24 EBX: f6a91c14 ECX: f65ac000 EDX: f65ac000 ESI: f66494c0 EDI: f6521de0 EBP: f65ac000 ESP: f65bbea4 DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Process X (pid: 6477, ti=f65ba000 task=f70711c0 task.ti=f65ba000) Stack: 0059 6459 f83441a0 f6a91c00 f6521de0 6459 f6a91c00 f65ac000 f833cda0 f6a91c00 f6521de0 0001 f83126fa 0002 762f0001 0001 f65bc200 6459 f6a91c24 Call Trace: [f833cda0] i915_gem_entervt_ioctl+0x0/0x4d0 [i915] [f83126fa] drm_ioctl+0x1ba/0x2f0 [drm] [c01a0ac8] vfs_ioctl+0x78/0x90 [c01a0c5c] do_vfs_ioctl+0x5c/0x4a0 [c0194bd6] vfs_write+0x106/0x140 [c01e6100] reiserfs_file_write+0x0/0xc0 [c01a10dd] sys_ioctl+0x3d/0x70 [c010324d] sysenter_do_call+0x12/0x21 Code: 44 24 20 e9 c2 fd ff ff b8 3a 00 34 f8 89 44 24 04 8d 7d 14 c7 04 24 38 10 34 f8 e8 29 77 de c7 b9 0d 00 00 00 eb c1 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 0f 0b eb fe 8d b6 00 EIP: [f833d252] i915_gem_entervt_ioctl+0x4b2/0x4d0 [i915] SS:ESP 0068:f65bbea4 ---[ end trace 89afc48929c53d42 ]--- Intel ICH :00:1e.2: PCI INT A disabled I've attached lspci -vv output, stdout/stderr, xorg.0.log and full dmesg output. thanks, Adam On Mon, Jan 5, 2009 at 2:22 PM, Adam Lantos h...@playma.org wrote: I have the same resume problem with UXA (GM915), GEM + Tuxonice. Mesa, xorg-server and xf86-video-intel from git master. EXA resumes correctly. cheers, adam On Mon, Jan 5, 2009 at 2:15 PM, Thomas Ilnseher il...@gmx.de wrote: -- Forwarded message -- From: Thomas Ilnseher ilnse...@eit.uni-kl.de To: Xorg xorg@lists.freedesktop.org Date: Mon, 05 Jan 2009 14:03:11 +0100 Subject: Re: Intel + GEM + suspend - fail Am Freitag, den 26.12.2008, 15:42 +0200 schrieb Vasily Khoruzhick: I have the same issue. Vanilla 2.6.28 kernel, Xorg stack from gentoo x11 overlay, gma950. Same here, GEM + GL960 (= GM965) + TuxOnIce. Note suspend/resume DOES work when I use metacity, but does not when Compiz is enabled. I also got a Problem when the Screensaver enters some low power mode (ie. screen off), then I can do a hard reset of the box. mesa is from Git (from the Gentoo overlay), the rest is stock Gentoo unstable. Sometimes it occurs even without suspend - few switches X-console-X are enought. Regards Vasily -- Thomas Ilnseher ilnse...@eit.uni-kl.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel 945 backtrace
On Wed, 2008-12-31 at 18:40 +, Peter Clifton wrote: Hi guys, I've been testing the beta release of the 2.6 series Intel driver against a 2.6.28 kernel, with UXA and DRI2 enabled. (I had 'Option DRI2 off' in the Xorg.conf, but apparently that was ignored - perhaps I put it in the wrong place, or this is not the right option to control DRI2). I've been noticing really poor performance whilst rendering lots of small lines, something which x11perf -line10 seems to bear out: x11perf - X11 performance program, version 1.2 The X.Org Foundation server version 10599003 on :0.0 from pcjc2lap Wed Dec 31 18:36:35 2008 Sync time adjustment is 0.0708 msecs. 60 reps @ 0.0100 msec (10.0/sec): 10-pixel line 60 reps @ 0.0100 msec (10.0/sec): 10-pixel line 60 reps @ 0.0100 msec (10.0/sec): 10-pixel line 60 reps @ 0.0100 msec (10.0/sec): 10-pixel line 60 reps @ 0.0100 msec ( 99900.0/sec): 10-pixel line 300 trep @ 0.0100 msec (10.0/sec): 10-pixel line When profiling, it appears the hot-spot is in the kernel, with ~90% of total system time spent waiting in there. I upgraded to a git version of sysprof today, and this is able to trace further inside the kernel. Hopefully this debugging information will be of use (I can send the whole capture file to anyone who wants it). This was traced whilst running x11perf -line10. The timings above were recorded without sysprof tracing, in case the sysprof overhead skewed the timings. Thanks for the sysprof data. The fix for software fallback performance just got merged to the stable branch, so that should fix this problem in the next rc. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Fix sis driver to compile with -Werror=format-security
On Tue, 2008-12-23 at 13:25 -0200, Ander Conselvan de Oliveira wrote: The attached patch fix the sis driver to compile with -Werror=format-security. Some of those strings are predefined and visible in the patch you posted (not a security issue). I certainly wouldn't apply this patch. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libdrm-2.4.3
On Tue, 2008-12-23 at 12:28 +, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 23/12/08 10:36 did gyre and gimble: 'Twas brillig, and Eric Anholt at 23/12/08 00:25 did gyre and gimble: I've tagged it and uploaded it. The big update this release is the modesetting userland support. I'm skipping the shortlog as it's noisy with the modesetting kernel changes that were merged and then reverted. I'll also push the release script updates to modular that I (almost) used to generate this. What happened to 2.4.2? Or is it just that 4.2 is *not* the answer afterall? :p I just tried out libdrm 2.4.3 + intel 2.5.99.1 on xserver 1.5.3 and mesa 7.2+ snapshot (similar one date to the redhat package). It didn't go too well! I got this in my xorg.log... Please let me know how I can debug further or if I need a newer Mesa etc. I'm also guessing this isn't the most useful of backtraces :s Yeah, you need gdb output for the backtrace to be really useful. There have been a couple of crashes reported with TexImage recently, but I guess the could be related to the fix that idr did since you're not running current server code. (II) XINPUT: Adding extended input device Macintosh mouse button emulation (type: MOUSE) (II) intel(0): EDID vendor LPL, prod id 0 (II) intel(0): EDID quirk: Detailed timings give sizes in cm. (II) intel(0): DDCModeFromDetailedTiming: 1680x1050 Warning: We only handle seperate sync. (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline 1680x1050x0.0 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync (64.1 kHz) (II) intel(0): Modeline 1680x1050x0.0 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync (64.1 kHz) (II) intel(0): EDID vendor LPL, prod id 0 (II) intel(0): EDID quirk: Detailed timings give sizes in cm. (II) intel(0): DDCModeFromDetailedTiming: 1680x1050 Warning: We only handle seperate sync. Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e9ed6] 1: /etc/X11/X(xf86SigHandler+0x3e) [0x47d14e] 2: /lib64/libc.so.6 [0x7f2487228a10] 3: /lib64/libc.so.6(memcpy+0xa3) [0x7f2487276463] 4: /usr/lib64/dri/i915_dri.so [0x7f2474b5fba3] 5: /usr/lib64/libdricore.so [0x7f24747f75c2] 6: /usr/lib64/libdricore.so(_mesa_texstore_argb+0x18d) [0x7f24747fb3fc] 7: /usr/lib64/dri/i915_dri.so [0x7f2474b5e060] 8: /usr/lib64/dri/i915_dri.so(intelTexImage2D+0x7d) [0x7f2474b5e273] 9: /usr/lib64/libdricore.so(_mesa_TexImage2D+0x26d) [0x7f24747eeb15] 10: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f24862d611a] 11: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f24862f906d] 12: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f24862fce72] 13: /etc/X11/X(Dispatch+0x364) [0x448954] 14: /etc/X11/X(main+0x45d) [0x42eb0d] 15: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f2487215316] 16: /etc/X11/X(FontFileCompleteXLFD+0x289) [0x42dee9] -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: intel without connected monitor
On Tue, 2008-12-16 at 12:07 +0100, strawks wrote: Hi all, I have a motherboard with an intel G45 chipset. When I try to launch an X server with no connected monitor it fails with (other outputs are ignored according to my xorg.conf) : (II) intel(0): Output HDMI-2 using monitor section Sharp Aquos (**) intel(0): Option PreferredMode 1080p (**) intel(0): Option Enable true (II) intel(0): I2C bus HDMIDDC_C initialized. (II) intel(0): HDMI output 2 detected (II) intel(0): EDID for output HDMI-2 (II) intel(0): Output HDMI-2 enabled by config file (WW) intel(0): Unable to find initial modes (EE) intel(0): Output HDMI-2 enabled but has no modes (EE) intel(0): No valid modes. I have read how to setup dual head at http://intellinuxgraphics.org/dualhead.html and my xorg.conf relevant sections look like this : Section Device Identifier Intel GMA X4500HD Driver intel BusID PCI:0:2:0 VendorName Intel BoardName G45 [Intel GMA X4500HD] Option AccelMethod EXA Option ModeDebug true Option monitor-VGA ignore Option monitor-HDMI-1ignore Option monitor-HDMI-2Sharp Aquos EndSection Section Monitor Identifier ignore Option ignoretrue EndSection Section Monitor Identifier Sharp Aquos ModeLine1080p 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync VertRefresh 23-61 HorizSync 15-68 Option PreferredMode 1080p Option enabletrue EndSection Is there a way to force the driver to use the 1080p mode even when no monitor are connected? thanks in advance. If you've ever successfully connected a monitor to your system and had X come up, please ignore the messages about SDVO. You almost surely have HDMI outputs, not SDVO. We'd need to see /var/log/Xorg.0.log with Option ModeDebug TRUE to figure out what was going wrong with your Option enable true. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: git problems with kernel drm repository
On Sun, 2008-12-14 at 10:36 +1100, garrone wrote: Hi. I am attempting to track the kernel drm driver git repository, branch drm-intel-next. To update, I change to the directory, ensure that the branch is set and the repository is clean, then pull from the remote repository. e.g. $ git reset --hard HEAD HEAD is now at 8a04a92 drm/i915: Disable the GM965 MSI errata workaround. $ git status # On branch drm-intel-next nothing to commit (working directory clean) $ git pull This gives conflict messages. Standard output is: You don't do git pull on kernel repositories other than linus, because we all have to rebase onto linus. git fetch, then if you have nothing of value in your branch, then git-reset --hard anholt/drm-intel-next. Otherwise, git-rebase anholt/drm-intel-next and lots of git-rebase --skip. Removed arch/mips/mti-malta/malta-mtd.c Auto-merged drivers/gpu/drm/drm_crtc_helper.c CONFLICT (add/add): Merge conflict in drivers/gpu/drm/drm_crtc_helper.c Auto-merged drivers/gpu/drm/drm_gem.c CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_gem.c Auto-merged drivers/gpu/drm/drm_stub.c CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_stub.c Auto-merged drivers/gpu/drm/i915/i915_gem.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem.c Auto-merged drivers/gpu/drm/i915/intel_fb.c CONFLICT (add/add): Merge conflict in drivers/gpu/drm/i915/intel_fb.c Auto-merged drivers/gpu/drm/radeon/radeon_drv.h And error output is: From git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel + fe9ab8f...04a17f6 drm-intel-next - origin/drm-intel-next (forced update) * [new branch] error-recovery - origin/error-recovery Automatic merge failed; fix conflicts and then commit the result. If I do a git-diff, I get conflicts on the following drm files: drivers/gpu/drm/drm_crtc_helper.c drivers/gpu/drm/drm_gem.c drivers/gpu/drm/drm_stub.c drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_fb.c I have attached the diff output. I know nothing about these modifications. If anyone could tell me a sequence of commands to repair my copy, and how to track future updates without these problems, would be grateful. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel driver accesses reserved register bit SDVOC/SDVO_DETECTED
On Tue, 2008-11-18 at 09:43 +1100, garrone wrote: Using the intel driver on a GM45 device, with monitors connected to the TMDS1/2 outputs, it was found that the xserver was refusing to accept the option option Monitor-TMDS-2 monitor-id and also leaving the second screen rather blank. Eventually, it was found that at xf86-video-intel::src/i830_driver.c, function I830SetupOutputs, line 922, the register SDVOC is anded with the SDVO_DETECTED mask in order to detect if a monitor was connected at startup. This register bit was clear, causing the screen to be missed. A careful reading of the intel documentation shows that while this bit indicates an initially detected connected monitor for SDVOB, in fact it is reserved in the SDVOC register, and should therefore be ignored. So to cause the second monitor to be enabled, the option ForceSDVODetect, false by default, should be set to true. Perhaps consideration could be given to defaulting this option to true, or even ignoring such initialization bits as SDVO_DETECTED altogether. It's true that the bit is reserved for G/GM965, but not for G/GM45. Also, (still) by my reading, it's not about a monitor being connected at startup, but the SDVO chip being present. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow exaOffscreenAlloc ?
On Wed, 2008-12-10 at 11:52 +0100, Michel Dänzer wrote: On Mon, 2008-12-08 at 15:23 -0800, Eric Anholt wrote: We've got a few ideas to improve things for UXA performance still, so it may get better. It's already a win over EXA, since EXA's stuck with only 50MB of aperture space. [...] UXA makes the pixmap offscreen space be unified with 3D and every other GPU activity. You know full well that the driver could do the same thing with EXA. It would be nice to fix the (rather academic) problems with the related EXA driver hook interfaces rather than wasting effort on yet another acceleration architecture. Yes, I do know. But that doesn't change what the driver options to today, because of the EXA driver hook interfaces. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/2] xf86-video-intel: i830_driver: drop I830GetRec
On Wed, 2008-11-26 at 01:39 -0500, Andres Salomon wrote:
There are a number of minor issues w/ I830GetRec:
- pI830 is local, and therefore never gets used
- it only ever returns TRUE (no need to check the result)
- it's only ever called once, so there's not much point in protecting
against multple calls
So, this drops I830GetRec and instead just calls xnfcalloc directly. Since
xnfcalloc will never fail, there's no point in checking the result.
Does this result in a leak for server regen?
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
---
src/i830_driver.c | 16 +---
1 files changed, 1 insertions(+), 15 deletions(-)
diff --git a/src/i830_driver.c b/src/i830_driver.c
index 1407a22..a24c8da 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -402,17 +402,6 @@ I830AvailableOptions(int chipid, int busid)
return NULL;
}
-static Bool
-I830GetRec(ScrnInfoPtr pScrn)
-{
- I830Ptr pI830;
-
- if (pScrn-driverPrivate)
- return TRUE;
- pI830 = pScrn-driverPrivate = xnfcalloc(sizeof(I830Rec), 1);
- return TRUE;
-}
-
static void
I830FreeRec(ScrnInfoPtr pScrn)
{
@@ -1755,11 +1744,8 @@ I830PreInit(ScrnInfoPtr pScrn, int flags)
if (flags PROBE_DETECT)
return TRUE;
- /* Allocate driverPrivate */
- if (!I830GetRec(pScrn))
- return FALSE;
+ pI830 = pScrn-driverPrivate = xnfcalloc(sizeof(I830Rec), 1);
- pI830 = I830PTR(pScrn);
pI830-SaveGeneration = -1;
pI830-pEnt = pEnt;
pI830-use_drm_mode = drm_mode_setting;
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel xf86-intel-video with G45: glxgears synchonised to VSYNC
On Mon, 2008-12-08 at 07:31 +, Terry Barnaby wrote: Hi, I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung HDTV. I am using Fedora 10 as the base with the latest DRM/X11/mesa xf86-intel-video drivers from the Xorg GIT repository. In general this appears to be working. One thing I note however, is that when I run glxgears the 3D drawing frame rate, reported by glxgears, is exactly the VSYNC rate. The CPU usage is well down and is definitely using DRI. When using the stock xf86-intel-video driver that came with Fedora 10, glxgears was reported around 1500. Is this correct behavior, I thought that glxgears simply drew as fast as possible and was not synchronised to the VSYNC frame rate ? No, this is correct behavior. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel G45 ModeLines
On Sun, 2008-12-07 at 06:48 +, Terry Barnaby wrote: Hi, I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung HDTV. I am using Fedora 10 as the base with the latest DRM/X11 driver from the Xorg GIT repository. In general this appears to be working. However, the TV's EDID is not correct in some details and so I wish to override some things in the Monitor section of the xorg.conf file. However they do not seem to work. If I add: DisplaySize890 500 this is ignored. If I add: ModeLine 1920x1080_50 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +HSync +VSync with a Modes 1920x1080_50 line in the Screen section this seems to be ignored. Is there any way to get the Intel driver to use a user provided ModeLine ? xorg.conf(5): Option PreferredMode string This optional entry specifies a mode to be marked as the preferred ini‐ tial mode of the monitor. (RandR 1.2-supporting drivers only) However the real preferred thing to do is write up a quirk for the server to fix your EDID so that other people get the benefit of your bugfixes. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is intel/SVDO supported
On Wed, 2008-12-03 at 10:49 -0500, Adam Jackson wrote: On Wed, 2008-12-03 at 19:45 +1100, garrone wrote: On Tue, Dec 02, 2008 at 02:23:32PM -0500, Adam Jackson wrote: On Tue, 2008-12-02 at 19:37 +1100, garrone wrote: The intel man page (in xf86-video-intel) says: SDVO and DVO TV outputs are not supported by the driver at this time. I'm curious as to why this is the situation with SDVO? Because no one both: has SDVO TV out hardware, and is capable of making it work. Thanks. I interpreted that as meaning Neither SDVO nor DVO TV outputs are supported... rather than the combination. Right. Many SDVO output types are supported, but SDVO TV isn't. Some people have built working TV support using the code in our git tree. I've even included their code with some modifications. So the difference from here to working SDVO TV support should be minor. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Warning fix for the definer and conumer of CopyGetMasterEvent.
--- mi/mi.h |3 +++ xkb/ddxDevBtn.c |3 ++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/mi/mi.h b/mi/mi.h index 444d3ad..1dc4780 100644 --- a/mi/mi.h +++ b/mi/mi.h @@ -222,6 +222,9 @@ extern void miClearDrawable( GCPtr /*pGC*/ ); +void CopyGetMasterEvent(DeviceIntPtr mdev, xEvent* original, + xEvent** master, int count); + /* mifillrct.c */ extern void miPolyFillRect( diff --git a/xkb/ddxDevBtn.c b/xkb/ddxDevBtn.c index 66a4cc4..d5465f6 100644 --- a/xkb/ddxDevBtn.c +++ b/xkb/ddxDevBtn.c @@ -36,6 +36,7 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE. #include inputstr.h #include scrnintstr.h #include windowstr.h +#include mi.h #include xkbsrv.h #include X11/extensions/XI.h #include X11/extensions/XIproto.h @@ -111,7 +112,7 @@ DeviceIntPtrmaster = NULL; if (!IsPointerDevice(master)) master = GetPairedDevice(dev-u.master); -CopyGetMasterEvent(master, events, m_events, count); +CopyGetMasterEvent(master, events, m_events, count); } (*dev-public.processInputProc)((xEventPtr)btn, dev, count); -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Warning fix (GL likes to call strings GLubyte * instead of char *).
---
glx/indirect_program.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/glx/indirect_program.c b/glx/indirect_program.c
index d23a0a9..cbea40e 100644
--- a/glx/indirect_program.c
+++ b/glx/indirect_program.c
@@ -103,7 +103,7 @@ int DoGetProgramString(struct __GLXclientStateRec *cl,
GLbyte *pc,
CALL_by_offset(GET_DISPATCH(),
(void (GLAPIENTRYP)(GLuint, GLenum, GLubyte *)),
get_program_string_offset,
- (target, pname, answer));
+ (target, pname, (GLubyte *)answer));
}
if (__glXErrorOccured()) {
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Warning fix: Remove dead glXDisp{, Swap}_DrawArraysEXT definitions.
---
glx/render2.c |5 -
glx/render2swap.c |5 -
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/glx/render2.c b/glx/render2.c
index a86a22a..b958d90 100644
--- a/glx/render2.c
+++ b/glx/render2.c
@@ -252,8 +252,3 @@ void __glXDisp_DrawArrays(GLbyte *pc)
CALL_DisableClientState( GET_DISPATCH(), (GL_SECONDARY_COLOR_ARRAY) );
CALL_DisableClientState( GET_DISPATCH(), (GL_FOG_COORD_ARRAY) );
}
-
-void __glXDisp_DrawArraysEXT(GLbyte *pc)
-{
- __glXDisp_DrawArrays(pc);
-}
diff --git a/glx/render2swap.c b/glx/render2swap.c
index 49449ff..3dfa61b 100644
--- a/glx/render2swap.c
+++ b/glx/render2swap.c
@@ -363,8 +363,3 @@ void __glXDispSwap_DrawArrays(GLbyte *pc)
CALL_DisableClientState( GET_DISPATCH(), (GL_SECONDARY_COLOR_ARRAY) );
CALL_DisableClientState( GET_DISPATCH(), (GL_FOG_COORD_ARRAY) );
}
-
-void __glXDispSwap_DrawArraysEXT(GLbyte *pc)
-{
- __glXDispSwap_DrawArrays(pc);
-}
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xserver master warning fixes
Here's a series of compile warning fixes I came up with while looking at them trying to figure out if anything was wrong that broke GLX (fix for that is already pushed). The ddxDevBtn.c one looks like a real bugfix. There are a few more that look important xf86Xinput.c:654: warning: ‘idev’ may be used uninitialized in this function xf86Xinput.c:653: warning: ‘drv’ may be used uninitialized in this function I couldn't convince myself that this was just the compiler getting it wrong. xf86Helper.c:2727: warning: passing argument 2 of ‘GetMotionHistory’ from incompatible pointer type This function looks completely broken now -- consumers of this API used to pass in storage, but now the function wants to do it itself, and this helper func doesn't get it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Warning fix in xf86Bus.c: too many brackets in initializer.
---
hw/xfree86/common/xf86Bus.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86Bus.c b/hw/xfree86/common/xf86Bus.c
index c825d23..eaa0618 100644
--- a/hw/xfree86/common/xf86Bus.c
+++ b/hw/xfree86/common/xf86Bus.c
@@ -66,7 +66,7 @@ xf86AccessRec AccessNULL = { noopEnableDisable,
noopEnableDisable, NULL };
_X_EXPORT xf86CurrentAccessRec xf86CurrentAccess = {NULL,NULL};
-BusRec primaryBus = { BUS_NONE, {{0}}};
+BusRec primaryBus = { BUS_NONE, {0}};
static Bool xf86ResAccessEnter = FALSE;
--
1.5.6.5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 3 commits
On Wed, 2008-12-03 at 20:52 -0800, Paulo Cesar Pereira de Andrade wrote:
.gitignore | 92 ++-
Makefile.am|2
configure.ac |1
hw/xfree86/Makefile.am |4 -
hw/xfree86/dummylib/Makefile.am| 38 ---
hw/xfree86/dummylib/README |7 --
hw/xfree86/dummylib/dixprivates.c | 19 -
hw/xfree86/dummylib/dummylib.h |9 --
hw/xfree86/dummylib/fatalerror.c | 25 ---
hw/xfree86/dummylib/getemptypci.c | 19 -
hw/xfree86/dummylib/getvalidbios.c | 19 -
hw/xfree86/dummylib/logvwrite.c| 21 --
hw/xfree86/dummylib/pcitestmulti.c | 19 -
hw/xfree86/dummylib/verrorf.c | 19 -
hw/xfree86/dummylib/xalloc.c | 111
-
hw/xfree86/dummylib/xf86addrestolist.c | 24 ---
hw/xfree86/dummylib/xf86allocscripi.c | 19 -
hw/xfree86/dummylib/xf86drvmsg.c | 24 ---
hw/xfree86/dummylib/xf86drvmsgverb.c | 24 ---
hw/xfree86/dummylib/xf86errorf.c | 33 -
hw/xfree86/dummylib/xf86errorfverb.c | 24 ---
hw/xfree86/dummylib/xf86getverb.c | 19 -
hw/xfree86/dummylib/xf86info.c | 12 ---
hw/xfree86/dummylib/xf86msg.c | 24 ---
hw/xfree86/dummylib/xf86msgverb.c | 24 ---
hw/xfree86/dummylib/xf86opt.c | 25 ---
hw/xfree86/dummylib/xf86screens.c | 12 ---
hw/xfree86/dummylib/xf86servisinit.c | 19 -
hw/xfree86/dummylib/xf86verbose.c | 12 ---
hw/xfree86/utils/cvt/Makefile.am |2
hw/xfree86/utils/cvt/cvt.c | 28
31 files changed, 40 insertions(+), 690 deletions(-)
.PHONY: ChangeLog
commit 5dbe70dd52fd8daf8d0797951cc5a758d2c3b44c
Author: Paulo Cesar Pereira de Andrade [EMAIL PROTECTED]
Date: Thu Dec 4 01:57:46 2008 -0200
Remove dummylib.
Only cvt required it, and only used XNF{,c}alloc
via xnf{,c}alloc macros.
Based on patch by Eric Anholt.
You appear to have taken my patch and s/fprintf(stderr, /perror(/.
Generally in a situation like this one would leave original authorship
intact (even my comments were preserved!).
diff --git a/configure.ac b/configure.ac
index 34b06f4..5649fe5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1896,7 +1896,6 @@ hw/xfree86/doc/man/Makefile
hw/xfree86/doc/sgml/Makefile
hw/xfree86/dri/Makefile
hw/xfree86/dri2/Makefile
-hw/xfree86/dummylib/Makefile
hw/xfree86/exa/Makefile
hw/xfree86/fbdevhw/Makefile
hw/xfree86/i2c/Makefile
diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
index 09ee350..115d829 100644
--- a/hw/xfree86/Makefile.am
+++ b/hw/xfree86/Makefile.am
@@ -14,12 +14,12 @@ endif
DOC_SUBDIR = doc
-SUBDIRS = common ddc dummylib i2c x86emu int10 fbdevhw os-support parser \
+SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support parser \
ramdac shadowfb vbe vgahw xaa \
xf8_16bpp loader dixmods exa modes \
$(DRI_SUBDIR) $(DRI2_SUBDIR) $(XF86UTILS_SUBDIR) $(DOC_SUBDIR)
-DIST_SUBDIRS = common ddc dummylib i2c x86emu int10 fbdevhw os-support \
+DIST_SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support \
parser ramdac shadowfb vbe vgahw xaa \
xf8_16bpp loader dixmods dri dri2 exa modes \
utils doc
diff --git a/hw/xfree86/dummylib/Makefile.am b/hw/xfree86/dummylib/Makefile.am
deleted file mode 100644
index 85a1d03..000
--- a/hw/xfree86/dummylib/Makefile.am
+++ /dev/null
@@ -1,38 +0,0 @@
-# libdummy.a contains just those bits used in the server itself
-# libdummy-nonserver.a contains additional routines normally found in the
-# server for use in building the utilities like config tools
-
-noinst_LIBRARIES = libdummy-nonserver.a
-
-INCLUDES = $(XORG_INCS)
-
-AM_CFLAGS = $(DIX_CFLAGS) $(XORG_CFLAGS)
-
-if NEED_STRLCAT
-STRL_SRCS = $(top_srcdir)/os/strlcat.c $(top_srcdir)/os/strlcpy.c
-endif
-
-libdummy_nonserver_a_SOURCES = \
- dixprivates.c \
- fatalerror.c \
- logvwrite.c \
- $(STRL_SRCS) \
- verrorf.c \
- xalloc.c \
- xf86allocscripi.c \
- xf86addrestolist.c \
- xf86drvmsg.c \
- xf86drvmsgverb.c \
- xf86errorf.c \
- xf86errorfverb.c \
- xf86getverb.c \
- xf86info.c \
- xf86msg.c \
- xf86msgverb.c \
- xf86opt.c \
- xf86screens.c \
- xf86servisinit.c \
- xf86verbose.c \
- $(srcdir)/../os-support/shared/sigiostubs.c
-
-EXTRA_DIST = README dummylib.h
diff --git a/hw/xfree86/dummylib/README b/hw/xfree86/dummylib/README
deleted file mode 100644
index 4e27030..000
--- a/hw/xfree86/dummylib/README
+++ /dev/null
@@ -1,7 +0,0 @@
-
-libdummy (dummylib) contains basic utility functions required by
libxf86_os.a
Re: Better gradient handling (migration/fallbacks)
On Thu, 2008-11-13 at 14:30 +0100, Clemens Eisserer wrote: Hi, I've experienced some performance problems with gradients when working on the xrender/java2d backend. A typical problematic case is when mask and desitation picture were in VRAM, and a gradient is used as source. As far as I understand this causes mask and dst to be moved out into sysmem, the composition is done by pixman and at the next accalerated operation the whole thing is moved back. In profiles I saw that about 35% of total cycles where spent in moveIn/moveOut and 5% in gradient generation itself, for a rather boring UI like the following: http://picasaweb.google.com/linuxhippy/LinuxhippySBlog?authkey=tXfo8RSnq4s#5224085419010972994 What I did to work arround the problem was to use a temporary pixmap, copy the gradient to the pixmap and use that pixpap later for composition. This means only moveIn's and enhanced performance a lot, about 3-4x for the UI workload mentioned above. This seems to be an acceptable workarround but causes an unnescessary burden for UMA architectures like Intel+GEM, so doing this be default should be up to the driver. Would it be possible to pass gradients down to the driver, to allow the driver to decide what to do with the gradient, or even provide accaleration for it. How complex would it be to provide the nescessary hooks? As far as I know two-stop gradients often can be accalerated with some texture-mapping tricks, and everything more complex still could be done with shaders. I am no xorg/exa expert, so maybe I just do not understand things and draw wrong conclusions. We just need to accelerate gradients, and is where any effort in software should occur. It's on our schedule, but not for quite a while. Setting up the X Server to allow drivers to request gradients was easy last time I did it, though I've misplaced the branch it looks like. Then someone would just have to write the shader for it, and for 915-class hardware that shouldn't be hard. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compile xorg from git, i915.ko missing
On Fri, 2008-11-07 at 16:40 +, Sergio Monteiro Basto wrote: export OS_HAS_GEM=1 Under no circumstances do this. That code is dead, and intel kernel modules come from the kernel now. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compile xorg from git, i915.ko missing
On Fri, 2008-11-07 at 13:36 -0600, Chris Pemberton wrote: Eric Anholt wrote: On Fri, 2008-11-07 at 16:40 +, Sergio Monteiro Basto wrote: export OS_HAS_GEM=1 Under no circumstances do this. That code is dead, and intel kernel modules come from the kernel now. So, i915.ko is from the latest 2.6.28+ git kernel. Understood. And I don't set OS_HAS_GEM=1. Understood. So, where should drm.ko come from: 1. the kernel or 2. git://git.freedesktop.org/git/mesa/drm? If drm.ko is from the kernel, do I need to do anything within the drm git directory? It comes from the kernel. All you need from drm.git is libdrm. But the released versions of that should serve. Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: observations with git X server intel/MTRR/performance
On Thu, 2008-11-06 at 14:03 +0100, Tobias Hain wrote: Hello, Problem 2: MTRR not being set on intel == My stock 8.10 system adds reg03 to the MTRR regions when launching x-server with stock intel 2.4.2 drivers: reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x07f80 ( 2040MB), size=8MB, count=1: uncachable reg02: base=0x07f70 ( 2039MB), size=1MB, count=1: uncachable reg03: base=0x0e000 ( 3584MB), size= 256MB, count=1: write-combining However if I launch the self build git x server stack reg03 is missing and only reg00-reg02 being set. Instead I get so error messages in dmesg such as: [ 209.308956] mtrr: base(0xe000) is not aligned on a size(0x77) boundary [ 211.173759] mtrr: no MTRR for e000,77 found And on every exit of the x session: waiting for X server to shut down error setting MTRR (base = 0xe000, size = 0x1000, type = 1) Invalid argument (22) and dmesg gets mtrr: no MTRR for e000,1000 found The intel driver tries to delete the MTRR, but for some reason it failed to set it up when launching the X driver. Xorg.0.log doesn't reveal anything suspicious. It does that behaviour with a PAT kernel as well as the old fashioned MTRR kernel. Again: I can fix that manually by writing the appropriate data to /proc/mtrr. But how to properly fix that? Who exactly is supposed to set up the MTRR registers? libdrm_intel.so? intel_drv.so? Can't be a privilege problem sind Xorg is owned by root and +s bit set (see above). Which interface does the intel component use to set the mtrr? A kernel API or /proc/mtrr? Getting working MTRRs has been getting harder and harder over time. So we're trying to make things work without them. Things that use libpciaccess (the X Server) should be getting correct wc mappings thanks to using the resource_wc sysfs file. If you update your kernel, the kernel also gets wc mappings using the new io_map_atomic interfaces. So at that point, the MTRR shouldn't be necessary. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to tell if GEM is enabled.
On Thu, 2008-11-06 at 19:47 +0200, Protas Oleksiy wrote: Hi, thanks for fast responce. Well GEM's not in mesa-7.2, so then neither GEM nor TTM is enabled in it? What accellertation Intel users are supposed to benefit from on this version then? classic mode As to upgrate, do I upgrade just to master git version? And what am I to recompile after I upgrade mesa? Thank you. git master, or we put out a release of mesa with gem. http://www.intellinuxgraphics.org/ -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel-2.5.0 is slow
On Tue, 2008-11-04 at 12:54 +0200, Vasily Khoruzhick wrote: On Tuesday 04 November 2008 11:52:15 you wrote: Mesa 7.2 is not enough for GEM to work. You need latest git. Grab dri2proto, drm(for libdrm only, not linux-core), mesa, and xf86-video-intel for GEM enabled kernel. Also make sure You have xserver-xorg-core 1.5.x (with EXA method as UXA is still a bit buggy and needs dri2) Do this if You dont plan to use blender, there are still some bugs, only compiz and desktop acceleration works well. 2008/11/4 Vasily Khoruzhick [EMAIL PROTECTED] Btw, are you sure that 3D should work OK on gem-enabled kernel with non-gem mesa? Because with non-gem kernel I have no problems with 3D So, you mean that I can't get 3D with gem-enabled kernel and non-gem mesa? I don't want any fancy dri2-things, just old mature dri :) The thing is that in 2.6.27 irda subsystem is broken, and sane patches to fix it exists only for 2.6.28... So I tried to use 2.6.28 RCs... So, ok, I'll rollback to 2.6.26 kernel :) pre-GEM Mesa is supposed to work fine with a GEM kernel. It pretty much did last we tested it. However, as it's compatibility code we're not putting testing or development time on it now. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel-2.5.0 is slow
On Tue, 2008-11-04 at 09:17 +0200, Vasily Khoruzhick wrote: On 4 November 2008 06:58:51 Eric Anholt wrote: It's not a single patch. It's in linus's master now. (drm-intel-next is updated for our current work against it) This fix changed nothing for me (now using kernel 2.6.28-rc3-git), GL-apps are still too slow Can you get some profiling on the problem? More details? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (libxcb)
On Wed, 2008-11-05 at 00:29 -0500, Chris Ball wrote: Thanks, added the make check test. I don't know if you plan to have the test suite launch X clients in the future, but I added it to the set of tests that is run against the newly-built libraries/server/drivers at the end of every tinderbox build, so launching clients will work if you want to. Here's the current set of tests used after every build run: xcb x11perf rendercheck cairotest cairoperf Here are the latest test results for the construct tinderbox machine: http://tinderbox.x.org/builds/2008-11-05-0005/ (Hm, it says 0 tests passed for libxcb; any idea what's up with that?) Running the X Test Suite would be awesome too. I'll take a look at the X Test Suite -- I haven't used it before. If there are any other suggestions for test programs to run against new builds of servers/drivers, I'd be happy to hear those too. Running piglit against software GLX would probably be a way of catching nasty issues in paths that most of us aren't testing on the desktop. http://people.freedesktop.org/~nh/piglit/ Easy to build, will require some parsing of results. Also, I notice that the cairo tests are coming out green despite failures. Expected so far? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel-2.5.0 is slow
On Mon, 2008-11-03 at 18:07 +0100, Hanno Böck wrote: Am Montag 03 November 2008 schrieb Eric Anholt: We've got a fix for a major slowdown on x86_64 in the for-review branch of my kernel repository, but the x86 maintainers are dragging their feet on integrating it. Is there a single patch one could apply? (git url) It's not a single patch. It's in linus's master now. (drm-intel-next is updated for our current work against it) -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libdrm 2.4.1
On Sat, 2008-11-01 at 14:46 +, Colin Guthrie wrote: Eric Anholt wrote: New libdrm release to fix the symbol name collision between Mesa 7.2 and libdrm_intel. Also includes a fix for deadlock in non-GEM 2D, and support for aperture size checking in GEM. Eric Anholt (3): intel: Rename dri_ and intel_ symbols to drm_intel_. Eric, the above commit broke things quite badly here. Running this on xserver 1.4.2 and intel 2.5.0. Not able to get some proper debug (it just crashes X) and I'm not really in a position to do so right now. I'm guessing some of the compatibility defines are not working. or does this compatibility layer require a recompile of something else? Reverting this commit works fine. Did you rebuild your 2D driver and Mesa after updating past that commit? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libdrm 2.4.1
On Sun, 2008-11-02 at 20:06 +0100, Arkadiusz Miskiewicz wrote: On Thursday 30 of October 2008, Eric Anholt wrote: New libdrm release to fix the symbol name collision between Mesa 7.2 and libdrm_intel. soname version should be changed when doing such incompatible change :-/ Assuming that distros were integrating things in order, they would have tried to update the following versions mesa 7.0.3 - mesa 7.2 libdrm 2.3 - libdrm 2.4.0 intel-2.4.2 - intel-2.5.0 And they would have found that libdrm 2.4.0 broke things and not integrated it. So our answer is we don't care about people who integrated 2.4.0, as it was broken. Thanks to Dave Airlie for tracking it down quickly and making me fix it. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel driver for graphics on dg45fc mainboard, getting it to work
On Fri, 2008-10-31 at 20:51 +0100, Dimitri Michaux wrote: Hi, The specs from the intel website say this card has a Intel Graphics Media Accelerator X4500HD which is not in the list of supported cards for the intel linux driver. I've tried compiling my own driver from the stable driver and from git, but none of them work, they all fail with the same error: (EE) intel(0): No valid modes. (EE) Screen(s) found, but none have a usable configuration. I think it is a problem with my xorg.conf file, but I can't get it to work. I'm now using the vesa driver, which works, but doesn't give me my widescreen resolution. I've attached my xorg.conf and the log from /var/log/Xorg.0.log. I would really like to see this card working because I like the mainboard and can't wait to use it with some decent linux drivers. My DG45FC's working great. You should update to the current 2D driver (you're using 2.3.2, not 2.5.0, so you don't have support for HDMI or DVI), and make sure you have the kernel AGP patch (in Linux master and in your friendly local distribution hopefully), and delete your xorg.conf. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
libdrm 2.4.1
New libdrm release to fix the symbol name collision between Mesa 7.2 and libdrm_intel. Also includes a fix for deadlock in non-GEM 2D, and support for aperture size checking in GEM. eaaaf08726d5ac6f3a7f20bf5ec0a013772d7b55 libdrm-2.4.1.tar.bz2 583c1c62f70877ec592245ca0316375662eeb693 libdrm-2.4.1.tar.gz 05feb4c5a48f1f0870a7cbe7617d6cf7 libdrm-2.4.1.tar.bz2 cbcb796bbb3bf9079c4cb22c9d051772 libdrm-2.4.1.tar.gz Alex Deucher (2): radeon: fix some fallout from the busmaster disable cleanup radeon: fix error in busmaster enable logic Ben Skeggs (2): nv50: move context-related tables a separate header file nv50: symlink nv50_grctx.h to linux-core... Eric Anholt (3): intel: Add dri_bufmgr_check_aperture support for bufmgr_gem. intel: Rename dri_ and intel_ symbols to drm_intel_. libdrm 2.4.1. Keith Packard (1): intel: ioctl is not defined to return -errno Matthias Hopf (1): drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831) Pekka Paalanen (1): drm: missing init_mm symbol, compatibility fix Robert Noland (3): [FreeBSD] This check isn't correct and causes at least mga to lockup. [FreeBSD] We should use dev2unit() rather than minor() i915: Since FreeBSD doesn't have gem support yet, don't advertise it. Xiang, Haihao (2): intel: avoid deadlock in intel_bufmgr_fake. intel: Also total child_size of the target_bos. Partial fix #17964. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Intel Xorg driver with GLSL freez system
On Mon, 2008-10-27 at 17:07 +0100, Mateusz Kaduk wrote: Hi, I have debian with xorg 1.5.2 and master mesa/libdrm/intel which I use with EXA and GEM enabled kernel from Eric. I installed nexuiz apt-get install nexuiz and game crash system when I run it with enabled GLSL. Can someone check it ? It also can be downloaded from http://downloads.sourceforge.net/nexuiz/nexuiz-242.zip I cant debug it because I dont have antoher computer to ssh in and it looks like a freez. Right now most GLSL debugging on the 965 driver is on hold while idr rewrites Mesa's GLSL compiler, since the driver part will need to be mostly rewritten after that, anyway. However, if people could isolate failing shaders and get them into piglit testcases, we might be able to get to them earlier, and it would benefit all future GLSL work as well. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: error messages - was: xf86-video-intel 2.5.0 performance questions
On Sun, 2008-10-26 at 15:09 +0100, Tobias Hain wrote: Keith Packard wrote: [drm:i915_getparam] *ERROR* Unknown parameter 5 set status page addr 0x01fff000 As Julien said, this is just the user-mode driver checking for GEM support which isn't present in your old kernel. If it were the new 2D driver printing the message, we would have fixed it, but it's the old kernel driver. That old driver could be patched to not print the message. When having problems with the intel driver, people's attention first get on one of the many error messages almost any intel video configuration exhibits. Among these messages are: [6] exaCopyDirty: Pending damage region empty! [6] (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. [16](EE) intel(0): underrun on pipe A! [5] mtrr: no MTRR for e000,1000 found [?] waiting for X server to shut down error setting MTRR (base = 0xe000, size = 0x1000, type = 1) Invalid argument (22) The number in square brackets [?] corresponds to the number of hits in the intel xorg video bugzilla. Even without patching old kernel code, I can think of many ways to prevent the latest *ERROR* Unknown parameter 5 message. Somebody involved in driver development, knows to judge those message. E.g. the underrun message is explained here: https://bugs.freedesktop.org/show_bug.cgi?id=16833#c16 However the general user (or developer, but just not being a video driver developer) is mislead by those bloating error messages. I think it would be helpful for people trying to debug issues, if those error messages get evaluated. Maybe some should be downgraded to warnings. Others may be presented more descriptive. With the recent addition of GEM and G4x code and the multitude of configurations deployed (libdrm, kernel, mesa, xserver, ...) the number of bugs/issues facing people increased and one of the first things they encounter are often one of the above error messages. This is a problem we have. Messages with escalated severity increase over time, and only get reduced when someone goes on a crusade to clean them up. It's happened a couple times before, and we're about due to do it again. It's going to be a goal of mine for 2.6.0. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
On Sat, 2008-10-25 at 15:33 +0100, Colin Guthrie wrote: Colin Guthrie wrote: Eric Anholt wrote: Could you get a gdb backtrace? Hmm it seems that whenever the machine is locked up and I attach gdb to the process it just prints: Redelivering pending alarm clock And then gdb freeze :s I've attached gdb to X process before the lockup this time and will see what happens when it next occurs. OK, got a good 'un. Hopefully this is understandable. Please let me know if you prefer to do this via BZ. I'm happy either way as I read this list quite often. Col plain text document attachment (x-dri-lockup.txt) (gdb) continue Continuing. ^C Program received signal SIGINT, Interrupt. 0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) info threads * 1 Thread 0x7ff12455d6f0 (LWP 22427) 0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x7ff123d7b694 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x7ff123d76f34 in _L_lock_100 () from /lib64/libpthread.so.0 #2 0x7ff123d76941 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x7ff120d1a664 in dri_fake_bo_exec (bo=0x2e853c0, used=1304, cliprects=0x1799210, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1060 #4 0x7ff10fe13d1f in _intel_batchbuffer_flush (batch=0x1ec1ec0, file=value optimized out, line=value optimized out) at intel_batchbuffer.c:152 #5 0x7ff10fe27812 in i915_emit_state (intel=0x1952a20) at i915_vtbl.c:345 #6 0x7ff10fe3bef1 in intelRenderStart (ctx=0x1952a20) at intel_tris.c:998 #7 0x7ff10fadb370 in run_render (ctx=0x17805c0, stage=0x80) at tnl/t_vb_render.c:275 #8 0x7ff10fad2374 in _tnl_run_pipeline (ctx=0x1952a20) at tnl/t_pipeline.c:158 #9 0x7ff10fe45810 in intelRunPipeline (ctx=0x1952a20) at intel_tris.c:987 #10 0x7ff10fad2ef9 in _tnl_draw_prims (ctx=0x1952a20, arrays=value optimized out, prim=0x7fff2c5ab3e0, nr_prims=1, ib=0x0, min_index=0, max_index=3) at tnl/t_draw.c:402 #11 0x7ff10faca2a9 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at vbo/vbo_exec_array.c:267 Thanks for the detailed info. This one is fixed in libdrm master, commit 769197c8f16eaf3c0a476a4459e535afd4a939cb. We should be rolling a 2.4.1 pretty soon once we clean up a couple more little issues. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Lockup on intel dri
On Fri, 2008-10-24 at 10:55 +0100, Colin Guthrie wrote: Hi, I'm wondering if anyone can advice of how to address this lockup? I'm running mesa master from a couple days ago + a few minor patches (quite similar to the Fedora dev package) + xserver 1.5.2 + patches (very similar to the Fedora dev package - I also cherry picked the dix backtrace stuff too). I'm using intel 2.5.0. I'm getting the [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. error but I know that's somewhat misleading. As I have the backtrace cherry-picks from master the following was dumped into my log. [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f67798bbf46] 5: /etc/X11/X [0x484115] 6: /etc/X11/X [0x4671d7] 7: /lib64/libpthread.so.0 [0x7f677cf38d20] 8: /lib64/libpthread.so.0 [0x7f677cf37694] 9: /lib64/libpthread.so.0 [0x7f677cf32f34] 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f677cf32941] 11: /usr/lib64/libdrm_intel.so.1 [0x7f6779ed6664] 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) [0x7f6768dc9d1f] 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f6768dde202] 14: /usr/lib64/libdricore.so(_mesa_Flush+0x64) [0x7f67689e158c] 15: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c5a9b] 16: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f677a9c1e32] 17: /etc/X11/X(Dispatch+0x364) [0x447464] 18: /etc/X11/X(main+0x45d) [0x42d64d] 19: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f677b8d8316] 20: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] I don't have anything special in my kernel and I'm not using GEM. My h/w is i945GM. The above was with an older evdev, but (as it was mentioned, I upgraded to 2.0.99.2 and got the following (similar output): [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /etc/X11/X(xorg_backtrace+0x26) [0x4e6d56] 1: /etc/X11/X(mieqEnqueue+0x291) [0x4c75d1] 2: /etc/X11/X(xf86PostMotionEventP+0xc4) [0x4831d4] 3: /etc/X11/X(xf86PostMotionEvent+0xb1) [0x4833b1] 4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7f48dc25d1a7] 5: /etc/X11/X [0x484115] 6: /etc/X11/X [0x4671d7] 7: /lib64/libpthread.so.0 [0x7f48df8dad20] 8: /lib64/libpthread.so.0 [0x7f48df8d9694] 9: /lib64/libpthread.so.0 [0x7f48df8d4f34] 10: /lib64/libpthread.so.0(pthread_mutex_lock+0x71) [0x7f48df8d4941] 11: /usr/lib64/libdrm_intel.so.1 [0x7f48dc878664] 12: /usr/lib64/dri/i915_dri.so(_intel_batchbuffer_flush+0x186) [0x7f48cb76ad1f] 13: /usr/lib64/dri/i915_dri.so(intelFlush+0xe9) [0x7f48cb77f202] 14: /usr/lib64/dri/i915_dri.so [0x7f48cb76c7ba] 15: /usr/lib64/dri/i915_dri.so(intelTexImage2D+0x7d) [0x7f48cb76d4f3] 16: /usr/lib64/libdricore.so(_mesa_TexImage2D+0x2a9) [0x7f48cb3fdc71] 17: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd36d933] 18: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd360a87] 19: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd35fa42] 20: /usr/lib64/xorg/modules/extensions//libglx.so [0x7f48dd363e32] 21: /etc/X11/X(Dispatch+0x364) [0x447464] 22: /etc/X11/X(main+0x45d) [0x42d64d] 23: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f48de27a316] 24: /etc/X11/X(FontFileCompleteXLFD+0x279) [0x42ca29] (evdev itself did odd things but that's another story!) Any ideas? So, it looks like somebody leaked the lock in libdrm, or we're attempting to double-lock it. The second seems unlikely since we batchbuffer_flush so regularly, but it's hard to say. Could you get a gdb backtrace? A lot of information is missing in server backtraces. Also, does whatever app you're running that causes this failure run in direct rendering mode? That may make it easier to get a decent backtrace. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel-2.5.0
On Fri, 2008-10-24 at 18:40 +0300, Bogdan Burlacu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I've compiled the latest kernel, 2.6.28-rc1 which is supposed to have GEM support and also installed xf86-video-intel-2.5.0. I use: - - xorg-server-1.5.2 - - mesa-7.2 - - libdrm-2.4 How can I tell if gem works? So far glxgears fpd dropped from ~950 (with driver 2.4.2) to ~530 with the latest drivers and I haven't seen any other improvements in 2d. You need master or intel-2008-q3 branch of mesa. Mesa 7.2 shipped without GEM because it hadn't made it into the kernel yet. (Also, obglxgearsisnotabenchmark) -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Tue, 2008-10-21 at 00:11 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? I would say yes. dmesg says : [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged while Xorg.0.log says : (II) intel(0): xf86BindGARTMemory: bind key 5 at 0x03bff000 (pgoffset 15359) (EE) intel(0): Failed to pin back buffer: Cannot allocate memory Fatal server error: Couldn't bind memory for BO back buffer The Legacy3D FALSE option may help you bring the GEM environment up in a limited-aperture-space situation. On our end, we should also cut back the EXA offscreen space in the presence of limited aperture to increase the chance of success. Also, we could use Legacy3D as a signal that it's safe to resize the framebuffer, and actually do that. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Mon, 2008-10-20 at 19:48 +0100, Sergio Monteiro Basto wrote: Hi , Since xf86-video-intel 2.5 needs libdrm 2.4.0 , we need Mesa 7.2 ? or is enough ? just upgrade libdrm , and compile xf86-video-intel 2.5 for xserver 1.4.2 No, it needs libdrm 2.4.0. That doesn't imply anything about mesa required. libdrm should always be safe to upgrade. If it isn't, we're doing something wrong. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sun, 2008-10-19 at 20:50 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. libdrm 2.4.0 is released. http://dri.freedesktop.org/libdrm/ I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sun, 2008-10-19 at 23:51 +0200, Stefan Dirsch wrote: On Sun, Oct 19, 2008 at 12:16:10PM -0700, Eric Anholt wrote: On Sun, 2008-10-19 at 20:50 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. libdrm 2.4.0 is released. http://dri.freedesktop.org/libdrm/ I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. ./configure: line 12342: syntax error near unexpected token `PTHREADSTUBS,' ./configure: line 12342: `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)' error: Bad exit status from /var/tmp/rpm-tmp.30192 (%build) line 12342 of configure in the distributed tarballs don't have PKG_CHECK_MODULES. It looks like you re-ran autotools in an environment without the pkgconfig macros installed, and didn't heed the warning that autotools gave you (sadly, autotools does continue along despite the error). -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Tue, 2008-10-14 at 16:49 +0200, Maarten Maathuis wrote: On Tue, Oct 14, 2008 at 4:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Hello, I've a use-case where the client uploads 32x32 A8 images to an 256x256x8 pixmap which is later used as mask in a composition operation. The test-case is able to render with 40fps on xserver-1.3/intel-2.1.1 however with the latest GIT of both I only get ~10-15fps. Unfourtunatly I've not been able to create a stand-alone testcase which triggers this problem :-/ Using sysprof I can see a lot of time is spent moving data arround, very strange is that PutImage seems to cause a readback: ProcPutImage-ExaCheckPutImage-exaPrepareAccessReg-exaDoMigration-exaDoMoveOutPixmap-exaCopyDirty-exaWaitSync-I830EXASync In Composite I see the re-uploading again. Any idea why ProcPutImage could to fallback (there's plenty of free vram)? Are there tools / settings which could help me to identify the problem? Thank you in advance, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I think this is because intel does not provide an UploadToScreen hook (because it has no vram). It hasn't made (visible) effort to reintegrate UXA in EXA, because you can obviously be bit smarter than what is currently being done. I've got an idea or two on how to improve this, but intel should be more than capable in dealing with this. Migrating out for a write-only operation is just broken, and is the thing that should be fixed there. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: For how long Intel users are stucked with OpenGL 1.4 ?
On Tue, 2008-10-07 at 20:26 +0200, Mateusz Kaduk wrote: Hi, Is there any chance to get OpenGL 2.1 on Intel 965GM ? A time ago I was using DRM module i915.ko from git and it was working nice. Now because of GEM, module is not compiling anymore and I am stucked with OpenGL 1.4 which does not work for most of applications that I was able to run before! While ati and nvidia support OpenGL 2.1 nicely, laptop users with onboard Intel are really stucked... Is there any walkaround for this bug ? Is there any branch that supports OpenGL 2.1 and does not have GEM in its code? You want the drm-intel-next kernel tree for GEM support (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel), not drm.git master. This is the code that will be going into 2.6.28. The OpenGL version number issue is not GEM-related. We decided not to merge the ARB_occlusion_query support that had been written because it was unsafe for multiple contexts and imposed extra idling on the hardware, such that it may have been worse for its consumers than not supporting the extension at all. Since ARB_oq was put into the OpenGL 1.5 base, we can't expose 2.0 even though we support everything but ARB_oq. I've got a branch of my work-in-progress ARB_oq support at git://anongit.freedesktop.org/~anholt/mesa#965-occlusion-query which I got compiling this morning waiting for a kernel build. I'm hoping to finish it in the next 2 weeks. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: For how long Intel users are stucked with OpenGL 1.4 ?
On Tue, 2008-10-07 at 12:05 -0700, Eric Anholt wrote: On Tue, 2008-10-07 at 20:26 +0200, Mateusz Kaduk wrote: Hi, Is there any chance to get OpenGL 2.1 on Intel 965GM ? A time ago I was using DRM module i915.ko from git and it was working nice. Now because of GEM, module is not compiling anymore and I am stucked with OpenGL 1.4 which does not work for most of applications that I was able to run before! While ati and nvidia support OpenGL 2.1 nicely, laptop users with onboard Intel are really stucked... Is there any walkaround for this bug ? Is there any branch that supports OpenGL 2.1 and does not have GEM in its code? I've got a branch of my work-in-progress ARB_oq support at git://anongit.freedesktop.org/~anholt/mesa#965-occlusion-query which I got compiling this morning waiting for a kernel build. I'm hoping to finish it in the next 2 weeks. Huh, it turned out to be as easy as I expected. That never happens. ARB_occlusion_query is now enabled in mesa master, and GL version reported is 2.1. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel (2.4.2) and support for Focus FS454
On Mon, 2008-10-06 at 20:04 +0200, Stefan /*St0fF*/ Hübner wrote: Hello list, I've got a system here which consists of Intel 830CGC and a focus fs454 chip to produce TV-output. Is there any way of making this work on a relatively current linux? I'm asking this as I could not make successful use of the IEGD-suites available from Intel a.t.m. How could the fs454 be made usable with the 2.4.2 version? (I've seen some sub-modules for other chips that seem to have the same purpose) Is support planned? Would Intel help? No, we're no longer adding additional support for old DVO encoders. Most of them have freely available specifications such that anyone with time and interest could write a driver for them. I saw fs454 register specs with some cursory googling. If that's not enough, mmiotrace and friends can help trace what the BIOS does to program your hardware so you can write a better native driver. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXfont 1.3.1
This release fixes bugs in the catalogue dir support. Ademar de Souza Reis Jr (4): Support relative paths in catalogue:dir symlinks. Fix dirfd leak on CatalogueRescan(). Dodji Seketeli (1): Remove side effects from BuiltinReadDirectory() Matthieu Herrb (1): Kill unused macro definition. git tag: libXfont-1.3.1 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.3.1.tar.bz2 MD5 (libXfont-1.3.1.tar.bz2) = b2f396b62633819bbdd9748383876e21 SHA1 (libXfont-1.3.1.tar.bz2) = 90153414cd3580d92cad6469166c099749cddd29 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.3.1.tar.gz MD5 (libXfont-1.3.1.tar.gz) = 59ca31a8dab4431af4ecc7c28bc8cdac SHA1 (libXfont-1.3.1.tar.gz) = e4ed676b704d5410402050eda381543c34b83553 -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.1.3
The most important feature of this release is a set of locking fixes, which unbreak this library for threaded apps. The lock issues were exposed by libxcb. Daniel Stone (2): XChangeDeviceControl: Fix completely broken locking XSetDeviceFocus: Add missing extension check David Weinehall (1): XGetSelectedExtensionEvents: Still more locking bugs Eric Anholt (1): Bump version to 1.1.3. Eric S. Raymond (1): Bug #9659: Bad markup on XListInputDevices.3x James Cloos (1): Add *~ to .gitignore to skip patch/emacs droppings git tag: libXi-1.1.3 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.1.3.tar.bz2 MD5: MD5 (libXi-1.1.3.tar.bz2) = 7c510abb0cad8dc20493fb27ff7859d8 SHA1: SHA1 (libXi-1.1.3.tar.bz2) = 60608bcbebadc5fe0b51b5012e9301eb720988fe http://xorg.freedesktop.org/archive/individual/lib/libXi-1.1.3.tar.gz MD5: MD5 (libXi-1.1.3.tar.gz) = 65e9a6deceb0756564ae4f5803ddc801 SHA1: SHA1 (libXi-1.1.3.tar.gz) = 57bdd2bff5f64e64715ad1efff0e76f108a2aa57 -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] renderproto-0.9.3
Along with documentation updates, this release fixes several types for the X Server on 64-bit platforms, which had resulted in BadMatches when unlucky. Be warned that this will break server ABI on those platforms in fixing them. This is intended to be included in video driver ABI 2.0 (server 1.4), pending merge of the server dependency on this version. git tag: renderproto-0.9.3 http://xorg.freedesktop.org/archive/individual/proto/renderproto-0.9.3.tar.bz2 MD5 (renderproto-0.9.3.tar.bz2) = 598bc9a493deee2e48e4434e94467189 SHA1 (renderproto-0.9.3.tar.bz2) = c3425e2a5ceecd160b09462c50a69848756e449e http://xorg.freedesktop.org/archive/individual/proto/renderproto-0.9.3.tar.gz MD5 (renderproto-0.9.3.tar.gz) = ab8f3e356973d9c99810a8f092db3a2e SHA1 (renderproto-0.9.3.tar.gz) = c137ec00faf0aee0f88a986aa827a590827447c1 -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel-1.9.94 (2.0 RC4)
In hopefully our last RC before release, here's xf86-video-intel 2.0 RC4. The big news in this one is the addition of 965GM support. Also present are some EXA fixes, documentation updates, and moving the debug output under Option ModeDebug YES. SHA1 (xf86-video-intel-1.9.94.tar.bz2) = deef198be9359bd135f9923e09736c1d60d34487 SHA1 (xf86-video-intel-1.9.94.tar.gz) = 47481496e2f8a93d80315c4cf5b33481961f275a MD5 (xf86-video-intel-1.9.94.tar.bz2) = d6c2e9700c74ae01b124183582827cf5 MD5 (xf86-video-intel-1.9.94.tar.gz) = bc629cabcc3a75b9f0c93ea4b09a941e (Full changelog from 1.9.93 to 1.9.94 elided due to large numbers of commits from the crestline branch which had already been replayed before). -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel-1.9.93 (2.0 RC3)
Significant differences over the previous RC include fixes for larger 915-generation LVDS panels, fixes for rotation on the 965, improved TV format selection, some SDVO output enabling fixes, I2C timing fixes to improve the chances of DDC, and cursor behavior fixes with RandR. SHA1 (xf86-video-intel-1.9.93.tar.bz2) = 2a058a8b2b62978894a4f92ae28500a40a07e0da SHA1 (xf86-video-intel-1.9.93.tar.gz) = a7c4fdcf0a31bd03072804828055152677b51a09 MD5 (xf86-video-intel-1.9.93.tar.bz2) = 75aef7467442dd7fb0dc94e4b6ebdb7e MD5 (xf86-video-intel-1.9.93.tar.gz) = 953dbdbf0580a45dbf86eb88cd93e15a Changes since xf86-video-intel-1.9.92: Eric Anholt: Fix sparse warnings about using 0 for NULL. Don't reload the cursors if we haven't set up the screen yet. Fix crashes and other failures when a cursor allocation fails. Fix compile failure due to needed types being in inttypes.h on Linux. Add the (afaict) correct ch7017 I2C slave address. Move vendor ID check in the utils to after pci_device_probe. Add debug output for ADPA. Print the mode actually being set per pipe. Set the CURSOR_SIZE register when present. Attempt to fix single/dual-channel issues on i9xx LVDS panels. Update manpage to remove Rotate option and point at xorg.conf instead. Power on the LVDS B-channel pairs only when we've chosen dual-channel mode. Update .gitignore. Bump version to 1.9.93 for 2.0RC3. Keith Packard: Use new driver-independent CRTC-based cursor layer. Remove extra (and incorrect) I2C ByteTimeout setting. Build fix for pre-XF86DRI_MM environments. Increase DDC I2C RiseFallTime to handle older monitors Cast ARGB cursor address to CARD32 * to eliminate warning. Elide I830DRIClipNotify for older DRI versions. Allocate 4 separate buffers for HW Cursors on Linux. Make i830_sdvo_write_sdvox write everything twice. TV output properties: TV_FORMAT, LEFT, TOP, RIGHT, BOTTOM. Property size is in units, not bytes. Don't call AdjustFrame on EnterVT. Record 3D state loss at EnterVT in last_3d value. Eliminate calls to RRPostPendingProperty. Switch TV_FORMAT property to format XA_ATOM Michel Dänzer: Fix build when DAMAGE is not defined. Wang Zhenyu: EXA: try to enable rotation for G965 EXA: don't smash vertex header in G965 -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
