Bug#568168: xserver-xorg-video-nouveau needs nouveau bits from libdrm
On 2010-03-28 16:36 +0200, Julien Cristau wrote:
> On Thu, Mar 25, 2010 at 16:17:00 +0100, Sven Joachim wrote:
>
>> 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.
>>
> That's only true for some chips (nv50 IIRC). You'd still need firmware
> for the rest.
I see. Loading external firmware is disabled by default in 2.6.34, it
requires the ctxfw module parameter.
>> 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.
>>
> From what I could see on the nouveau mailing list, it seemed pretty
> clear that there would be further ABI breaks. So going for 2.6.34 would
> mean shipping something that's not going to be supported by anyone
> for more than a few months either. I don't think it's a good plan.
Okay. The current combination is at least supported by Canonical,
although not by anyone else.
> On Thu, Mar 25, 2010 at 16:12:20 +0100, Sven Joachim wrote:
>
>> On 2010-03-24 09:20 +0100, Julien Cristau wrote:
>>
>> > I think I'd just apply the relevant parts of the ubuntu diff manually
>> > instead of doing it as a git merge. Hopefully that won't be too hard to
>> > extract, and that way we don't import the unrelated changes you mention.
>> > merge --squash and revert the changes we don't want before committing
>> > looks like would do that (I didn't know about merge --squash, thanks for
>> > the pointer!).
>>
>> I've done that, cherry-picking one of their commits (xsfbs update)
>> before squash-merging. What was left after reverting were basically
>
> We usually just merge from git.d.o:/git/pkg-xorg/xsfbs instead of
> applying the changes separately.
Thanks, I am not familiar with the X strike's conventions.
>> only changes to debian/control, I split these into several commits.
>> The results can be seen 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
I put a warning into that repository's description, since I intend to
redo some of the work in a better way.
>> There are some rough edges left:
>>
>> - We need something like Ubuntu's 01_include_snapshot_date patch to
>> ensure that NV_DRIVER_DATE is set to something meaningful when
>> building outside the Git repository. NV_DRIVER_DATE is only used to
>> print the driver date into Xorg's log file, so setting it to the empty
>> string is not the end of the world, but still not nice.
>>
> Well if people are using the package the snapshot date is not really
> informative, if we're going to be cherry-picking/reverting commits, so I
> think using the debian package version would be better here?
Maybe. Anyway, the only really important thing is to keep users from
wasting everybody's time by reporting bugs upstream instead of in
Debian, I think.
> (also WTF patching configure without the corresponding patch to
> configure.ac)
The decision to put the snapshot-date file into the upstream-ubuntu
branch is not exactly stellar either, I would like to keep this and
other generated files out of the upstream-experimental branch (undoing
the merge with the upstream-ubuntu branch).
> So I'd use something like this:
>
> diff --git a/configure.ac b/configure.ac
> index f5df8ad..cf6911e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -35,9 +35,6 @@ AC_DEFINE_UNQUOTED([NV_MINOR_VERSION],
> AC_DEFINE_UNQUOTED([NV_PATCHLEVEL],
> [$(echo $PACKAGE_VERSION | sed -e 's/^[[0-9]]*\.[[0-9]]*\.\([[0-9]]*\)/\1/')],
> [Patch version])
> -AC_DEFINE_UNQUOTED([NV_DRIVER_DATE],
> - [$(echo -n \";git log |head -3|tail -1|tr -d '\n';echo -n \")],
> - [Driver date])
>
> AC_CONFIG_SRCDIR([Makefile.am])
> AM_CONFIG_HEADER([config.h])
> diff --git a/debian/rules b/debian/rules
> index d7ad241..139b45d 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -25,6 +25,8 @@ endif
> # kbd_drv.a isn't phenomenally useful; kbd_drv.so more so
> confflags += --disable-static
>
> +CPPFLAGS = -DNV_DRIVER_DATE=\\\"$(SOURCE_VERSION)\\\"
> +
> get-orig-source:
> git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau && \
> cd xf86-video-nouveau && autoreconf -v --install && \
> @@ -41,7 +43,7 @@ build-stamp:
> cd obj-$(DEB_BUILD_GNU_TYPE) && \
> ../configure --prefix=/usr --mandir=\$${prefix}/share/man \
> --infodir=\$${prefix}/share/info $(confflags) \
> - CFLAGS="$(CFLAGS)"
> + CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)"
> cd obj-$(DEB_BUILD_GNU_TYPE) && $(MAKE)
> touch $@
>
ISTM this has the problem that the get-orig-source target will still run
the unpatched configure.ac, so that is necessary to re-run autoconf at
package build time. Maybe it is best to not include generated files in
the .orig.tar.gz at all?
>> - Shipping an upstream changelog would be useful (could probably be
>> achieved with a suitable invocation of "git log").
>>
> 'git log $upstream_commit > ChangeLog' should do just fine.
This might be a good thing to do in the get-orig-source target, I
suppose?
>> But overall, the package already works quite okay. I have yet to test
>> it with a Debian kernel, though (running self-compiled 2.6.33.1 ATM).
>>
> Cool, thanks.
Meanwhile I have tested a Debian kernel
(linux-image-2.6.32-4-amd64_2.6.32-10_i386.deb), and this one also works
fine with nouveau.
Sven
Reply to: