On Sun, Mar 28, 2010 at 19:25:43 +0200, Sven Joachim 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. > >> > On 2010-03-28 16:36 +0200, Julien Cristau wrote: > > > That's only true for some chips (nv50 IIRC). You'd still need firmware
nv40 actually. > > for the rest. > > I see. Loading external firmware is disabled by default in 2.6.34, it > requires the ctxfw module parameter. > This doesn't seem to have changed between .33 and .34 afaict? > 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). > ack. > > So I'd use something like this: > > > > [patch for NV_DRIVER_DATE] > > 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? > for all other X drivers we ship the pristine tarball, but delete the generated files on clean and run autoreconf on build. For nouveau you could do something similar I think. Could the get-orig-source target be a simple invocation of git archive, until the driver gets a real release? > 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. Great. Cheers, Julien
signature.asc
Description: Digital signature
