Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211619 > unrolled thread

Re: Psychedelic GUI after stable update to buster

Back to article view | Back to linux.debian.user

Contents

  Re: Psychedelic GUI after stable update to buster hobie@rumormillnews.com - 2019-07-22 02:20 +0200
    Re: Psychedelic GUI after stable update to buster Felix Miata <mrmazda@earthlink.net> - 2019-07-22 02:40 +0200
      Re: Psychedelic GUI after stable update to buster hobie@rumormillnews.com - 2019-07-22 10:40 +0200
        Re: Psychedelic GUI after stable update to buster Felix Miata <mrmazda@earthlink.net> - 2019-07-22 12:00 +0200
          Re: Psychedelic GUI after stable update to buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-22 18:50 +0200
            Re: Psychedelic GUI after stable update to buster Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-22 22:00 +0200
              Re: Psychedelic GUI after stable update to buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-07-23 00:20 +0200

#211619 — Re: Psychedelic GUI after stable update to buster

> On 21/07/2019 22.04, hobie@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

[toc] | [next] | [standalone]

#211620

hobie@rumormillnews.com composed on 2019-07-21 20:13 (UTC-0400):

> my console is no longer 80x25, the way I want it; it's something much smaller,
> pretty much impossible for me to read.

At 1600x900 you're seeing 200x56 with the standard 16x8 font.

> 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.

Add to cmdline:

	video=640x400

I usually use video=1440x900 to produce 180x56.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#211627

> hobie@rumormillnews.com composed on 2019-07-21 20:13 (UTC-0400):
>
>> my console is no longer 80x25, the way I want it; it's something much
>> smaller,
>> pretty much impossible for me to read.
>
> At 1600x900 you're seeing 200x56 with the standard 16x8 font.
>
>> 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.
>
> Add to cmdline:
>
> 	video=640x400
>
> I usually use video=1440x900 to produce 180x56.
> --

Thanks, Felix. :) It works, and I could get used to it. :)  Yet it's not
the same thing that was there before, with 'nomodeset' in the command
line.  It now takes up all the display real estate, stretching from
side-to-side, where before there were margins on either side.  I'm
guessing 'nomodeset' leads to essentially a VGA display, while
video=640x400 leads to a graphic display that's similar to the VGA one...?
 I made a few tries at using the 'vga=' parameter talked about in docs on
the Web but I get the impression it's no longer used. (?)

As I said, I could get used to this and live contentedly with it. :)  But
it seems odd not to be able easily to regain the console display I was so
used to for so many years.

--hobie

[toc] | [prev] | [next] | [standalone]

#211628

hobie@rumormillnews.com composed on 2019-07-22 04:37 (UTC-0400):

> Thanks, Felix. :) It works, and I could get used to it. :)  Yet it's not
> the same thing that was there before, with 'nomodeset' in the command
> line.  It now takes up all the display real estate, stretching from
> side-to-side, where before there were margins on either side.  I'm
> guessing 'nomodeset' leads to essentially a VGA display, while
> video=640x400 leads to a graphic display that's similar to the VGA one...?
>  I made a few tries at using the 'vga=' parameter talked about in docs on
> the Web but I get the impression it's no longer used. (?)

> As I said, I could get used to this and live contentedly with it. :)  But
> it seems odd not to be able easily to regain the console display I was so
> used to for so many years.

KMS overrides vga=. Nomodeset disables KMS, allowing vga=normal or nothing at all
to produce 80x25.

Since your display is in fact a widescreen display, you might wish to try a
proportionally better video mode, e.g. video=1024x600 to produce 128x37, 1024x576
to produce 128x36, 960/540 to produce 120x33, or video=720x480 to produce 90x30.
The text in each will be smaller than 80x25, but proportionally correct, and
likely as big as you really need. Next step tinier text would be 1280x720, very
roughly 1/3 bigger than the mousetype you get with your screen's native 1600x900.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#211645

[Multipart message — attachments visible in raw view] — view raw

On 22/07/2019 11.57, Felix Miata wrote:
> hobie@rumormillnews.com composed on 2019-07-22 04:37 (UTC-0400):
> 
>> Thanks, Felix. :) It works, and I could get used to it. :)  Yet it's not
>> the same thing that was there before, with 'nomodeset' in the command
>> line.  It now takes up all the display real estate, stretching from
>> side-to-side, where before there were margins on either side.  I'm
>> guessing 'nomodeset' leads to essentially a VGA display, while
>> video=640x400 leads to a graphic display that's similar to the VGA one...?
>>  I made a few tries at using the 'vga=' parameter talked about in docs on
>> the Web but I get the impression it's no longer used. (?)
> 
>> As I said, I could get used to this and live contentedly with it. :)  But
>> it seems odd not to be able easily to regain the console display I was so
>> used to for so many years.
> 
> KMS overrides vga=. Nomodeset disables KMS, allowing vga=normal or nothing at all
> to produce 80x25.
> 
> Since your display is in fact a widescreen display, you might wish to try a
> proportionally better video mode, e.g. video=1024x600 to produce 128x37, 1024x576
> to produce 128x36, 960/540 to produce 120x33, or video=720x480 to produce 90x30.
> The text in each will be smaller than 80x25, but proportionally correct, and
> likely as big as you really need. Next step tinier text would be 1280x720, very
> roughly 1/3 bigger than the mousetype you get with your screen's native 1600x900.
> 

Good Day,

Orthogonally, you may also want to investigate the use of
setupcon(1) and the configuration file console-setup(5) to set
alternative, more readable font.  The configuration file is
stored in /etc/default/console-setup.

Mine looks like:

	# Consult the console-setup(5) manual page.
	ACTIVE_CONSOLES="/dev/tty[1-6]"
	CHARMAP="UTF-8"
	CODESET="guess"
	FONTFACE="TerminusBold"
	FONTSIZE="12x24"
	BEEP="polite"
	VIDEOMODE=

But you could specify a font size up to 16x32 px per character,
if you wish so.  Once a change is done, just type:

	$ setupcon

And there it is, a readable font!

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

[toc] | [prev] | [next] | [standalone]

#211653

[Multipart message — attachments visible in raw view] — view raw

On Lu, 22 iul 19, 18:41:01, Étienne Mollier wrote:
> 
> Orthogonally, you may also want to investigate the use of
> setupcon(1) and the configuration file console-setup(5) to set
> alternative, more readable font.  The configuration file is
> stored in /etc/default/console-setup.

Or just run 'dpkg-reconfigure console-setup' ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#211659

[Multipart message — attachments visible in raw view] — view raw

On 22/07/2019 21.52, Andrei POPESCU wrote:
> On Lu, 22 iul 19, 18:41:01, Étienne Mollier wrote:
>> Orthogonally, you may also want to investigate the use of
>> setupcon(1) and the configuration file console-setup(5) to set
>> alternative, more readable font.  The configuration file is
>> stored in /etc/default/console-setup.
> Or just run 'dpkg-reconfigure console-setup' ;)

True, I should have mentioned that, since I used it a few times
myself in the past.  The fact is, I have less difficulties
dealing with data sets rather than functions.  Sometimes it is a
bad habit, and sometimes it comes from the extensive use of
heavy duty administrative tools, such as Thomas Lange's FAI.

Furthermore, I don't recall having seen the possibility to set
a "polite" BEEP using dpkg-reconfigure, but I probably missed a
few options.  ;)

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>
               5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web