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: Linus Torvalds on 4 Mar 2010 18:00 On Thu, 4 Mar 2010, Stephane Marchesin wrote: > > In short, the "don't break user space interfaces" principle is making > user space code quality worse for everyone. And it makes our lives as > graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? 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: Adam Jackson on 4 Mar 2010 18:10 On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: > > # sed -i 's/\<kernel\>.*/& nouveau.modeset=0/g' /etc/grub.conf > > Never tried this part. The bug I'm assuming you're referring to is https://bugzilla.redhat.com/show_bug.cgi?id=519298 in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. However, the log in that bug only shows you using the built-in autoconfig logic, and not an xorg.conf file. So, given you were talking about a kernel without nouveau, I am left to assume one of: - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. - ajax
From: Linus Torvalds on 4 Mar 2010 18:10 On Thu, 4 Mar 2010, Adam Jackson wrote: > 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. That's what I told people I can do (I'd just revert that commit). I can do that. But it's not very productive, is it? What about the people who _do_ want to run the rawhide tree? Seriously - what's wrong with my suggestion to just version things properly? What's wrong with _fixing_ a stupid technical problem? What's wrong with people that you can't see that there are actual _solutions_ to the f*cking mess that is the current situation? I can solve it for my own use, and I already stated so. But while kernel developers should be scratching their own itches, a kernel developer that can't see past his own small sandbox is pretty damn worthless. We do need to fix this - and I'm bringing it up and complaining about it, because the nouveau people have _not_ done anything remotely sane. The current situation causes problems for people. Anybody who disputes that is in denial. Can somebody come up with a _better_ solution than the one I suggested? Feel free to do so, but in the meantime, I have to say that your reply and that of Matthew and others have been totally pointless, and making excuses rather than trying to actually face the fact that there is a problem. So man up, guys. Face the problem, rather than say "well, it's staging", or "well, we can revert it". Neither of those really solve anything in the short run _or_ the long run. 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 18:10 On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Thu, 4 Mar 2010, Stephane Marchesin wrote: >> >> In short, the "don't break user space interfaces" principle is making >> user space code quality worse for everyone. And it makes our lives as >> graphics developers pretty miserable actually > > And _my_ point is that if you did a half-way decent job on versioning, you > wouldn't be in the crappy situation you are now. > > For chissake, the DRM versioning model is a total disaster. The reason you > can never ever break user space interfaces is exactly because when you > break them, X stops working. Stop aligning DRM versioning with nouveau versioning. This isn't a generic problem with DRM, we've supported versioning interfaces for years and have broken them maybe once. > What I suggested is to _keep_ a working model across different versions, > so that you can get out of the rat-hole you are in now (and the rat-hole > you put your users into, and the distributions). > > It's simply _not_ acceptable to tie the X server and the kernel version so > tightly together as the crazy DRM model does right now. It's not all that > different from us requiring people to install a new glibc every once in a > while, just because we added a new filesystem. Everybody understands that > that would be totally insane. > > Why does the X community not understand simple library versioning? Its nouveau project not X not DRM, stop generalising the situation. 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: Jesse Barnes on 4 Mar 2010 18:10
On Thu, 4 Mar 2010 14:54:03 -0800 (PST) Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Thu, 4 Mar 2010, Stephane Marchesin wrote: > > > > In short, the "don't break user space interfaces" principle is making > > user space code quality worse for everyone. And it makes our lives as > > graphics developers pretty miserable actually > > And _my_ point is that if you did a half-way decent job on versioning, you > wouldn't be in the crappy situation you are now. > > For chissake, the DRM versioning model is a total disaster. The reason you > can never ever break user space interfaces is exactly because when you > break them, X stops working. > > What I suggested is to _keep_ a working model across different versions, > so that you can get out of the rat-hole you are in now (and the rat-hole > you put your users into, and the distributions). > > It's simply _not_ acceptable to tie the X server and the kernel version so > tightly together as the crazy DRM model does right now. It's not all that > different from us requiring people to install a new glibc every once in a > while, just because we added a new filesystem. Everybody understands that > that would be totally insane. > > Why does the X community not understand simple library versioning? We use versioning on the Intel side, but in the form of feature flags as new things are added (we've had a handful since GEM was added in 2.6.28). It's a pain to handle the various code paths, but no more so than having lots of separate library versions to support. That would be nice from one perspective, but it would only save work if we abandoned the old versions quickly and kept a big shared component between library versions. -- Jesse Barnes, Intel Open Source Technology Center -- 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/ |