On Mon, 2004-08-16 at 07:56, Dave Airlie wrote:
At the moment we are adding a lot of 2.6 stuff to the DRM under
development in the DRM CVS tree and what will be merged into the -mm and
Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
still work,
which is uglyfying the
On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
If we can manage to support FreeBSD and Linux from one codebase, surely
supporting 2.4 and 2.6 isn't too difficult?
It for sure is possible.
However the DRM codebase proves that it's incapable of even doing BSD
support properly
Arjan van de Ven wrote:
On Mon, 2004-08-16 at 07:56, Dave Airlie wrote:
At the moment we are adding a lot of 2.6 stuff to the DRM under
development in the DRM CVS tree and what will be merged into the -mm and
Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
still work,
which
Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
If we can manage to support FreeBSD and Linux from one codebase, surely
supporting 2.4 and 2.6 isn't too difficult?
It for sure is possible.
However the DRM codebase proves that it's incapable of even doing
On Mon, Aug 16, 2004 at 11:12:53AM +0100, Keith Whitwell wrote:
Most of the abstractions that you're complaining about existed prior to the
addition of freebsd support
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...
I'm currently open for constructive critics with ideas on how to fix these
things, the DRM is open for business if we can fix things up
On Mon, Aug 16, 2004 at 11:42:00AM +0100, Dave Airlie wrote:
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...
I'm currently open for constructive critics with ideas on how to fix
Dave Airlie wrote:
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...
Heh. I actually find those ones pretty innocuous and easy to work with,
compared to some of the stuff in there. Nothing
On Llu, 2004-08-16 at 08:11, Arjan van de Ven wrote:
I would strongly urge you to no longer update DRM in 2.4 in significant
ways. 2.4 is the release for doing strict maintenance; people who want
to run newer X will generally run 2.6 kernels as well anyway.
Then 2.4 users can't use the new
Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 12:42:51PM +0100, Keith Whitwell wrote:
Dave's hit the nail on the head here. If you'd like some changes, feel
free to make suggestions.
once the new intel DRM driver hits Linus' tree I want to start an experiment
to make it look like a linux
ways. 2.4 is the release for doing strict maintenance; people who want
to run newer X will generally run 2.6 kernels as well anyway.
Then 2.4 users can't use the new Xorg release fully. That would be
rather out of keeping with X policy.
Nope never said that, they won't be able to use the
Brian Paul wrote:
At this point, given that the X.Org tree is still monolithic, our Mesa
usage is somewhat independent of Mesa releases in my view. I chose to
integrate the development branch because of the great advances made in
the DRI drivers in general (though we have some issues to resolve
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 available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
Philipp Klaus Krause wrote:
Since the driver supports GL_NV_texture_retangle,
GL_EXT_texture_retangle and probably soon will GL_ARB_texture_retangle
I wonder why GL_ARB_texture_non_power_of_two isn't supported.
AFAIK, R200 (and R100) can't do all of GL_ARB_texture_non_power_of_two.
That
Do we really need the DRM() macro around function names? With Linux the
only exported symbols are the ones marked with EXPORT_SYMBOL. Is this a
work around for another OS to stop symbol conflicts when the OS exports
all symbols?
=
Jon Smirl
[EMAIL PROTECTED]
Jon Smirl wrote:
Do we really need the DRM() macro around function names? With Linux the
only exported symbols are the ones marked with EXPORT_SYMBOL. Is this a
work around for another OS to stop symbol conflicts when the OS exports
all symbols?
Is that even the case if multiple DRM drivers are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 16 August 2004 16:29, Ian Romanick wrote:
Philipp Klaus Krause wrote:
Since the driver supports GL_NV_texture_retangle,
GL_EXT_texture_retangle and probably soon will GL_ARB_texture_retangle
I wonder why
On Mon, Aug 16, 2004 at 01:39:20PM -0700, Ian Romanick wrote:
Jon Smirl wrote:
Do we really need the DRM() macro around function names? With Linux the
only exported symbols are the ones marked with EXPORT_SYMBOL. Is this a
work around for another OS to stop symbol conflicts when the OS
18 matches
Mail list logo
