Re: DRI2 + buffer creation
On Tue, 2009-03-31 at 15:43 +1000, Dave Airlie wrote: So I've been playing a bit more with DRI2 and I'm having trouble finding how the buffer creation was meant to work for depth buffers. If my app uses a visual 0xbc 24 tc 0 24 0 r . . 8 8 8 0 0 16 0 0 0 0 0 0 0 None which is 24-bits + 16-bit depth, I don't have enough information in the DDX to create a depth buffer with a cpp of 2, the DDX can only see the drawable information it knows nothing about the visual. Now it goes and creates a set of 4 buffers to give back to Mesa, which then goes and takes the cpp of the depth buffer as 4 when clearly it would need to be 2, then bad things happen. So should I just be creating the depth buffer in Mesa, does the DDX need to know about it all really... Yep, go create the depth buffer in Mesa. The DDX doesn't really need to know about it. Alan. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI2 flush extension
Attached is a new DRI2 flush extension that allows the driver to perform
a real flush before dispatching a swap or Xserver copy operation.
Currently we do this before a DRI2CopyRegion() call.
This allows drivers a real end of scene flush to ensure rendering is
complete prior to a swap.
I've committed this already to the gallium-mesa-7.4 branch, but any
comments appreciated before I push to the master branch?
Thanks,
Alan.
commit b163d4f9ee2ab4d54daf7c17c097cae51c9c6db2
Author: Alan Hourihane al...@vmware.com
Date: Thu Feb 19 18:39:08 2009 +
glx: add support for a reallyFlush() function before swap occurs.
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index 27cc1be..a726b93 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -78,6 +78,7 @@ typedef struct __DRIswrastExtensionRec __DRIswrastExtension;
typedef struct __DRIbufferRec __DRIbuffer;
typedef struct __DRIdri2ExtensionRec __DRIdri2Extension;
typedef struct __DRIdri2LoaderExtensionRec __DRIdri2LoaderExtension;
+typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
/*...@}*/
@@ -245,6 +246,16 @@ struct __DRItexBufferExtensionRec {
__DRIdrawable *pDraw);
};
+/**
+ * Used by drivers that implement DRI2
+ */
+#define __DRI2_FLUSH DRI2_Flush
+#define __DRI2_FLUSH_VERSION 1
+struct __DRI2flushExtensionRec {
+__DRIextension base;
+void (*flush)(__DRIdrawable *drawable);
+};
+
/**
* XML document describing the configuration options supported by the
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 639aa19..fdda852 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -207,7 +207,13 @@ static void dri2CopySubBuffer(__GLXDRIdrawable *pdraw,
xrect.width = width;
xrect.height = height;
+#ifdef __DRI2_FLUSH
+if (pdraw-psc-f)
+ (*pdraw-psc-f-flush)(pdraw-driDrawable);
+#endif
+
region = XFixesCreateRegion(pdraw-psc-dpy, xrect, 1);
+/* should get a fence ID back from here at some point */
DRI2CopyRegion(pdraw-psc-dpy, pdraw-drawable, region,
DRI2BufferFrontLeft, DRI2BufferBackLeft);
XFixesDestroyRegion(pdraw-psc-dpy, region);
@@ -235,6 +241,11 @@ static void dri2WaitX(__GLXDRIdrawable *pdraw)
xrect.width = priv-width;
xrect.height = priv-height;
+#ifdef __DRI2_FLUSH
+if (pdraw-psc-f)
+ (*pdraw-psc-f-flush)(pdraw-driDrawable);
+#endif
+
region = XFixesCreateRegion(pdraw-psc-dpy, xrect, 1);
DRI2CopyRegion(pdraw-psc-dpy, pdraw-drawable, region,
DRI2BufferFakeFrontLeft, DRI2BufferFrontLeft);
@@ -255,6 +266,11 @@ static void dri2WaitGL(__GLXDRIdrawable *pdraw)
xrect.width = priv-width;
xrect.height = priv-height;
+#ifdef __DRI2_FLUSH
+if (pdraw-psc-f)
+ (*pdraw-psc-f-flush)(pdraw-driDrawable);
+#endif
+
region = XFixesCreateRegion(pdraw-psc-dpy, xrect, 1);
DRI2CopyRegion(pdraw-psc-dpy, pdraw-drawable, region,
DRI2BufferFrontLeft, DRI2BufferFakeFrontLeft);
diff --git a/src/glx/x11/dri_common.c b/src/glx/x11/dri_common.c
index 4fda649..90c3d8c 100644
--- a/src/glx/x11/dri_common.c
+++ b/src/glx/x11/dri_common.c
@@ -392,6 +392,13 @@ driBindExtensions(__GLXscreenConfigs *psc, int dri2)
}
#endif
+#ifdef __DRI2_FLUSH
+ if ((strcmp(extensions[i]-name, __DRI2_FLUSH) == 0) dri2) {
+ psc-f = (__DRI2flushExtension *) extensions[i];
+ /* internal driver extension, no GL extension exposed */
+ }
+#endif
+
/* Ignore unknown extensions */
}
}
diff --git a/src/glx/x11/glxclient.h b/src/glx/x11/glxclient.h
index 3e70759..caf58bb 100644
--- a/src/glx/x11/glxclient.h
+++ b/src/glx/x11/glxclient.h
@@ -519,6 +519,10 @@ struct __GLXscreenConfigsRec {
const __DRItexBufferExtension *texBuffer;
#endif
+#ifdef __DRI2_FLUSH
+const __DRI2flushExtension *f;
+#endif
+
#endif
/**
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Xserver 1.5 to not have DRI2 ? [Was Re: drm: Changes to 'libdrm-2_3-branch']
On Fri, 2008-06-06 at 12:36 +0100, Alan Hourihane wrote: On Fri, 2008-06-06 at 11:23 +0100, Dave Airlie wrote: Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? I think it will have to not have DRI2 by default unless Kristian does the decoupling from the mm interface. Ouch. It would be good to know Kristian's plans. Just changing the title so it's more obvious to others... Alan. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Changes to 'libdrm-2_3-branch'
On Tue, 2008-06-03 at 21:12 -0700, Dave Airlie wrote: New branch 'libdrm-2_3-branch' available with the following commits: commit f892b4adf4021e82a7d4f2eb06256d6f4200ed15 Author: Dave Airlie [EMAIL PROTECTED] Date: Wed May 28 15:31:18 2008 +1000 remove include commit c28c1cf756979cebb67ffd64bc29ba371f1a9c4b Author: Dave Airlie [EMAIL PROTECTED] Date: Wed May 28 15:08:08 2008 +1000 libdrm: make a branch for libdrm which drops all the TTM apis. This will be the next release of libdrm as 2.3.1, Mesa needs to deal with this for 7.1. Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? Alan. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Changes to 'libdrm-2_3-branch'
On Fri, 2008-06-06 at 11:23 +0100, Dave Airlie wrote: Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? I think it will have to not have DRI2 by default unless Kristian does the decoupling from the mm interface. Ouch. It would be good to know Kristian's plans. Alan. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM modesetting sysfs
On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote: On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote: I was going to suggest that you plug it into the hotplug_stage_two function but it looks like you have already done that. Things might be routed differently now then since the last time I looked at the code, are you sure that stage_two is being run? I'll have to check, I'm not sure I'm even getting interrupts... Jesse, Is this i915 or i945/i965 you are testing on ?? Alan. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM modesetting sysfs
On Wed, 2008-04-09 at 09:34 -0700, Jesse Barnes wrote: On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote: On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote: On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote: I was going to suggest that you plug it into the hotplug_stage_two function but it looks like you have already done that. Things might be routed differently now then since the last time I looked at the code, are you sure that stage_two is being run? I'll have to check, I'm not sure I'm even getting interrupts... Jesse, Is this i915 or i945/i965 you are testing on ?? I've been testing on my i915 based laptop, haven't tried my other systems yet... With VGA (i.e. ADPA) output ? If so, that's the problem. From what I can tell of i915 docs, they only support hotplug for SDVO devices only, so that's how it's coded up at the moment. For i945/i965 it can go the whole hog. Alan. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wed, 2007-09-26 at 15:43 +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
linux-core/drm_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
diff-tree 6671ad1917698b6174a1af314b63b3800d75248c (from
03c47f1420bf17a1e0f2b86be500656ae5a4c95b)
Author: Alan Hourihane [EMAIL PROTECTED]
Date: Wed Sep 26 15:38:54 2007 +0100
don't copy back if an error was returned.
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index cedb6d5..8513a28 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -645,7 +645,7 @@ long drm_unlocked_ioctl(struct file *fil
retcode = func(dev, kdata, file_priv);
}
- if (cmd IOC_OUT) {
+ if ((retcode == 0) cmd IOC_OUT) {
Hmm, brackets around the == but not around the ??
Could you humour me and change that to something like:
if (retcode == 0 (cmd IOC_OUT)) {
Sure. should of caught that.
Alan.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI changes
On Wed, 2007-06-13 at 18:48 -0400, Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. I've been trying to understand the change better in order to try to come up with a backwards compatible way to do the same. I think I've found a way to let the DDX driver tell libdri not to map the framebuffer and then do it itself. The problem is that Alans patch also changes the DRI driver side of things to not map the front buffer in the loader but in the driver code, based on extra info from the DDX device private. A compromise that will leave the DDX device private untouched is still require the framebuffer info (handle and size etc) through DRIGetDeviceInfo, but to not map the front buffer in the loader. Instead we just pass the handle and size into the DRI driver (as we do now), and the driver can then do the drmMap(). However, at this point I'm wondering what the intention of the patch is and if my suggested change somehow conflicts with that... help? Kristian, What you are suggesting sounds fine, but do you have patches to back up the suggested compromise so I can double check ?? Thanks, Alan. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI changes
On Sat, 2007-06-16 at 15:05 +0200, Jerome Glisse wrote: On 6/16/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: On 6/14/07, Keith Whitwell [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. Kristian, Just letting you know Alan's on holidays this week, back on Monday. Ah, thanks. I was talking to Dave about it in IRC and it sounds like we can let the DDX driver add the front buffer map and let the DRI driver set it up without breaking the shared private struct. I've attached three patches (on top of my dri2 work) to illustrate the idea. What's missing is the i810 specific setup in mesa and a mechanism to indicate whether or not dri_util.c should map the buffer or if the DRI driver will do that. But that's all behind the DRI interface, so it's not a big deal. I'm not sure why we're doing this though. It looks like things are mostly working as it is, it's just not very elegant. And if we're about to shake things up with DRM memory manager enabled DDX and DRI drivers, do we want to add a hack like this? Kristian My feeling is that i would love to avoid hack and take advantage of undergoing change to fix API in sane way btw all component involved. Maybe we should accept to break backward compat at a point in order to properly and cleanly change all this. But as i can't devote time to this is just my personnal view. Actually, I agree here too. Alan. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wed, 2007-04-11 at 10:40 -0700, Jesse Barnes wrote:
On Wednesday, April 11, 2007, Jesse Barnes wrote:
Some people were asking about modeseting on #dri-devel this morning so I
thought I'd post an update (airlied is asleep so we can blame him for
all the problems :).
The modesetting-101 branch of the DRM tree is coming along nicely. Much
of X.Org's modesetting code has been pulled in (will look very familiar
to those of you who've worked with X.Org's Randr 1.2 code), along with
driver support code for Intel chipsets.
Dave pulled over a bunch of it, and integrated the patches from Jakob
(ioctl interface for modesetting) and I (initial port of some X.Org code
along with DDC and i2c code) into the tree, got it working and wrote a
simple drmfb driver to sit on top.
Based on that, I've been working on making the i915 driver
initialization less dependent on userspace for things, like mapping
registers, allocating memory, setting modes, etc. I just checked in
some code to initialize drmfb at load time and set the correct modes
depending on output configuration (seems to work ok for external vga but
lvds modes are still messed up somehow).
It's all still very fragile at this point, so you probably won't want to
play with it unless you're really interested in hacking on it.
Some of the open questions we're wrestling with atm:
o how do we free drm drivers to init a load time rather than
addmap/etc. time?
o how can we do TTM memory allocation at load time? depends on AGP
init happening early, etc.
o what should the initial config be? cloned? multihead? single,
primary head with other heads initialized to a blank screen?
and of course there's lots to do on the logistics front: output, crtc
list management, locking, etc., and bugs in DDC probing for old monitors
(need more delays and i2c poking).
Oh, and if you want this to have any chance of working at the moment,
you'll need this patch too (I haven't pushed it for fear of breaking other
drivers), warning this was cut pasted:
diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c
index f4da7da..13652eb 100644
--- a/linux-core/drm_stub.c
+++ b/linux-core/drm_stub.c
@@ -113,10 +113,6 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
dev-driver = driver;
- if (dev-driver-load)
- if ((retcode = dev-driver-load(dev, ent-driver_data)))
- goto error_out_unreg;
-
if (drm_core_has_AGP(dev)) {
if (drm_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
@@ -136,6 +132,11 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
}
}
+
+ if (dev-driver-load)
+ if ((retcode = dev-driver-load(dev, ent-driver_data)))
+ goto error_out_unreg;
+
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR(Cannot allocate memory for context bitmap.\n);
This is all very very nice.
I don't see a problem in pushing this if drivers don't expose a load
function though.
Alan.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wed, 2007-04-11 at 19:13 +0100, Alan Hourihane wrote:
On Wed, 2007-04-11 at 10:40 -0700, Jesse Barnes wrote:
On Wednesday, April 11, 2007, Jesse Barnes wrote:
Some people were asking about modeseting on #dri-devel this morning so I
thought I'd post an update (airlied is asleep so we can blame him for
all the problems :).
The modesetting-101 branch of the DRM tree is coming along nicely. Much
of X.Org's modesetting code has been pulled in (will look very familiar
to those of you who've worked with X.Org's Randr 1.2 code), along with
driver support code for Intel chipsets.
Dave pulled over a bunch of it, and integrated the patches from Jakob
(ioctl interface for modesetting) and I (initial port of some X.Org code
along with DDC and i2c code) into the tree, got it working and wrote a
simple drmfb driver to sit on top.
Based on that, I've been working on making the i915 driver
initialization less dependent on userspace for things, like mapping
registers, allocating memory, setting modes, etc. I just checked in
some code to initialize drmfb at load time and set the correct modes
depending on output configuration (seems to work ok for external vga but
lvds modes are still messed up somehow).
It's all still very fragile at this point, so you probably won't want to
play with it unless you're really interested in hacking on it.
Some of the open questions we're wrestling with atm:
o how do we free drm drivers to init a load time rather than
addmap/etc. time?
o how can we do TTM memory allocation at load time? depends on AGP
init happening early, etc.
o what should the initial config be? cloned? multihead? single,
primary head with other heads initialized to a blank screen?
and of course there's lots to do on the logistics front: output, crtc
list management, locking, etc., and bugs in DDC probing for old monitors
(need more delays and i2c poking).
Oh, and if you want this to have any chance of working at the moment,
you'll need this patch too (I haven't pushed it for fear of breaking other
drivers), warning this was cut pasted:
diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c
index f4da7da..13652eb 100644
--- a/linux-core/drm_stub.c
+++ b/linux-core/drm_stub.c
@@ -113,10 +113,6 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
dev-driver = driver;
- if (dev-driver-load)
- if ((retcode = dev-driver-load(dev, ent-driver_data)))
- goto error_out_unreg;
-
if (drm_core_has_AGP(dev)) {
if (drm_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
@@ -136,6 +132,11 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
}
}
+
+ if (dev-driver-load)
+ if ((retcode = dev-driver-load(dev, ent-driver_data)))
+ goto error_out_unreg;
+
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR(Cannot allocate memory for context bitmap.\n);
This is all very very nice.
I don't see a problem in pushing this if drivers don't expose a load
function though.
Whoops. Ignore that comment. Just got in from a long distance travel and
obviously hadn't drunk enough coffee.
But don't ignore the first comment, this is still very very nice.
Alan.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
bug #5714 frontbuffer removal pending !!! Was [Re: [Bug 7767] No hardware rendering for SuperSavage/IXC 64 and Xorg 7.2 RC3]
On Wed, 2007-02-28 at 10:55 +0100, Michel Dänzer wrote: On Sun, 2007-02-25 at 19:35 +, Alan Hourihane wrote: I know what the problem is here. And bugzilla #5714 will cure it. So I'm getting inclined to pull the frontbuffer-removal branch into master and fix up the drivers on the fly. How does this sound to others. At FOSDEM, I chatted about this with Kristian Høgsberg, and he had some ideas how the transition could be handled without requiring lockstep between all involved components. Kristian, mind describing those ideas here? Kristian ??? I'm keen to get this patch integrated. Alan. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 7767] No hardware rendering for SuperSavage/IXC 64 and Xorg 7.2 RC3
I know what the problem is here. And bugzilla #5714 will cure it. So I'm getting inclined to pull the frontbuffer-removal branch into master and fix up the drivers on the fly. How does this sound to others. Alan. On Sat, 2007-02-24 at 15:00 -0800, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7767 --- Additional Comments From [EMAIL PROTECTED] 2007-02-24 15:00 --- did you test it though? As I said further up this bug, there are no functional difference between the savage in the drm tree and the one in the kernel tree, they are just either whitespace or a difference caused by the device binding methods used... so what I did was bring over a bunch of drm core code that could affect the area you are seeing the problem in.. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current DRM git broken on 965
Andi,
That's a bug that's been around for a while, and regardless of the
machine having no AGP, you still need agpgart for the 965 driver to
function as internally it's really an AGP device.
Alan.
On Sun, 2006-08-13 at 11:06 +0200, Andi Kleen wrote:
Hello,
After the recent announcements I tried the current DRM git tree on a
Board with Intel 965 graphics. But this gives the appended oops
when loading the i915 module.
The crash is in this line in drm_lastclose(), presumably
because the magic free list isn't initialized in this error path.
list_for_each_entry_safe(pt, next, dev-magicfree, head) {
Of course the system doesn't have any AGP bridge since it is
PCI-E only. agpgart was compiled in, but not active.
The driver seems to have PCI IDs for my graphics device.
-Andi
[drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
Unable to handle kernel NULL pointer dereference at RIP:
[88094bbc] :drm:drm_lastclose+0xc9/0x332
PGD 38381067 PUD 36ba7067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq snd_hda_intel
snd_hda_codec snd_pcm snd_timer snd snd_page_alloc
Pid: 3875, comm: insmod Not tainted 2.6.18-rc4 #11
RIP: 0010:[88094bbc] [88094bbc]
:drm:drm_lastclose+0xc9/0x332
RSP: 0018:8100378bdc28 EFLAGS: 00010297
RAX: RBX: ffe8 RCX: c100
RDX: 81003f4e5610 RSI: 8100378bc000 RDI:
RBP: 81003eb6e000 R08: 8100378bc000 R09:
R10: 0080 R11: 0001 R12: 81003f38b000
R13: 81003eb6e028 R14: 81003f38b000 R15: ffea
FS: 2b14a8e926d0() GS:807fb000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 36bab000 CR4: 06e0
Process insmod (pid: 3875, threadinfo 8100378bc000, task 81003f4db5d0)
Stack: 81003eb6e000 81003eb6e000 880af900 81003f38b000
880af638 880979ff 880af638 880af440
0296 8022bc04 0003
Call Trace:
[880979ff] :drm:drm_get_dev+0x2c2/0x4d9
[80347543] pci_device_probe+0xdd/0x142
[8039fd75] driver_probe_device+0x52/0xa8
[8039fea0] __driver_attach+0x6b/0xa9
[8039f2b6] bus_for_each_dev+0x43/0x6e
[8039f5f8] bus_add_driver+0x73/0x10f
[880afb00] :i915:__this_module+0x0/0xcec7
DWARF2 unwinder stuck at __this_module+0x0/0xcec7 [i915]
Leftover inexact backtrace:
[803470ca] __pci_register_driver+0x57/0x7d
[88094719] :drm:drm_init+0xc5/0x141
[8024b4f4] sys_init_module+0x15ed/0x1727
[80209612] system_call+0x7e/0x83
Code: 4c 8b 63 18 eb 3e 48 8b 53 18 48 8b 41 08 48 8d bd e8 00 00
RIP [88094bbc] :drm:drm_lastclose+0xc9/0x332
RSP 8100378bdc28
CR2:
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel DRI driver crash
On Sun, 2006-06-18 at 20:38 -0700, Eric Anholt wrote:
With a clean Mesa build as of yesterday, glxgears is crashing at:
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
#1 0x2839dd6d in _mesa_resize_framebuffer (ctx=0x80af000, fb=0x8060400,
width=300, height=300) at main/framebuffer.c:331
#2 0x2834b612 in intelWindowMoved (intel=0x80af000) at
intel_context.c:576
#3 0x2834b6fa in intelMakeCurrent (driContextPriv=0x80521e0,
driDrawPriv=0x80eff00, driReadPriv=0x80eff00) at intel_context.c:612
#4 0x2832cee6 in DoBindContext (dpy=0x805e000, draw=54525954,
read=54525954,
ctx=0x80695b0, modes=0x8055500, psp=0x8069300)
at ../common/dri_util.c:343
#5 0x2832cf7e in driBindContext (dpy=0x805e000, scrn=0, draw=54525954,
read=54525954, ctx=0x80695b0) at ../common/dri_util.c:376
#6 0x280abe29 in BindContextWrapper () from /usr/X11R6/lib/libGL.so.1
#7 0x280ac2b7 in glXMakeCurrentReadSGI ()
from /usr/X11R6/lib/libGL.so.1
#8 0x280ac37e in glXMakeCurrent () from /usr/X11R6/lib/libGL.so.1
#9 0x0804b7d2 in ?? ()
...
(gdb) frame 0
#0 0x2839de7d in _mesa_update_draw_buffer_bounds (ctx=0x80af000)
at main/framebuffer.c:384
384if (buffer-Name) {
(gdb) p buffer
$1 = (struct gl_framebuffer *) 0x0
Anyone else seeing this?
Update your CVS.
I've already fixed this.
Alan.
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
On Thu, 2006-06-01 at 11:20 -0600, Brian Paul wrote: Alan Hourihane wrote: On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: On 5/30/06, Pedro Maia [EMAIL PROTECTED] wrote: To run quake2 please use, LD_PRELOAD=path/to/libGL.so quake2 In my case it works fine, with that trick , without it didn't work. But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Actually I do remember my theory When a program is linked at build time, libGL is the one responsible for dlload'ing the DRI driver and resolves symbols perfectly well with the current RTLD flags. But when the program dlopen's libGL itself, it resolves what it currently has access to which the DRI driver isn't actually loaded. I suspect for this to work the libGL's dlinit() routine (that's called when dlopen'ed) would need to someone link in the correct DRI driver at that time - but I'm pretty sure all the available details to do that wouldn't be available. I don't think there's any easy fix, which is why I resorted to the LD_PRELOAD approach. This may all be bogus though. This sounds related to the -Bsymbolic linker option. When you build a shared library, the -Bsymbolic option tells the linker to resolve references in the shared library to symbols defined within the library, in preference to other locations. For example, if libGL had a function called init_driver(), -Bsymbolic would ensure that references to init_driver() were resolved to that function, and not another init_driver() function that might be defined in the application itself. The lack of -Bsymbolic in some libraries has caused me grief in the past. I've also raised this issue with some commercial OpenGL vendors. It can't be this as the libGL we're using now is from Mesa, and mklib already add the -Bsymbolic for us. I'm not sure how the linker can resolve the symbol anyway. The fact that the application has dlopen'ed libGL and the linker doesn't even know which DRI driver to pull in to resolve at that time. Having an unresolvable symbol like _glapi_add_dispatch in libGL without libGL being able to do it's loadable DRI driver first maybe a bad thing. Unless some of the glibc folks can help resolve this one. Alan. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: On 5/30/06, Pedro Maia [EMAIL PROTECTED] wrote: To run quake2 please use, LD_PRELOAD=path/to/libGL.so quake2 In my case it works fine, with that trick , without it didn't work. But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Doing this... export LD_PRELOAD=/usr/lib/libGL.so to force the libGL linkage fixes the issue. Alan. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: On 5/30/06, Pedro Maia [EMAIL PROTECTED] wrote: To run quake2 please use, LD_PRELOAD=path/to/libGL.so quake2 In my case it works fine, with that trick , without it didn't work. But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Actually I do remember my theory When a program is linked at build time, libGL is the one responsible for dlload'ing the DRI driver and resolves symbols perfectly well with the current RTLD flags. But when the program dlopen's libGL itself, it resolves what it currently has access to which the DRI driver isn't actually loaded. I suspect for this to work the libGL's dlinit() routine (that's called when dlopen'ed) would need to someone link in the correct DRI driver at that time - but I'm pretty sure all the available details to do that wouldn't be available. I don't think there's any easy fix, which is why I resorted to the LD_PRELOAD approach. This may all be bogus though. Alan. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Enabling Direct Rendering at CVS tip
On Sat, 2006-02-18 at 19:41 -0500, Adam Jackson wrote: On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a bug report I opened explicitly for this. Is this major enough to warrant bumping the libdri major number? It certainly sounds like it if all the drivers have to be touched. Absolutely. Alan. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Enabling Direct Rendering at CVS tip
On Sat, 2006-02-18 at 19:49 -0500, Adam Jackson wrote: On Saturday 18 February 2006 19:41, Adam Jackson wrote: On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a bug report I opened explicitly for this. Is this major enough to warrant bumping the libdri major number? It certainly sounds like it if all the drivers have to be touched. Never mind me, hadn't read through to your patch yet. No problem, comments appreciated. Alan. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Enabling Direct Rendering at CVS tip
On Wed, 2006-02-15 at 20:00 +, Dave Airlie wrote: libGL error: drmMap of framebuffer failed (Invalid argument) libGL error: reverting to (slow) indirect rendering I've been wondering about this, I mentioned it to Alan + Keith at XDC, I've had to patch my libdrm to be okay with an 0 length mmap, Something like I'm sure TG have done something different or maybe just never checed this in .. Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a bug report I opened explicitly for this. Alan. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: Re: sizeof(I830DRIRec) does not match passed size from device driver
On Wed, 2006-02-08 at 13:38 -0800, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: This is due to snapshots building X.org drivers from the monolith tree, the monolith tree is dead so no new devel is done in it.. TG commited changes to the i810 driver for rotate which changed the size of rec... re-doing snapshot to use the modular tree is a bit of work though.. If that's the case, shouldn't there have been a version bump in the DDX? The DRI driver should require the newer version. The DDX was bumped, but the check in intel_screen.c was missed to check for the newer DDX. I've just fixed that now. Alan. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915-Graphics Driver for Xorg-7.0
It's not a problem. Don't worry about it. Alan. On Wed, 2006-01-25 at 21:56 +0100, Peter Weber wrote: Hello, I hope I've got the right mail-adress, I have a question at the i915 (GMA900) developer of the i810 driver?! As far as I know nearly everyone with an i915GM-Chipset (GMA900) has a problem with a BusID-Error, everything seems to work good but something must be not working in the right way. Just see below (don't care about the xkbcomp-message): System is Gentoo-Linux based. Thanks Peter Weber PS: If you want addional information, just mail me. X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.14.2 i686 Current Operating System: Linux party 2.6.14.2 #8 Fri Dec 30 16:01:26 CET 2005 i686 Build Date: 24 December 2005 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Fri Dec 30 19:00:00 2005 (==) Using config file: /etc/X11/xorg.conf (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) found Warning!? expected keysym, got dead_diaresis: line 143 of pc/de The XKEYBOARD keymap compiler (xkbcomp) reports: Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols Ignoring extra symbols Errors from xkbcomp are not fatal to the X server --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Front buffer rotation
I'm just about to commit to fairly large updates to the intel driver that offers rotation support fully accelerated with 3D as well. One of the problems that surfaced in this was the dri layers own mapping of the front buffer which we ended up working around by mapping a 0 length one for now. But the next logical step is to remove this mapping from the DRI layer and leave it upto the drivers to map it just as if it were a back or depth buffer. Any objections or comments on this, as it may well break binary drivers that depend on the DRI mapping it ?? Alan. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM MTRR's
Has anyone any objections to me removing the MTRR code from the DRM. It doesn't have the intimate knowledge needed to properly configure MTRR's and fails in many cases. There are two cases currently, one for the framebuffer and a second for the entire AGP space. Certainly in Intel hardware this is the same memory space and you always get bogus error messages in your kernel logs as things fail due to lack of boundary checks. I'm more of the opinion that it should be left up to userspace to configure MTRR's if it indeed wants them and we shouldn't force them within the DRM. Additionally, the Xserver (for user-space) already sets up the MTRR's, as should Xgl (Xegl) or other user space apps. What makes the situation a little worse is that vesafb (and other *fb drivers) also setup an mtrr which frequently stops subsequent processes from adding a new one that overlaps an existing write-combining range. But the *fb drivers do provide a nomtrr option in many cases. (But I'd like to remove it from them too :-) or at least default those to off) Comments ?? Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM MTRR's
On Fri, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: Has anyone any objections to me removing the MTRR code from the DRM. It doesn't have the intimate knowledge needed to properly configure MTRR's and fails in many cases. There are two cases currently, one for the framebuffer and a second for the entire AGP space. Certainly in Intel hardware this is the same memory space and you always get bogus error messages in your kernel logs as things fail due to lack of boundary checks. I'm more of the opinion that it should be left up to userspace to configure MTRR's if it indeed wants them and we shouldn't force them within the DRM. Additionally, the Xserver (for user-space) already sets up the MTRR's, as should Xgl (Xegl) or other user space apps. What makes the situation a little worse is that vesafb (and other *fb drivers) also setup an mtrr which frequently stops subsequent processes from adding a new one that overlaps an existing write-combining range. But the *fb drivers do provide a nomtrr option in many cases. (But I'd like to remove it from them too :-) or at least default those to off) Comments ?? One thing to add, is that I did initially look at just removing DRIVER_USE_MTRR from the intel DRM, but it really doesn't satisfy other use cases for the other chipsets. Again, inline with the fact there may already be existing mtrr's setup and the DRM fails to honour proper checking. But I'm interested in others comments on this. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM MTRR's
On Fri, 2005-09-23 at 12:46 +0100, Dave Airlie wrote: It doesn't have the intimate knowledge needed to properly configure MTRR's and fails in many cases. I don't think we can really just nuke support for them, maybe we should fix the support if we can... the problem I have is removing them will signiciantly slow down a lot of working systems.. if the X server doesn't do the correct thing.. Problem here Dave is that there are probably a lot of systems that use the *fb drivers are already slower. In an *fb model in that the user hasn't explicitly turned off the mtrr then there's only a small range that will actually get configured for video memory. The DRM will already fail to add the correct range as the kernel will refuse to overwrite an existing range. You may find things speed up in many cases if we remove it from the DRM. AGP space is a different matter for those non-integrated systems where the DRM setting the MTRR will probably be just fine at the moment. You can remove the DRIVER_USE_MTRR from the i915 driver, but I'd be worried about any regressions, regressing the kernel is very rarely acceptable.. some way to perhaps have the X server tell the DRM driver to not bother with them... The Xserver does set the range correctly on Intel hardware. I'm not sure about the others, so removing DRIVER_USE_MTRR on i915 hardware is reasonable for now. But anything outside of the Xserver would need to explicitly turn them on. For Radeon IGP chipsets I would expect us to have similiar issues but I'm not sure how they do the mapping.. Right. There are two cases currently, one for the framebuffer and a second for the entire AGP space. Certainly in Intel hardware this is the same memory space and you always get bogus error messages in your kernel logs as things fail due to lack of boundary checks. I'm more of the opinion that it should be left up to userspace to configure MTRR's if it indeed wants them and we shouldn't force them within the DRM. Additionally, the Xserver (for user-space) already sets up the MTRR's, as should Xgl (Xegl) or other user space apps. Well EGL would need to set it up, not the X server itself, or I suppose in the case I'd like to get designed is to have the mode-setting/DRM initing process to do it.. My point here, being user space needs to set these up, not the kernel. What makes the situation a little worse is that vesafb (and other *fb drivers) also setup an mtrr which frequently stops subsequent processes from adding a new one that overlaps an existing write-combining range. But the *fb drivers do provide a nomtrr option in many cases. (But I'd like to remove it from them too :-) or at least default those to off Not sure what to do there.. have to ask the fb devel guys.. Ben ? Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM MTRR's
On Fri, 2005-09-23 at 12:46 +0100, Dave Airlie wrote: acceptable.. some way to perhaps have the X server tell the DRM driver to not bother with them... In the interests of backwards compatibility I suppose this may be a reasonable option though. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM MTRR's
On Fri, 2005-09-23 at 13:28 +0100, Dave Airlie wrote: I don't think we can really just nuke support for them, maybe we should fix the support if we can... the problem I have is removing them will signiciantly slow down a lot of working systems.. if the X server doesn't do the correct thing.. Problem here Dave is that there are probably a lot of systems that use the *fb drivers are already slower. In an *fb model in that the user hasn't explicitly turned off the mtrr then there's only a small range that will actually get configured for video memory. The DRM will already fail to add the correct range as the kernel will refuse to overwrite an existing range. You may find things speed up in many cases if we remove it from the DRM. Looking at X it sets up the framebuffer mtrr for most cards, but nothing for AGP, mtrr for AGP is as far as I know a big win as we can't cache the aperture so write combining is needed... maybe we can stop the DRM from allocating MTRRs for framebuffers in the DRM but leave the code in for the AGP space... then the i915 can just turn it off in the drm and let X do it... Right, that's what I mention in my previous email. But remember that AGP space in Intel hardware is where the framebuffer comes from so X is already doing this for us. So there's no point in the i915 drm doing it for AGP framebuffer memory as it's the same thing. I'll just remove DRIVER_USE_MTRR from the i915 setup for now. We can add an option for DRM to turn on mtrr for framebuffer.. or maybe we can check for an pre-existing and if there is one we can just do nothing, or add one if not .. or a drm driver option to enable/disable it.. My other point here is that some hardware requires MTRR's to be aligned and the DRM doesn't know how to do that it just ships off the current region to mtrr and doesn't look back. So it needs more intimate knowledge if it's going to continue to do it - regardless of driver. Alan. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: problem with intel 830M board Display driver
Sahul, It's probably better that you download a DRI snapshot from http://dri.freedesktop.org/wiki/Download and click the Snapshots item from the initial menu which will tell you how to install them. Alan. On Wed, 2005-09-21 at 09:50 +0530, Sahul wrote: Hi I downloaded the driver from Intel website, as i am using a standard Intel board with 82830M Graphics controller. But now they have stopped the support for this 82830 as they have moved to the next. I am new to linux (just 3 months) and i am using the old kernel 2.4.20-8,with Xfree version 4.3. My problem in moving to new kernel is that my other applications are compiled for older kernel and recompiling them will take a lot of time... so i downloaded this driver from intel website and they have put that it will support 82830M boards and also older kernels.. So please guide me on this Thanks.. On 9/20/05, Alex Deucher [EMAIL PROTECTED] wrote: On 9/20/05, Sahul [EMAIL PROTECTED] wrote: Hi I am testing a development platform whose specifications are as follows.. Its a Intel 830M Board which uses a FS-454 chipset on board for graphics dislay on television. I tried the driver intelgraphics_060704.tar.gz which i downloaded from your website. But i was not able to get through. I am attaching the dri.log file here with for your reference..Please help me out in getting this issue resolved... I'm not sure where you got this driver from, but your best bet is to build the driver using these instructions: http://dri.freedesktop.org/wiki/Building Alex Sahul --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is AGP apeture at zero on x86 okay?
On Sat, Jul 09, 2005 at 11:08:21 +0100, Dave Airlie wrote: On my x86 laptop I get Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 915GM Chipset. agpgart: AGP aperture is 256M @ 0x0 This machine doesn't have an AGP card, just a PCI Express ATI Radeon X300.. Dave, Can you do 'lspci -vn' and send me the output. Thanks. Alan. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
There's another issue here. And that's drmAddress in the 2D DDX drivers. On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because drmAddress is passed in the *DRIRec things break. The client-side 3D driver gets the *DRIRec and as it's a different size things are a mess when using a 32bit client on a 64bit arch. It looks like the radeon and r128 don't suffer from this but most of the other drivers do. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: There's another issue here. And that's drmAddress in the 2D DDX drivers. On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because drmAddress is passed in the *DRIRec things break. The client-side 3D driver gets the *DRIRec and as it's a different size things are a mess when using a 32bit client on a 64bit arch. It looks like the radeon and r128 don't suffer from this but most of the other drivers do. For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. How about casting it to drm_handle_t? I think we can just remove it in the other cases. I've just looked at the via and sis drivers and it doesn't make any real use of it. I'm sure the other drivers don't make any real use of it too. I think it's best to just remove it's use completely. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Thu, Jun 30, 2005 at 04:19:45 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. How about casting it to drm_handle_t? I think we can just remove it in the other cases. I've just looked at the via and sis drivers and it doesn't make any real use of it. I'm sure the other drivers don't make any real use of it too. I think it's best to just remove it's use completely. Right. Some cleanup doesn't hurt. This drmAddress looks like something that was introduced without checking if something similar existed already. The cleanup does hurt, as it breaks backwards compatibility between the DRI clients and the Xserver. But if 7.0 is around the corner I'd rather break things now, and with idr's changes breaking compatibility too, now is the time to do it. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Thu, Jun 30, 2005 at 11:32:52AM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Hourihane wrote: On Thu, Jun 30, 2005 at 04:19:45 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. How about casting it to drm_handle_t? I think we can just remove it in the other cases. I've just looked at the via and sis drivers and it doesn't make any real use of it. I'm sure the other drivers don't make any real use of it too. I think it's best to just remove it's use completely. Right. Some cleanup doesn't hurt. This drmAddress looks like something that was introduced without checking if something similar existed already. The cleanup does hurt, as it breaks backwards compatibility between the DRI clients and the Xserver. But if 7.0 is around the corner I'd rather break things now, and with idr's changes breaking compatibility too, now is the time to do it. While I do agree with that sentiment, my proposed breaks are a little different. All of the interfaces that I'm proposing breaking are between client-side components (libGL and the client-side driver). If someone wants to install a newer client-side driver on 6.8.x, they can install a newer libGL to get things working. If the client/server protocol breaks, there is no easy work-around. Right. But my point being, let's do all the breakages at once. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Thu, Jun 30, 2005 at 12:04:13AM +0100, Dave Airlie wrote: The issues remaining are: a) should we provide backwards compat stuff for users of old kernels in DRM CVS, without cluttering up the nice code.. It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to build because the .compat_ioctl doesn't exist in 2.6.9. Or, at the very least, we'll need to check if compat_ioctl exists before allowing compilation. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On Tue, Jun 28, 2005 at 12:09:52PM +1000, Benjamin Herrenschmidt wrote: On Fri, 2005-06-24 at 09:58 -0400, Jon Smirl wrote: On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: I'm update with your changes this morning. I'm still seeing this at system shutdown. I modprobe drm,radeon and then unloaded them (no errors) then shut the system down. With some more experiments, it only happens with radeonfb loaded. You also have to leave drm/radeon loaded when rebooting. If you rmmod them reboot is ok. It is starting to look like something is not right in kernel support for sysdev devices in loadable drivers. As I said earlier, using a sysdev for DRM is bogus anyway. On ppc at least, it will probably break sleep/wakeup since by the time the sysdev suspend routine will be called, the video chip will be in D2 or D3 state. O.k. I've yanked the code from CVS for this now, as I don't want to pollute things if they're not going to work properly. Is anyone working on a stub driver ?? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote: Is it possible to run 32bit OpenGL applications on an AMD64 with DRI support? 64bit applications are working fine, but 32bit apps always use software rendering on my machine (Radeon 7500). It looks like an kernel issue. So my question is, if there are any kernel patches available to solve this problem? There is a patch but it doesn't provide full backwards compat .. it's bugzilla 943 on bugs.freedesktopp.org Egbert is hoping to look at it again, I keep getting hopelessly lost in types when I start looking at it.. I don't have the hardware to test it on... Egbert's patch has been updated and it's looking good. I'd suggest committing it to CVS now for more widespread testing. I'll commit it by the end of the week unless there are any arguments against it. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Tue, Jun 28, 2005 at 01:16:14PM +0100, Dave Airlie wrote: bugzilla 943 on bugs.freedesktopp.org Egbert is hoping to look at it again, I keep getting hopelessly lost in types when I start looking at it.. I don't have the hardware to test it on... Egbert's patch has been updated and it's looking good. I'd suggest committing it to CVS now for more widespread testing. I'll commit it by the end of the week unless there are any arguments against it. I've started pushing the kernel bits to the kernel from Paulus, Linus has accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and r128 and whatever other bits are in Egberts patch... If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Tue, Jun 28, 2005 at 02:02:39PM +0100, Dave Airlie wrote: I've started pushing the kernel bits to the kernel from Paulus, Linus has accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and r128 and whatever other bits are in Egberts patch... If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? Mainly as I've only got two hands, and Paulus submitted it to the kernel first and it was easier to get into -mm and test it... it was a trivial push to get it into Linus's kernel.. also the kernel interfaces for this stuff has changed recently so I'm not sure about how to support older kernels via DRM CVS, so I'd rather punt on that and not support them... I've just committed untested the compat code to DRM CVS but I've no 64-bit system to even test it on... Thanks for updating the CVS, and no problem on the 'two hands' thing either. I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 hadn't been updated by Paul and all of a sudden it appears in the kernel first without being in the DRM CVS for at least a little while to get tested here. I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote: I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 hadn't been updated by Paul and all of a sudden it appears in the kernel first without being in the DRM CVS for at least a little while to get tested here. Paul and Egbert discussed it on the bug at the time Paul was working on it .. I was happier with Pauls initial approach for the kernel, and Egberts first patch I also felt to be overly intrusive from the start, and uncaring of backwards compat, i.e. fine for SuSE distros but not for the kernel as we would break old Xs I understand the backwards compatibility issues and that's good to have, but even Paul noted that when the chance arrives that the scheme should be changed to match more of what Egbert was trying to achieve. The libdri.a library has just been bumped to 5.0.0 in X.Org's snapshot 6.8.99.8, so now maybe a good time to adjust things a little more and bump libdrm.a to 2.0.0 as well. I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Yes they probably do need to be applied alright, really Egberts patch need to take more care of what Paul was aiming for with compatibility... I didn't get enough time to full review his last patch, but I would prefer to see it split up into the drm/Mesa/Xorg pieces so each can be assessed by each team, the days of the drm being a part of Xorg are coming to an end... To be honest, looking at the bug report, I'm not sure which patch should be applied to Mesa and/or X.Org in association with Paul's patch or Egberts. I was hoping the two of them would sort it out and supply me with a final solution as I've no access to any equipment using this stuff, and couldn't ever get anyone to review Egberts patch until Paul turned up with his own.. Indeed. Things seem to have slid a little here. I hope that Egbert and Paul can hash things out a little more. I've directly CC'ed them here for an update. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 915 DRM PM
On Mon, Jun 27, 2005 at 09:58:22AM -0400, Jon Smirl wrote: Is it possible to add the suspend/resume support to Intelfb instead of the DRM driver and then just load both drivers? Do we really want to start building another suspend/resume infrastructure inside of DRM if it is possible to address the problem through existing means? It seems to me like this could get very complicated if both DRM and fbdev both start to try controlling suspend/resume. The intelfb driver doesn't support the i9XX series of Intel chips, and also may not actually be loaded in two cases. One is if the user is already using vesafb, and second when the user isn't using fbdev at all. The case for coming up with a low level stub driver, seems to be a little stronger in this case rather than an fbdev/DRM glued approach. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Fri, Jun 24, 2005 at 05:07:53PM -0400, Jon Smirl wrote: On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: Jon, I've noticed you've moved drm_pm_init(). The reason it was were it was before is that the sysdev approach needn't and shouldn't be used when fbdev isn't loaded. Alan. It was too complicated gettting all the error paths right. Easier to just add it all of the time, it doesn't hurt anything. But as you are registering the sysdev in the case of the DRM being loaded without fbdev, don't you risk the case where the suspend/resume calls get called twice, once by the PCI driver and then later by sysdev ? Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Fri, Jun 24, 2005 at 05:19:30PM -0400, Jon Smirl wrote: On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: On Fri, Jun 24, 2005 at 12:31:06PM -0700, Jon Smirl wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/linux-core/ Changes by: [EMAIL PROTECTED] 05/06/24 12:31:06 Log message: More err path clean up for drm_pm Add mandatory sysdev shutdown function Modified files: drm/linux-core/: drm_drv.c drm_pm.c Revision ChangesPath 1.120drm/linux-core/drm_drv.c 1.4 drm/linux-core/drm_pm.c Jon, I've noticed you've moved drm_pm_init(). The reason it was were it was before is that the sysdev approach needn't and shouldn't be used when fbdev isn't loaded. Alan. Shouldn't the power management be per device instead of global to DRM? In fbdev it is per device. If it is per device we don't need the global class. The class is global, but the call is to the power() function is device specific. Maybe this is incorrect though for multiple cards, and should be moved to per device classes. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
Someone has logged a bug (#3549) that might be the cause. I've just not had time to investigate this yet. If no-one beats me to it, I'll take a look early next week. Alan. On Thu, Jun 23, 2005 at 04:45:48PM -0400, Jon Smirl wrote: Something in CVS is corrupting memory and causing various failures. My suspicion it is related to the power management code but I haven't been able to track it down. It is possible that this is related. On 6/23/05, Thomas Hellström [EMAIL PROTECTED] wrote: From bug 3609: I don't think this is via specific. Anybody that has a clue? kernel BUG at include/linux/dcache.h:294! invalid operand: [#1] PREEMPT Modules linked in: via drm nsc_ircc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq parport_pc parport psmouse pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_ircc irda acerhk amd64_agp agpgart eth1394 sata_via sata_svw libata sbp2 ohci1394 ieee1394 usb_storage usbhid CPU:0 EIP:0060:[c019d25c]Not tainted VLI EFLAGS: 00213246 (2.6.12-gentoo) EIP is at sysfs_remove_dir+0xfc/0x110 eax: ebx: db5aaf30 ecx: edx: ddf6f280 esi: db5aa800 edi: db891d14 ebp: dc5c16c0 esp: dac0de94 ds: 007b es: 007b ss: 0068 Process X (pid: 12235, threadinfo=dac0c000 task=db1835a0) Stack: dc62c9c0 dce3783a c04faea0 db5aaf30 db5aa800 dc62c940 dc5c16c0 c0300670 db5aaf30 db5aaf30 c03006a0 db5aaf30 0002 dc62cb20 df03d72d db5aaf30 dbb71380 df03e3a8 00203282 dac0c000 db5aa800 ddf64c80 Call Trace: [c0300670] kobject_del+0x10/0x20 [c03006a0] kobject_unregister+0x20/0x30 [df03d72d] drm_takedown+0x34d/0x3f0 [drm] [df03e3a8] drm_fasync+0x48/0x90 [drm] [df03e7c5] drm_release+0x3d5/0x540 [drm] [df03d950] drm_version+0x0/0xa0 [drm] [df03dbb3] drm_ioctl+0x1c3/0x23c [drm] [c0246400] udf_create+0x30/0x1b0 [df03d950] drm_version+0x0/0xa0 [drm] [c0246400] udf_create+0x30/0x1b0 [c0172cb7] do_ioctl+0x77/0xb0 [c015f58a] __fput+0x16a/0x1b0 [c015d942] filp_close+0x52/0xa0 [c015d9e8] sys_close+0x58/0xa0 [c010325b] sysenter_past_esp+0x54/0x75 Code: 89 44 24 08 8b 00 89 04 24 e8 c1 a9 fa ff 8b 54 24 08 8b 42 04 89 04 24 e8 32 35 16 00 8b 44 24 08 89 04 24 e8 a6 a9 fa ff eb 93 0f 0b 26 01 a2 94 49 c0 e9 17 ff ff ff 8d b4 26 00 00 00 00 83 /Thomas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Fri, Jun 17, 2005 at 09:35:31AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote: The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a texture copy is kept in system RAM doesn't depend on the DRM driver having suspend/VT swap hooks since it is able to rebuild VRAM at any point. Take a look at the _pm code in current DRM CVS it uses sysdev to hook suspend/resume for DRM... I'm not too happy about this going into upstream yet, but I'm willing to give it a try... A sysdev is the wrong approach imho. These are very low level, run with interrupts off, and have ordering issues, I'd rather avoid them. Also, at the point your sysdev suspend is called, it's likely that the video card will already be in D3 state - no access to vram. Ben, Can you provide more detail here ? The current situation is that when fbdev is loaded the DRM falls back to using the sysdev approach. If fbdev isn't loaded it takes direct control as the DRM becomes a real PCI driver and accesses the PCI functions for suspend/resume directly. What's the alternative to sysdev in the current model when fbdev is loaded ?? Also, can you explain the ordering issues ?? Thanks, Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Fri, Jun 17, 2005 at 03:02:09PM -0400, Jon Smirl wrote: On 6/17/05, Alan Hourihane [EMAIL PROTECTED] wrote: Ben, Can you provide more detail here ? The current situation is that when fbdev is loaded the DRM falls back to using the sysdev approach. If fbdev isn't loaded it takes direct control as the DRM becomes a real PCI driver and accesses the PCI functions for suspend/resume directly. The code for DRM conditionally taking direct control of the device is only in DRM CVS. It was rejected as a kernel submission. I realize that Jon, I'm trying to understand the issues with sysdev regardless of the current situation with the kernel. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: snapshot 20050610 [i810]
On Thu, Jun 16, 2005 at 11:21:52 +0100, Christian Marquardt wrote: I'm not sure if this is a bug in the snapshot or due to my setup... I have a Samsung X20 with an Intel i915GM graphics chip running under Mandrake LE2005. The latter has a 2.6.11 kernel and Xorg 6.8.2. I have installed both the common-20050610 and i810-20050610 snapshots You've picked the wrong snapshot for the i915GM chip. You need i915-20050610 instead of i810-20050610. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: agp mode and egl
On Tue, Jun 07, 2005 at 08:56:09 -0400, Jon Smirl wrote: On 6/7/05, Dave Airlie [EMAIL PROTECTED] wrote: An issue with doing all this on bootup is I can see very long kernel command lines appearing, which is something I don't really want to have to tell ppl, editing /etc/display.conf is a lot easier than say add radeon:agp_mode=4 to everyones command line.. you would just let it boot with default. Then in a script: echo mode /sys/class/drm/card0/agpmode if you need to override the default. Bear in mind what we'd be doing for other OS's besides Linux. Alan. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm_stub.c
On Fri, May 27, 2005 at 10:48:50AM -0700, Ian Romanick wrote:
Lukas Hejtmanek wrote:
drm_stub.c version 1.52 contains check whether device is AGP. I have i915
card
that is PCIE and it fails to initialize i915 module. If I comment out
check for
AGP then everything is OK.
That's interesting. I guess the problem is that the i915 driver has
DRIVER_REQUIRE_AGP set. I'm not sure what the right answer is here.
Even though my change to drm_stub.c broke the Linux version, the BSD
version *already* had that same check (and was therefore already broken
in the same way).
I suspect we may need to change the way drm_device_is_agp works. Right
now, the drm_driver::device_is_agp function can only fail a device that
would have otherwise passed. Changing the return code of
drm_driver::device_is_agp from meaning {might be AGP, abosolutely not
AGP} to a tri-state meaning {absolutely is AGP, might be AGP,
abosolutely not AGP} might do the trick.
Keith, since you're the main i915 guy, what do you think? Would this
bug also effect Via PCI-e chipsets with integrated graphics?
Ian,
Why does the mga_drv.c set DRIVER_REQUIRE_AGP when it doesn't 'require' it
if there's a PCI Matrox card ?
Couldn't we do
if (drm_device_is_agp(dev) || DRIVER_REQUIRE_AGP)
dev-agp = drm_agp_init(dev);
and remove DRIVER_REQUIRE_AGP from mga_drv.c ?
Alan.
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm_stub.c
On Fri, May 27, 2005 at 02:53:12PM -0400, Michel Dänzer wrote:
On Fri, 2005-05-27 at 19:02 +0100, Alan Hourihane wrote:
Why does the mga_drv.c set DRIVER_REQUIRE_AGP when it doesn't 'require' it
if there's a PCI Matrox card ?
Couldn't we do
if (drm_device_is_agp(dev) || DRIVER_REQUIRE_AGP)
dev-agp = drm_agp_init(dev);
and remove DRIVER_REQUIRE_AGP from mga_drv.c ?
Oops, try again...
if (drm_device_is_agp(dev) || drm_core_check_feature(dev,
DRIVER_REQUIRE_AGP))
dev-agp = drm_agp_init(dev);
if (dev-agp == NULL)) {
DRM_ERROR(Cannot initialize the agpgart module.\n);
retcode = -EINVAL;
goto error_out_unreg;
}
Shouldn't it be:
if (drm_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
if (drm_core_check_feature(dev, DRIVER_REQUIRE_AGP))
{
if (dev-agp == NULL)) {
DRM_ERROR(Cannot initialize the agpgart module.\n);
retcode = -EINVAL;
goto error_out_unreg;
}
}
That's what exists at the moment, but the the drm_device_is_agp(dev)
returns 0 because it's not an AGP device but PCIE, even though the
functionality of agpgart still exists in the chipset.
You've probably seen my easier fix already which will fix this problem.
Alan.
---
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] add PCI ID for i945G chipset for i915 drm
On Tue, May 17, 2005 at 05:11:40PM -0400, Christopher Allen Wing wrote: I am testing a x86_64 computer with integrated i945G video. The existing i915 DRI driver seems to work correctly on it once you tell it the correct PCI IDs. Is anyone looking into supporting the newer Intel chips? Just treating it like a i915G seems to work for me. Here is a patch against DRM CVS to add the i945G ID to the DRM kernel module code. I'll take care of things, they aren't exactly the same. Alan. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
On Thu, Mar 03, 2005 at 04:48:58AM +0100, Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? The 3 intel drivers and the s3v are not converted due to their support of a RGB555 format spantmp2 can't handle (actually, the i810 does not support the 555 format in its span functions, the driver elsewhere has support for it, this probably can't be right). tdfx and ffb are not converted since they support a 888 format. gamma is not converted since it performs some unusual always-round-up tricks when using RGB565 format. trident is not converted since it doesn't support span functions yet at all :-). - remove HW_CLIPLOOP, HW_ENDCLIPLOOP, CLIPPIXEL and CLIPSPAN macros out of the drivers whenever possible, since they are almost always identical. ffb uses very different macros, and some drivers do not use the driDrawable struct for HW_CLIPLOOP (which btw is interesting, I'm not quite sure why some drivers need to handle that differently, I didn't look too much into it but the difference is due to the handling of front and back buffers somehow), so they keep their own definitions hopefully. There are probably more macro definitions which could be factored out. - change CLIPSPAN to never return negative number of pixels (only change that once! not a dozen times, which is why I've done that macro definition removal in the first place...). Does this look sane? Driver source code should get quite a bit smaller overall. It looks o.k. and if there's hardware that's more obscure than the common cases then they'd have their own span routines anyway. Just watch out on the macro expansion though. You've got this currently... #define GET_SRC_PTR(_x, _y) (read_buf + _x * 2 + _y * pitch) and it should be... #define GET_SRC_PTR(_x, _y) (read_buf + (_x) * 2 + (_y) * pitch) Alan. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 915G lockup problem
Craig, Can you try adding this to your device section. Option CacheLines 512 and send me another log. Alan. On Wed, Jan 26, 2005 at 07:44:05PM -0600, Sylla, Craig wrote: Here is the full X log, gzipped. Craig -Original Message- From: Alan Hourihane [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 6:26 PM To: Sylla, Craig Cc: 'Dri-devel@lists.sourceforge.net' Subject: Re: Intel 915G lockup problem On Wed, Jan 26, 2005 at 05:54:51PM -0600, Sylla, Craig wrote: Using X.org, Mesa, and DRM all from CVS on Jan 10, and following the build instructions on the DRI wiki, I am getting lockups on my Intel 915G system. I'm running Fedora Core 2, and did have to build / replace the agpgart/intel-agp ko's using the ones from the Intel webpage (dated about June) as the PCI id's weren't into Core 2 yet. Here is the tail-end of the X.org log, there are no other errors in the log. The screen is filled with garbage, and the system is non-responsive (did not try telnet/rlogin). A full copy of the log would be useful Craig. Alan. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 915G lockup problem
On Wed, Jan 26, 2005 at 05:54:51PM -0600, Sylla, Craig wrote: Using X.org, Mesa, and DRM all from CVS on Jan 10, and following the build instructions on the DRI wiki, I am getting lockups on my Intel 915G system. I'm running Fedora Core 2, and did have to build / replace the agpgart/intel-agp ko's using the ones from the Intel webpage (dated about June) as the PCI id's weren't into Core 2 yet. Here is the tail-end of the X.org log, there are no other errors in the log. The screen is filled with garbage, and the system is non-responsive (did not try telnet/rlogin). A full copy of the log would be useful Craig. Alan. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 drm checkin...
On Sat, Jan 08, 2005 at 04:01:19AM +, Dave Airlie wrote: Hi Alan, you checked in some changes to the i915 drm but the changelog looks like you did more did you miss some changes in the checkin? mainly it says added resume functionality but the patch just changed a function name added the pci id and bumped the driver version... No. The name change was it. The resume functionality was already in the drm. It's just the 2D DDX never took advantage of it. So I just wanted to make sure it's known about now. That's why the changelog said what it did. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 09:49:30PM +, Alan Cox wrote: On Llu, 2005-01-03 at 14:46, Sjoerd Langkemper wrote: Hello, I would like 3D acceleration for my on-board Trident Cyberblade (VIA PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What do I have to program in order to get this done? You would need to write - Locking hooks for the X server driver for the trident - A kernel module to supervise the access to the video chip and remove unsafe commands - A 3D graphics driver library for MESA A few tiny starting points exist in the form of some bad documentation for the cyberblade and some very early code for an old MESA that was written by Alan Hourihane and then abandoned before it even drew triangles. Correction here. It does draw triangles. But that's about it. The documentation is seriously lacking and so bringing up the engine on how to draw triangles is the hardest part. Now that it draws triangles I was going to revisit the Command Queueing engine. I've just never had enough time to devote back to it. NOTE: That the code in Mesa CVS, is for the CyberBladeXP. So it won't work on other CyberBlades. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 05:09:31PM -0500, Adam Jackson wrote: On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: Hello, I would like 3D acceleration for my on-board Trident Cyberblade (VIA PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What do I have to program in order to get this done? Though there is a trident driver in CVS now, it does not work. The DDX is not DRI-aware and there is no DRM driver. The DDX and DRM driver are still in the DRI CVS on the trident-0-0-2 branch. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 06:02:27PM -0500, Alex Deucher wrote: On Mon, 3 Jan 2005 17:09:31 -0500, Adam Jackson [EMAIL PROTECTED] wrote: On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: Hello, I would like 3D acceleration for my on-board Trident Cyberblade (VIA PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What do I have to program in order to get this done? Though there is a trident driver in CVS now, it does not work. The DDX is not DRI-aware and there is no DRM driver. Actually it did work at one time, basic stuff like glxgears, at least according to AlanH. you'd probably need the trident branch from dri cvs to get it working, plus I'm not sure which chipsets were supported. Exactly. CyberBladeXP is the only one supported. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 06:10:37PM -0500, Adam Jackson wrote: On Monday 03 January 2005 18:02, Alex Deucher wrote: On Mon, 3 Jan 2005 17:09:31 -0500, Adam Jackson [EMAIL PROTECTED] wrote: On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: Hello, I would like 3D acceleration for my on-board Trident Cyberblade (VIA PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What do I have to program in order to get this done? Though there is a trident driver in CVS now, it does not work. The DDX is not DRI-aware and there is no DRM driver. Actually it did work at one time, basic stuff like glxgears, at least according to AlanH. I only said does not. Present tense ;) It should still work on the trident-0-0-2 branch. Shouldn't it ? you'd probably need the trident branch from dri cvs to get it working, plus I'm not sure which chipsets were supported. Cyberblade XP only, I believe. Indeed. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
Sounds like you are using an old CVS. Try updating. Alan. On Thu, Dec 16, 2004 at 06:20:55PM +0100, Dieter Nützel wrote: SM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM dri_util.c In file included from dri_util.c:52: dri_util.h:563: Warnung: redundant redeclaration of `glXGetProcAddress' in same scope /opt/Mesa/include/GL/glx.h:295: Warnung: previous declaration of `glXGetProcAddress' dri_util.c:57: error: conflicting types for `PFNGLXGETMSCRATEOMLPROC' /opt/Mesa/include/GL/glxext.h:617: error: previous declaration of `PFNGLXGETMSCRATEOMLPROC' dri_util.c:57: Warnung: redundant redeclaration of `PFNGLXGETMSCRATEOMLPROC' in same scope /opt/Mesa/include/GL/glxext.h:617: Warnung: previous declaration of `PFNGLXGETMSCRATEOMLPROC' dri_util.c: In function `glx_find_dri_screen': dri_util.c:157: Warnung: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness dri_util.c: In function `driCreateNewContext': dri_util.c:1073: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1074: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1076: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1077: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1081: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1082: Warnung: ISO C forbids assignment between function pointer and `void *' make[6]: *** [dri_util.o] Fehler 1 make[6]: Leaving directory `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' make[5]: *** [all] Fehler 2 Thanks, Dieter --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI backwards compatibility problem from X.Org 6.8.0 onwards
On Fri, Dec 10, 2004 at 07:04:51PM +, Alan Hourihane wrote: Folks, There's a backwards compatibility breakage with X.Org 6.8.0 and beyond because of revision 1.3 of the file xc/include/glxint.h. So, those that provide binary drivers that were compiled against X.Org 6.7.x or XFree86 4.4.0 or earlier will break as well. The problem stems from these additional fields in the GLXvisualConfigRec which actually are not needed. int multiSampleSize; int nMultiSampleBuffers; int visualSelectGroup; Ah, It seems as though the DMX code probably added these as it makes use of them. Alan. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm round 2...
On Wed, Aug 18, 2004 at 07:57:56PM +0100, Keith Whitwell wrote: Alan Cox wrote: On Mer, 2004-08-18 at 12:32, Keith Whitwell wrote: Once again, I predict the gamma driver which reportedly doesn't work and doesn't have any users will prove to be the stumbling block... I would suggest the gamma driver is retired. And I think I say that as about the only Linux user other than Alan Hourihane who has one 8) That would be fine with me... Dave, AlanH, has the moment arrived? Chop it! Alan. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 drm freebsd..
On Thu, Jul 29, 2004 at 12:18:05PM +0100, Dave Airlie wrote: I've just checked in the basics of the i915 DRM for FreeBSD but nothing happens... I'm running FreeBSD 5.2.1, After I kldload i915.ko I see nothing in the dmesg... am I missing something? or as the AGP driver stolen the card? Have you ported the required i915 AGP changes as well ?? If not, they've appeared in the 2.6.8-rc2-mm1 diff. Alan. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i830 driver status..
On Thu, Jul 15, 2004 at 08:22:42AM +0100, Dave Airlie wrote: Is the i830 driver considered to be dead, should any future work go towards the i915 one? I think you can deem the i830 driver dead, and the i915 superceeds it. All future work should go to the i915 driver. Alan. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Moving forward with the TLS work
On Wed, Jun 23, 2004 at 10:18:32AM -0600, Brian Paul wrote: Ian Romanick wrote: Ian Romanick wrote: I'm getting back to the TSL work, and I'd like to wrap it up as much as possible by the end of the week. I sent a patch out of the current state of things a little bit ago. Performance testing has shown that the new dispatch functions and the old, non-thread safe dispatch functions perform equally. The difference between the two is within the error margin of the test. That's the good news. The bad news is that the combination of a multithreaded app, with an old driver, and a new libGL will result in a segfault. The code sets _glapi_Dispatch to NULL in the multithreaded case as a signal to call _glapi_get_dispatch. When the code is fully converted to TLS, the call to _glapi_get_dispatch will be replaced with a 'movl %gs:_gl_DispatchTSD, %eax' or something similar. I want to maintain compatibility across the whole matrix of old / new libGL with old / new drivers. I may be willing to sacrifice new driver + old libGL, but that's the only combination I'd be willing to give on. I think we need to do 3 things to get there: 1. Keep the old meaning of _glapi_Dispatch. This means that all the _ts_* functions and their support mechanism will have to be kept. :( However, it will only be needed for the DRI libGL. The software rendering Mesa version won't need it. This turned out to not be as bad as I thought. There is still the extra dispatch table, but all of the function pointers in it point to the regular dispatch functions. In the multithreaded case, if an old driver does _glapi_Dispatch-Vertex3fv, it will end up calling glVertex3fv, which will see _glapi_DispatchTSD is NULL, which will call _glapi_get_dispatch to get the real dispatch and call the real function. The _ts_* functions are still gone. Everyone is happy. :) The one catch is that glapitemp.h (and the Python generator scripts) were modified. If NAME is not defined, glapitemp.h will not generate the dispatch functions. If DISPATCH_TABLE_NAME is defined, it will still generate the dispatch table. 2. For non-TLS new code, implement a new variable called _glapi_DispatchTSD that implements the new behavior. There will be a weak version of that variable, that is always NULL in dri_util.c. This should allow non-TLS new code to work with old libGL binaries. This is done and works perfectly. The only problem *I* have with it is the use of a GCC specific feature. Of course, the whole TLS thing is pretty GCC specific, so I guess this is somewhat moot. 3. TLS new code can do whatever it wants. I imagine this will be a __thread variable called _glapi_tls_Dispatch or something similar. This part isn't done yet, but should be easy enough. This patch also still requires you to manually generate glapi_x86.S by doing: cd src/mesa/glapi python2 ./gl_x86_asm.py ../x86/glapi_x86.S The other new thing in this patch is the state variable ThreadSafe is gone. Instead, the code universally uses _glapi_DispatchTSD == NULL to determine if it is in multi-threaded mode. Some other code in glapi.c changes as a direct result. If nobody raises any concerns, my intention is to commit these changes *tomorrow* afternoon (23-June-2004). The next two steps will be to start adding in some of the 'visibility(hidden)' stuff and (of course) the TLS support. I plan to mostly follow Jakub's lead with two exceptions. Instead of using 'hidden' as the macro for '__attribute__ ((visibility(hidden))', I'm going to take a cue from the PowerPC glibc code and use attribute_hidden. I'm also going to pick a different name than GLX_USE_TLS to enable compilation of the TLS code. I haven't decide what to use, though. Ian, I haven't had time to follow this too closely. A few questions: 1. Is thread safety in the GL API layer going to require TLS now? What about people who want thread safety but aren't using a version of Linux that supports TLS? 2. Which common Linux distros support TLS? I believe RH9 and later do, but that's all I'm aware of. I think Mandrake 10 also supports it. Alan. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New i915 driver in cvs
On Thu, Jun 10, 2004 at 01:51:42PM +0100, Keith Whitwell wrote: OK, the 3D and drm components are in CVS now. It'll be a little while before it can be used by anyone as we need to get the DDX changes in somewhere as well. O.k. I've popped the 2D ddx into XFree86's CVS, followed up by a merge of a snapshot of Mesa 6.1 from back in March time. Along with that, I've also merged in the latest DRM kernel modules in XFree86's tree as well. Some of the highlights of the 2D DDX are: - Dual Display Clone support, although no MergedFB - it could be done now tho' - ARGB cursor support (requires updated AGPgart - patches sent to Dave Jones) - Lid status checking (good for laptops) - Some fixes to Xvideo limits checking. With Ian working on some more structural changes it was easier to go straight into XFree86 CVS. There's nothing stopping someone merging it across though. Alan. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: New i915 driver in cvs
On Fri, Jun 11, 2004 at 12:37:49PM -0400, Alex Deucher wrote: On Thu, 10 Jun 2004 20:50:57 +0100, Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Jun 10, 2004 at 01:51:42PM +0100, Keith Whitwell wrote: OK, the 3D and drm components are in CVS now. It'll be a little while before it can be used by anyone as we need to get the DDX changes in somewhere as well. O.k. I've popped the 2D ddx into XFree86's CVS, followed up by a merge of a snapshot of Mesa 6.1 from back in March time. Along with that, I've also merged in the latest DRM kernel modules in XFree86's tree as well. Some of the highlights of the 2D DDX are: - Dual Display Clone support, although no MergedFB - it could be done now tho' - ARGB cursor support (requires updated AGPgart - patches sent to Dave Jones) - Lid status checking (good for laptops) - Some fixes to Xvideo limits checking. Alan, I haven't gotten a chance to look at the source, but does the new DDX support native mode switching? I would assume so since it now supports the second crtc, but perhaps that can be programmed by the bios as well. No, no native mode switching. The second pipe is handled by the BIOS. Alan. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Thread Local Storage libGL
I emailed Keith regarding this a while back and he had some concerns over the patches used, but I just wanted to bring to light both RedHat and now Mandrake are shipping with the TLS versions of libGL and cause the binary DRI packages to break. Is there someone looking to integrate the TLS patches for libGL ?? We should certainly take a look soon and comment upon the patches used. Alan. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
Attached is the patches from redhat source tree which are based on XFree86 4.3.0 for review. I think this code hits a lot of stuff that Ian has been working on, so it'd be good if Ian has some comments. Alan. XFree86-4.3.0-redhat-libGL-opt-v2.patch.bz2 Description: BZip2 compressed data XFree86-4.3.0-redhat-libGL-TLS-buildfix.patch.bz2 Description: BZip2 compressed data
Re: Thread Local Storage libGL
On Fri, May 21, 2004 at 03:08:41PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: I emailed Keith regarding this a while back and he had some concerns over the patches used, but I just wanted to bring to light both RedHat and now Mandrake are shipping with the TLS versions of libGL and cause the binary DRI packages to break. Is there someone looking to integrate the TLS patches for libGL ?? We should certainly take a look soon and comment upon the patches used. I'd really like to get good support for modern TLS into our libGL. My big problem was that the patches were made against generated files and had rapidly become out-of-date. O.k. I'll try and muster up a patch for people to review and post it here. Alan. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Mesa (DRI) CVS is broken in drivers/x11/xm_api.c
Thanks Dieter, I'll fix that up asap as soon as CVS is working again on pdx. Alan. On Mon, Apr 26, 2004 at 02:09:57PM +0200, Dieter Nützel wrote: gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl -I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include drivers/x11/xm_api.c -o drivers/x11/xm_api.o drivers/x11/xm_api.c: In function `setup_grayscale': drivers/x11/xm_api.c:797: error: `DitherValues' undeclared (first use in this function) drivers/x11/xm_api.c:797: error: (Each undeclared identifier is reported only once drivers/x11/xm_api.c:797: error: for each function it appears in.) make[4]: *** [drivers/x11/xm_api.o] Fehler 1 make[4]: Leaving directory `/opt/Mesa/src/mesa' make[3]: *** [default] Fehler 2 make[3]: Leaving directory `/opt/Mesa/src/mesa' make[2]: *** [subdirs] Fehler 1 make[2]: Leaving directory `/opt/Mesa/src' make[1]: *** [default] Fehler 1 make[1]: Leaving directory `/opt/Mesa' make: *** [linux-x86] Fehler 2 72.989u 5.325s 1:18.89 99.2%0+0k 0+0io 0pf+0w /opt/Mesa grep -r DitherValues src/ src/mesa/drivers/x11/xm_api.c: (void) DitherValues; /* Muffle compiler */ -Dieter --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Sun, Apr 18, 2004 at 01:33:41PM +0200, Michel Dänzer wrote: On Sun, 2004-04-18 at 04:19, Donnie Berkholz wrote: On Sat, 2004-04-17 at 07:54, Alan Hourihane wrote: On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dänzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. I'm pretty sure the autoconfig work, under the X-Oz license (nearly identical to the problematic one), was in at that point. Right, that's what I was thinking of. Mmmm, things hotted up after the 4.3.99.902 release, but your right the file xf86AutoConfig.c does have the new license in that release. So that means dropping back to 4.3.99.901 or just let the individuals merge in DDX changes of their own accord, which may be the simpler approach. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dänzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. and closer to what X.Org went with for now. That will bring us closer to both trees. And then we can delay a decision until things have settled on both sides of the pond, and see where the land lies. Assuming it's really clear, I'm fine with your proposal, although I don't see XFree86 suddenly changing their mind... I'm not talking about them changing their mind, just on how things are panning out. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Thu, Apr 15, 2004 at 08:13:53AM -0700, Alex Deucher wrote: Speaking of merging, what are everyone's thoughts on merging the DDX trees (drivers at least, I don't know about the rest, especially with the licensing)? I was thinking mostly DRI-xfree86 but I suppose we could look at gatos too. Specifically the radeon driver has some new fixes in the xfree86 tree and there is MergedFB and IGP 3D support in the DRI tree. There are probably some things in other drivers that could go both ways as well. Thoughts? I could merge in XFree86 4.3.99.902 which is before the license change and closer to what X.Org went with for now. That will bring us closer to both trees. And then we can delay a decision until things have settled on both sides of the pond, and see where the land lies. What do people think of that? Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Changes in client's single2.c. Is the reporterd server fix in?
On Thu, Apr 08, 2004 at 06:22:15PM +0200, Dieter Nützel wrote:
dri-trunk/xc diff -ur xc/programs/Xserver/GL/glx/single2.c
xc/programs/Xserver/GL/glx/single2.c.orig
--- xc/programs/Xserver/GL/glx/single2.c2004-03-04 23:01:25.0
+0100
+++ xc/programs/Xserver/GL/glx/single2.c.orig 2004-04-08 18:19:38.936761159
+0200
@@ -344,7 +344,7 @@
if ( xf86atof( string ) xf86atof( GLServerVersion ) ) {
buf = __glXMalloc( __glXStrlen( string )
+ __glXStrlen( GLServerVersion )
- + 4 );
+ + 3 );
if ( buf == NULL ) {
string = GLServerVersion;
}
Just committed.
Alan.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage drm build problem
There are problems building the savage driver on systems that pass 5 args into remap_page_range(). Looking at that function, isn't it best to follow suit with how the i810 and i830 do this ? Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage drm build problem
On Fri, Apr 09, 2004 at 12:38:07AM +0100, Dave Airlie wrote: BTW, I'm going to start working on the DRM driver soon. I'm not sure where to make my changes, in the xc module or in the new drm module. Has the transition been formally completed? I havn't heard anything definite yet. But apperently some people are already committing stuff in the new place. the DRM now lives in the drm module, I don't know if anyone has commited the patches from Jon Smirl that he sent to the list to switch over the trees, if no-one has I vote someone does ASAP... Done. Let me know of any problems, but I'm doing a full checkout again now. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, Mar 17, 2004 at 09:14:52AM +, Keith Whitwell wrote: Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch Checkout still fails: [EMAIL PROTECTED] xc-trunk]$ cvs checkout drm cvs checkout: Updating drm cvs checkout: Updating drm/bsd U drm/bsd/Imakefile U drm/bsd/Makefile.bsd U drm/bsd/ati_pcigart.h U drm/bsd/drmP.h U drm/bsd/drm_agpsupport.h U drm/bsd/drm_auth.h U drm/bsd/drm_bufs.h U drm/bsd/drm_context.h U drm/bsd/drm_dma.h U drm/bsd/drm_drawable.h U drm/bsd/drm_drv.h U drm/bsd/drm_fops.h U drm/bsd/drm_ioctl.h U drm/bsd/drm_irq.h U drm/bsd/drm_lock.h U drm/bsd/drm_memory.h U drm/bsd/drm_memory_debug.h U drm/bsd/drm_os_freebsd.h U drm/bsd/drm_os_netbsd.h U drm/bsd/drm_pci.h U drm/bsd/drm_scatter.h U drm/bsd/drm_sysctl.h U drm/bsd/drm_vm.h U drm/bsd/mga_drv.c U drm/bsd/r128_drv.c U drm/bsd/radeon_drv.c U drm/bsd/sis_drv.c U drm/bsd/tdfx_drv.c cvs checkout: Updating drm/bsd/drm cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm' (/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/cvs/dri/drm/bsd/drm' cvs [checkout aborted]: read lock failed - giving up I tried to patch up the bsd build but I don't run bsd so could someone please check it. Give me feedback and I can adjust the drm directory structure or the patch. When everyone likes the new setup I will commit the patch. It will only take a minute to do the switch over, I'll recopy the drm CVS v files when switching to pick up any new checkins. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. Indeed Keith. I'd also like to mention that the Imakefile's or Makefile.linux/bsd will still need to be in some form in these three directories. xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel The reason being is that this new drm module is more than likely going to get imported into... xc/extras/drm and then symlinked into the original directories with the Imakefile during the XFree86 build process. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, Mar 17, 2004 at 09:07:12AM -0800, Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'd also like to mention that the Imakefile's or Makefile.linux/bsd will still need to be in some form in these three directories. xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel The reason being is that this new drm module is more than likely going to get imported into... xc/extras/drm and then symlinked into the original directories with the Imakefile during the XFree86 build process. Please don't do the individual file symlinking again. It makes the build process very fragile. For example if I add a new include file to the drm project individual symlinks will make me need to patch up the Imakefile file in all of the dri branches. Linking directories is ok. The changes I made to mesa impacted all of the dri branches because of the individual symlinks. The Mesa tree is external to the dri tree; dri branches do not insulate you from external changes. Directory symlinks are better at isolating things. With directory symlinks addition of a new file doesn't break things. Of course if we add a new directory things will break again. The best isolation is a single symlink to the top of the external tree and then use makefiles that are stored in the external tree. May I suggest you provide an Imakefile that does what your suggesting ? Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of XFree86 4.4.0 integration?
On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter Nützel wrote: Someone preparing a merge? Possibly, for the binary packages we need to include the LICENSE documents. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of XFree86 4.4.0 integration?
On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote: On Mon, Mar 01, 2004 at 02:15:13PM +, Alan Hourihane wrote: On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter Nützel wrote: Someone preparing a merge? Possibly, for the binary packages we need to include the LICENSE documents. Including the LICENSE documents is, strictly speaking, required by many of the other licenses too. Even the old style MIT licence that you use for your trident driver says: ... and that both that copyright notice and this permission notice appear in supporting documentation. Right, and so we need to fix these things up. Felix, Can you add the LICENSE file to the binary packages ? Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Status of XFree86 4.4.0 integration?
On Mon, Mar 01, 2004 at 10:26:58PM +0100, Felix Kühling wrote: On Mon, 1 Mar 2004 19:29:45 + Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote: On Mon, Mar 01, 2004 at 02:15:13PM +, Alan Hourihane wrote: On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter Nützel wrote: Someone preparing a merge? Possibly, for the binary packages we need to include the LICENSE documents. Including the LICENSE documents is, strictly speaking, required by many of the other licenses too. Even the old style MIT licence that you use for your trident driver says: ... and that both that copyright notice and this permission notice appear in supporting documentation. Right, and so we need to fix these things up. Felix, Can you add the LICENSE file to the binary packages ? Sure. I assume you mean programs/Xserver/hw/xfree86/doc/LICENSE? Yup. Thanks. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage driver in DRI/MESA cvs: Compile problem with gcc-2.95.4
On Tue, Feb 24, 2004 at 03:29:01PM +0100, Martijn Uffing wrote: Ave people DRI/MESA won't compile with gcc 2.95.4 My system is debian stable with gcc 2.95.4 as system compiler. I get the error only with 2.95.4. If I use gcc 3.3.3 the whole buildtree compiles fine. I get the exact same error (and no error with gcc 3.3.3) on the savage-2-0-0 branch . The buildtree is DRI CVS with MESA CVS and both were updated minutes ago. The error is in the file DRI-CVS/xc/programs/Xserver/hw/xfree86/drivers/savage/savage_accel Part of buildlog: savage_accel.c: In function `SavageInitAccel': savage_accel.c:1391: parse error before `int' savage_accel.c:1395: `scanlines' undeclared (first use in this function) savage_accel.c:1395: (Each undeclared identifier is reported only once savage_accel.c:1395: for each function it appears in.) make[6]: *** [savage_accel.o] Error 1 Thanks for the report, I've just checked in the fix. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage driver in DRI/MESA cvs: Compile problem with gcc-2.95.4
On Tue, Feb 24, 2004 at 05:57:34PM +, Sérgio Monteiro Basto wrote: On Tue, 2004-02-24 at 14:40, Alan Hourihane wrote: On Tue, Feb 24, 2004 at 03:29:01PM +0100, Martijn Uffing wrote: Ave people DRI/MESA won't compile with gcc 2.95.4 My system is debian stable with gcc 2.95.4 as system compiler. I get the error only with 2.95.4. If I use gcc 3.3.3 the whole buildtree compiles fine. I get the exact same error (and no error with gcc 3.3.3) on the savage-2-0-0 branch . The buildtree is DRI CVS with MESA CVS and both were updated minutes ago. Thanks for the report, I've just checked in the fix. I update savage-2-0-0 branch minutes ago and with gcc 3.3.x now give me a bunch of warnings! yesterday I almost sure that I haven't so many warnings How can I know? what has been updated since yesterday ? Use cvs's -D yesterday and see what changed. Other than that. Post your warning messages and let's take a look, as I've not currently get gcc 3.3.x installed. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage driver in DRI/MESA cvs: Compile problem with gcc-2.95.4
On Tue, Feb 24, 2004 at 06:09:06PM +, Sérgio Monteiro Basto wrote: On Tue, 2004-02-24 at 14:40, Alan Hourihane wrote: Thanks for the report, I've just checked in the fix. Alan. Now DRI/MESA won't compile with gcc 3.3 the output of make World have 3 megas bytes ! mapr.c:56: warning: ISO C90 does not support `long long' mmapr.c: In function `main': mmapr.c:226: warning: ISO C90 does not support `long long' mmapw.c:56: warning: ISO C90 does not support `long long' mmapw.c: In function `main': mmapw.c:97: warning: ISO C90 does not support `long long' mmapw.c:194: warning: ISO C90 does not support `long long' mmapw.c:195: warning: ISO C90 does not support `long long' macro in not recognized -- ignoring xdriinfo.c: In function `main': xdriinfo.c:60: warning: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness xdriinfo.c:61: warning: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness This has nothing to do with the change I checked in. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage-2-0-0 test notes
On Tue, Feb 24, 2004 at 02:01:39PM -0700, Brian Paul wrote: Felix Kühling wrote: On Tue, 24 Feb 2004 19:33:16 +0100 Felix Kühling [EMAIL PROTECTED] wrote: On Tue, 24 Feb 2004 09:56:29 -0700 Brian Paul [EMAIL PROTECTED] wrote: Gregory Davis wrote: [snip] Greg Davis In the savage driver, after the calls to _swrast_allow_pixel/vertex_fog(), put in corresponding calls to _tnl_allow_pixel/vertex_fog() and see what happens. I just tried this. Now there is no fog at all in tuxracer. But fog looks ok in flightgear now. So this fix is ok but there's probably another problem with fog in tuxracer. With Mesa 5.0 (on the savage-2-0-0-branch) fog was ok in tuxracer too. I don't have tuxracer handy - I'll have to download it later. Do you happen to know which fog mode is used, and if the GL_FOG_HINT is set? Brian, It uses NICEST. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
Felix, How about dropping your current DRI savage driver into the Mesa trunk (6.1) and whipping the driver into shape with the current DRI trunk. I think that will serve you best, in that Mesa 5.x is obviously being left behind now, and if you hit problems they may be bugs in 5.x your hitting. I'm going to bring my T20 up-to-speed to see if I can help with this at some point, but it'd be good to get it into the Mesa 6 trunk code first. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, Feb 20, 2004 at 05:30:57PM +0100, Felix Kühling wrote: On Fri, 20 Feb 2004 14:55:55 + Alan Hourihane [EMAIL PROTECTED] wrote: Felix, How about dropping your current DRI savage driver into the Mesa trunk (6.1) and whipping the driver into shape with the current DRI trunk. Are you suggesting to continue development on DRI trunk or make a new branch from the current DRI trunk? The latter is what just happened with mach64. I'd do the same with savage. Either way, seeing as the driver would be in the Mesa trunk, DRI branches don't seem to make much sense anymore to me, unless it's for work on GLX like the work Ian's doing. The whole point of DRI branches before was to isolate new driver work, but the Mesa trunk works in the opposite direction - i.e. new work being on the trunk. I think that will serve you best, in that Mesa 5.x is obviously being left behind now, and if you hit problems they may be bugs in 5.x your hitting. I'm going to bring my T20 up-to-speed to see if I can help with this at some point, but it'd be good to get it into the Mesa 6 trunk code first. Ok. That's fine with me. If Brian agrees I could make the move over the weekend. O.k. But I doubt Brian would disagree. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56alloc_id438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage 3D driver roadmap
On Fri, Feb 20, 2004 at 10:45:54PM +, Dave Airlie wrote: mach64. I'd do the same with savage. Either way, seeing as the driver would be in the Mesa trunk, DRI branches don't seem to make much sense anymore to me, unless it's for work on GLX like the work Ian's doing. The whole point of DRI branches before was to isolate new driver work, but the Mesa trunk works in the opposite direction - i.e. new work being on the trunk. the main reason mach64 is still on a branch in DRI is it is insecure by default, I'm going to look into it when I've moved apartments and got myself settled in again :-), I don't think putting insecure code into the trunk where it may get merged up to XFree86 is such a good idea :-) Forgetting the DRI for a second Dave. The mach64 code is in the trunk of Mesa. What's stopping someone using that with the miniGLX stuff (with a few fixups) and not knowing about the security issues. All I'm saying is the mach64 code is much more visible now being on the trunk in Mesa, than it used to be in a branch off the DRI. I don't think the savage would be any worse off. Plus, I also think it'd get more testing and more people might know of it's existence to help out. Heck, we can always tell XFree86 to not merge that code because it is insecure. But there are always those who don't care about security and just need accelerated 3D. Alan. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI broken
On Thu, Feb 05, 2004 at 08:59:44AM +1100, Daniel Stone wrote: On Wed, Feb 04, 2004 at 05:03:15PM +, Alan Hourihane wrote: Either cvs updating or committing to the DRI on freedesktop.org is broken again. Can you fix it Daniel, seeing as Eric is away ? cvs update: Updating . cvs update: failed to create lock directory for `/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers' (/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository `/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers' cvs [update aborted]: read lock failed - giving up Sure, done. Have you done it ? As I've just tried now and I still get the same problem. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI broken
On Thu, Feb 05, 2004 at 09:26:44AM +1100, Daniel Stone wrote: On Wed, Feb 04, 2004 at 10:21:47PM +, Alan Hourihane wrote: On Thu, Feb 05, 2004 at 09:18:47AM +1100, Daniel Stone wrote: Hmm, you're not in the DRI group. Should you be? Yes, and I don't know how I fell out of it. Added back. I think the problem was that when someone else removed all the groups in /etc/groups, they didn't synchronise it with LDAP properly. O.k. Thanks Daniel. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI broken
Either cvs updating or committing to the DRI on freedesktop.org is broken again. Can you fix it Daniel, seeing as Eric is away ? cvs update: Updating . cvs update: failed to create lock directory for `/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers' (/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository `/cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers' cvs [update aborted]: read lock failed - giving up Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 new revolutionary lighting
On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dänzer wrote: About keeping track of your patches: I wonder what others think about giving you write access? Go for it. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 new revolutionary lighting
On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel Dänzer wrote: On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote: On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dänzer wrote: About keeping track of your patches: I wonder what others think about giving you write access? Go for it. I would, but I can't. Maybe Eric can do it, but I think there should be others with Eric's access ability so these others can do it too. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Moving the configs pointer in __GLXscreenConfigsRec (was Re: CVS Update: xc (branch: trunk))
On Wed, Jan 28, 2004 at 03:05:35PM -0800, Ian Romanick wrote: Alan Hourihane wrote: Log message: restore backwards compatibility Modified files: xc/xc/lib/GL/glx/: glxclient.h Was there an actual breakage? The __GLXscreenConfigsRec isn't supposed to be used by anything outside libGL. The location of driScreen shouldn't matter as the driver is given a pointer to that field by libGL. Forgot to mention. That the call to __driUtilCreateScreen() in all of the 3D drivers then pull in a bunch of code from lib/GL/dri and just happens to pull in the code that does the visual matching. So in XFree86 4.3.0 the radeon_dri.so contained the function __driFindGlxConfig() and referenced GLXscreenConfigs directly. libGL hardly references any code in the lib/GL/dri directory at all. The same goes for current versions of the 3D drivers and that they still pull in a lot of the dri_util.c code and reference it inside itself rather than leaving it to libGL to sort out. To sort this mess out, there'll probably need to be function tables passed between the 3D driver and libGL. Obviously libGL wants the __DriverAPIRec and the 3D driver wants a list of dri* functions (probably with versioning). This way libGL should contain the dri* functions and the 3D driver wouldn't. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Moving the configs pointer in __GLXscreenConfigsRec (was Re: CVS Update: xc (branch: trunk))
On Wed, Jan 28, 2004 at 03:05:35PM -0800, Ian Romanick wrote: Alan Hourihane wrote: Log message: restore backwards compatibility Modified files: xc/xc/lib/GL/glx/: glxclient.h Was there an actual breakage? The __GLXscreenConfigsRec isn't supposed to be used by anything outside libGL. The location of driScreen shouldn't matter as the driver is given a pointer to that field by libGL. Yes, there was an actual breakage. The fact is that __driFindGlxConfig() when comparing visuals got completely bogus information to the requested visual because of this structure change. This function is in XFree86 4.3.0's libGL and references GLXscreenConfigs directly. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 09:44:31PM -0600, Otto Solares wrote: On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote: What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. Does this means that finally we will see XFree and linux-solo build it's drivers from Mesa-newtree/src/drivers/dri or this is not the case yet? That's the goal, but it's not working yet. Alan. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
