[git pull] drm fixes for v4.12-rc1

Hi Linus, Some fixes that it would be good to have in rc1. It contains the i915 quiet fix that you reported. It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 which is new in this kernel and is preliminary support so may have a fair bit of movement. Otherwise a few

Re: [git pull] drm fixes for v4.12-rc1

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull

[git pull] drm fixes - some more

Looks like I didn't build on IA64 (who knew), fix from Tony and a few more radeon fixes one for a regression since the output probing. The following changes since commit c42750b0261274107ae85c894c088e618a3e38b9: drm/r600: fix possible NULL pointer derefernce (2010-07-21 10:29:32 +1000) are

Re: [git pull] drm fixes + agp + one fb patch

On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc

Re: [git pull] drm fixes + agp + one fb patch

On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older

Re: [git pull] drm fixes + agp + one fb patch

On Wed, Jun 30, 2010 at 5:57 PM, Dave Airlie airl...@gmail.com wrote: On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes:

Re: [git pull] drm fixes + agp + one fb patch

On Wed, Jun 30, 2010 at 06:00:32PM +1000, Dave Airlie wrote: On Wed, Jun 30, 2010 at 5:57 PM, Dave Airlie airl...@gmail.com wrote: On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: Hi Linus,

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 5:31 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: one fb layer fix in a flag I introduced, the rest are drm fixes: radeon

Re: [git pull] drm fixes + agp + one fb patch

On Wednesday, June 30, 2010, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes.

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 3:31 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf wrote: On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote: one fb layer fix in a flag I introduced, the rest are drm fixes: radeon

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 10:58 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 10:49:41AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 3:31 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 11:14 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 11:03:33AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 10:58 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 10:49:41AM -0400, Alex Deucher wrote:

Re: [git pull] drm fixes + agp + one fb patch

On Wed, Jun 30, 2010 at 6:13 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday, June 30, 2010, Dave Airlie wrote: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 11:50 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 11:34:53AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 11:14 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 11:03:33AM -0400, Alex Deucher wrote:

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 11:34:53AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 11:14 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 11:03:33AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 10:58 AM, Markus Trippelsdorf mar...@trippelsdorf.de

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 11:03:33AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 10:58 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 10:49:41AM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 3:31 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote:

Re: [git pull] drm fixes + agp + one fb patch (bisected)

On Wed, Jun 30, 2010 at 12:04:35PM -0400, Alex Deucher wrote: On Wed, Jun 30, 2010 at 11:50 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On Wed, Jun 30, 2010 at 11:34:53AM -0400, Alex Deucher wrote: The attached patch should fix the issue. Sorry, but it does not. I've still

[git pull] drm fixes + agp + one fb patch

Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with some updates to the evergreen command stream

Re: [git pull] drm fixes + agp + one fb patch

2010/6/30 Dave Airlie airl...@linux.ie: Hi Linus, one fb layer fix in a flag I introduced, the rest are drm fixes: radeon fixes: the larger ones in the command stream checker for older cards, which was causing a lot of userspace apps to fail. Also some powerpc server fixes. along with

[git pull] drm regression fix

Just one patch from Jean to fix some regressions in the buffer code rework. Thanks to Jean for tracking this down. The following changes since commit 8cfe92d683a0041ac8e016a0b0a487c99a78f6c1: Thomas Hellstrom (1): drm/ttm: Remove the ttm_bo_block_reservation() function. are available

[git pull] drm fixes

Nothing major, Mostly nouveau changes, some radeon tv output fixes, and a couple of quirks. The following changes since commit d668046c13024d74af7d04a124ba55f406380fe7: Dave Airlie (1): drm/radeon/kms: enable ACPI powermanagement mode on radeon gpus. are available in the git

[git pull] drm tree

a pull from nouveau + minor drm core fixes, Lots of radeon fixes from a...@amd, main thing is turning off the use of the hw i2c engine by default again, it was causing problems for some people, we now have a module option. Lots of misc radeon fixes from Alex also, along with RV7xx HDMI audio

Re: [git pull] drm fixes

2010/4/1 Rafał Miłecki zaj...@gmail.com: W dniu 30 marca 2010 09:07 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this

Re: [git pull] drm tree

W dniu 1 kwietnia 2010 09:32 użytkownik Dave Airlie airl...@linux.ie napisał: a pull from nouveau + minor drm core fixes, Lots of radeon fixes from a...@amd, main thing is turning off the use of the hw i2c engine by default again, it was causing problems for some people, we now have a module

Re: [git pull] drm fixes

W dniu 1 kwietnia 2010 09:43 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/4/1 Rafał Miłecki zaj...@gmail.com: W dniu 30 marca 2010 09:07 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother,

Re: [git pull] drm fixes

W dniu 30 marca 2010 09:07 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of

Re: [git pull] drm fixes

2010/3/30 Michel Dänzer mic...@daenzer.net: On Tue, 2010-03-30 at 05:34 +0100, Dave Airlie wrote: Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked

Re: [git pull] drm fixes

On Tue, 2010-03-30 at 05:34 +0100, Dave Airlie wrote: Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), [...] While I was able to work around

Re: [git pull] drm fixes

2010/3/30 Dave Airlie airl...@linux.ie: [re-pull request] Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of the tree at this point, but I realised I was falling back to the old ways, of

Re: [git pull] drm fixes

On Tue, 30 Mar 2010, Dave Airlie wrote: Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of the tree at this point, but I realised I was falling back to the old ways, of putting

Re: [git pull] drm fixes

On Tue, Mar 30, 2010 at 07:24:42AM -0700, Linus Torvalds wrote: On Tue, 30 Mar 2010, Dave Airlie wrote: Actually Linus, don't bother, consider this revoked, I'm going to kill the GPU reset code and re-send this tomorrow, its just a mess to get it back out of the tree at this point,

[git pull] drm fixes

[re-pull request] Original pull req below + reverts the fallback placement change which had a side effect of causing more lockups on some AGP systems (this is a bug in the AGP drivers that needs to be tracked down), adds some further fixes from Alex for radeon. Also in case you are wondering

Re: [git pull] drm fixes

Hi Dave, 2010/3/25 Dave Airlie airl...@linux.ie: Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users

Re: [git pull] drm fixes

On Thu, Mar 25, 2010 at 4:52 PM, Pekka Enberg penb...@cs.helsinki.fi wrote: Hi Dave, 2010/3/25 Dave Airlie airl...@linux.ie: Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff

Re: [git pull] drm fixes

On Don, 2010-03-25 at 03:35 +, Dave Airlie wrote: [...] I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU

[git pull] drm fixes

Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote: On Fri, 5 Mar 2010, Daniel Stone wrote: FWIW, Option ModulePath in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. The thing is, Xorg has - and I

Re: [git pull] drm request 3

They want the benefits of lots of testers, without wanting to be courteous to those testers. Except for the small rather important detail that the Nouveau developers didn't ask for it to be merged in the first place.

Re: [git pull] drm request 3

On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for

Re: [git pull] drm request 3

On Sat, Mar 06, 2010 at 08:52:35PM +, Alan Cox wrote: They want the benefits of lots of testers, without wanting to be courteous to those testers. Except for the small rather important detail that the Nouveau developers didn't ask for it to be merged in the first place. *Someone* on

Re: [git pull] drm request 3

On Sat, Mar 06, 2010 at 11:28:16AM -0800, Linus Torvalds wrote: On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology,

Re: [git pull] drm request 3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-03-05 22:51 schrieb ty...@mit.edu: On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too.

Re: [git pull] drm request 3

Hi, On Thu, 2010-03-04 at 10:43 -0800, Linus Torvalds wrote: it difficult to have some libdrm that can handle both versions. You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. So when you saw a error message driver nouveau 0.0.n+1 and have

Re: [git pull] drm request 3

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. Why? Why shouldn't I expect that? I already outlined exactly _how_ it could be done. Why are people saying that technology has to suck?

Re: [git pull] drm request 3

On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . -- Sérgio M. B. smime.p7s Description:

Re: [git pull] drm request 3

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get

Re: [git pull] drm request 3

On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote: Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always

Re: [git pull] drm request 3

On Thu, Mar 4, 2010 at 4:41 PM, Linus Torvalds torva...@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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane

Re: [git pull] drm request 3

On Thu, Mar 4, 2010 at 23:44, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful

Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri 5.Mar'10 at 8:44:07 +0100, Ingo Molnar wrote: Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this

Re: [git pull] drm request 3

On 03/04/2010 05:59 PM, Adam Jackson wrote: 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

Re: [git pull] drm request 3

The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, 05 Mar 2010 11:00:30 +0100, Carlos R. Mafra said: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the

Re: [git pull] drm request 3

On Fri, Mar 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote: Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this

Re: [git pull] drm request 3

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 stop and think for a minute instead. Maybe a timeline would help Nouveau development starts

Re: [git pull] drm request 3

On Thu, 04 Mar 2010 14:32:02 -0500 Jeff Garzik j...@garzik.org 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.

Re: [git pull] drm request 3

Why does the X community not understand simple library versioning? Why does Linus Torvalds not understand the Kconfig of his own staging directory ? Alan -- Download Intel#174; Parallel Studio Eval Try the new software

Re: [git pull] drm request 3

From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 12:38:34 + The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be

Re: [git pull] drm request 3

If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base

Re: [git pull] drm request 3

From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 15:09:34 + I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, C. Bergström wrote: staging != stable This really is being repeated, over and over. But it's irrelevant. It's irrelevant because it's just a bad _excuse_. That driver is used in production environments. That's _reality_. The whole staging thing is nothing more than a

Re: [git pull] drm request 3

On Fri, 2010-03-05 at 06:37 -0800, David Miller wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 12:38:34 + The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the

Re: [git pull] drm request 3

From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:17:54 +0200 On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making

Re: [git pull] drm request 3

Personally I wouldn't have ever committed to that user visible APIs can break cause it's in -stable. Because that's complete garbage Staging has to have the no API rules. Read some of the stuff in there to understand why or apply about 30 seconds of thought to what it would mean to you. There

Re: [git pull] drm request 3

Hi, On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote: On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the

Re: [git pull] drm request 3

On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to

Re: [git pull] drm request 3

On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote: On 03/04/2010 05:59 PM, Adam Jackson wrote: 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

Re: [git pull] drm request 3

From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:40:09 +0200 On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. That's a matter for the

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, 5 Mar 2010, Carlos R. Mafra wrote: Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. Actually, take it from me: Xorg is _pleasant_ to test these days. Ok, so that's partly compared to the mess it _used_ to be, but it's

Re: [git pull] drm request 3

It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace versions side-by-side. This means that if you install your new kernel and userspace,

Re: [git pull] drm request 3

You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. We're better than that. If you consider the

Re: [git pull] drm request 3

On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen.

Re: [git pull] drm request 3

From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 16:02:17 + You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't.

Re: [git pull] drm request 3

From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Now, I agree that that would have been the optimal setup from a testing an user standpoint, but I think it's a bit too strong.

Re: [git pull] drm request 3

On Fri, 5 Mar 2010 16:56:10 +0100 Luca Barbieri luca.barbi...@gmail.com wrote: It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

Hi, On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote: These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) Indeed, no argument here. That said, the _one_ thing I really wish

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, Alan Cox wrote: You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it.

Re: [git pull] drm request 3

On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: 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). Read it

Re: [git pull] drm request 3

On Fri, 5 Mar 2010 08:44:07 +0100 Ingo Molnar mi...@elte.hu wrote: It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, Alan Cox wrote: Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan - it seems you're missing the whole point. The thing I objected to, in the VERY

Re: [git pull] drm request 3

So the watershed moment was _never_ the Linus merged it. The watershed moment was always Fedora started shipping it. That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? So why are you screaming at the DRM and Nouveau people about

Re: [git pull] drm request 3

I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. Sure, but each user must manually find out how to setup that, and

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Carlos R. Mafra wrote: Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. Actually, take it from me: Xorg is

Re: [git pull] drm request 3

On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller da...@davemloft.net wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your

Re: [git pull] drm request 3

The thing I objected to, in the VERY BEGINNING in this thread, i the fact that the thing was done in such a way that it's basically impossible to support the old/new ABI at all! What did you expect them to do. They said when you first forced a merge that they would do this. They have no

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

On Fri, 5 Mar 2010, Daniel Stone wrote: FWIW, Option ModulePath in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. The thing is, Xorg has - and I think for _very_ good reasons - deprecated using xorg.conf at all.

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, Alan Cox wrote: So the watershed moment was _never_ the Linus merged it. The watershed moment was always Fedora started shipping it. That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? So why are you

Re: [git pull] drm request 3

Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last

Re: [git pull] drm request 3

On Fri, 5 Mar 2010, Daniel Stone wrote: So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? I think that's what David ended up saying, but I

Re: [git pull] drm request 3

Alan Cox wrote: Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I

Re: [git pull] drm request 3

On Fri, Mar 05, 2010 at 04:31:29PM +, Alan Cox wrote: On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller da...@davemloft.net wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body

Re: [git pull] drm request 3

On Fri, Mar 5, 2010 at 11:05 AM, David Miller da...@davemloft.net wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 16:02:17 + You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to

Re: [git pull] drm request 3

* Mike Galbraith efa...@gmx.de wrote: On the bright side, all this hubbub sends a very positive message to the noveau development crew. Folks, your work is important. I'd be proud as a peacock :) Heh, most definitely so! Noveau really is a game-changer i think, it's a big break-through

Re: [git pull] drm request 3

On 03/05/2010 10:17 AM, Daniel Stone wrote: On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so

  1   2   3   4   5   >