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: Maarten Maathuis on 4 Mar 2010 16:30 On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > Hmm. What the hell am I supposed to do about > > � � � �(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 > � � � �(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 > � � � �(EE) NOUVEAU(0): 879: > > now? You can update your userspace components. No compatibility is offered between versions in any direction. > > What happened to the whole backwards compatibility thing? I wasn't even > warned that this breaks existing user space. That makes it impossible to > _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid > model, lots of people are just using some random distribution (F12 in my > case), and you just broke it. > > I see the commit that does this was very aware of it: > > � � � �commit a1606a9596e54da90ad6209071b357a4c1b0fa82 > � � � �Author: Ben Skeggs <bskeggs(a)redhat.com> > � � � �Date: � Fri Feb 12 10:27:35 2010 +1000 > > � � � � � �drm/nouveau: new gem pushbuf interface, bump to 0.0.16 > > � � � � � �This commit breaks the userspace interface, and requires a new libdrm for > � � � � � �nouveau to operate again. > > � � � � � �The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for > � � � � � �compatibility purposes are now gone, and replaced with the new ioctl which > � � � � � �allows for multiple push buffers to be submitted (necessary for hw index > � � � � � �buffers in the nv50 3d driver) and relocations to be applied on any buffer. > > � � � � � �A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed > � � � � � �for userspace modesetting have also been removed. > > � � � � � �Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> > � � � � � �Signed-off-by: Francisco Jerez <currojerez(a)riseup.net> > > but why the hell wasn't I made aware of it before-hand? Quite frankly, I > probably wouldn't have pulled it. > > We can't just go around breaking peoples setups. This driver is, like it > or not, used by Fedora-12 (and probably other distros). It may say > "staging", but that doesn't change the fact that it's in production use by > huge distributions. Flag days aren't acceptable. > > � � � � � � � �Linus > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- 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: Maarten Maathuis on 4 Mar 2010 16:30 On Thu, Mar 4, 2010 at 10:21 PM, Maarten Maathuis <madman2003(a)gmail.com> wrote: > On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds > <torvalds(a)linux-foundation.org> wrote: >> >> >> Hmm. What the hell am I supposed to do about >> >> � � � �(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 >> � � � �(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 >> � � � �(EE) NOUVEAU(0): 879: >> >> now? >> >> What happened to the whole backwards compatibility thing? I wasn't even >> warned that this breaks existing user space. That makes it impossible to >> _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid >> model, lots of people are just using some random distribution (F12 in my >> case), and you just broke it. >> >> I see the commit that does this was very aware of it: >> >> � � � �commit a1606a9596e54da90ad6209071b357a4c1b0fa82 >> � � � �Author: Ben Skeggs <bskeggs(a)redhat.com> >> � � � �Date: � Fri Feb 12 10:27:35 2010 +1000 >> >> � � � � � �drm/nouveau: new gem pushbuf interface, bump to 0.0.16 >> >> � � � � � �This commit breaks the userspace interface, and requires a new libdrm for >> � � � � � �nouveau to operate again. >> >> � � � � � �The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for >> � � � � � �compatibility purposes are now gone, and replaced with the new ioctl which >> � � � � � �allows for multiple push buffers to be submitted (necessary for hw index >> � � � � � �buffers in the nv50 3d driver) and relocations to be applied on any buffer. >> >> � � � � � �A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed >> � � � � � �for userspace modesetting have also been removed. >> >> � � � � � �Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> >> � � � � � �Signed-off-by: Francisco Jerez <currojerez(a)riseup.net> >> >> but why the hell wasn't I made aware of it before-hand? Quite frankly, I >> probably wouldn't have pulled it. >> >> We can't just go around breaking peoples setups. This driver is, like it >> or not, used by Fedora-12 (and probably other distros). It may say >> "staging", but that doesn't change the fact that it's in production use by >> huge distributions. Flag days aren't acceptable. >> >> � � � � � � � �Linus >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> -- >> _______________________________________________ >> Dri-devel mailing list >> Dri-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dri-devel >> > > What i'm about to say is my personal opinion, not that of nouveau as a > whole (not even sure if such a thing exists). > > 1. We are in staging because our abi isn't final yet. > 2. We (already) adjusted our way of working to ensure we have a usable > and proper codebase by the time we are ready for mainline. > 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree). > 4. You are forcing red hat to force something on the rest of us. > 5. I for one am happy we keep a clean api. > 6. We keep an internal kernel tree that is tested to some degree (in > this case the abi break was in there for a few weeks iirc) none of the > developers asked for a revert. Point 6 is iirc, someone can correct me if this is not the case. > 7. Everyone (users, distros) are (or should) be aware of the nature of > this driver, our userspace interface is experimental for that very > reason. > 8. Experience has tought me that in the case of nouveau, if a > developer isn't using a codepath it will bitrot. > > So please, also take into consideration that this project isn't solely > made by red hat and it's usually the other people that get to keep the > pieces. > > Sincerely, > > Maarten Maathuis. > -- 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: Adam Jackson on 4 Mar 2010 17:20 On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: > On 03/04/2010 02:04 PM, Matthew Garrett wrote: > > 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? # cat << EOF > /etc/X11/xorg.conf Section "Device" Identifier "Card0" Driver "nv" EndSection EOF # sed -i 's/\<kernel\>.*/& nouveau.modeset=0/g' /etc/grub.conf # telinit 6 HTH. - ajax
From: Jeff Garzik on 4 Mar 2010 17:30 On 03/04/2010 05:18 PM, Adam Jackson wrote: > On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: >> On 03/04/2010 02:04 PM, Matthew Garrett wrote: >>> 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? > > # cat<< EOF> /etc/X11/xorg.conf > Section "Device" > Identifier "Card0" > Driver "nv" > EndSection > EOF Already tried that, and other suggested variations thereof. Did not work on F11 or F12 with 05:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GX2 (rev a2) > # sed -i 's/\<kernel\>.*/& nouveau.modeset=0/g' /etc/grub.conf Never tried this part. 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: Adam Jackson on 4 Mar 2010 17:30
On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: > On Thu, 4 Mar 2010, Matthew Garrett wrote: > > If you'd made it clear that you wanted the interface to be stable > > before it got merged, I suspect that it simply wouldn't have been merged > > until the interface was stable. > > What kind of excuse is that? It's "we did bad things, but if we didn't do > those bad things, we'd have done _other_ bad things"? > > Two wrong choices don't make a right. So unmerge it. - ajax |