Your message dated Sun, 28 Mar 2021 04:46:48 +0200
with message-id <[email protected]>
and subject line Re: Bug#840897: general: framebuffer modules for non-dri
graphics cards are not loaded
has caused the Debian Bug report #840897,
regarding general: framebuffer modules for non-dri graphics cards are not loaded
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
840897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840897
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: general
Severity: normal
Hello,
I dusted off a notebook with hardware serial port which also happens to have a
Mach64 graphics card.
Accidentally during system upgrade an extra display manager was installed which
broke the text console. Running two X servers without KMS is problematic.
Upstream has a solution that should prevent most of these problems. The current
X drivers seem to work reasonably well with fbdev so long as the fb module is
loaded before the X server is started. At least the Mach64 driver looks ok.
Since the X driver appears to have fbdev integration it should not break the
console so long as fbdev is available.
Unfortunately, atyfb is not loaded by Debian. What's worse, adding the driver
to /etc/modules or /etc/initramfs-tools/modules has no effect. The module is
not loaded.
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.
Thanks
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)
Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Am 01.09.2020 um 20:16 schrieb Michael Biebl:
Am 01.09.20 um 19:43 schrieb Ben Hutchings:
On Sun, 30 Aug 2020 19:08:00 +0200 Michael Biebl <[email protected]> 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 <[email protected]>:
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.
Thanks for this additional information, Ben.
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.
You can still do that by creating a file
/etc/modprobe.d/fbdev-blacklist.conf which will override the one from /lib.
This does not explain why listing atyfb in a modules list does not
work; the "blacklist" directive should not affect that.
Maybe the user did not rebuild his initramfs and the initramfs already
loaded the non-fb driver, so loading fbdev failed?
Michal, can you still reproduce the problem after running
update-initramfs -u ?
Ben listed a few convincing arguments, why we should keep the blacklist
for the fbdev drivers by default.
As said, you can override that locally though.
Thus closing the issue.
Regards,
Michael
--- End Message ---
