> On 21/07/2019 22.04, ho...@rumormillnews.com wrote: >> Thanks. :) Result: no observable change. Thankfully, my console's still >> at 80x25. But the shift to psychedelic colors is still there, too. What the heck is this all about...?? > Greetings, > That is a good question. What does your kernel tell you this > time? (Use the command dmesg, and perhaps inxi if the driver > loads happily, to get this information hopefully.)
inxi -Gxxxz Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: N/A bus ID: 00:01.0 chip ID: 1002:130f Display: x11 server: X.Org 1.20.4 driver: ati,vesa unloaded: fbdev,modesetting,radeon resolution: 1600x900~N/A OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon' [ 0.337851] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G (family: 0x15, model: 0x38, stepping: 0x1) [ 2.013894] [drm] amdgpu kernel modesetting enabled. [ 2.024926] amdgpu 0000:00:01.0: CIK support provided by radeon. [ 2.024927] amdgpu 0000:00:01.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override. After editing at reboot, adding to grub's commandline as suggested in the output above, "Use radeon.cik_support=0 amdgpu.cik_support=1 to override," we get: dmesg | grep -iE 'amd-graphics|amdgpu|\<ati\>|fglrx|radeon' [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=c378147d-1aca-4d98-a589-6b47f02e0ef7 ro reboot=pci quiet radeon.cik_support=0 amdgpu.cik_support=1 [ 0.206295] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=c378147d-1aca-4d98-a589-6b47f02e0ef7 ro reboot=pci quiet radeon.cik_support=0 amdgpu.cik_support=1 [ 0.338735] smpboot: CPU0: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G (family: 0x15, model: 0x38, stepping: 0x1) [ 2.005560] [drm] amdgpu kernel modesetting enabled. [ 2.034351] amdgpu 0000:00:01.0: VRAM: 1024M 0x000000F400000000 - 0x000000F43FFFFFFF (1024M used) [ 2.034352] amdgpu 0000:00:01.0: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF [ 2.034510] [drm] amdgpu: 1024M of VRAM memory ready [ 2.034511] [drm] amdgpu: 3072M of GTT memory ready. [ 2.034619] [drm] amdgpu: dpm initialized [ 2.034885] [drm] AMDGPU Display Connectors [ 2.034926] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_pfp.bin [ 2.034941] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_me.bin [ 2.034955] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_ce.bin [ 2.034973] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_mec.bin [ 2.034990] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_mec2.bin [ 2.035004] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_rlc.bin [ 2.035433] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_sdma.bin [ 2.035445] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_sdma1.bin [ 2.035621] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_uvd.bin [ 2.035879] amdgpu 0000:00:01.0: firmware: direct-loading firmware amdgpu/kaveri_vce.bin [ 2.463006] fbcon: amdgpudrmfb (fb0) is primary device [ 2.946468] amdgpu 0000:00:01.0: fb0: amdgpudrmfb frame buffer device [ 2.973247] [drm] Initialized amdgpu 3.27.0 20150101 for 0000:00:01.0 on minor 0 Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu v: kernel bus ID: 00:01.0 chip ID: 1002:130f Display: x11 server: X.Org 1.20.4 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 1600x900~60Hz OpenGL: renderer: AMD KAVERI (DRM 3.27.0 4.19.0-5-amd64 LLVM 7.0.1) v: 4.5 Mesa 18.3.6 direct render: Yes I think this is the first time we've seen "resolution: 1600x900~60Hz" - previously it's always been "resolution: 1600x900~N/A". And it's the first time we've seen something other than llvmpipe as renderer. :) Settings->Display now lists 8 resolutions for the first time, too. THIS _MOSTLY_ SOLVES THE PSYCHEDELIC COLORS PROBLEM. :) I say "mostly" because my console is no longer 80x25, the way I want it; it's something much smaller, pretty much impossible for me to read. Experimenting, if I put 'nomodeset' back into the cmdline, at the -end- of the cmdline, the console displays at 80x25 - but the psychedelic colors also return. If I put 'nomodeset' earlier in the cmdline, console starts out at 80x25 but soon goes to something smaller, and the psychedelic colors go away. That leaves us with a few questions: - Why did this happen when 'buster' became the new 'stable'? - How can I get an 80x25 console without 'nomodeset' in the cmdline? Many thanks, Etienne, Alexander, Felix, Carl, Cindy Sue, and even bw, for the ideas, brainstorms, and general patience and for walking with me on this rather weird journey. :) If somehow we can get my 80x25 console back, I think we could declare total victory on this one. --hobie