drm request 3
in [Kernel]
|
Prev: [GIT PULL] SLAB updates for 2.6.34-rc1
Next: [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
From: Luc Verhaegen on 4 Mar 2010 20:00 On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote: > > > > The F13 packages *will* work, so long as you're not bisecting back and > > forth. > > How do I install just the F13 libdrm thing, without changing everything > else? I'm willing to try. We can make it part of the 2.6.34 release notes. > > And if we end up having people bisecting back and forth, I will hate that > f*cking nouveau driver even more. > > Linus libdrm is composed of the main libdrm, and several driver specific libdrms today (... and libkms, yes). While the main libdrm is relatively stable, the library specific ones move all the time, and there is only one version that is being tracked, and that is being bumped all the time. The most recent one: http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527 Only drivers depend on the driver specific libdrms. The xserver is compatible all the way to libdrm 2.3.0, which was tagged august 2006. xf86-video- drivers might depend on newer driver specific libdrms. And when the mesa tree is taken apart, when drivers are taken out of it, you'll find that its real dependency is also 2.3.0. It's the mesa drivers that are responsible for the main mesa dependency on libdrm 2.4.15. Luc Verhaegen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 4 Mar 2010 20:30 On Thu, 4 Mar 2010, Linus Torvalds wrote: > > Anyway, since I had looked at the libdrm sources, I had most of this on my > machine anyway, so I've compiled it all, and am going to reboot and see if > I can make a few symlinks work. > > IOW, right now I have this: > > [root(a)nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ > [root(a)nehalem drivers]# ll nouveau_drv.so* > lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16 > -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 > -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 Naah, I just end up with a really screwed up screen with that. I probably did something wrong in the configuration phase or something. I'll look for the precompiled ones, and hope they don't have some other odd dependencies. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 4 Mar 2010 20:30 >> >> Anyway, since I had looked at the libdrm sources, I had most of this on my >> machine anyway, so I've compiled it all, and am going to reboot and see if >> I can make a few symlinks work. >> >> IOW, right now I have this: >> >> � �[root(a)nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ >> � �[root(a)nehalem drivers]# ll nouveau_drv.so* >> � �lrwxrwxrwx 1 root root � � �21 2010-03-04 17:00 nouveau_drv.so -> nouveau_drv.so-0.0.16 >> � �-rwxr-xr-x 1 root root �343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 >> � �-rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 > > Naah, I just end up with a really screwed up screen with that. I probably > did something wrong in the configuration phase or something. I'll look for > the precompiled ones, and hope they don't have some other odd > dependencies. Looks like libdrm_nouveau didn't get updated along with nouveau. We don't have mesa in F12 so that won't matter. wget http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.18/1.fc13/src/libdrm-2.4.18-1.fc13.src.rpm rpmbuild --rebuild libdrm-2.4.18-1.fc13.src.rpm rpm -Uvh ~/rpmbuild/RPMS/libdrm-2.4.18-1.fc13.x86_64.rpm ~/rpmbuild/RPMS/libdrm-devel-2.4.18-1.fc13.x86_64.rpm wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 4 Mar 2010 21:00 On 03/04/2010 01:32 PM, Jeff Garzik wrote: > On 03/04/2010 02:04 PM, Matthew Garrett wrote: >> "Please note that these drivers are under heavy development, may or may >> not work, and may contain userspace interfaces that most likely will be >> changed in the near future." > > Shipping it as the default Fedora driver for NVIDIA hardware makes that > text largely irrelevant. Indeed, that text isn't really reconcilable with the fact that the driver is being used by default in a stable distro release. (Why do people keep forgetting the whole "upstream development" thing?) > > Jesse said >> Dave and the nouveau guys include the driver in Fedora to get >> much needed test coverage, and make sure the latest bits in rawhide >> work together. > > but when it is the default driver, it is the default _production_ driver > for Fedora users, in an official, stable Fedora release. > > And the alternative? You said >> F-12 continues to ship the -nv driver, which will work fine with any >> kernel version as long as nouveau is disabled. > > FAIL. I actually tried that. Have you? Do you think it is remotely easy > for a technically component, non-Xorg-hacker type to accomplish? > > I attempted to use the non-default 'nv' driver just before nouveau was > merged into upstream/staging, because I wanted a development kernel that > actually worked on my Fedora-based devel boxes. It was a complete > exercise in frustration, requiring at least one bugzilla bug report, and > ultimately resulted in failure. Advising people to use nv is pretty much a joke IMHO, it's barely above VESA in some ways. People would be more likely to use the nvidia binary driver than that contraption.. Aside from the fact that running nouveau on this machine would drive me crazy (there's no fan speed control implemented so the GPU fan screams away at maximum speed), the other big reason I can't use it is that at least until quite recently it couldn't work with upstream kernels. Unfortunately, changes like this will being that problem back.. So at this point the nvidia binary driver is the most practical solution that actually meets my needs, sadly enough.. > > I gave up and waiting for Linus to merge nouveau, which instantly made > my life a lot easier :) > > Kernel hacking on Fedora, my own dogfood, has become increasingly > cumbersome because of all these graphics issues. Sometimes it's just > easier to test a modern kernel on an ancient distro, sadly. > > Jeff > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Luck on 4 Mar 2010 21:10
On Thu, Mar 4, 2010 at 4:41 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > And if we end up having people bisecting back and forth, I will hate that > f*cking nouveau driver even more. Would it help to tag the flag day commit? At least that would make it trivial for bisecters to see whether each step in a bisection contains the commit or not. Generalizing that ... perhaps there could be a way to tell git that some set of tags represent flag days, so it could warn in any bisection if the set of included flag days changes. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |