[arch-dev-public] [RFC] removing blacklisting of framebuffers from the udev package
Hi guys, Currently the udev package ships /lib/modules.d/framebuffer_blacklist.conf This file blacklists all the framebuffer modules present on the build machine. This does not feel quite right to me, and it is not exactly self-documenting what bug is being fixed. If possible, I'd like to drop this file and add more specific blacklisting where needed. If I understand correctly, the main issue is in the case where proprietary drivers are used (nvidia / catalyst) and the opensource drivers are loaded instead. If this is the only problem, I'd like to propose we solve it as follows: Add /lib/modules.d/nvidia.conf: blacklist nouveau blacklist nvidiafb to the nvidia package (and analogously to the catalyst package in aur). This is exactly what /lib/modules.d is for, so it makes a lot of sense to me. Are there any other use-cases I have missed? I'll push an udev package with this change to staging shortly, so people can try it out if they wish. Cheers, Tom
On 02/07/2012 06:59 PM, Tom Gundersen wrote:
Hi guys,
Currently the udev package ships
/lib/modules.d/framebuffer_blacklist.conf
This file blacklists all the framebuffer modules present on the build machine. This does not feel quite right to me, and it is not exactly self-documenting what bug is being fixed.
If possible, I'd like to drop this file and add more specific blacklisting where needed. If I understand correctly, the main issue is in the case where proprietary drivers are used (nvidia / catalyst) and the opensource drivers are loaded instead. If this is the only problem, I'd like to propose we solve it as follows:
Add
/lib/modules.d/nvidia.conf: blacklist nouveau blacklist nvidiafb
to the nvidia package (and analogously to the catalyst package in aur).
instead of trying to avoid such issues, why not drop most of framebuffers from kernel instead? that's a more logical step. for example, fedora only has enabled in his kernel: config-generic:CONFIG_VIDEO_FB_IVTV=m config-generic:CONFIG_FB_I810=m config-generic:CONFIG_FB_I810_GTF=y config-generic:CONFIG_FB_I810_I2C=y config-generic:CONFIG_FB_TILEBLITTING=y config-generic:CONFIG_FB_VESA=y config-generic:CONFIG_FB_VGA16=m config-generic:CONFIG_FB_VIRTUAL=m config-generic:CONFIG_FB_VOODOO1=m config-generic:CONFIG_FB_EFI=y config-generic:CONFIG_FB_UDL=m
This is exactly what /lib/modules.d is for, so it makes a lot of sense to me. Are there any other use-cases I have missed?
I'll push an udev package with this change to staging shortly, so people can try it out if they wish.
Cheers,
Tom
-- Ionuț
On Tue, Feb 7, 2012 at 6:14 PM, Ionut Biru <ibiru@archlinux.org> wrote:
instead of trying to avoid such issues, why not drop most of framebuffers from kernel instead?
Either (or both) approaches are fine with me. I don't know if anyone uses the fb modules... -t
Am 07.02.2012 18:56, schrieb Tom Gundersen:
On Tue, Feb 7, 2012 at 6:14 PM, Ionut Biru <ibiru@archlinux.org> wrote:
instead of trying to avoid such issues, why not drop most of framebuffers from kernel instead?
Either (or both) approaches are fine with me. I don't know if anyone uses the fb modules...
-t
I guess it should be save to remove those old fb drivers; esp. those which have newer replacements. -- Pierre Schmitz, http://pierre-schmitz.com
On Tue, Feb 7, 2012 at 6:14 PM, Ionut Biru <ibiru@archlinux.org> wrote:
instead of trying to avoid such issues, why not drop most of framebuffers from kernel instead?
that's a more logical step.
for example, fedora only has enabled in his kernel:
config-generic:CONFIG_VIDEO_FB_IVTV=m config-generic:CONFIG_FB_I810=m config-generic:CONFIG_FB_I810_GTF=y config-generic:CONFIG_FB_I810_I2C=y config-generic:CONFIG_FB_TILEBLITTING=y config-generic:CONFIG_FB_VESA=y config-generic:CONFIG_FB_VGA16=m config-generic:CONFIG_FB_VIRTUAL=m config-generic:CONFIG_FB_VOODOO1=m config-generic:CONFIG_FB_EFI=y config-generic:CONFIG_FB_UDL=m
Following up on this. rivafb, nvidiafb and nouveau (which are all enabled in our kernel) conflict. Unless there are good reasons not to, I suggest at least disabling rivafb and nvidiafb. Until now they were blacklisted by a modprobe config file, so people would have to mask the blacklisting file in order to make them work. Thomas, Tobias, what do you think? Cheers, Tom
On Wed, Feb 15, 2012 at 8:57 AM, Tom Gundersen <teg@jklm.no> wrote:
this. rivafb, nvidiafb and nouveau (which are all enabled in our kernel) conflict. Unless there are good reasons not to, I suggest at least disabling rivafb and nvidiafb.
I asked about this in #nouveau (as I don't have much clue about nvidia drivers/hardware): [09:12] <tomegun> [...] any reason at all to keep the old nvidiafb/rivafb modules around in a standard kernel, or are their usecases covered well by nouveau these days? [09:13] <airlied> should all be covered by nouveau really, maybe some ppc corner cases [...] [09:17] <RSpliet> NV03 (nVidia Riva 128) is not supported by nouveau [09:17] <RSpliet> dropping... well... probably rivafb, might cause small problems on these ancient machines (1998) [09:18] <tomegun> RSpliet: ah, ok. thanks [09:19] <pq> or maybe they'd better use a generic fb driver... [09:20] <RSpliet> pq: sounds sane too -t
+1 for dropping ancient framebuffer modules. -Andy
participants (4)
-
Andreas Radke
-
Ionut Biru
-
Pierre Schmitz
-
Tom Gundersen