Dave Airlie <[EMAIL PROTECTED]> writes:
> can you insert the module with drm_opts=debug option and see what it
> says..
>
> can you also send on lspci -v and the contents of /proc/iomem
unfortunately my disk just died so i won't be able to do any testing
until ibm sends a new one. sorry.
--alex-
I've wrapped up Mesa 6.1. The CVS tree has been tagged with
'mesa_6_1' and the tarballs can be downloaded from the SourceForge site.
I'll leave it up to the DRI/X.org developers to pull this into the
upcoming X server release. There have been only minor changes over
the past week, I believe.
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 use
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 w
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 us
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 tha
I've just added vertex program support to the r200 driver.
It uses the software emulation Mesa provies, though the
hardware could do accelerated vertex programs.
I'll do some more testing of GL_ARB_vertex_program,
though I haven't seen any problems so far.
GL_NV_vertex_program is completely unteste
Dave Airlie wrote:
Okay take a look at
http://www.skynet.ie/~airlied/patches/dri/mtrr_removal.diff
This is how I intend dumping the __HAVE_ set of macros, I've just patched
the radeon in this patch.. any objections to this approach any neater ways
to do it?
That looks good. Having the bits explici
On Wed, Aug 18, 2004 at 01:10:56PM +0100, Dave Airlie wrote:
>
> >
> > A few points (based only on the diff).
> > 1) Rename CONFIG_MTRR to CONFIG_DRM_MTRR to provide better context
>
> well we are using the kernels CONFIG_MTRR so if the kernel has MTRR
> built-in we want to use it
Back home with
On 16 Aug 2004 18:30:00 -, Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> This is just a friendly reminder that the weekly dri-devel IRC meeting will
> be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
> 5:00PM EDT or 2:00PM PDT, if you prefer).
>
> Time zone conversion a
>
> A few points (based only on the diff).
> 1) Rename CONFIG_MTRR to CONFIG_DRM_MTRR to provide better context
well we are using the kernels CONFIG_MTRR so if the kernel has MTRR
built-in we want to use it .. so I've noticed it already supplies stubs
for mtrr_add/mtrr_del if it isn't built in so
>
> Okay take a look at
>
> http://www.skynet.ie/~airlied/patches/dri/mtrr_removal.diff
>
> This is how I intend dumping the __HAVE_ set of macros, I've just patched
> the radeon in this patch.. any objections to this approach any neater ways
> to do it?
A few points (based only on the diff).
1) R
> This does make it a lot clearer what's going on with those REALLY_ macros. I'm
> wondering if there are any of those capability bits that can be dropped
> because all or no drivers use them. Like CTX_BITMAP, for instance.
Yes CTX_BITMAP is what I'm looking at now.. it is the gamma that
causes
Dave Airlie wrote:
Okay take a look at
http://www.skynet.ie/~airlied/patches/dri/mtrr_removal.diff
This is how I intend dumping the __HAVE_ set of macros, I've just patched
the radeon in this patch.. any objections to this approach any neater ways
to do it?
Regards,
Dave.
This does make it a lot cl
Okay take a look at
http://www.skynet.ie/~airlied/patches/dri/mtrr_removal.diff
This is how I intend dumping the __HAVE_ set of macros, I've just patched
the radeon in this patch.. any objections to this approach any neater ways
to do it?
Regards,
Dave.
--
David Airlie, Software Engineer
http
can you insert the module with drm_opts=debug option and see what it
says..
can you also send on lspci -v and the contents of /proc/iomem
Dave.
> using the latest cvs (as of this morning) i get the following oops
> when loading the radeon module:
>
> kernel: mtrr: 0xe000,0x200 overlaps
Philipp Klaus Krause wrote:
How is functionality already implemented by Mesa added to a driver?
I want to try adding vertex program support to the r200 driver.
I took a look at the i915 driver to see what is done there. The
only things I could find where the added extensions in the extension
string
17 matches
Mail list logo
