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
