[arch-dev-public] [signoff] udev 118-4

[Tobias Powalowski]

> >  no signoff
> >  please add the framebuffer blacklist again to load-modules.sh
>
> This is a terrible place for it, as I tried to explain on IRC. We
> should not explicitly block a set of modules here. If we don't want
> them, then why the hell do we even put them in our kernel?
There was a request from people who wants to use it.
You need user interaction to get them working.

> If we do want them, then blacklist them correctly, which means people
> can have the option of *not* blacklisting them.
You need parameters to enable the funtionality,
disable the built in vesa framebuffer on kernel boot prompt and load the 
correct framebuffer module by rc.conf.

> >, it's not
> >  possible to block framebuffer loading by udev rules.
>
> Can you please explain why? Thanks.
Show me the rule which would do it?
It is triggered by the pci subsystem so there is no chance in blocking it from 
loading.

> >  framebuffer modules can cause weird issues for amd/ati and nvidia binary
> >  drivers.
>
> Sure, but not everyone uses a binary driver, and/or even xorg for that
> matter.
Why to cause trouble for people, where it is not needed?

> I feel like I'm just being a naysayer here without actually providing
> a way to fix it, but this just seems like such a backwards way to fix
> a problem to me.
Well going backwards at least fixes issues here, 
sure it could be probably done also by a generated blacklist which is only 
generated once, but we need to do something here.

greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa at archlinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080308/e247329f/attachment.pgp>