Linux 2.4.17-pre6 drm-4.0

Linux 2.4.17-pre6 drm-4.0

[Keith Owens]

On Fri, 7 Dec 2001 19:38:23 -0200 (BRST), 
Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>pre6:
>- direct render for some SiS cards		(Torsten Duwe/Alan Cox)

IA64 is still using the drm-4.0 code, as are the (possibly obsolete)
-ac kernels.  The drm 4.0 makefiles are a pain in the neck and I want
to get rid of them asap.  The SiS direct render is only for drm 4.1 so
now is a good time to question if 4.0 is still required.

How long do people plan to keep drm 4.0 code in their versions of the
kernel?

Re: Linux 2.4.17-pre6 drm-4.0

[Robert Love]

On Fri, 2001-12-07 at 18:20, Keith Owens wrote:

> How long do people plan to keep drm 4.0 code in their versions of the
> kernel?

For 2.5, there probably is no intention of keeping that around.  But can
we honestly ditch it in the middle of a stable kernel?  Personally I
don't use it, but its not polite ...

	Robert Love

Re: Linux 2.4.17-pre6 drm-4.0

[Keith Owens]

On 07 Dec 2001 18:27:11 -0500, 
Robert Love <rml@tech9.net> wrote:
>On Fri, 2001-12-07 at 18:20, Keith Owens wrote:
>
>> How long do people plan to keep drm 4.0 code in their versions of the
>> kernel?
>
>For 2.5, there probably is no intention of keeping that around.  But can
>we honestly ditch it in the middle of a stable kernel?  Personally I
>don't use it, but its not polite ...

Linus ditched drm 4.0 months ago.  It only survives in arch add on
patches like ia64 and in -ac trees.

Re: Linux 2.4.17-pre6 drm-4.0

[Robert Love]

On Fri, 2001-12-07 at 18:32, Keith Owens wrote:
> On 07 Dec 2001 18:27:11 -0500, Robert Love <rml@tech9.net> wrote:

> >For 2.5, there probably is no intention of keeping that around.  But can
> >we honestly ditch it in the middle of a stable kernel?  Personally I
> >don't use it, but its not polite ...

> Linus ditched drm 4.0 months ago.  It only survives in arch add on
> patches like ia64 and in -ac trees.

I know.  I meant we should continue to support the drm-4.0 package. 
It's the usual song ... we shouldn't change interfaces or required tools
in a stable series, and the least we can do is make 4.0 available
somehow, because someone may rely on it.

On the flip side, I don't care, and I suspect the people who actually
are using DRM are on 4.1 now.  Further, if _you_ are maintaining the
cruft and it bothers _you_, then stop :)

	Robert Love

Re: Linux 2.4.17-pre6 drm-4.0

[Barry K. Nathan]

> Linus ditched drm 4.0 months ago.  It only survives in arch add on
> patches like ia64 and in -ac trees.

No, it also survives as an add-on tarball for the standard kernel:
http://www.kernel.org/pub/linux/kernel/v2.4/drm-4.0.x.tar.bz2

Let me dig through my old mail so I can quote Linus on this... Here's
what he said in his Linux 2.4.8 announcement message (Subject
"Linux-2.4.8", sent on August 10th of this year):

> Ok, this one has various VM niceness tweaks that have made some people
> much happier. It also does a upgrade to the XFree86-4.1.x style DRM code,
> which means that people with XFree86-4.0.x can no longer use the built-in
> kernel DRM by default.
> 
> However, never fear. It's actually very easy to get the old DRM code too:
> if you used to use the standard kernel DRM and do not want to upgrade to a
> new XFree86 setup, just get the "drm-4.0.x" package from the same place
> you get the kernel from, and do
> 
>  - unpack the kernel
>  - cd linux/drivers/char
>  - unpack the "drm-4.0.x" package here
>  - mv drm new-drm
>  - mv drm-4.0.x drm
> 
> and you should be all set.

The impression I get (for 2.4) is that DRM 4.1 comes standard but you
should still be able to use 4.0 if you want, via that tarball.

-Barry K. Nathan <barryn@pobox.com>

Re: Linux 2.4.17-pre6 drm-4.0

[Eyal Lebedinsky]

Keith Owens wrote:
> 
> On 07 Dec 2001 18:27:11 -0500,
> Robert Love <rml@tech9.net> wrote:
> >On Fri, 2001-12-07 at 18:20, Keith Owens wrote:
> >
> >> How long do people plan to keep drm 4.0 code in their versions of the
> >> kernel?
> >
> >For 2.5, there probably is no intention of keeping that around.  But can
> >we honestly ditch it in the middle of a stable kernel?  Personally I
> >don't use it, but its not polite ...
> 
> Linus ditched drm 4.0 months ago.  It only survives in arch add on
> patches like ia64 and in -ac trees.

Well, I am on Debian stable, and the only Xfree4 contributed packages
are for 4.0.

I will move on to 4.1 when Debian moves on, but as you know they are
slower than a tired snail when it comes to new releases.

I wonder how many other people use these 4.0 packages off:

deb ftp://debian.cri74.org/debian-cri potato/contrib_luis_sismeiro main
non-free

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.anu.edu.au/eyal/>

Re: Linux 2.4.17-pre6 drm-4.0

[Alan Cox]

> > How long do people plan to keep drm 4.0 code in their versions of the
> > kernel?
> 
> For 2.5, there probably is no intention of keeping that around.  But can
> we honestly ditch it in the middle of a stable kernel?  Personally I
> don't use it, but its not polite ...

I said it shouldn't have been ditched, Linus overruled. 

Re: [Linux-ia64] Linux 2.4.17-pre6 drm-4.0

[David Mosberger]

>>>>> On Sat, 08 Dec 2001 10:20:10 +1100, Keith Owens <kaos@ocs.com.au> said:

  Keith> On Fri, 7 Dec 2001 19:38:23 -0200 (BRST), Marcelo Tosatti
  Keith> <marcelo@conectiva.com.br> wrote:
  >> pre6: - direct render for some SiS cards (Torsten Duwe/Alan Cox)

  Keith> IA64 is still using the drm-4.0 code, as are the (possibly
  Keith> obsolete) -ac kernels.  The drm 4.0 makefiles are a pain in
  Keith> the neck and I want to get rid of them asap.  The SiS direct
  Keith> render is only for drm 4.1 so now is a good time to question
  Keith> if 4.0 is still required.

  Keith> How long do people plan to keep drm 4.0 code in their
  Keith> versions of the kernel?

You mean for 2.5?  I don't think there is a good reason to keep
drm-4.0 there.  For 2.4, we should keep it because there might be
folks out there that rely on it.

	--david

Re: [Linux-ia64] Linux 2.4.17-pre6 drm-4.0

[Keith Owens]

On Fri, 7 Dec 2001 15:38:23 -0800, 
David Mosberger <davidm@hpl.hp.com> wrote:
>You mean for 2.5?  I don't think there is a good reason to keep
>drm-4.0 there.  For 2.4, we should keep it because there might be
>folks out there that rely on it.

Good.  I will drop drm 4.0 support from kbuild 2.5.

Re: Linux 2.4.17-pre6 drm-4.0

[Alan Cox]

> to get rid of them asap.  The SiS direct render is only for drm 4.1 so
> now is a good time to question if 4.0 is still required.

That argument doesnt fly. The 4.0 DRM is the only working GMX renderer..

Re: [Linux-ia64] Re: Linux 2.4.17-pre6 drm-4.0

[Christoph Hellwig]

On Sat, Dec 08, 2001 at 11:35:43AM +0000, Alan Cox wrote:
> > to get rid of them asap.  The SiS direct render is only for drm 4.1 so
> > now is a good time to question if 4.0 is still required.
> 
> That argument doesnt fly. The 4.0 DRM is the only working GMX renderer..

So what DRM can build out of tree easily - e.g. the Caldera LTP
(3.1 early access) had a DRM package built completly out of tree.

David, would you remove drm-4.0 from the ia64 patch if I'd do the work
again and package an up-to-date and ia64-capable drm 4.0 out-of-tree?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [Linux-ia64] Re: Linux 2.4.17-pre6 drm-4.0

[Alan Cox]

> So what DRM can build out of tree easily - e.g. the Caldera LTP
> (3.1 early access) had a DRM package built completly out of tree.

XFree86 4.0, 4.1, ... ship with the DRM kernel modules buildable from
the XFree86 tree too

Re: [Linux-ia64] Re: Linux 2.4.17-pre6 drm-4.0

[Christoph Hellwig]

On Sat, Dec 08, 2001 at 03:34:38PM +0000, Alan Cox wrote:
> > So what DRM can build out of tree easily - e.g. the Caldera LTP
> > (3.1 early access) had a DRM package built completly out of tree.
> 
> XFree86 4.0, 4.1, ... ship with the DRM kernel modules buildable from
> the XFree86 tree too

Been there, done that.

Having seen the XFree build process this doesn't look like an option to
me anymore.  Also a separate tarball easyfies building a new set of modules
for a new kernel a lot.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.