[Nouveau] [Bug 60772] xf86-video-nouveau fails to modprobe nouveau: KMS not enabled

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60772

--- Comment #14 from Honza <hkmaly at bigfoot.com> ---
(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-one is saying there is a need for (other) patch(es)
> 

"If you really want to change the behaviour, send a patch, ping people, etc."

> > I fail to see why you think it's necessary to change behaviour of
> > xf86-video-nouveau to support less workflows just to force the workflow you
> > prefer. All replies against this patch I saw was on ideological ground, none
> > presented any real reason why it's better this way.
> > 
> Afaics thing will work fine if you use udev/eudev/mdev over linux-hotplug.
> In the latter of which I cannot see any progress (or changes) over the last
> few years.
> 

I successfully ignored devfs. Fads like that come and go. No need to change
what's working. Current attempts of integrating pulseaudio and init doesn't
convince me udev is stable. Sure, sysvinit didn't have much change in last few
years ... because it's working. Systemd, on the other hand ...

> Whereas for the ideological ground - I think that the maintainer of the
> kernel drm subsystem(Dave) would know better. Yes a bit more information
> would not hurt, but considering the other drivers are doing this I do not
> see it as a wrong thing/bikeshedding.
> 
> Btw, I believe he already mentioned that it's racy :)
> 

He mentioned that there is race when you start the module and X server
immediately starts using it. If you start udev and immediately after it start
X, the race will still be there, wouldn't it? In fact, it will be even worse,
as udev doesn't exactly have predictable timing.

With distributions trying to make startup fast and parallel and often starting
display managers-based logins, I'm actually surprised it works.

If the code would be supposed to solve the race, it would contain cycle
sleeping until some ioctl returns the module finished initialization. Probably
with timeout around 30 seconds.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20130822/013fb196/attachment.html>