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

[Michal Soltys]

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