The nouveau driver has reached a state where it works better than the xf86-video-nv driver in many regards (eg. RandR 1.2 for more chipsets). I have been running it for some months now, using a modified xf86-video-ati-9999.ebuild from the x11 overlay. A live ebuild and a snapshot ebuild will be attached to this bug. Reproducible: Always Steps to Reproduce:
Created attachment 177333 [details] xf86-video-nouveau-9999.ebuild live nouveau ebuild
Created attachment 177335 [details] xf86-video-nouveau-0.0.20081228.ebuild nouveau snapshot ebuild
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/x11-drivers/xf86-video-nouveau
update summary for the sunrise overlay
I created a clone of the x11 overlay and added the xf86-video-nouveau live git ebuild to it. You can find it at git://github.com/chithanh/x11-overlay.git if you want to test. It is planned to merge the driver to the x11 overlay soon.
The x11 overlay contains all working (at this time) ebuilds needed to use Nouveau, apart from 3D, of course. Shouldn't this bug be closed?
I would prefer if the bug remains open until nouveau enters the portage tree.
And that will be loong road, btw i guess this should be assigned to x11, since it is in our overlay, Remi do you agree or should we keep this as-is?
Sure, that's fine with me. @Chi-Thanh, did you get in touch with upstream to see if they would consider doing (semi-)official snapshots? Cheers
My most current information is that no release is going to be tagged before the nouveau drm kernel interface is stable. Whether this will happen in the foreseeable future I don't know. Also, when requesting such a symbolic act for Gentoo, what reason should I give why Gentoo is special in this regard? Other distributions (Ubuntu, Fedora, Arch, ...) didn't require this for inclusion in their official repository. Work has begun on a nouveau/linux-2.6 newttm kernel tree with nouveau drm included (replacing mesa/drm), so I guess they are preparing for a merge. But according to comments on IRC it will not be ready for 2.6.31. I would vote for keeping the bug assigned to maintainer-wanted@g.o until an actual maintainer steps up to put this in portage. If someone would become proxy-maintainer for me (so all bugs are handled by me), I would be fine with that too.
(In reply to comment #10) > My most current information is that no release is going to be tagged before the > nouveau drm kernel interface is stable. Whether this will happen in the > foreseeable future I don't know. Also, when requesting such a symbolic act for > Gentoo, what reason should I give why Gentoo is special in this regard? Other > distributions (Ubuntu, Fedora, Arch, ...) didn't require this for inclusion in > their official repository. It's mostly about reducing the burden that it puts on us. That and "Release Early, Release Often" © Eric S. Raymond. > I would vote for keeping the bug assigned to maintainer-wanted@g.o until an > actual maintainer steps up to put this in portage. If someone would become > proxy-maintainer for me (so all bugs are handled by me), I would be fine with > that too. I don't mind proxy-maintaining for you (unless you want to commit ebuilds every couple of house :p). It's just that, again, not having clear releases by upstream makes this a bit awkward for me (see ffmpeg for another example of release-less project...) and I wish things were a bit different. Anyhow, you should probably get in touch with Ben Skeggs, he now works for Red Hat so he probably has a plan for nouveau's stabilization and overall presence withing Fedora. Thanks
This seems to be a good place to give a heads-up: The x11-drm-9999 ebuild in x11 overlay, or any other ebuild that uses drm.git master HEAD for kernel modules, is now broken for Nouveau. Nouveau has been broken for a few days now, and it will not be fixed. It is moving to a kernel tree for development and the user documentation is coming, a good part of it is already at http://nouveau.freedesktop.org/wiki/InstallDRM . Or maybe someone already patched x11-drm-9999? I haven't taken a look. More info will be written (and some already is) in the Nouveau wiki. If you want snapshots, you can do them yourself. There are so few people working upstream that all efforts are best invested in stabilising and getting to the first real release. The .31 merge window has closed, .32 merge is probably unlikely. My guess is that Nouveau might hit .33 the earliest as a staging driver, but that's really just my guess as a user - I don't write the code, so I probably shouldn't say that. Thanks. btw. "Release Early, Release Often" might not be the best thing when introducing new user/kernel ABIs in Linux ;-)
(In reply to comment #12) > This seems to be a good place to give a heads-up: Thanks for stopping by :) > It is moving to a kernel > tree for development and the user documentation is coming, a good part of it is > already at http://nouveau.freedesktop.org/wiki/InstallDRM . > > Or maybe someone already patched x11-drm-9999? I haven't taken a look. I guess we'll just have to provide a sys-kernel/nouveau-sources-9999 ebuild instead. That's fine with me. > btw. "Release Early, Release Often" might not be the best thing when > introducing new user/kernel ABIs in Linux ;-) Heh, true :) I was just mentioning releases for inclusion in portage. But if you still think nouveau is still a moving target, then I guess we could somehow find with you (the nouveau team) a "reasonably stable" commit in nouveau's ddx and ship that. The only real thing bother me about not having releases if that if we're the only ones doing them. If we ship something that's close to what other distros ship, then I'm overall fine with it. Thanks for the updates Chi-Thahn, I'm eagerly awaiting your commits in the overlay now ;) Cheers
This issue is bit more problematic. If one take look on drm git on fdo, it is lately done only for libdrm development, drm development itself is done in some kernel package so it is getting really really tricky how to package x11-base/x11-drm.
Its in our overlay so i wrangled it for us so we have headups, anyway chithead is bugreporter for this and also maintainer so he will work on it :]
Just to state progress, video_cards_nouveau is availible on mesa-7.7 and later :]
(In reply to comment #16) > Just to state progress, video_cards_nouveau is availible on mesa-7.7 and later > :] This is not good. Not good at all. I really hope I have misunderstood something. Please, correct me. Gallium seems to be enabled by default. If one happens to have VIDEO_CARDS="nouveau", you will get Nouveau Gallium driver installed SYSTEM-WIDE! Granted, it is in ~arch, but it is in the official Gentoo package repo. This is *far* too easy to get installed by accident. No-one should install Nouveau-gallium system-wide, it is buggy, and can kill the whole X session without a warning. It may even trigger kernel bugs on some rare occasions. Quite a bold move from a distribution, I sincerely hope all the fallout comes on to Gentoo and not Nouveau developers. There is no need to install it, really, just compile and point the environment variables to the proper locations, and one can try it app by app. I probably do not have to emphasize, that the gallium drivers are moving fast, so everyone is best off with the latest git sources. FWIW, I agree with Younes here: http://lists.freedesktop.org/archives/nouveau/2009-December/004366.html Also, why is Nouveau Gallium in the official repo in the first place, when the Nouveau DDX is not? Furthermore, I see the official Gentoo libdrm-2.4.17 package has nouveau enabled. Why? AFAICT Portage contains nothing (working software) that uses it. I would like to suggest to keep the unreleased stuff in the x11 overlay, and avoid compiling useless code (libdrm_nouveau and Nouveau Gallium) in mainstream Portage. This rant may apply to radeon as well, but you have to ask the radeon people about it.
Hi Pekka, thanks for commenting :) (In reply to comment #17) > This is not good. Not good at all. I really hope I have misunderstood > something. Please, correct me. > > Gallium seems to be enabled by default. If one happens to have > VIDEO_CARDS="nouveau", you will get Nouveau Gallium driver installed > SYSTEM-WIDE! > Granted, it is in ~arch, but it is in the official Gentoo package repo. > > This is *far* too easy to get installed by accident. No-one should install > Nouveau-gallium system-wide, it is buggy, and can kill the whole X session > without a warning. It may even trigger kernel bugs on some rare occasions. > Quite a bold move from a distribution, I sincerely hope all the fallout comes > on to Gentoo and not Nouveau developers. I think we're going to keep disabling gallium for a while longer, it's causing issues for other chips as well. > There is no need to install it, really, just compile and point the environment > variables to the proper locations, and one can try it app by app. I probably do > not have to emphasize, that the gallium drivers are moving fast, so everyone is > best off with the latest git sources. > > FWIW, I agree with Younes here: > http://lists.freedesktop.org/archives/nouveau/2009-December/004366.html > > Also, why is Nouveau Gallium in the official repo in the first place, when the > Nouveau DDX is not? We were sort of hoping you'd start making releases of the DDX at some point, so we prepped up the tree for those... > Furthermore, I see the official Gentoo libdrm-2.4.17 package has nouveau > enabled. Why? AFAICT Portage contains nothing (working software) that uses it. Makes things easier in the ebuild. The extra libs are small and don't cost much in terms of build time. Should the number of driver-specific grow, we'll add USE flags to libdrm. > I would like to suggest to keep the unreleased stuff in the x11 overlay, and > avoid compiling useless code (libdrm_nouveau and Nouveau Gallium) in mainstream > Portage. This rant may apply to radeon as well, but you have to ask the radeon > people about it. Obviously, Chi-Tahn is the one handling nouveau for us, so it's his decision to support nouveau in portage (or not...). As far as nouveau (upstream) is concerned, do you guys have plans for any sort of releases, "stable" snapshots, something that would help both upstream and downstream better support users' hardware in cooperation? Thanks
(In reply to comment #18) > As far as nouveau (upstream) is concerned, do you guys have plans for any sort > of releases, "stable" snapshots, something that would help both upstream and > downstream better support users' hardware in cooperation? To my knowledge Nouveau follows the DRI release policy: - get Nouveau DRM from staging to mainline - have a mainline kernel release - have a libdrm release - make the first DDX release You probably knew that, and it's all I can say. Cheers.
I would be ok with having video_cards_nouveau use.mask'ed for mesa, so users do not install nouveau dri accidentally. Splitting libdrm_nouveau from libdrm into an extra package is kind of pain and additional maintenance burden for no benefit. The present situation is not dangerous for users though. Nouveau dri does not do anything without the ddx, which is not in portage yet.
(In reply to comment #20) > Splitting libdrm_nouveau from libdrm into an extra package is kind of pain and > additional maintenance burden for no benefit. I was proposing to just drop --enable-nouveau-experimental-api from the release libdrm package, because nothing requires it. There are the Nouveau Gallium drivers, but IMHO those should not be built. If someone uses Nouveau, they'd better use the libdrm-9999 package from x11 as well, where it is enabled. > The present situation is not dangerous for users though. Nouveau dri does not > do anything without the ddx, which is not in portage yet. That is true, and then users probably do not have video_cards_nouveau either, so non-x11 users are safe. People, who do use Nouveau already from x11, likely have video_cards_nouveau enabled, and they would be caught by surprise DRI disaster. On a personal note, I've been using the x11 overlay packages libdrm and xf86-video-nouveau for a long time, and they work fine and are helpful. Some time ago I downgraded from git xorg-server to 1.7.3, so nowadays I'm using only few 9999-packages. Kernel modules I build from git, out-of-tree, and the Mesa drivers I use as described earlier (or mostly not at all). At least Chi-Thanh should already know, that nv04-nv20 classes of cards will likely have a classic DRI driver in Mesa, and nv30 and up have Gallium drivers. Therefore there will be nouveau_vieux_dri.so for classic and nouveau_dri.so for Gallium. Just a heads-up, nothing to see there yet. :-) Hm, is this a good place to have this discussion? Feels to be getting a bit off-topic by now.
Fixed in CVS
