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

Tobias Powalowski t.powa at gmx.de
Sat Mar 8 11:59:33 EST 2008

> >  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 

> >  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.

Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
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>

More information about the arch-dev-public mailing list