Change resolution to 1600x1200 on integrated Matrox MGA G200e in D2939 Fujitsu motherboard

[Sergei_Shablovsky]

Looks like that. That Matrox GPU that you have is rather old, and rather rare. It was designed to only provide basic graphics for a server machine. In its heyday (2000-2010), that would have been a nice server-grade GPU that can do a lot. However, the graphics software stack has evolved since then, and requires much more recent hardware to run properly.

Thank You so much for passion and help!
Sad, but true...

These forums have their share of stubborn people who want to run the latest FreeBSD release on outdated hardware, and have that setup do everything under the sun. FreeBSD is not a museum, but forums are a place to help others, get help, and share expertise.

I also agree with You, and very thankful that so many peoples take a such effort to help me in this small problem.

If you want to run something other than Xorg (Like Wayland or Arcan), you'll need different hardware, basically a whole new computer. And you'll be setting the stuff up very differently from Xorg.

Totally agree. But as I wrote before this is equipment that client already have. I just try to do as much effort as I can on existed equipment & applience.

 

[sko]

Totally agree. But as I wrote before this is equipment that client already have. I just try to do as much effort as I can on existed equipment & applience.

Then you should tell the client that if he wants to sit in front of his "server" and look at fancy high-res graphics he has to either look for a desktop machine or upgrade that old thing and/or give it a dedicated graphics card. Other than that there is only X-forwarding his fancy GUI to a remote machine (where he can change the resolution as he likes) or he has to live with the low resolution that his ancient hardware is capable of.

There is absolutely no point in having full-blown graphics on a server that is supposed to sit in a rack somewhere - that's why those on-board GPUs and IPMI/iKVM/etc are very basic and are only meant for emergencies and/or OSes that can't be installed/managed properly over a text-based (ssh) console (and therefore IMHO shouldn't be allowed to run bare metal anyways).

I wonder if your client pays for all this effort you are undergoing - if yes it would have been cheaper for him to just buy a new server from the beginning.

 

[Erichans]

All the effort undertaken didn't give the desired result. Matrox heralds its MGA G200 (Matrox G200) and it also has non-prehistoric Matrox MGA G200 drivers for it but, not for FreeBSD. So, I have to agree with sko, wholeheartedly.

You and your client have a decision to make: to buy a dedicated graphics card—or not.

For a dedicated graphics card, the NVIDIA NVS 300 x1 (as mentioned for example on p. 181 of PRIMERGY RX300 S7 Server Upgrade and Maintenance Manual) comes into view. The seperate NVIDIA NVS 300 card seems to have a FreeBSD driver (see: FreeBSD Display Driver – x64, tab "SUPPORTED PRODUCTS") but, unless you find a workable solution to this Bug 214217, that doesn't seem to lead to a workable graphics card solution.

• Select a graphics card PCIE 2.0 or PCIE 3.0 of x1 wide (or wider) that has a known workable FreeBSD driver.

I presume you have a free PCIe slot left. Seeing the specs from the NVIDIA NVS 300 card and your intensions about what it has to display, that means basically everything that has a compatible output (DVI, HDMI, VGA) to your hardware; you should have some options available. I can't help you with that graphics card selection because I'm not knowledgable in that area.

 

[astyle]

Then you should tell the client that if he wants to sit in front of his "server" and look at fancy high-res graphics he has to either look for a desktop machine or upgrade that old thing and/or give it a dedicated graphics card. Other than that there is only X-forwarding his fancy GUI to a remote machine (where he can change the resolution as he likes) or he has to live with the low resolution that his ancient hardware is capable of.

Gotta be a bit more professional than that. If you're capable of making a go of the existing hardware, then by all means, take on the project. If not - you're the expert in the area, you can say, "You know what, not impossible, but it will take a lot of work", or "Sorry, I wouldn't know how to make a go of THAT". Gotta have a conversation with the client, and get on the same page about the most sensible way forward.

 

[Sergei_Shablovsky]

? sc(4)is for text mode. As a reminder - text mode is what you get when you boot a fresh install of FreeBSD for the first time, before you install any packages like editors/nano or x11/xorg. And the Philips monitor you have (I assume it's local, not remote) - it's more than enough to display the command-line interface, a.k.a. text mode.

As next routine step in server maintenance, I have a small time to trying another one time to resolve the issue: now I have



In /boot/loader.conf.local

i915kms_load="NO"
mga_load="YES"
vesa_load="YES"
#hw.vga.textmode="1"
kern.vty=sc
#kern.vt.fb.default_mode="1024x768"
#screen.textmode="1"
#vbe_max_resolution="1024x768"

In /boot/device.hints
# $FreeBSD$

hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.atkbd.0.at="atkbdc"
hint.atkbd.0.irq="1"
hint.psm.0.at="atkbdc"
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x0080"
hint.sc.0.vesa_mode="285"
hint.vga.0.at="isa"

And as result of vidcontrol -I mode command:

    mode#     flags   type    size       font      window      linear buffer
------------------------------------------------------------------------------
  0 (0x000) 0x00000001 T 40x25           8x8   0xb8000 32k 32k 0x00000000 32k
  1 (0x001) 0x00000001 T 40x25           8x8   0xb8000 32k 32k 0x00000000 32k
  2 (0x002) 0x00000001 T 80x25           8x8   0xb8000 32k 32k 0x00000000 32k
  3 (0x003) 0x00000001 T 80x25           8x8   0xb8000 32k 32k 0x00000000 32k
  4 (0x004) 0x00000003 G 320x200x2 C     8x8   0xb8000 32k 32k 0x00000000 32k
  5 (0x005) 0x00000003 G 320x200x2 C     8x8   0xb8000 32k 32k 0x00000000 32k
  6 (0x006) 0x00000003 G 640x200x1 C     8x8   0xb8000 32k 32k 0x00000000 32k
 13 (0x00d) 0x00000003 G 320x200x4 4     8x8   0xa0000 64k 64k 0x00000000 256k
 14 (0x00e) 0x00000003 G 640x200x4 4     8x8   0xa0000 64k 64k 0x00000000 256k
 16 (0x010) 0x00000003 G 640x350x2 2     8x14  0xa0000 64k 64k 0x00000000 128k
 18 (0x012) 0x00000003 G 640x350x4 4     8x14  0xa0000 64k 64k 0x00000000 256k
 19 (0x013) 0x00000001 T 40x25           8x14  0xb8000 32k 32k 0x00000000 32k
 20 (0x014) 0x00000001 T 40x25           8x14  0xb8000 32k 32k 0x00000000 32k
 21 (0x015) 0x00000001 T 80x25           8x14  0xb8000 32k 32k 0x00000000 32k
 22 (0x016) 0x00000001 T 80x25           8x14  0xb8000 32k 32k 0x00000000 32k
 23 (0x017) 0x00000021 T 40x25           8x16  0xb8000 32k 32k 0x00000000 32k
 24 (0x018) 0x00000021 T 80x25           8x16  0xb8000 32k 32k 0x00000000 32k
 26 (0x01a) 0x00000003 G 640x480x4 4     8x16  0xa0000 64k 64k 0x00000000 256k
 27 (0x01b) 0x00000003 G 640x480x4 4     8x16  0xa0000 64k 64k 0x00000000 256k
 28 (0x01c) 0x00000003 G 320x200x8 P     8x8   0xa0000 64k 64k 0x00000000 64k
 30 (0x01e) 0x00000021 T 80x50           8x8   0xb8000 32k 32k 0x00000000 32k
 32 (0x020) 0x00000021 T 80x30           8x16  0xb8000 32k 32k 0x00000000 32k
 34 (0x022) 0x00000021 T 80x60           8x8   0xb8000 32k 32k 0x00000000 32k
 37 (0x025) 0x00000003 G 320x240x8 V     8x8   0xa0000 64k 64k 0x00000000 256k
112 (0x070) 0x00000001 T 80x43           8x8   0xb8000 32k 32k 0x00000000 32k
113 (0x071) 0x00000001 T 80x43           8x8   0xb8000 32k 32k 0x00000000 32k
256 (0x100) 0x0000000f G 640x400x8 P     8x16  0xa0000 64k 64k 0xdd000000 250k
257 (0x101) 0x0000000f G 640x480x8 P     8x16  0xa0000 64k 64k 0xdd000000 300k
258 (0x102) 0x0000000b G 800x600x4 4     8x14  0xa0000 64k 64k 0x00000000 234k
259 (0x103) 0x0000000f G 800x600x8 P     8x16  0xa0000 64k 64k 0xdd000000 468k
261 (0x105) 0x0000000f G 1024x768x8 P    8x16  0xa0000 64k 64k 0xdd000000 768k
263 (0x107) 0x0000000f G 1280x1024x8 P   8x16  0xa0000 64k 64k 0xdd000000 1280k
266 (0x10a) 0x00000009 T 132x43          8x8   0xb8000 32k 32k 0x00000000 5k
272 (0x110) 0x0000000f G 640x480x16 D    8x16  0xa0000 64k 64k 0xdd000000 600k
273 (0x111) 0x0000000f G 640x480x16 D    8x16  0xa0000 64k 64k 0xdd000000 600k
274 (0x112) 0x0000000f G 640x480x32 D    8x16  0xa0000 64k 64k 0xdd000000 1200k
275 (0x113) 0x0000000f G 800x600x16 D    8x16  0xa0000 64k 64k 0xdd000000 937k
276 (0x114) 0x0000000f G 800x600x16 D    8x16  0xa0000 64k 64k 0xdd000000 937k
277 (0x115) 0x0000000f G 800x600x32 D    8x16  0xa0000 64k 64k 0xdd000000 1875k
278 (0x116) 0x0000000f G 1024x768x16 D   8x16  0xa0000 64k 64k 0xdd000000 1536k
279 (0x117) 0x0000000f G 1024x768x16 D   8x16  0xa0000 64k 64k 0xdd000000 1536k
280 (0x118) 0x0000000f G 1024x768x32 D   8x16  0xa0000 64k 64k 0xdd000000 3072k
281 (0x119) 0x0000000f G 1280x1024x16 D  8x16  0xa0000 64k 64k 0xdd000000 2560k
282 (0x11a) 0x0000000f G 1280x1024x16 D  8x16  0xa0000 64k 64k 0xdd000000 2560k
284 (0x11c) 0x0000000f G 1600x1200x16 D  8x16  0xa0000 64k 64k 0xdd000000 3750k
285 (0x11d) 0x0000000f G 1600x1200x16 D  8x16  0xa0000 64k 64k 0xdd000000 3750k
##############################——-#

And partially success are in that monitor OSD menu really show that display work in 1600x1200@60Hz mode.
So seems that settings in /boot/device.hints working correct with mga.ko driver.
BUT! Screen output of bpytop are unreadable (see attached picture).

Seems that something related to screen fonts, that bpytop not able to recognize or using correctly:
from sc(4) page https://www.freebsd.org/cgi/man.cgi?query=sc&sektion=4

Any idea how to fix that ?


Software Font
For most modern video cards, e.g., VGA, the syscons driver and the video card driver allow the user to change the font used on the screen. The vidcontrol(1)command can be used to load a font file from /usr/share/syscons/fonts.
The font comes in various sizes: 8x8, 8x14 and 8x16. The 8x16 font is typically used for the VGA card in the 80-column-by-25-line mode. Other video modes may require different font sizes. It is better to always load all three sizes of the same font.
You may set font8x8, font8x14and font8x16 variables in /etc/rc.conf to the desired font files so that they will be automatically loaded when the system starts up.
Optionally you can specify a particular font file as the default. See the SC_DFLT_FONT option below.

ScreenMap
If your video card does not support software fonts, you may still be able to achieve a similar effect by re-mapping the font built into your video card. Use vidcontrol(1)to load a screen map file which defines the mapping between character codes.

 

[astyle]

And partially success are in that monitor OSD menu really show that display work in 1600x1200@60Hz mode.

In /boot/loader.conf.local
...
i915kms_load="NO"
mga_load="YES"
vesa_load="YES"
#hw.vga.textmode="1"
kern.vty=sc
#kern.vt.fb.default_mode="1024x768"
#screen.textmode="1"
#vbe_max_resolution="1024x768"

If you don't want to load a module, just comment it out. This is cleaner than setting it to "NO".

Also, I suspect that the mga.ko is competing with vesa.ko, so the screens look like a mess.

Also, if you have your monitor's resolution set to 1600x1200, I'd think that the software settings in your /boot/loader.conf.local need to reflect that. auto is a variable to look into when when trying to figure out what valid settings are for your hardware.

 

[Sergei_Shablovsky]

If you don't want to load a module, just comment it out. This is cleaner than setting it to "NO".

Sorry for some code mess,- this is result of experiments with different settings.

Right now:

In /boot/loader.conf.local

mga_load="YES"
kern.vty=sc
kern.vt.fb.default_mode=“1600x1200”
vbe_max_resolution="1600x1200"

Is that correct ?

Also, I suspect that the mga.ko is competing with vesa.ko, so the screens look like a mess.

When only mga.ko loaded - the same result as on pictures above...
Sad but true.

Let’s to note, all other apps with dynamic output on local terminal (like top, iftop...) working as needed. So I still thinking this is something related to ability of bpytop loading/using needed fonts set...

Where my mistake?

Also, if you have your monitor's resolution set to 1600x1200, I'd think that the software settings in your /boot/loader.conf.local need to reflect that. auto is a variable to look into when when trying to figure out what valid settings are for your hardware.

Could You be so please to explain a little bit more?

 

[astyle]

In /boot/loader.conf.local
...
mga_load="YES"
kern.vty=sc
kern.vt.fb.default_mode=“1600x1200”
vbe_max_resolution="1600x1200"
...

Is that correct ?

Looks about right... does it work correctly for you?

Also: Did you try loading just vesa.ko, instead of mga.ko?

Could You be so please to explain a little bit more?

Your most recent edits show that you did understand my suggestions correctly.

 

[shkhln]

mga_load="YES"
kern.vty=sc
kern.vt.fb.default_mode=“1600x1200”
vbe_max_resolution="1600x1200"

sc doesn't care about vt's settings and vice versa. Moreover, kern.vt.fb.default_mode works only with the drm-kmod (aka kernel modesetting) drivers.

 

[Sergei_Shablovsky]

sc doesn't care about vt's settings and vice versa. Moreover, kern.vt.fb.default_mode works only with the drm-kmod (aka kernel modesetting) drivers.

Thank You, so I just truncate to:

mga_load="YES"
kern.vty=sc
vbe_max_resolution="1600x1200"

That’s right?

 

[Sergei_Shablovsky]

Looks about right... does it work correctly for you?

The goal was to set video output on local screen in best possible for monitor & simultaneously possible to capture by iRMC resolution.
So as a result of this thread:
- monitor now are at 1600x1200@60Hz;
- iRMC able to capture local screen output just a second before the system crash&reboot/down.

Also: Did you try loading just vesa.ko, instead of mga.ko?

Of coarse: result was the same 1600x1200@60Hz. (This make me smiling a little bit, because we spend a time at start of this thread to determine where to take mga.ko driver for certain Matrox G200e [PILOT] chip in iRMC).

Do You suggest using vesa.ko instead mga.ko ?
If answer would be YES, on what a You are based in my certain usecase (hi-res local screen output & ability iRMC to capturing) ?

Your most recent edits show that you did understand my suggestions correctly.

So just a few corrections to polishing, and status going to be COMPLETELY SOLVED...

 

[Sergei_Shablovsky]

Developer of btop/bpytop confirm:

Btop prints out ANSI escape sequences for formatting and coloring and relies on UTF-8 encoded fonts to display the correct symbols. If your terminal (or terminal emulator) of choice doesn't support either of those two requirements, it's simply not gonna work as intended.

So, I need to step back and try to pushing my Matrox G200e [PILOT] embedded in iRMC working with vt.

Do someone have thoughts how to doing this?

 

[astyle]

Developer of btop/bpytop confirm:


So, I need to step back and try to pushing my Matrox G200e [PILOT] embedded in iRMC working with vt.

Do someone have thoughts how to doing this?

This is necroposting, but still...

Leave the GPU-related stuff alone, and install some ports related to UTF-8 and other character encodings. Just make a clean break from thinking about hardware, because font encoding is a purely software-related issue.

 

[Sergei_Shablovsky]

This is necroposting, but still...

Leave the GPU-related stuff alone, and install some ports related to UTF-8 and other character encodings. Just make a clean break from thinking about hardware, because font encoding is a purely software-related issue.

I just come in to upgrade and clean this server, update software, etc.

And see that
a)
14.0-RELEASE would perfectly resolving the issue with Matrox G200** support;
b)
The btop monitoring utility change ownership and last year frequently updated, and now working with ttys well;

So, now 1600x1200 60Hz on 21” screen

I just playing with another fonts AND autologon as separate restricted user and on another from ttyv0 console.

After that topic would be marked as [SOLVED].

Thank You for patience and help!
Have a nice day!