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
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
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 Fedora driver for NVIDIA hardware makes that
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
On 12/11/2009 04:18 AM, Alan Cox wrote:
F11 certainly shipped some bits of it for 2D support. I am not sure if
F10 shipped a purely userspace set up. Neither had it enabled as the
default driver - they used nv or vesa depending upon the card.
F11 uses nouveau here. It is actually a pain to
On 12/11/2009 10:28 AM, Linus Torvalds wrote:
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
Ian Romanick wrote:
So, you have x_ata.ko and y_ata.ko that are both linked with libata.
What happens when when the user loads both modules at once? How do you
avoid symbol conflicts from the libata linked to both drivers? This is
basically what the DRM does, but we have the evil macros (no,
On Mon, Oct 27, 2003 at 03:14:11PM +, Keith Whitwell wrote:
Jeff Garzik wrote:
Thank you for saying it. This is what I have been preaching (quietly)
for years -- command submission and synchronization (and thus, DMA/irq
handling) needs to be in the kernel. Everything else can
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
Graphics processors are growing more general, too -- moving towards
generic vector/data processing engines. I bet you'll see an optimal
model emerge where you have some sort
Linus Torvalds wrote:
Quite frankly, I'd much rather see a low-level graphics driver that does
_two_ things, and those things only:
- basic hardware enumeration and setup (and no, basic setup does not
mean mode switching: it literally means things like doing the
pci_enable_device() stuff.
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote:
So wouldn't it be nice if we just had those ten lines as a generic
function like
int pci_enable_rom(struct pci_device *dev)
{
...
int pci_disable_rom(..);
Yes. Agreed,
Jeff
Linus Torvalds wrote:
[ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is
there some helper function I missed? ]
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
Larry McVoy wrote:
A few comments on why I don't like this patch:
1) It's a formatting only patch. That screws over people who are using
BK for debugging, now when I double click on these changes I'll get
to your cleanup patch, not the patch that was the last substantive
Larry McVoy wrote:
On Mon, Aug 11, 2003 at 01:53:17PM -0400, Jeff Garzik wrote:
Larry McVoy wrote:
are function calls at a 10-nanosecond glance. Also, having two styles
of 'if' formatting in your example just screams inconsistent to me :)
It is inconsistent, on purpose. It's essentially like
Larry McVoy wrote:
On Mon, Aug 11, 2003 at 01:15:58PM -0400, Jeff Garzik wrote:
if (expr) statement; // OK
The test and the statement run together visually, which is it is
preferred to put the statement on the following line.
Nah.
if (!p) return (whatever);
if (foo
Larry McVoy wrote:
That ought to be balanced with don't screw up the revision history, people
use it. It's one thing to reformat code that is unreadable, for the most
part this code didn't come close to unreadable.
Granted.
I wasn't suggesting that. I was saying
if (expr) statement; // OK
16 matches
Mail list logo
