https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #14 from Honza ---
(In reply to comment #13)
> (In reply to comment #11)
> > Mirkin: You might've overlooked it, but there IS patch in the message you
> > posted reference to. I don't see what other patch might be needed.
> >
> No-on
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #13 from Emil Velikov ---
To put this in another light
(In reply to comment #11)
> Mirkin: You might've overlooked it, but there IS patch in the message you
> posted reference to. I don't see what other patch might be needed.
>
No-o
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #12 from Honza ---
PS: Oh, and isn't "I hate it when things do stuff behind my back" argument
AGAINST udev?
--
You are receiving this mail because:
You are the assignee for the bug.
___
No
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #11 from Honza ---
Mirkin: You might've overlooked it, but there IS patch in the message you
posted reference to. I don't see what other patch might be needed.
Also, the behaviour I'm seeking is behaviour previous versions (like
xf86
https://bugs.freedesktop.org/show_bug.cgi?id=60772
Ilia Mirkin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #9 from Honza ---
I can confirm the patch works (and unlike how I switched the calls myself
probably cleans up after itself correctly :-)).
Dave Airlie: Isn't modules.conf obsolete?
Also, it's still kernel loading the driver, it's no
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #8 from Dave Airlie ---
having the X server load the module isn't supported, I don't care if it ever
worked before. Its racy and horrible. The way Linux works if you have a driver
the kernel is responsible for loading it, the X server
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #7 from Emil Velikov ---
Thanks for the information guys. All of those are valid cases which I have not
thought of (and to be honest this is the first time I've heard about
linux-hotplug)
The patch has been posted on the mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #6 from Honza ---
Should I post this bug on http://www.explainxkcd.com/wiki/index.php?title=1172
:-) ?
I repeat: there is NO mode switch in my workflow before starting X, therefore
no need for KMS. Power saving is also not needed, as
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #5 from Marcin Slusarz ---
Blacklisting nouveau module can lead to exactly this situation - nouveau is not
automatically loaded on boot, but can be loaded on request by xserver (if
configured to use nouveau).
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #4 from Emil Velikov ---
This case reminds me XKCD's "Workflow" [1]
Please note that KMS is not only about "shiny boot splash". Here is a snippet
from Arch's Wiki [2]
"...
Kernel Mode Setting (KMS) is a method for setting display re
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #3 from Honza ---
Probably due to the fact that lacking boot splash image, there is nothing which
would need the nouveau before :-).
(I have standard VGA text screen before loading X and I don't see any reason to
change that - it may
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #2 from Emil Velikov ---
On 18/02/13 00:47, Dave Airlie wrote:> On Sun, Feb 17, 2013 at 6:48 AM, Emil
Velikov wrote:
>> "Regression" caused by
>> commit e34cfbd5bd23f7f15372af52d8a39a5715ce7310
>> Author: Emil Velikov
>> Date: Fri
https://bugs.freedesktop.org/show_bug.cgi?id=60772
--- Comment #1 from Emil Velikov ---
Created attachment 74945
--> https://bugs.freedesktop.org/attachment.cgi?id=74945&action=edit
Fix
To be honest I am a little confused why your system does not load nouveau at an
earlier stage, rather than r
14 matches
Mail list logo
