On Sun, 30 Aug 2020 19:08:00 +0200 Michael Biebl <bi...@debian.org> wrote: > Control: reassign -1 udev > Control: tags -1 + moreinfo > > Am 30.08.20 um 12:21 schrieb Chris Hofstaedtler: > > Control: reassign -1 systemd > > > > * Michal Suchanek <hramr...@gmail.com>: > >> So I would like the fbdev modules removed from whatever blacklist prevents > >> loading them and have them loaded on systems that don't have dri modules to > >> handle graphics. > > > > AFAICT systemd ships the fbdev blacklist nowadays, reassigning > > there. > > The udev package does (but it's src:systemd, so close enough) in > /lib/modprobe.d/fbdev-blacklist.conf > > I don't know the history behind this file though, it predates the > udev/systemd merge and a quick search in the old src:udev package did > not really yield anything useful. > > Hopefully Marco can chime in here and provide some context why it was > added and if it's still required thoday.
The old-style fbdev drivers generally cannot coexist with user-mode graphics drivers or DRM drivers for the same devices (but the latter can coexist with each other). The fbdev API provides very little opportunity for X graphics acceleration, so it's generally preferable to use X with user-mode graphics drivers (or the newer combined DRM/KMS drivers). Therefore the fbdev drivers were blocked from auto-loading by default. I believe this file used to be a conffile in /etc so that it was possible to override it in case the user prefers the fbdev driver. This does not explain why listing atyfb in a modules list does not work; the "blacklist" directive should not affect that. Ben. -- Ben Hutchings The Peter principle: In a hierarchy, every employee tends to rise to their level of incompetence.
signature.asc
Description: This is a digitally signed message part