On Sun, Mar 9, 2008 at 8:48 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Sonntag, 9. März 2008 schrieb Aaron Griffin:
Er? No. Modprobe loads it. udev calls a script that calls modprobe. We are not talking about where the CURRENT frambuffer blacklist exists, because I'm sure we all agree it is inefficient and broken. I'm talking about where it SHOULD be.
A file which belongs to a package that will affect also an other is bad. Placing it in kernel package is bad because it might interfere with an other kernel package. Placing the file in udev affects all kernels the same and udev is our primary module loader for now.
But, that's exactly my point. This is only an issue with OUR kernel. If some custom kernel builds in different framebuffer modules, or even only includes the one that is needed, then the blacklisting is moot. The need to blacklist this modules is ONLY an artifact of the way we build the kernel.
Just for your information, i have a full splitup rule udev here now.
I'm not sure what this means? The udev.rules? Shouldn't we just be using (mostly) default rules from the udev source? I notice our PKGBUILD deletes a lot of rules. Why don't we just... not delete these, and then add our own like all the other distros do (i.e. 50-archlinux.rules)
about blacklisting, problem with modprobe.d/frambuffer would be if a modprobe.conf is present it ignores the modprobe.d/ directory completly :(
Ew, I just noticed that. That's a little annoying that it only loads one or the other. There are two solutions to that though: 1) Add "include /etc/modprobe.d" to the default modprobe.conf 2) Patch modprobe to not stop after the first thing found