> > 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 us
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 drive
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 X
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 driver.. (I'm waiting
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 t
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
>
> 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
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
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 BS
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 i
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 properl
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
12 matches
Mail list logo
