Re: [arch-general] [arch-dev-public] [signoff] udev 118-4
You can block frambuffer in udev, but you have to block the driver by its modalias or other attributes (similary as if you tried to block sound through udev). For example, following rule would do the thing in my case, on one of my machines (that has some old ati card): SUBSYSTEM=="pci", ATTR{vendor}=="0x1002", ATTR{device}=="0x5446", OPTIONS="ignore_device" Or you could just use modalias. For example - provide auto generated 03-fb-block.rules by PKGBUILD in form similar to: ACTION!="add", GOTO="fb_block_end" DRIVER=="?*", GOTO="fb_block_end" ENV{MODALIAS}!="?*", GOTO="fb_block_end" ENV{MODALIAS}=="modaliases #1", OPTION="ignore_device" ENV{MODALIAS}=="modaliases #2", OPTION="ignore_device" ..... LABEL="fb_block_end" This should be blazing fast, without any need for extra logic in module loading scripts you call from udev. Moreover - if users don't want it - they can simply mv or rm that file. However you name the file, make sure it's parsed before big compound udev.rules you use. Btw - is there any reason why fbcon is built into kernel, instead of being left as a module (also, fbcon never loads automatically) ? Consoles are not taken until fbcon is activated - so maybe it would solve the issue with binary blobs having problems with active framebuffer driver. Just a thought (although as per fbcon documentation, depending on how well the framebuffer driver is written, consoles might end with garbaged screen w/o fbcon ; they shouldn't though). cheers Michal
On Sun, Mar 09, 2008 at 10:05:04AM +0100, Michal Soltys wrote:
Btw - is there any reason why fbcon is built into kernel, instead of being left as a module (also, fbcon never loads automatically) ? Consoles are not taken until fbcon is activated - so maybe it would solve the issue with binary blobs having problems with active framebuffer driver. Just a thought (although as per fbcon documentation, depending on how well the framebuffer driver is written, consoles might end with garbaged screen w/o fbcon ; they shouldn't though).
I needed to have fbcon built in for uvesafb to work. But when put in the initrd, it worked too. So maybe this could simply be done by the v86d hook. http://bbs.archlinux.org/viewtopic.php?pid=337963#p337963
On Sun, Mar 9, 2008 at 3:05 AM, Michal Soltys <soltys@ziu.info> wrote:
ENV{MODALIAS}=="modaliases #1", OPTION="ignore_device" ENV{MODALIAS}=="modaliases #2", OPTION="ignore_device"
This is way more complex than you think it is. Let me explain. A typical module exposes it's aliases WITH wildcartds included. Here's an example: $ modinfo nvidiafb alias: pci:v000010DEd*sv*sd*bc03sc*i* If you want to write out modalias rules for this, you are welcome to. I will give you a hint, though: each of those asterisks above is a 4 digit number. And that is just nvidia. Don't forget intel, ati, unichrome, and all the other framebuffer modules out there. No, if this were my decision, "blacklist nvidiafb" makes much more sense. And it's only one line.
Aaron Griffin wrote:
On Sun, Mar 9, 2008 at 3:05 AM, Michal Soltys <soltys@ziu.info> wrote:
ENV{MODALIAS}=="modaliases #1", OPTION="ignore_device" ENV{MODALIAS}=="modaliases #2", OPTION="ignore_device"
This is way more complex than you think it is. Let me explain. A typical module exposes it's aliases WITH wildcartds included. Here's an example:
$ modinfo nvidiafb alias: pci:v000010DEd*sv*sd*bc03sc*i*
If you want to write out modalias rules for this, you are welcome to. I will give you a hint, though: each of those asterisks above is a 4 digit number. And that is just nvidia. Don't forget intel, ati, unichrome, and all the other framebuffer modules out there.
But you can use that alias as-is in udev rules, as wildcards are supported. As for generating, something analogous to... cat >03-fb-block.rules <<EOF ACTION!="add", GOTO="fb_block_end" DRIVER=="?*", GOTO="fb_block_end" ENV{MODALIAS}!="?*", GOTO="fb_block_end" EOF for i in `find /lib/modules/$(uname -r)/kernel/drivers/video/ -iname "*fb*.ko"` ; do modinfo "$i" | sed -ne 's/alias: *\(.*\)/ENV{MODALIAS}=="\1" OPTIONS="ignore_device"/ ;/^ENV/p'
03-fb-block.rules ; done
cat >>03-fb-block.rules <<EOF LABEL="fb_block_end" EOF ...would do the thing. The file is not tiny though ~300 rules for Arch's generic kernel. But it's not an issue of any sort for udevd. My general idea was to get that into kernel's, or udev's PKGBUILD.
On Sun, Mar 9, 2008 at 6:36 PM, Michal Soltys <soltys@ziu.info> wrote:
Aaron Griffin wrote:
On Sun, Mar 9, 2008 at 3:05 AM, Michal Soltys <soltys@ziu.info> wrote:
ENV{MODALIAS}=="modaliases #1", OPTION="ignore_device" ENV{MODALIAS}=="modaliases #2", OPTION="ignore_device"
This is way more complex than you think it is. Let me explain. A typical module exposes it's aliases WITH wildcartds included. Here's an example:
$ modinfo nvidiafb alias: pci:v000010DEd*sv*sd*bc03sc*i*
If you want to write out modalias rules for this, you are welcome to. I will give you a hint, though: each of those asterisks above is a 4 digit number. And that is just nvidia. Don't forget intel, ati, unichrome, and all the other framebuffer modules out there.
But you can use that alias as-is in udev rules, as wildcards are supported.
Wow, I actually didn't know that is allowed wildcard matching on the MODALIAS rules. Woohoo!
participants (3)
-
Aaron Griffin
-
Michal Soltys
-
Xavier