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?
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
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
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
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
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) Rename
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
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 access
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
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 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
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
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
13 matches
Mail list logo
