Bug#927219: xorg log
Hi Jonathan,
Jonathan Carter:
> KMS seems to work just fine, I see the full-resolution plymouth splash,
> it's only when Xorg starts when the screen goes blank (I can switch to
> VTs though).
Well, it may work well enough for Plymouth but both the kernel and
X.Org try to use modesetting and fail:
- In the Live kernel logs I see:
[drm] radeon kernel modesetting enabled.
[drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or later requires firmware installed
See https://wiki.debian.org/Firmware for information about missing firmware
- … which probably explains:
(II) [KMS] drm report modesetting isn't supported.
On that Live system, X.Org tries in turn the ati, modesetting, fbdev,
and vesa drivers. My understanding is that they all fail, some by
nicely detecting they can't work without full KMS support, and the
vesa driver (I think, since fbdev has been unloaded already at this
point) less nicely: it bails out.
While on your installed system, you, or d-i, or something else, has
explicitly disabled KMS, presumably to workaround the problem this
bug report is about:
> [ 23.526] Kernel command line:
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64
> root=UUID=857f7028-b03d-465d-a5db-c8dfb12dc02b ro quiet nomodeset
^^^^^^^^^
Then in a context where it's clear(er) that KMS is not fully
supported, X.Org manages to fall back to the vesa driver, which
somehow manages to display something in degraded mode.
I'm no expert in this field but it seems to me that on the Live
system, the X.Org vesa video driver fails to detect that it's running
in an environment where KMS is enabled but not fully supported, and
then does not fall back to degraded mode. Either the kernel exposes an
interface that would theoretically allow vesa to identify this
situation and accordingly switch to degraded mode, and then it's a bug
in the vesa driver. Or the kernel does not, and vesa is unavoidably
mislead into believing KMS is fully functional, and then it's a bug in
the kernel. It would be nice to check if there are known kernel or
X.Org bugs in this area, and if not, ask their respective maintainers
guidance wrt. where to reassign this bug report.
On the Debian Live front, apart of documenting the known issue and its
workaround (add "nomodeset" on the kernel command line), it may
technically be possible to workaround this bug for images that use
syslinux: dynamically add "nomodeset" to the kernel command line if an
affected PCI device is detected (using lua.c32). I don't know if
that's possible with GRUB.
Cheers,
--
intrigeri
Reply to: