[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#568168: xserver-xorg-video-nouveau needs nouveau bits from libdrm



On 2010-03-24 02:53 +0100, Cyril Brulebois wrote:

> Sven Joachim <svenjoac@gmx.de> (23/03/2010):
>> I have some good news, since (after fixing #568162) I indeed managed
>> to build a working package.  At least X has been running for about
>> two hours which is a promising start. :-)
>
> I'd like to echo Julien's thanks. BTW: Do you plan to maintain nouveau
> on a regular basis or is that just a one-time shot?

Well, I have not quite made up my mind about it, which you can probably
understand when I tell you that Wednesday was the first time I have ever
_used_ nouveau.  My overall impression is quite good, but there are some
things that are mid-term obstacles:

- I like to run upstream kernels and do in general not use or even
  install Debian kernels.  While I will test the latest sid kernel in
  the next days, my primary kernel for the next 2-3 months will be
  2.6.33.x.  And then…

- …The recent big ABI break in libdrm 2.4.18 (to be reverted in the
  Debian 2.4.18-4 version) and Linux 2.6.34 make it impossible¹ to run
  anything newer than 2.6.33 with the xserver-xorg-video-nouveau package
  that's intended for Squeeze.  Being stuck with an unsupported 2.6.33
  or the Debian 2.6.32 kernel for the next 9-12 months is not a very
  appealing prospect to me.

> I'm currently
> wondering whether to order some hardware to make sure I have some
> boards to reproduce user-reported issues, and to check for regressions
> when packaging new versions, but I might skip nvidia stuff if you're
> going to work on it. :)

I will happily test new versions, as long as they work with a kernel
that is supported upstream, including -rcx kernels with x >= 2.  Which
means that there needs to be a libdrm version in experimental that works
with 2.6.34 (or 2.6.35-rcx) when 2.6.33 support ends upstream.  I would
be happy to help packaging that, too.

As far as the current nouveau version is concerned, I cannot support it
until the Squeeze release, much less beyond that.  It is also going to
break on partial upgrades, as the only kernel that is going to work with
it is the Debian Squeeze kernel.  IMO it still belongs in experimental
because of the reckless ABI breaks, despite Fedora and Ubuntu releasing
with it.

The only remedy for that would be if the Debian kernel team could pull
nouveau drm from 2.6.34 rather than 2.6.33.  They are probably not going
to do that, but I'd have a good argument for it.  The 2.6.33 nouveau
module needs non-free firmware blobs called ctxprogs to initialize the
GPU.  It works without them, but there won't be any acceleration then.
In 2.6.34, the driver has code to do that itself, so the firmware is no
longer necessary.

Of course, as long as nouveau is in staging, there is no guarantee that
there won't be another flag day that requires users to upgrade the
kernel, libdrm, mesa and what not in lock-step.

>> I think I don't want to trample over any of your existing branches
>> yet, so I would prefer to use a new branch, or publish my work on my
>> joachim-guest account on Alioth where you can pull from at your
>> leisure.
>
> Feel free to publish it there as a first step, so that other folks can
> have a look at it. :)

Available here:

git://git.debian.org/users/joachim-guest/xserver-xorg-video-nouveau.git
http://git.debian.org/?p=users/joachim-guest/xserver-xorg-video-nouveau.git

Cheers,
       Sven


¹ http://lwn.net/Articles/377953/

-- 
I think the real problem was that Fedora and the Neauveu community are
acting incredibly selfishly.  They only care about their narrow point
of view, and don't care about the pain they are inflicting on the
kernel development process and other kernel developers.  This is
_legal_.  It is, however, anti-social.  -- Theodore Ts'o



Reply to: