the code significantly if done wrong
So the question is do we want to a final stable DRM for 2.4 in the next
2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
tree (and maybe branch it ...),
I would strongly urge you to no longer update DRM in 2.4 in significant
ways. 2.4
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
is uglyfying the code significantly if done wrong
So the question is do we want to a final stable DRM for 2.4 in the next
2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
tree (and maybe branch it ...),
I would strongly urge you to no longer update DRM in 2.4
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
be able to patch it up nicely...
So the question is do we want to a final stable DRM for 2.4 in the next
2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
tree (and maybe branch it ...),
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied
12 matches
Mail list logo
