On Wed, 3 Sep 2003, Alan Cox wrote:
Since I rsync from a CVS checkout all the cvs commands still work but go
back off to the CVS server saving a ton of bandwidth and cpu
This only works if the CVS server itself is working well _anyway_.
So yes, rsync in that sense can be used to (somewhat
On Thu, 4 Sep 2003, Chris Ison wrote:
Because of this the core of the linux team appear to be more concerned
about getting the job done due to the fact that some big money is
supporting and using linux. Although linux is FREE, its pholisiphy has
changed from one of Screw you Billy Goat, I'm
On Wed, 3 Sep 2003, Ville Syrjälä wrote:
Isn't there some sort of delay involved here? I remember seeing something
about the kernel BK-CVS lagging by several days. If so moving to BK could
make the problem worse...
The main delay we've seen is when the central BK places have gone down due
On Sun, 7 Sep 2003, Jon Smirl wrote:
I'm getting this with standalone Mesa not DRI. Can a someone more familar with
the R200 kernel DRM driver give me a clue as to what is not being set up
correctly? I die in RADEON_PURGE_CACHE() in radeon_do_cp_start().
More precisely:
Unable to handle
On Mon, 8 Sep 2003, Jon Smirl wrote:
I think I have tracked this down to the DRM drivers in the kernel not matching
the ones in DRI CVS. Some of the structures in the initialization IOCTL have
changed which caused one of the ring pointers to initialize to zero instead of
what it needed.
On Tue, 9 Sep 2003, Linus Torvalds wrote:
I can do a new merge [ ... ]
Is the dri.freedesktop.org tree up-to-date? Nothing has happened on it
lately, and I wonder if people are still using the old one for
development?
Linus
On Tue, 9 Sep 2003, Michel Dänzer wrote:
Absolutely, otherwise it's a bug. FWIW, the DRM from DRI CVS seems to
work the same here as the one from the linuxppc-2.5 tree shortly before
the -test5 merge. The only recent change I see which might cause
problems is my Radeon AGP = GART cleanup; I
Ok, I've merged the current DRI CVS tree from freedesktop.org into the
kernel, and as a result I now have another (pretty obvious) diff for
back-merging into DRI. I hope somebody with commit access will do this.
The merge has three parts:
- a real fix for an i830_irq.c misfeature, where the
compatibility crud.
So before applying that part, just edit out the one chunk that changes
DO_MUNMAP to do_munmap and apply the rest (that chunk appended here for
clarity).
Sorry for missing that on editing the patch. My bad.
Linus
On Thu, 25 Sep 2003, Linus Torvalds wrote
On Thu, 25 Sep 2003, Eric Anholt wrote:
I applied the radeon.h and the Kconfig patches (redone, since whitespace
got mangled in the email).
Hmm.. It's not mangled here - I just verified by applying the whole patch
as it came in off the dri-devel list (as opposed to what I sent out) to
the
On Thu, 25 Sep 2003, Dave Airlie wrote:
If Linus thinks your patch goes far enough for him..
I actually usually don't much like whitespace changes, and the one I sent
was purely in response to the fact that there already was a lot of
whitespace changes in the i810 driver.
Don't worry too
On Thu, 9 Oct 2003, Michel Dänzer wrote:
I could, and I just fixed this in CVS. The cause was dereferencing a
pointer which is uninitialized in non-MergedFB mode.
It's still broken on i845, though.
No crashes, but Xv windows show up as all blue (I assume that's the
overlay color), and the X
On Wed, 8 Oct 2003, Alex Deucher wrote:
A fix just went into xfree86 CVS earlier today that fixed several
things related to Xv on i8xx hardware. that code hasn't been synced
with DRI CVS yet. I don't have intel hardware so I can't test.
Well, the thing is definitely broken the same way on
On Wed, 15 Oct 2003, Jon Smirl wrote:
If you are familar with the hardware please check that I got the PCI ID lists
right.
Please fix the fact that modern PCI is _not_ enumerated with just bus,
slot, function. A lot of machines are starting to have a domain number,
which allows fro multiple
On Wed, 15 Oct 2003, Michel Dänzer wrote:
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
This new scheme allows the entire PCI probing stage of xfree to be eliminated.
I'll believe it when the relevant XFree86 developers agree with you. :)
If they don't, they are clueless.
There's no way
[ Following up to myself ]
On Wed, 15 Oct 2003, Linus Torvalds wrote:
Yes, XF86 may need to have some legacy module for backwards compatibility.
But thinking that X should try to probe on its own is just silly.
This is also relevant to 2D, since more and more graphics cards really
Am I the only one who sees an undefined _gl_context_modes_destroy()
symbol with the current DRI tree on i830? LIBGL_DEBUG gives this:
libGL: XF86DRIGetClientDriverName: 1.3.0 i830 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/tls/i830_dri.so
libGL:
Solved. Read on..
On Tue, 21 Oct 2003, Felix Kühling wrote:
glcontextmodes.o gets linked to libGL, not the driver. Apperently you
have an outdated libGL installed.
Well, my regular libGL.so is as new as the driver and compiled from DRI.
And yes, _gl_context_modes_destroy is there according
On Tue, 21 Oct 2003, Eric Anholt wrote:
What is the proper way to get the equivalent of pci_name(pdev) on
pre-2.5? Also, what is the cutoff where pci_name is available? Are the
values from pci_name decimal or hex?
The cut-off is 2.5.74 or so.
The numbers are hex, and it's really
On Thu, 23 Oct 2003, Jon Smirl wrote:
What about the fundamental question? We have several pairs of device drivers
that want to control the same hardware. One example would be radeon DRM and
radeon Framebuffer. How should these drivers coordinate probing and claiming
resources?
Since they
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is
there some helper function I missed? ]
On Thu, 23 Oct 2003, Jon Smirl wrote:
I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for marking PCI resources as being in use while DRM is using
On Thu, 23 Oct 2003, Jeff Garzik wrote:
The mechanics aren't complicated, but I seem to recall there being a
Real Good Reason why you want to leave it disabled 99% of the time. No,
I don't recall that reason :( But my fuzzy memory seems to think that
enable, grab a slice o 'rom,
On Fri, 24 Oct 2003, Petr Vandrovec wrote:
It would be nice if it works... For matrox hardware I have to map ROM
over framebuffer (it is solution recommended by datasheet), as there is
no way to get memory range allocated for ROM unless ROM was left enabled
all the time.
That's fine - it
On Sat, 25 Oct 2003, Egbert Eich wrote:
Speaking of XFree86: when I developed the PCI resource stuff in
XFree86 I was trying to get support from kernel folks to get the
appropriate user space interfaces into the kernel. When I got
nowhere I decided to do everything myself.
There won't
On Mon, 27 Oct 2003, Ian Romanick wrote:
I'm also baffled by the general animosty shown towards Linux.
I don't think it is animosity vs Linux per se, but I do think that XFree86
tends to have a very strong bias against infrastructure change.
Which is somewhat understandable: I'm a kernel
On Tue, 28 Oct 2003, James Simmons wrote:
This is good design for DMA based graphics cards. Unfortunely at present
maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers
use IO access :-( Sure we could convert as many as possible to DMA, which I was
planning to do
On Fri, 7 Nov 2003, Jon Smirl wrote:
I should be more specific, it's mapping the ROM into PCI space that the kernel
doesn't know about. Of course the kernel knows about the mapping from PCI space
to user space. During a hotplug event the kernel could map the new device on top
of the ROM in
On Wed, 10 Dec 2003, Ryan Underwood wrote:
They're not available anymore :( It's a real shame since they seemed to be
quite friendly towards open source developers at one point. I can almost
understand that they don't want to release any parhelia docs but I don't
understand why they
On Mon, 29 Dec 2003, Matt Sealey wrote:
Ian: wouldn't it be possible to have an official patch, for compressed
texture stuff, that tracks the trees releases?
I think that would be good, if somebody maintains it. It's pretty much
guaranteed that anybody who has a modern graphics card has
On Mon, 29 Dec 2003, Daniel Vogel wrote:
FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their
Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I
guess they didn't feel like licensing the patent from a competitor.
Interesting.
I believe exposing
On Thu, 1 Jan 2004, Michel Dänzer wrote:
well the advantage is that the ifdefs can just go away in kernel trees of
specific versions... (eg unifdef it)
Does this look better? Maybe a macro (or a typedef?) for the type of the
last argument would still be a good idea? Or is there yet a
On Fri, 2 Jan 2004, Nigel Cunningham wrote:
Of course there are also advantages to _not_ using the file-per-kernel
version scheme.
No there isn't.
The thing is, you should keep those file-per-OS files as small as
possible, and only contain the things that are literally different.
On Mon, 26 Jan 2004, Felix Kühling wrote:
after a CVS upgrade last night I got two some assertions in the radeon
driver. One happened when exiting from glxgears in radeonDeleteTexture.
Commenting out the assert statement helped.
I get something similar, except I'm using i830, not radeon.
On Mon, 9 Feb 2004, Jon Smirl wrote:
There are lots of solutions to this:
1) queue the printk's
2) add an in-kernel path for write to console that cooperates with the normal
user space one
3) if you know you are going to be debugging code like this, use an alternative
solution like the
On Wed, 12 May 2004, Dave Airlie wrote:
I just looked at drm.h and nearly all the ioctls use int, this file is
included in user-space applications also at the moment, I'm worried
changing all ints to __u32 will break some of these, anyone on DRI list
care to comment?
Right now, all
On Sat, 11 Sep 2004, Jon Smirl wrote:
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline. DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth where it uses the
On Sat, 11 Sep 2004, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Now it is _you_ who confuse 3D mode and 2D mode.
THERE IS NO SUCH THING.
There is only hardware.
How can you build a system that process swaps between these two modes?
You don't switch
On Sat, 11 Sep 2004, Alan Cox wrote:
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
My personal preference for this whole mess has always been the silly
driver that isn't even hardware-specific, and really does _nothing_ on
its own. This one would be the only thing that actually
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
Jon, you want to get to that Final step is to integrate the chip specific
code from DRM and fbdev. Alan doesn't even want to get there. I think
Alan just wants some
On Sat, 11 Sep 2004, Jon Smirl wrote:
On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
[EMAIL PROTECTED] wrote:
So I'd much rather see the hey, somebody else might have stolen my
hardware, and now I need to re-initialize as the _basic_ model. That just
allows others to do
On Sun, 12 Sep 2004, Dave Airlie wrote:
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state on driver swap are, especailly
on running fbcon and X on a
On Mon, 21 Feb 2005, Jon Smirl wrote:
I was working on the assumption that all PCI based, VGA class hardware
that is not the boot device needs to be posted.
I don't think that's true. We certainly don't _want_ it to be true in the
long run - and even now there are cards that we can
On Tue, 22 Feb 2005, Dmitry Torokhov wrote:
This sounds awfully like firmware loader that seems to be working just
fine for a range of network cards and other devices.
Yes. HOWEVER - and note how firmware loading for this case is not validly
done at device discovery, but at ifconfig time.
On Mon, 13 Feb 2006, Adrian Bunk wrote:
Dave's patch removes the entry for the card with the 0x5b60.
According to his bug report, Mauro has a Radeon X300SE that should
have the 0x5b70 according to pci.ids from pciutils
No. Look closer:
04:00.0 VGA compatible controller: ATI
On Mon, 13 Feb 2006, Adrian Bunk wrote:
The one thing I have not yet been proven wrong for is that this PCI id
is the only one we have in this driver for an RV370.
It definitely is an RV370, you're right in that. I'm too lazy to actually
see if the other entries that claim to be RV350's
On Mon, 13 Feb 2006, Linus Torvalds wrote:
So I decided to just remove it. Even if there is some other bug that could
make it work again, we can always just re-add it at that time. In the
meantime, this should fix both DaveJs and Mauros problems, and is clearly
no worse than 2.6.15
On Mon, 7 May 2007, Dave Airlie wrote:
20 files changed, 196 insertions(+), 349 deletions(-)
That looked promising, but I think you generated the diffstat the wrong
way around. It was actually
20 files changed, 349 insertions(+), 196 deletions(-)
delete mode 100644
On Tue, 8 May 2007, Dave Airlie wrote:
Please pull the 'drm-patches' branch from
git://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
That's not a valid URL. master.kernel.org doesn't run the git-daemon.
Please fix your script.
Linus
On Mon, 16 Jul 2007, Dave Airlie wrote:
Please pull the 'drm-patches' branch from the drm git tree.
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
This totally breaks for me.
CC drivers/char/drm/drm_ioc32.o
On Tue, 17 Jul 2007, Dave Airlie wrote:
Please pull the 'drm-patches' branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
I really think this or the previous tree is buggy.
Trying to start any 3D client just hangs my Evo laptop hard. It's a Radeon
On Tue, 17 Jul 2007, Dave Airlie wrote:
Could you re-pull?
There are two patches, one fixes a missed typedef for Sis and one adds the
idr_init that fell out of the drawable changeset.. which should fix any
hangs..
Yup, hang fixed. Thanks,
Linus
On Sat, 6 Oct 2007, Jiri Slaby wrote:
I guess, this will break my graphics, no?
http://lkml.org/lkml/2007/9/20/447
Can you try it?
We do have a rule about no regressions, so I think we'll have to do the
revert, but it would be nice to hear what the consequences for the revert
is for the
On Thu, 7 Feb 2008, Dave Airlie wrote:
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-patches
Very happy to. I can confirm that this does indeed finally make
suspend/resume work on my laptop, screen and all.
On Sun, 24 Aug 2008, Dave Airlie wrote:
So this has fixes for the SiS build with fbdev, a fix for a warning
reported by Jiri Slaby in the irq locking code, a fix for debugging the X
server startup sequence, r300/r500 radeon lockup fixes, Intel hw
instability fixes in the irq and hw
On Fri, 17 Oct 2008, Dave Airlie wrote:
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
Grr.
This whole merge series has been full of people sending me UNTESTED CRAP.
So what's the excuse _this_ time for adding all these
On Fri, 17 Oct 2008, Eric Anholt wrote:
Yeah, none of us are on x86-64, so we missed those warnings in testing.
Really? None of you use any modern CPU's, or you're _all_ running 32-bit
distros even though your cpu's could support 64-bit ones?
I would suggest at least _somebody_ in the
On Sat, 18 Oct 2008, Keith Packard wrote:
The basic plan is to have four new functions (yes, I'm making up names
here):
struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev,
int bar,
int
On Sat, 18 Oct 2008, Jon Smirl wrote:
Is it possible to use a segment register to map the whole aperture on
32b?
No. Segment registers don't extend the virtual address space, they can
only limit visibility into the one single 32-bit one.
IOW, segment registers don't actually extend
On Sat, 18 Oct 2008, Eric Anholt wrote:
It's not being disloyal to your CEO, really. I'm pretty sure nobody will
be fired just for ignoring that whole 640kB^H^H^H^H^H32-bits should be
enough for everybody idiocy.
Writing 3D drivers means running 3D games. Running 3D games
On Thu, 23 Oct 2008, Andrew Morton wrote:
Given that all highmem-implementing archtiectures must use the same
declaration here, we might as well put it into include/linux/highmem.h.
Although that goes against current mistakes^Wcode.
Does powerpc32 still implement highmem? It seems that
On Thu, 23 Oct 2008, Keith Packard wrote:
So I'd much rather create a new linux/kmap.h or something. Or just
expose this from to asm/fixmap.h or something. Let's not confuse this
with highmem, even if the implementation _historically_ was due to that.
Sure, we readily admit that
On Thu, 23 Oct 2008, Keith Packard wrote:
I'm fine with sticking the mapping in a separate structure; it's just
the return from ioremap_wc on 64-bit systems, and nothing at all on
32-bit systems.
Actually, on 32-bit, the 'prot' should be there, as should the starting
physical page.
Dave,
you have some odd and slightly git usage model, which shows up in various
commits. Lookie here as an example from comit 335041ed:
Author: Jesse Barnes jbar...@virtuousgeek.org 2009-01-22 04:22:06
Committer: Dave Airlie airl...@redhat.com 2009-01-22 04:22:06
On Mon, 26 Jan 2009, Sam Ravnborg wrote:
Well I'm not 100% sure what happened for this patch, I suspect,
jbarnes sent patch a week
or two ago, it misapplied against the tree I had currently when
applied with git-am, it didn't work so I hand
applied the patch with patch and then did
On Mon, 26 Jan 2009, Linus Torvalds wrote:
There must be easier ways to do so I think.
Um. Yes. Something like
git am -s -C1
which ends up requiring just a single line of context for the patch to
apply, exactly like the GNU 'patch' program.
The difference being that GNU
On Wed, 28 Jan 2009, Dave Airlie wrote:
I'm quite happy to push this, if nobody objects with a good reason.
Heh, since I was the one asking for this, I already applied it. If it
breaks something, people can blame me.
Linus
On Fri, 27 Mar 2009, Eric Anholt wrote:
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
drm-intel-next
Grr.
Guys, what the *hell* is wrong with you, when you can't even react to
trivial warnings and fix buggy code pointed out by
On Sun, 29 Mar 2009, Dave Airlie wrote:
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he should, but it really screws over my tree. I don't
mind direct pulls outside the
On Sun, 29 Mar 2009, Dave Airlie wrote:
My plans from now on are just to send you non-linear trees, whenever I
merge a patch into my next tree thats when it stays in there, I'll pull
Eric's tree directly into my tree and then I'll send the results, I
thought we cared about a clean merge
On Mon, 30 Mar 2009, Dave Airlie wrote:
- Don't merge upstream code at random points.
You should _never_ pull my tree at random points (this was my biggest
issue with early git users - many developers would just pull my current
random tree-of-the-day into their
On Mon, 18 May 2009, Ingo Molnar wrote:
Btw., why did the patch (and the revert) make any difference to the
test? Timing differences look improbable.
It's the change from
!signal_group_exit(signal)
to
!sig_kernel_only(signr)
and quite frankly, I still don't see the
On Sat, 16 May 2009, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13329
Subject : cifs_close: NULL pointer dereference
Submitter : Luca Tettamanti kronos...@gmail.com
Date : 2009-05-16 16:28 (1 days old)
References:
On Fri, 5 Jun 2009, Dave Airlie wrote:
On Fri, Jun 5, 2009 at 3:42 PM, Markus
Trippelsdorfmar...@trippelsdorf.de wrote:
On Thu, Jun 04, 2009 at 04:39:50AM +0100, Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-fixes' branch from
On Tue, 16 Jun 2009, Ryan Hope wrote:
+#ifdef MODULE
module_init(radeon_init);
+#else
+late_initcall(radeon_init);
+#endif
You should never need something like that.
Just do
late_initcall(radeon_init);
and if it's a module (which doesn't have early vs late etc), it will
On Sun, 21 Jun 2009, Maxim Levitsky wrote:
Something from this tree breaks my i965.
Using -git just before this was pulled,
a552f0af753eb4b5bbbe9eff205fe874b04c4583 works, but using latest git
makes google earth stall, it doesn't update its main window. It appears
that openining and
On Sun, 21 Jun 2009, Dave Airlie wrote:
I tried this tree (specifically, a merge of Linus' fb20871 this tree) on
Fedora 11 with modesetting enabled on an integrated Radeon 2100, and
plymouthd
crashes immediately with a corrupt page table. Photo attached. After the
crash, bootup
On Sun, 21 Jun 2009, Linus Torvalds wrote:
Dave - no amount of userspace differences make a corrupted page table
acceptable.
This needs to be fixed. No excuses. Kernel crashes are never an issue of
you used the wrong user space.
So corrupted page table means that one of the reserved
On Sun, 21 Jun 2009, Andrew Lutomirski wrote:
Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
where exactly we set the invalid bits. Andy, mind trying it out? You
should get the warnign much earlier, and it should have a much more useful
back-trace.
Your
On Mon, 22 Jun 2009, Thomas Hellström wrote:
It would be very helpful if we could introduce an fbdev mutex that protects
fbdev accesses to the kernel map and to the fbdev acceleration functions.
Not going to happen.
Why? 'printk'.
If you can't handle printk, then you're basically useless.
On Mon, 22 Jun 2009, Andrew Lutomirski wrote:
What if we only guaranteed that the framebuffer is mapped when it's
showing on the screen?
I think that works ok. We only care about printk being immediate in that
case, and if it gets buffered I don't think we care.
printk doesn't need to
On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
As far as I can remember, all fbdev operations are done under the
console semaphore.
Yeah, and some of them are horribly broken (ie copying data from user
space while doing it - causing horrible things like VC switching latencies
and
. Wysocki r...@sisk.pl
Date : 2009-08-02 13:37 (1 days old)
Handled-By: Linus Torvalds torva...@linux-foundation.org
Patch : http://patchwork.kernel.org/patch/38774/
Ok, this is committed as 79896cf42f6a96d7e14f2dc3473443d68d74031d.
Bug-Entry : http
On Tue, 25 Aug 2009, mailing54 wrote:
Linus Torvalds schrieb:
Are you using the same config? It sounds very much like your -rc7 problems
are due to the Intel KMS (kernel mode setting) driver, which I know has had
problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
On Wed, 26 Aug 2009, Zhenyu Wang wrote:
In my experience, the BIOS setup doesn't reflect what outputs should be
used at runtime, and certainly not the correct configuration of the
enabled outputs. For example, if we went to this, the giant monitor
attached to my laptop that I actually
On Wed, 26 Aug 2009, Dave Airlie wrote:
If you actually detected things _right_, none of this would be an issue.
But you don't. And you seem to have a really hard time even admitting
that. You try to re-detect things, and you SCREW UP.
This isn't anything to do with redetection, and
On Wed, 26 Aug 2009, Zhenyu Wang wrote:
We can't depend on any BIOS display config as you noted before our driver.
But you do. You depend on the even _less_ reliable existence of a VBT
table.
And our driver does more flexible config than VBIOS does.
If by flexible you mean doesn't work
On Wed, 26 Aug 2009, Dave Airlie wrote:
3. Here's the thing, we do detect something has changed, we detect we no
longer have a monitor connected on the mac mini because the routing
for the DDC pins is insane and need special treatment in the driver.
That's the second thing - DDC in general
On Thu, 8 Oct 2009, Dave Airlie wrote:
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Its had a recent merge because it was definitely getting non-trivial to
fixup,
non-radeon-kms: adds proper fb layer colormap
On Thu, 10 Dec 2009, Dave Airlie wrote:
The biggest missing feature [ ... ]
No, the biggest missing feature is that Fedora is _still_ shipping
Nouveau, and I'm _still_ not seeing Red Hat people actively trying to get
it merged into mainline.
What the _hell_ is going on?
On Thu, 10 Dec 2009, Xavier Bestel wrote:
Last time they were asked that, they wanted to be free of changing their
kernel/userspace interface before upstreaming.
I've heard all the excuses. If it isn't ready, they shouldn't ship it to
millions of people. And if it's ready, they should work
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
You assume that Red Hat has full control over the project, which i
don't think is the case. The reason it isn't in staging yet (as far as
i know) is because of some questions over the copyright of some
(essential) microcode. Either the question
On Thu, 10 Dec 2009, Stephane Marchesin wrote:
I'm not sure why people are arguing so much over this, given that no
nouveau devs were at the kernel summit, and we only heard rumours
afterwards that there were complaints about us not being ready for
merging.
The thing is, my complaint is
On Thu, 10 Dec 2009, Alan Cox wrote:
But not only is Fedora not following the rules,
You changed the rules. You require a Signed-off-by:. Fedora can no more
add a signed off by than you can. It's not their code nor Red Hat's code
any more than they own the kernel because they pay
On Thu, 10 Dec 2009, C. Bergström wrote:
Thanks for the rather lengthly explanation, but in case you missed what people
are trying to say here..
With all due respect Linus..
patches welcome
The problem is that I have never even heard a Red Hat or Fedora person
actually acknoledge
On Fri, 11 Dec 2009, Dave Airlie wrote:
I'm going to see what Ben can do with a firmware loader and the ctxprogs,
we can send a patch that contains all the other bits of the driver, however
since the ctxprogs aren't currently something we can add Signed-off-by to,
someone else will have to
On Fri, 11 Dec 2009, Jeff Garzik wrote:
F11 uses nouveau here. It is actually a pain to get 'nv' going as an
alternate -- bugs have been filed. Makes kernel dev more difficult for me. I
was actually told, by Fedora people, that I should be hacking on the Fedora
(rpm-based) kernel,
On Fri, 11 Dec 2009, Dave Airlie wrote:
Please pull the 'drm-nouveau-pony' branch from
PONIES! Yay! I lurve ponies!
And it works for me too. Needed to get the firmware from the fedora
project, and make sure that it loads as a module rather than built in (so
that it can find the
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki r...@sisk.pl
Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement
new pm ops for i915), among other things, removed the .suspend and
.resume pointers from the struct drm_driver object in i915_drv.c,
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
Which is functionally equivalent to my patch, because i915_suspend/resume()
won't be called by drm_class_suspend/resume() in the KMS case anyway.
Ahh, right you are - that class suspend function does a check for
DRIVER_MODESET, and only does the
On Sat, 9 Jan 2010, Jerome Glisse wrote:
On Fri, Jan 08, 2010 at 06:50:41PM -0800, Jesse Barnes wrote:
Linus, can we ever drop those old paths? Maybe after the new bits have
been around for awhile? Users of really old userspace stacks would
lose 3D support, but they'd still have 2D,
101 - 200 of 263 matches
Mail list logo
