Re: DRI2 + buffer creation

[Alan Hourihane]

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

[Alan Hourihane]

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 
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']

[Alan Hourihane]

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'

[Alan Hourihane]

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: Changes to 'libdrm-2_3-branch'

[Alan Hourihane]

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 modesetting & sysfs

[Alan Hourihane]

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 modesetting & sysfs

[Alan Hourihane]

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: Branch 'master'

[Alan Hourihane]

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

[Alan Hourihane]

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: Merging DRI changes

[Alan Hourihane]

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: Latest on modesetting

[Alan Hourihane]

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.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Latest on modesetting

[Alan Hourihane]

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.php&p=sourceforge&CID=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"]

[Alan Hourihane]

On Wed, 2007-02-28 at 10:55 +0100, Michel Dänzer wrote:
> On Sun, 2007-02-25 at 19:35 +0000, 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.php&p=sourceforge&CID=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"

[Alan Hourihane]

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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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

[Alan Hourihane]

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: 
>  [] :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:[]  [] 
> :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:
>  [] :drm:drm_get_dev+0x2c2/0x4d9
>  [] pci_device_probe+0xdd/0x142
>  [] driver_probe_device+0x52/0xa8
>  [] __driver_attach+0x6b/0xa9
>  [] bus_for_each_dev+0x43/0x6e
>  [] bus_add_driver+0x73/0x10f
>  [] :i915:__this_module+0x0/0xcec7
> DWARF2 unwinder stuck at __this_module+0x0/0xcec7 [i915]
> Leftover inexact backtrace:
>  [] __pci_register_driver+0x57/0x7d
>  [] :drm:drm_init+0xc5/0x141
>  [] sys_init_module+0x15ed/0x1727
>  [] 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  [] :drm:drm_lastclose+0xc9/0x332
>  RSP 
> 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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: intel DRI driver crash

[Alan Hourihane]

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

[Alan Hourihane]

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

[Alan Hourihane]

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: _glapi_add_dispatch

[Alan Hourihane]

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: Enabling Direct Rendering at CVS tip

[Alan Hourihane]

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=lnk&kid=103432&bid=230486&dat=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

[Alan Hourihane]

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=lnk&kid=103432&bid=230486&dat=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

[Alan Hourihane]

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=lnk&kid=103432&bid=230486&dat=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

[Alan Hourihane]

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=lnk&kid=103432&bid=230486&dat=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

[Alan Hourihane]

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  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=lnk&kid=103432&bid=230486&dat=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=lnk&kid=103432&bid=230486&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Front buffer & rotation

[Alan Hourihane]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: DRM & MTRR's

[Alan Hourihane]

On Fri, 2005-09-23 at 22:07 +0800, Antonino A. Daplas wrote:
> 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)
> 
> I don't know the repercussions of defaulting to nomtrr. But I would
> surmise that a large percentage of users gives more importance to X/DRI
> performance than console performance (majority of vesafb users still
> use redraw for scrolling where ypan is magnitudes faster, so I'm pretty
> sure defaulting vesafb to nomtrr will not be noticeable to most users,
> they probably go straight to X anyway :-)
> 
> I cannot decide on this alone, so I'm going to CC the fbdev-devel list.
> Perhaps I can submit a patch that defaults all drivers to nomtrr and a
> big warning about mtrr not being set in dmesg. If I don't get any
> backlash for a few patch cycles, I can make this permanent.

Tony,

What was the outcome of this in kernel land ??

Just to give you an idea of why it really causes problems.

If you are using vesafb and it sets up it's own mtrr for usually the
first 4MB of the framebuffer. Now, X will fail to set it's MTRR. And
thus the first 4MB remains write-combined.

Running the isosurf benchmark from Mesa, shows only 300fps. Yet, doing
echo "disable=3" > /proc/mtrr to remove that vesafb mtrr and allows X to
setup the full range results in isosurf jumping to 650fps.

Defaulting vesafb (and the others) to nomtrr which save us this pain.

Alan.


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: DRM & MTRR's

[Alan Hourihane]

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: DRM & MTRR's

[Alan Hourihane]

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

[Alan Hourihane]

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

[Alan Hourihane]

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

DRM & MTRR's

[Alan Hourihane]

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: problem with intel 830M board Display driver

[Alan Hourihane]

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: UniChrome DRI bug and fix

[Alan Hourihane]

On Mon, 2005-08-29 at 17:02 +0200, Litvinov Vadim Antonovich wrote:
> Hello all,
>I have found a bug in current Mesa CVS. viaRegion structure in via_dri.h 
> is 
> not the same in Mesa unichrome driver and via driver in X.org CVS. As a 
> result we have an error when trying to use an OpenGL program and Mesa falls 
> back to indirect rendering.
>   I include a patch that correct the problem.

Committed. Thanks.

Alan.


---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Fixes to make DRI Device Info data machine size independent

[Alan Hourihane]

On Fri, 2005-07-15 at 13:10 +0200, Egbert Eich wrote:
> The Mesa patch below helps to make the data passed between 
> the Xserver and an DRI client in the GetDeviceInfo request of
> the DRI extension independ of the machine size - a prerequisite 
> to support mixing of 32 and 64bit DRI clients.
> 
> The patch eliminates the need to use of drmAddress in these 
> structures.
> drmAddress is unsigned long and therefore machine size dependent.
> 
> Furthermore it fixes a bug in the MGA DRI module which makes the
> assumption that a 'handle' is a base address of a mapped area.
> Appearantly the affected code is not used any more with the latest
> versions of DRM.
> 
> Like the patches to libdrm none of these fixes should raise any
> compatibility issues.
> I suggest to postpone the changes which eliminate drmAddress from
> these structures and make drm_handle_t unsigned int until all 
> other things are in place and do them all at once as they will 
> change the ABI between the Xserver and DRI clients.

Egbert,

The only thing I think that's missing from this is bumping the ddx
version and the check in the Mesa driver to signify this change.

I've already done the i810 (DDX) and i915 (Mesa) driver, so I'll commit
this if you can modify the patch below to bump the version according to
your change in the DDX as well.

Thanks,

Alan.



---
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
--
___
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?

[Alan Hourihane]

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

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ioctl32 on amd64

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: sysfs_remove_dir bug?

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 915 DRM PM

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: CVS Update: drm (branch: trunk)

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: CVS Update: drm (branch: trunk)

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: sysfs_remove_dir bug?

[Alan Hourihane]

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:[]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:
> > [] kobject_del+0x10/0x20
> > [] kobject_unregister+0x20/0x30
> > [] drm_takedown+0x34d/0x3f0 [drm]
> > [] drm_fasync+0x48/0x90 [drm]
> > [] drm_release+0x3d5/0x540 [drm]
> > [] drm_version+0x0/0xa0 [drm]
> > [] drm_ioctl+0x1c3/0x23c [drm]
> > [] udf_create+0x30/0x1b0
> > [] drm_version+0x0/0xa0 [drm]
> > [] udf_create+0x30/0x1b0
> > [] do_ioctl+0x77/0xb0
> > [] __fput+0x16a/0x1b0
> > [] filp_close+0x52/0xa0
> > [] sys_close+0x58/0xa0
> > [] 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=7477&alloc_id=16492&op=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_idt77&alloc_id492&op=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_idt77&alloc_id492&op=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

[Alan Hourihane]

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=7477&alloc_id=16492&op=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

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: snapshot 20050610 [i810]

[Alan Hourihane]

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=7477&alloc_id=16492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: agp mode and egl

[Alan Hourihane]

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

[Alan Hourihane]

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: drm_stub.c

[Alan Hourihane]

On Fri, May 27, 2005 at 11:10:29AM -0700, Ian Romanick wrote:
> 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 ?
> 
> It does still require it.  The PCI cards are not (yet) supported.  The 
> whole reason I added the call to drm_device_is_agp in that place and 
> added the drm_driver::device_is_agp hook was so that the PCI G450 cards 
> (which are AGP cards with a universal PCI-to-PCI bridge) could be 
> detected and failed gracefully.

Then I guess the easy approach for now is adding this to the i810_drv.c,
i830_drv.c and i915_drv.c...

int XXX_driver_device_is_agp(drm_device_t * dev)
{
return 1;
}

And add this to the drm_driver structure

   .device_is_agp = XXX_driver_device_is_agp

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

[Alan Hourihane]

On Fri, May 27, 2005 at 06:58:08PM +0100, Alan Hourihane wrote:
> 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 ?

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;
   }

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

[Alan Hourihane]

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: [PATCH] add PCI ID for i945G chipset for i915 drm

[Alan Hourihane]

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=7412&alloc_id=16344&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: dri span patches...

[Alan Hourihane]

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=6595&alloc_id=14396&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Intel 915G lockup problem

[Alan Hourihane]

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

[Alan Hourihane]

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: i915 drm checkin...

[Alan Hourihane]

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: checking things into extras/drm

[Alan Hourihane]

On Sat, Jan 08, 2005 at 04:10:36AM +, Dave Airlie wrote:
> 
> Hi,
>   I've just noticed that Alan has checked some changes into
> extras/drm in the Xorg tree, I'm sure these are needed to build the latest
> drivers but I'm just wondering how we should approach these things in
> future?
 
The DRM isn't merged in at a regular rate, so I think it's right to
commit changes to imported code, especially if other code relies on the
changes.

> When we next import a DRM from the main tree will we have to much about
> with CVS admin to put things back on the vendor branch?
 
You shouldn't have to muck about with CVS admin. I don't understand
this. Using 'cvs import' and fixing conflicts should be fine.

> Dave.
> p.s. Alan can you check those changes into the main DRM repository you
> only got pieces of them so I can push them to Linus

There were some extra DPMS code in X.Org's DRM which I'm massaging into
the DRM trunk, but's it's not perfect yet because of the diverging code there.

But don't worry I'll get to it.

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

[Alan Hourihane]

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: Getting started

[Alan Hourihane]

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

[Alan Hourihane]

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

[Alan Hourihane]

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: DRI/Mesa CVS (XFree86) compilation error

[Alan Hourihane]

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

[Alan Hourihane]

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...

[Alan Hourihane]

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..

[Alan Hourihane]

On Thu, Jul 29, 2004 at 01:15:29PM +0100, Dave Airlie wrote:
> 
> >
> > Have you ported the required i915 AGP changes as well ??
> 
> well I've only got a i865 so I hopefully don't need any i915 specific
> stuff..

O.k. that makes sense. It wasn't clear from your original email.

Maybe Eric can shed some light on the needed changes, as I've not
done any FreeBSD work for a while.

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=4721&alloc_id=10040&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: i915 drm freebsd..

[Alan Hourihane]

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=4721&alloc_id=10040&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: i830 driver status..

[Alan Hourihane]

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=4721&alloc_id=10040&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Moving forward with the TLS work

[Alan Hourihane]

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

[Alan Hourihane]

On Fri, Jun 11, 2004 at 06:20:43PM +0100, Alan Cox wrote:
> On Iau, 2004-06-10 at 20:50, Alan Hourihane wrote:
> > 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.
> 
> Is the 915 driver code licensed under an Xorg compatible license and
> going to go into that tree as well ?

It will be going in - yes.

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

[Alan Hourihane]

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

Re: New i915 driver in cvs

[Alan Hourihane]

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: Thread Local Storage libGL

[Alan Hourihane]

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=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Thread Local Storage libGL

[Alan Hourihane]

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

Thread Local Storage libGL

[Alan Hourihane]

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=3149&alloc_id=8166&op=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

[Alan Hourihane]

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

[Alan Hourihane]

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_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI/Xfree86 Merge

[Alan Hourihane]

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_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI/Xfree86 Merge

[Alan Hourihane]

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=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Savage drm build problem

[Alan Hourihane]

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=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Savage drm build problem

[Alan Hourihane]

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=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM and LK ...

[Alan Hourihane]

On Thu, Apr 08, 2004 at 05:48:52PM +0200, Dieter Nützel wrote:
> Am Donnerstag, 8. April 2004 17:14 schrieb Michel Dänzer:
> > On Thu, 2004-04-08 at 16:32, Dieter Nützel wrote:
> > > Am Donnerstag, 8. April 2004 15:13 schrieb Dave Airlie:
> > > > our DRM is now synced with changes in 2.6 that we don't have, now to
> > > > try and get a patch or maybe a bk repo going the other way...
> >
> > Thanks for working on this Dave.
> >
> > > Apr  7 17:39:53 SunWave1 kernel: radeon: no version for "struct_module"
> > > found: kernel tainted.
> > > Apr  7 17:39:53 SunWave1 kernel: radeon: no version magic, tainting
> > > kernel.
> >
> > IIRC this happens when you insmod radeon.o instead of radeon.ko .
> 
> Sorry, no.
> 
> -rw-r--r--1 root root   146092 2004-04-04 
> 13:59 /lib/modules/2.6.4-44.9-smp/kernel/drivers/char/drm/radeon.ko
> 
> This is the DRI CVS version.
> Copied from radeon.o to radeon.ko

You should not be copying radeon.o to radeon.ko.

When you build the kernel modules on a 2.6 system the Makefile.linux
will generate the correct radeon.ko file.

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_id70&alloc_id638&op=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?

[Alan Hourihane]

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_id70&alloc_id638&op=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

[Alan Hourihane]

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=1470&alloc_id=3638&op=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

[Alan Hourihane]

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=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI-/Mesa-CVS is totally broken after Mesa "update"

[Alan Hourihane]

It doesn't build Jon, because drm.h is being pulled from the shared
directory in the DRI tree first and not the Mesa tree.

Alan.

On Fri, Mar 12, 2004 at 09:01:25AM -0800, Jon Smirl wrote:
> I just pulled a clean tree and it built without problems.
> 
> --- Dieter Nützel <[EMAIL PROTECTED]> wrote:
> > MX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM   r200_context.c
> > In file included from r200_context.c:54:
> > r200_context.h:572: error: parse error before "drm_hw_lock_t"
> > r200_context.h:572: Warnung: no semicolon at end of struct or union
> > r200_context.h:575: error: parse error before '}' token
> > r200_context.h:575: Warnung: ISO C does not allow extra `;' outside of a 
> > functio
> > n
> > r200_context.h:862: error: field `dri' has incomplete type
> > In file included 
> > from ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/
> > radeon_dri.h:41,
> >  from r200_ioctl.h:42,
> >  from r200_context.c:55:
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:146:
> > 
> > e
> > rror: conflicting types for `RADEON_INIT_FULLSCREEN'
> >
> ../../../../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeo
> > n_drm.h:429: error: previous declaration of `RADEON_INIT_FULLSCREEN'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:146:
> > 
> > W
> > arnung: redundant redeclaration of `RADEON_INIT_FULLSCREEN' in same scope
> >
> ../../../../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeo
> > n_drm.h:429: Warnung: previous declaration of `RADEON_INIT_FULLSCREEN'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:148:
> > 
> > e
> > rror: conflicting types for `RADEON_CLEANUP_FULLSCREEN'
> >
> ../../../../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeo
> > n_drm.h:431: error: previous declaration of `RADEON_CLEANUP_FULLSCREEN'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:148:
> > 
> > W
> > arnung: redundant redeclaration of `RADEON_CLEANUP_FULLSCREEN' in same scope
> >
> ../../../../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeo
> > n_drm.h:431: Warnung: previous declaration of `RADEON_CLEANUP_FULLSCREEN'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:422:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_getparam'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:431:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_mem_alloc'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:438:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_mem_free'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:443:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_mem_init_heap'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:451:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_irq_emit'
> > ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h:455:
> > 
> > e
> > rror: redefinition of `struct drm_radeon_irq_wait'
> > make[6]: *** [r200_context.o] Fehler 1
> > 
> > [snip]
> > 
> > -Dieter
> > 
> > 
> > ---
> > 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=1470&alloc_id=3638&op=click
> > --
> > ___
> > Dri-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> 
> 
> =
> Jon Smirl
> [EMAIL PROTECTED]
> 
> __
> Do you Yahoo!?
> Yahoo! Search - Find what you’re looking for faster
> http://search.yahoo.com
> 
> 
> ---
> 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=1470&alloc_id=3638&op=click
> --
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel


---
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_id70&alloc_id638&op=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?

[Alan Hourihane]

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_id56&alloc_id438&op=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?

[Alan Hourihane]

On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote:
> On Mon, Mar 01, 2004 at 02:15:13PM +0000, 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_id56&alloc_id438&op=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?

[Alan Hourihane]

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_id56&alloc_id438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] savage-2-0-0 test notes

[Alan Hourihane]

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_id56&alloc_id438&op=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

[Alan Hourihane]

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_id56&alloc_id438&op=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

[Alan Hourihane]

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_id56&alloc_id438&op=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

[Alan Hourihane]

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=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Savage 3D driver roadmap

[Alan Hourihane]

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=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel