Dave Airlie wrote:
That would be fine with me... Dave, AlanH, has the moment arrived?
Okay I'll stick with chopping it, what the best way to go about it - will
I just let it break naturally (that'll take about 5 mins...) or will I
actively remove it?
Removing it would be cleaner, but either way's
> >
>
> That would be fine with me... Dave, AlanH, has the moment arrived?
Okay I'll stick with chopping it, what the best way to go about it - will
I just let it break naturally (that'll take about 5 mins...) or will I
actively remove it?
What about the kernel one, can I just mark it as broken?
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
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
>
> 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
13 matches
Mail list logo
