[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Setting a console resolution



>> In addition, on the computer with the Matrox-adapter running
>> something as simple as 'dmesg -T' is really really slow. It literally
>> takes several seconds while the text scrolls on the screen.
>> The thing is, I do not really care about fancy framebuffer resolution and
>> graphics on the console. I just want fairly big text that scrolls
>> without hiccups, even in 640x480 :P
>[...]
> It is true that "video=800x600" works, but "video=800x600x32" (what the
> OP had tried) does not.  The color depth, if any, has to be preceded by
> a '-' sign, i.e. "video=800x600-32", see Documentation/fb/modedb.txt[1].

The OP may wish to specify colour depth; but probably *not* 32, because:

* fbcon uses memcpy, so on x86 at least it occupies CPU/RAM cycles.
  If you have an Atom (or a Celeron, like me), it can end up quite slow.
* memcpy speed correlates roughly linearly to the amount copied
* The memory required to display a screen of pixels scales with colour depth.
* If you do not specify, _the default is 32 bits per pixel on mgag200_
  (on a 2MB G200SE it might default to 16 - see mgag200_driver_load)

If you just want console/ncurses, 8-bit is probably fine, and four times as fast! And if it's not enough you can still reduce the resolution a bit.

Here is the kernel (and real) time to run 'dmsg' on a 1280x1024 160x64 character framebuffer running on a Celeron G16510T@2.3Ghz:
8-bit - 2.660 sec
16-bit - 4.707 sec [seems broken here, looked super-dim]
24-bit - 8.074 sec
32-bit - 11.353 sec

24-bit is likely falling out of cache, but even then it has an edge over 32-bit. My own video kernel parameters are:
video=1280x1024R-8@75 consoleblank=0 drm.debug=0xe

The R [reduced blanking] and/or M flags can be useful if if your screen supports either or both of these timing modifications, and you're looking for a higher resolution from the more limited chips in the G200 range.... the other parameters stop it blanking out after a while, and return useful information in dmesg / kern.log as to why certain modes are not working.

[If anyone's struggling with an early MGA-G200SE with 2MB RAM, there's also a kernel patch available to reduce colour depth for validation, although the 'drm_pci_init(&driver, &mgag200_pci_driver)' bit should now be 'pci_register_driver(&mgag200_pci_driver)' - https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg191567.html ]

> Rather than changing the display resolution, I would use a bigger font.
> The console-setup-linux package ships various fonts with up to 32x16
> pixels in the /usr/share/consolefonts directory which can be tried out
> with setfont(1) and set in /etc/default/console-setup.

Might well help. I use a 8x16 font to pack more onscreen (possibly over several panels, with 'screen'), but I guess it depends on your vision and screen. As it's a VGA input, be sure to tune pixel clock (coarse) and phase (fine) along with the other 'Display' settings on your monitor, it can make a big difference - you may find smaller text is readable after all.

--
Laurence "GreenReaper" Parry
https://greenreaper.co.uk/

Reply to: