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



## Sergei_Shablovsky (Nov 1, 2021)

Hi, FreeBSD Gurus!

The Fujitsu PRIMERGY *server* motherboard D2939 have integrated video, exactly Matrox MGA G200e.

Local *widescreen monitor* have max resolution 1680x1058, 60Hz (D-sub) / 75Hz (DVI-D).

Due needs to remote management and iRMS (built-in server remote management card) requirements, *max available resolution must be set equal or below 1600x1200, 60Hz*.

So, I ask for suggestion *how to set 1600x1200/60Hz in FreeBSD 12 / 13, when graphics environment not needed (this is network server only)*, and I try to avoid unnecessary system pressure on hardware.



> pciconf -lv | grep -A 4 vga
> 
> vgapci0@pci0:13:0:0:   class=0x030000 card=0x11cc1734 chip=0x0522102b rev=0x05 hdr=0x00
> vendor     = 'Matrox Electronics Systems Ltd.'
> ...



But looks like kernel not load any mga.ko driver, but i915kms.ko loaded already  (I use kldstat command for this)

P.S. I also not find in whole BSD Hardware Database that support for this card exist by default.


----------



## SirDice (Nov 1, 2021)

Sergei_Shablovsky said:


> But looks like kernel not load any mga.ko driver


No such driver exists. 


Sergei_Shablovsky said:


> but i915kms.ko loaded already (I use kldstat command for this)


As that driver is for Intel GPUs this does exactly nothing. 



Sergei_Shablovsky said:


> Due needs to remote management and iRMS (built-in server remote management card) requirements, *max available resolution must be set equal or below 1600x1200, 60Hz*.


I've found setting the console to text mode instead of graphics usually works a lot better. In /boot/loader.conf:

```
hw.vga.textmode="1"
```


----------



## Phishfry (Nov 1, 2021)

Usually a setting like this in /boot/loader.conf would allow you to change the resolution.

```
kern.vt.fb.default_mode="1440x900"
```
But vt requires a kms driver to set resolution and there is no Matrox KMS driver.​Only Intel and Radeon(AMD).
Also the monitor has to support any mode you are trying to use.


----------



## Sergei_Shablovsky (Nov 2, 2021)

Phishfry said:


> Usually a setting like this in /boot/loader.conf would allow you to change the resolution.
> 
> ```
> kern.vt.fb.default_mode="1440x900"
> ...



Let’s to note that I use local-attached to server monitor ONLY for next purposes:
- *Bpytop* (running *24/7/365 on local screen*, that give ability to remote see screen (VGA console) output, and which are *more important* - save last screen output by RMC board into internal memory before server crash or hangs to help investigate the source of problem);
- *Smokeping* (running 24/7/365, on-screen only when network stuff need to make OS/NIC/hw parameters tuning.

Both apps using pseudo-graphics to display a results of work.
So I not need all linked to graphics mode at all, am I right?


----------



## Sergei_Shablovsky (Nov 2, 2021)

SirDice said:


> No such driver exists.
> 
> As that driver is for Intel GPUs this does exactly nothing.
> 
> ...



As I note before, looks like I not need all linked to graphics mode at all, am I right?

If so, how to prevent to loading in memory/free resource from unwanted drivers/kernel modules to reduce unnecessary hw loading (memory, interrupts, io operations, etc...)?

I try to keep system as clean as possible. If this possible


----------



## Phishfry (Nov 2, 2021)

Sergei_Shablovsky said:


> I not need all linked to graphics mode at all, am I right?


Yes you are correct i915kms is only for Intel Graphics.



Sergei_Shablovsky said:


> If so, how to prevent to loading in memory/free resource from unwanted drivers/kernel modules to reduce unnecessary


Look at `top` for apps and memory and `service -e` for services.
Figure out what is in use that is unneeded for your use case.
FreeBSD ships with a bare set of services enabled.
Some low hanging ones I pare are vi_recover and mixer.

As for interrupts they are more of a concern on bad acting network cards and storage cards.
You will know when there is a problem with an interrupt storm.
For system health check `vmstat`( And all its options) and `gstat`.
Know your kernel environment with `kenv`.

Unless you really know what you are doing leave kernel modules alone.
They are loaded dynamically (or via kernel inclusion) and really don't eat much RAM.
Only if you are trying to slim an installation for real small storage would I worry about kernel modules.
Their size is insignificant unless building FreeBSD for 1G or less storage.


----------



## Phishfry (Nov 2, 2021)

I want to point out that Matrox G200e is usually tied to the Broadband Management Controller via VGA


Sergei_Shablovsky said:


> Both apps using pseudo-graphics to display a results of work.
> So I not need all linked to graphics mode at all, am I right?


Probably not.
One way to run several applications at once is to use Virtual Terminals.
You can run `top` in one Virtual Terminal and `gstat` in another.
Switching back and forth with <ctrl><alt><F1> and <ctrl><alt><F2> for example.


----------



## Sergei_Shablovsky (Nov 2, 2021)

SirDice said:


> I've found setting the console to text mode instead of graphics usually works a lot better. In /boot/loader.conf:
> 
> ```
> hw.vga.textmode="1"
> ```


Could a You be so please to explain, is the *text mode* better than *graphics mode* for console in case that

- this is server, network router/fw with a huge loading;
- non-UEFI;
- video resolution upper limit are 1600x1200 (because iRMC limitation to save video in internal memory buffer);
- local monitor used only for reference for sysadmin;
- primary remote control/management using Eth connection, and COM connection as backup;

from hardware loading point of view (memory using, cpu using, interrupts using....);
?

P.S. Sorry for may  be dumb questions, I'm just newbie in BSD


----------



## Sergei_Shablovsky (Nov 2, 2021)

Phishfry said:


> I want to point out that Matrox G200e is usually tied to the Broadband Management Controller via VGA



Please explain how this impact on VGA console settings? 

Let’s note, documentation only indicate that iRMC controller (BMC) able to *save screenshot up to 1600x1200 resolution*, not more.
May be this limitation is due the NVRAM size on iRMC.


----------



## Sergei_Shablovsky (Nov 2, 2021)

SirDice said:


> No such driver exists.


I read in
Absolute FreeBSD, 3rd Edition: The Complete Guide to FreeBSD​By Michael W. Lucas

that mgadrm (Direct Rendering Module, DRM) for an “AGP Matrox G200, G400, G450, G550” already exist in GENERIC FreeBSD.

Is this help me or I need to install the x11-drivers/xf86-video-mga port to be able to use mga.ko driver?


----------



## Phishfry (Nov 2, 2021)

Sergei_Shablovsky said:


> Please explain how this impact on VGA console settings?


Usually this is a bare bones VGA with small amount video RAM. Limited capacity.
But for console use it works fine. It's meant for system management not gaming.

SuperMicro uses a similar arrangement with AST2400/2500 video chip tied to BMC.
There is even a xorg driver that works with it.
So it can provide a basic desktop. I suspect the matrox driver could be used for the same.


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> Usually this is a bare bones VGA with small amount video RAM. Limited capacity.
> But for console use it works fine. It's meant for system management not gaming.
> 
> SuperMicro uses a similar arrangement with AST2400/2500 video chip tied to BMC.
> ...



Thank You again for patience and passion to help!
Appreciate Your work here!

So, only one way exist to push this pesky “MGA G200e [Pilot] ServerEngines (SEP1)” to work are the installing (and configuring properly) the x11-drivers/xf86-video-mga port to be able to use mga.ko driver?

And in this case the MGA 200e would work only in graphics mode or in text mode?

Also I read this tread and find that I also need proper fonts for desired resolution, isn’t ?


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> Usually this is a bare bones VGA with small amount video RAM. Limited capacity.
> But for console use it works fine.



Is this mean that physically graphics chip for whole motherboard and for BMC are the one?


----------



## Phishfry (Nov 3, 2021)

Sergei_Shablovsky said:


> So, only one way exist to push this pesky “MGA G200e [Pilot] ServerEngines (SEP1)” to work are the installing (and configuring properly) the x11-drivers/xf86-video-mga port to be able to use mga.ko driver?


The Matrox MGA module is for X11. It will do nothing for console use.
Consider trying the sc(4) driver.


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> The Matrox MGA module is for X11. It will do nothing for console use.
> Consider trying the sc(4) driver.



Please, explain me, *why I cannot able to see mga.ko loaded (using kldstat), but picconf show the graphics chip correctly* ? 

Please see this example: user also have G200 but have mga.ko module loaded already.

The difference in both situations are:
a) User no point is this discrete graphics card or not, I vote that his card are discrete;
b) I have embedded some sort of  modified chip “MGA G200e [Pilot] ServerEngines (SEP1)”


----------



## SirDice (Nov 3, 2021)

Sergei_Shablovsky said:


> but picconf show the graphics chip correctly


pciconf(8) just enumerates the devices it finds by querying the bus. It has nothing to do with drivers.






						PCI configuration space - Wikipedia
					






					en.wikipedia.org


----------



## Sergei_Shablovsky (Nov 3, 2021)

SirDice said:


> pciconf(8) just enumerates the devices it finds by querying the bus. It has nothing to do with drivers.


So, why system not loading mga.ko ?


----------



## SirDice (Nov 3, 2021)

Sergei_Shablovsky said:


> So, why system not loading mga.ko ?


No idea where he got that from. It certainly doesn't exist on 12 or 13.


----------



## Sergei_Shablovsky (Nov 3, 2021)

SirDice said:


> No idea where he got that from. It certainly doesn't exist on 12 or 13.



I also a little bit confused 

So, Is it possible to install mga.ko manually in case I able to find it in this Universe?


----------



## T-Daemon (Nov 3, 2021)

It looks like "mga.ko" was provided from deleted port graphics/drm-legacy-kmod (expand pkg-plist). Not sure if port builds on supported versions.


----------



## Sergei_Shablovsky (Nov 3, 2021)

T-Daemon said:


> It looks like "mga.ko" was provided from deleted port graphics/drm-legacy-kmod (expand pkg-plist). Not sure if port builds on supported versions.



I come to the same tough, that after 8.2 release, the mga.ko was dropped out. (after reading this)

So, how to install only mga.ko ?


----------



## Sergei_Shablovsky (Nov 3, 2021)

Thanks to Phishfry, ( he running FreeBSD 12.2) is found in /boot/kernel/mga.ko

Loaded by kldload mga, and view in the list of loaded by kldstat, and view in the list of loaded by kldstat.

Sorry my lack of knowledge in FreeBSD, how to make this module at BSD start?
(And unload the i915kms.ko, if it not needed for vt() for my usecase.)

And of course, set the resolution that I want for VGA terminal (see forts post in this tread)?


----------



## Phishfry (Nov 3, 2021)

Sergei_Shablovsky said:


> how to make this module at BSD start?


Remove this line in your /etc/rc.conf

```
### VIDEO ###
kld_list="i915kms"
```

Now add the Matrox driver instead. This driver loads generic DRM driver for you.

```
### VIDEO ###
kld_list="mga"
```


----------



## Phishfry (Nov 3, 2021)

Lets bring all this back to your original thread instead of dragging up an old thread.

To test you could start by adding the resolution you desire to /boot/loader.conf


```
kern.vt.fb.default_mode="1024x768"
```

Once you have a drm driver running you can also experiment with GOP from boot loader menu.
Here is an example of GOP


			Console text resolution mode config


----------



## Sergei_Shablovsky (Nov 3, 2021)

Sergei_Shablovsky said:


> And unload the i915kms.ko, if it not needed for vt() for my usecase


And what about this ?


----------



## Phishfry (Nov 3, 2021)

Unload it because it is for Intel Graphics. It could confilct with Matrox and generic DRM driver (KMS)


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> Unload it because it is for Intel Graphics. It could confilct with Matrox and generic DRM driver (KMS)


Thank You!
Done,- not see it by kldstat.

but resolution not changed no to 1024x768, nor 1600x1200

Also I see:



> dmesg | grep error





> module_register_init: MOD_LOAD (iwi_monitor_fw, 0xffffffff80761ab0, 0) error 1
> module_register_init: MOD_LOAD (vesa, 0xffffffff81411210, 0) error 19





> dmesg | grep vga





> VT(vga): text 80x25
> vtvga0: <VT VGA driver> on motherboard
> vgapci0: <VGA-compatible display> mem 0xdd000000-0xddffffff,0xde800000-0xde803fff,0xde000000-0xde7fffff irq 16 at device 0.0 on pci8
> vgapci0: Boot video device
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid PNP0900 on isa0


----------



## Phishfry (Nov 3, 2021)

Sergei_Shablovsky said:


> - non-UEFI;


GOP will only work on UEFI so you can strike that.

Because DRM has deep hooks I would not only unload the module but reboot.


----------



## Phishfry (Nov 3, 2021)

Sergei_Shablovsky said:


> iwi_monitor_fw,


That sounds like an Intel Wireless interface firmware. Are you using Intel wifi?




Sergei_Shablovsky said:


> module_register_init: MOD_LOAD (vesa, 0xffffffff81411210, 0) error 19


This one has been around forever. Ususally safe to ignore. But....
VESA does fall into the realm of VGA output on Legacy BIOS FreeBSD.
But if I remember right this was needed for VESA mode X11. Not console use.
Real basic legacy driver for X11 comparible to the generic scfb driver for UEFI Installations.
It can be loaded to solve the error message.


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> GOP will only work on UEFI so you can strike that.
> 
> Because DRM has deep hooks I would not only unload the module but reboot.



I make cold reboot after each change.


----------



## Phishfry (Nov 3, 2021)

Maybe you have settings for Intel wireless card but removed hardware??





						iwifw(4)
					






					www.freebsd.org
				



This is the module referenced in your error report.


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> That sounds like an Intel Wireless interface firmware. Are you using Intel wifi?


Definitely no, this is network server.



Phishfry said:


> This one has been around forever. Ususally safe to ignore. But....
> VESA does fall into the realm of VGA output on Legacy BIOS FreeBSD.
> But if I remember right this was needed for VESA mode X11. Not console use.
> Real basic legacy driver for X11 comparible to the generic scfb driver for UEFI Installations.
> It can be loaded to solve the error message.


Ok, ignore.


----------



## SirDice (Nov 3, 2021)

Try these in loader.conf(5):

```
screen.textmode="0"
vbe_max_resolution="1920x1080"
```


```
screen.textmode
                     Value “0” will trigger BIOS loader to switch to use VESA
                     BIOS Extension (VBE) frame buffer mode for console.  The
                     same effect can be achieved by setting
                     vbe_max_resolution.

                     Value “1” will force BIOS loader to use VGA text mode.

                     If vbe_max_resolution is not set, the loader will try to
                     set screen resolution based on EDID information.  If EDID
                     is not available, the default resolution is 800x600 (if
                     available).
```


```
vbe_max_resolution
                     Specify the maximum desired resolution for the EFI or VBE
                     framebuffer console.  The following values are accepted:

                     Value           Resolution
                     480p            640x480
                     720p            1280x720
                     1080p           1920x1080
                     2160p           3840x2160
                     4k              3840x2160
                     5k              5120x2880
                     WidthxHeight    WidthxHeight
```


----------



## Phishfry (Nov 3, 2021)

Since your hardware description is vague I looked it up. Fujitsu Primergy RX300 S7 Rack mount server.
Sandy/Ivy Bridge LGA2011 Xeon.

I have one of these Matrox video chips from the same generation; a Tyan S7030 storage server.
The board has no evidence of a Matrox chip. The VGA Chip is embedded within the BMC chip.
Just like the AST2300 on same generation Supermicro boards. The Aspeed BMC chip has video cores embedded.
So the BMC company probably licensed the video core IP. It could just be a shell of its former self.


----------



## Sergei_Shablovsky (Nov 3, 2021)

Phishfry said:


> Since your hardware description is vague I looked it up. Fujitsu Primergy RX300 S7 Rack mount server.
> Sandy/Ivy Bridge LGA2011 Xeon.


Better to know all details that You may need from this partners spec: PRIMERGY RX300 S7 System Configurator:




Phishfry said:


> I have one of these Matrox video chips from the same generation; a Tyan S7030 storage server.
> The board has no evidence of a Matrox chip. The VGA Chip is embedded within the BMC chip.
> Just like the AST2300 on same generation Supermicro boards. The Aspeed BMC chip has video cores embedded.
> So the BMC company probably licensed the video core IP. It could just be a shell of its former self.


Thank You for detailed explanation. Very Interesting!


----------



## Sergei_Shablovsky (Nov 3, 2021)

SirDice said:


> Try these in loader.conf(5):
> 
> ```
> screen.textmode="0"
> ...



Are You sure for 1920x1080 ?

From PRIMERGY RX300 S7 System Configurator:
(page 11):

Graphics Controller integrated in iRMC S3 (integrated Remote Management Controller):
1600x1200x16bpp 60Hz, 1280x1024x16bpp 60Hz, 1024x768x32bpp 75Hz, 800x600x32bpp 85Hz, 640x480x32bpp 85Hz (1280x1024x24bpp 60Hz only possible if local monitor or remote video redirection is off)

PHILIPS monitor that I have connected is 1680x1050, 60Hz native res



SirDice said:


> ```
> screen.textmode
> Value “0” will trigger BIOS loader to switch to use VESA
> BIOS Extension (VBE) frame buffer mode for console.  The
> ...


----------



## Erichans (Nov 3, 2021)

Perhaps these help:
D2939 BIOS Setup Utility for PRIMERGY RX300 S7
PRIMERGY RX300 S7 Server Operating manual



			
				p. 27-Operating manual said:
			
		

> Remote Management Controller:
> Integrated Remote Management Controller
> (iRMC S3, 32 MB attached memory incl. graphics
> controller), IPMI 2.0 compatible



I'm not familiar with IPMI but, does it offer perhaps some commands that can manipulate the resolution?

Glancing trough both it seems more likely though that Fujitsu has an OS-specific driver that can manipulate from "the inside" the resolution of the graphics part of the iRMC. The graphics output can be directed through iRMC or not; set in the BIOS setup utility. With an extra seperate graphics card that last option should be chosen.


----------



## Sergei_Shablovsky (Nov 4, 2021)

Phishfry said:


> Lets bring all this back to your original thread instead of dragging up an old thread.
> 
> To test you could start by adding the resolution you desire to /boot/loader.conf
> 
> ...


Already done.



Phishfry said:


> Once you have a drm driver running ...



Is this output from kldstat mean that drm driver loaded successfully?

Id Refs Address                Size Name
 1   41 0xffffffff80200000  3aee768 kernel
 2    1 0xffffffff83cf0000    131f0 mga.ko
 3    2 0xffffffff83d04000    21d08 drm.ko
 ...


----------



## Sergei_Shablovsky (Nov 4, 2021)

Erichans said:


> Perhaps these help:
> D2939 BIOS Setup Utility for PRIMERGY RX300 S7
> PRIMERGY RX300 S7 Server Operating manual


Thank You that take part on this “battle against so pesky Matrox”!
Appreciate You efforts!



Erichans said:


> I'm not familiar with IPMI but, does it offer perhaps some commands that can manipulate the resolution?


Not sure, but according my experience:
- You May able to choose resolution in Remote Access utility (java-based app) to see actual screen (means VGA console) output in real-time.
(see message above about resolution limitation)
- You may able to Remote boot on Management-LAN (thru connect to iRMC / BMC) from scratch with VGA-console, keyboard, mouse redirection and mounting local-attached media.



Erichans said:


> Glancing trough both it seems more likely though that Fujitsu has an OS-specific driver that can manipulate from "the inside" the resolution of the graphics part of the iRMC.





Erichans said:


> The graphics output can be directed through iRMC or not; set in the BIOS setup utility. With an extra seperate graphics card that last option should be chosen.


Khm... I go to read manuals again one time. 

But how this may help us so resolve question?


----------



## Sergei_Shablovsky (Nov 4, 2021)

SirDice said:


> Try these in loader.conf(5):
> 
> ```
> screen.textmode="0"
> ...


Is this important before or after the



> hw.vga.textmode="1”



string ?


----------



## Phishfry (Nov 4, 2021)

Sergei_Shablovsky said:


> Is this important before or after the
> 
> 
> 
> string ?


No I dont think so.
What I would recommend is to use the loader prompt. It is an ideal test facility.
At FreeBSD bootup during Beastie logo use option #3 "Escape to loader prompt".

A good beginner test is boot with more verbosity. So from loader prompt type
`boot -v`
Hit return key.
This will boot up and give you more boot output.

For changing video output modes loader prompt is useful because it will return a value.

From SirDice example.
To use loader mode you must prefix the command with a action.
screen.textmode="0" in /boot/loader.conf is equal to
`set screen.textmode="0"` <return key>
So you are setting a loader variable by hand. If it fails here it might give a clue.
Then to complete it.
`set vbe_max_resolution="1280x720"` <return key>
`boot`<return key>
This needs to go somewhere. Find out by trying.
`set hw.vga.textmode="1”` <return key>

This is how you twiddle the loader buttons.


----------



## astyle (Nov 4, 2021)

Try using the "vesa" driver. I think it's provided by x11-drivers/xf86-video-vesa. I think you'll find a vesa.ko file, and specify it *instead* of mga.ko or i915.ko. Pretty generic driver. You might end up giving up very high resolution, though.


----------



## Sergei_Shablovsky (Nov 4, 2021)

Phishfry said:


> No I dont think so.
> What I would recommend is to use the loader prompt. It is an ideal test facility.
> At FreeBSD bootup during Beastie logo use option #3 "Escape to loader prompt".
> 
> ...


May be I doing something wrong, but... the result are still negative...


----------



## astyle (Nov 4, 2021)

Are you able to get to Xorg at all? as in, get to the TWM desktop? I think that getting to the desktop comes first, and then you can fiddle with the resolution. In FreeBSD (and Linux, too!) doing things correctly and in correct order makes a difference. If you skip a step, it gets messy in a hurry.


----------



## Vull (Nov 4, 2021)

Sergei_Shablovsky said:


> ...
> Also I see:





> dmesg | grep vga





> VT(vga): text 80x25
> vtvga0: <VT VGA driver> on motherboard
> vgapci0: <VGA-compatible display> mem 0xdd000000-0xddffffff,0xde800000-0xde803fff,0xde000000-0xde7fffff irq 16 at device 0.0 on pci8
> vgapci0: Boot video device
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid PNP0900 on isa0



This output you provided shows that you are presently configured in *text mode* only.

Note the line above that says `VT(vga): text 80x25` -- This means 80 character columns x 25 character rows. It tells nothing about _graphics_ screen resolution. Please let me try and answer some of your earlier questions:

Graphics screen resolution is specified in pixels, not characters. For example: 1024x768 *(graphics mode, in pixels)*

Screen character dimension is specified in characters, not pixels. For example: 80x25 *(text mode, in characters)*

For comparison, my laptop monitor has a default screen resolution of 1366x768, but my "virtual terminal" (vt) screen character dimensions are the same as yours: 80x24.

For further comparison, here is my VT line from my dmesg output:


> dmesg | grep VT





> VT(efifb): resolution 1366x768



A FreeBSD system which is capable of graphical output, like my laptop, will be running in text mode on the console (/dev/ttyv0), but will usually display graphics on a different virtual terminal. Typically, graphics are displayed on /dev/ttyv8.

If I press CTRL ALT F1 I see my text console output on /dev/ttyv0.
If I press CTRL ALT F9 I see my graphics output on /dev/ttyv8.

In answer to some more of your earlier questions, after looking at screenshots for SmokePing and BPYTOP, it appears you need *graphics mode* to display those programs, SmokePing in particular. Looking at the link you provided to the PRIMERGY RX300 S7 System Configurator guide, there's an optional "NVIDIA NVS300" graphics card which you don't seem to have, according to your `pciconf` output. This guide also mentions a "S26361-F2748-E637 PY VGA LP card 256MB PCI-e x1" which doesn't seem to show up in your output either. Maybe this is another name for the "Matrox MGA G200e" card you do have? I don't know, and it's all very confusing to me, too.

This Remote Management Controller User's Guide I found includes a long list of Microsoft, Red Hat, SUSE, and Intel LANDesk operating systems, but doesn't mention FreeBSD as a supported operating system, and leaves me wondering if this iRMC server software has ever been successfully installed on any FreeBSD system. Do you know if it has?

I agree with astyle that your first order of business should be to get graphics running on this hardware. If you can get that to happen, then maybe SirDice or Phishfry can help you fix your maximum display resolution-- personally, I've never been able to change mine to anything other than 1366x768, so I can't really help you there.

Alternatively, maybe you could get the server running in text mode, and then just use some other computer to remotely manage your remote management controller console. Whatever you try next, you can check the output of `dmesg | grep VT` to see what your default resolution is going to be-- because, as long it keeps saying `VT(vga): text 80x25` I don't think you'll be able to run any graphics programs on your console. I could be wrong-- it wouldn't be the first time. Good luck with it in any case.

One other point: it seems unlikely _to me_ that a nearly obsolete graphics driver like VGA would provide a default resolution higher than 1600x1200, even on a widescreen monitor. But I could be wrong about that too.

Edited to add:
Please provide the output of:
`pciconf -lv | grep -A 1 -B 3 display`
and
`uname -a`
Thanks


----------



## astyle (Nov 4, 2021)

FWIW, very high resolution like 1600x1200 is a bit problematic for OP's card:









						Matrox G200 - Wikipedia
					






					en.wikipedia.org
				



Basic VGA output is what it the card is intended for (by the manufacturer) these days.


----------



## Vull (Nov 4, 2021)

astyle said:


> FWIW, very high resolution like 1600x1200 is a bit problematic for OP's card:
> 
> 
> 
> ...


Worth clarifying again that OP's application requires staying under at or under 1600x1200, not _attaining _or going _over_ such a high resolution.


----------



## Sergei_Shablovsky (Nov 4, 2021)

Vull said:


> In answer to some more of your earlier questions, after looking at screenshots for SmokePing and BPYTOP, it appears you need *graphics mode* to display those programs, SmokePing in particular.


Are You sure about this ?

From my knowledge:
BPUTOP using bash ANSI/VT100 control sequences for symbol's color and formatting.

Smokeping able to be used in 2(two) modes:
- *see the reports on generated html page from remote machine* (to not running up graphics environment and html page browser directly on a server, to minimize hw resource loading and avoid software conflicts when future updates occur);
- *see the reports on local VGA console*;

And for both this second mode on local VGA console and for BPYTOP I need exactly to change output resolution on local VGA screen.


----------



## Sergei_Shablovsky (Nov 4, 2021)

Vull said:


> Whatever you try next, you can check the output of `dmesg | grep VT` to see what your default resolution is going to be-- because, as long it keeps saying `VT(vga): text 80x25` I don't think you'll be able to run any graphics programs on your console.


Please, look at

`VT(vga): resolution 640x480
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
vtvga0: <VT VGA driver> on motherboard
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
VT(vga): resolution 640x480
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
vtvga0: <VT VGA driver> on motherboard
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID`



Vull said:


> Please provide the output of:
> `pciconf -lv | grep -A 1 -B 3 display`


Already done on the start of tread  Please look at https://forums.freebsd.org/threads/...mga-g200e-in-d2939-fujitsu-motherboard.82686/


----------



## Vull (Nov 4, 2021)

Sergei_Shablovsky said:


> Please, look at
> 
> `VT(vga): resolution 640x480
> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> ...


My thinking is that `VT(vga): resolution 640x480` might be adequate for your purposes. 30-40 years ago, 640x480 was often the highest resolution I could get on a lot of the old VGA graphics systems.

If I'm reading them right, the iRMC software requirements only give 1600x1200 as a _maximum_ resolution, and not as a _minimum_ requirement. Also, I'm guessing that something like 1024x768 or 1920x1080 might very likely be the highest resolution you can get with this Matrox card, which is what I think astyle was also saying.



> Already done on the start of tread  Please look at https://forums.freebsd.org/threads/...mga-g200e-in-d2939-fujitsu-motherboard.82686/


I saw that, but you were grepping for "vga" and I'm suggesting that you might try grepping for "display" in the hope that you might have the optional NVIDIA card. (I'm not sure if it would show up as "vga" because I've never had a system with an NVIDIA card before.) If an NVIDIA card is available, it might offer a higher resolution.

Plus, I would also like to see the output of `uname -a` because it would show us your FreeBSD version number and other useful info.


----------



## astyle (Nov 4, 2021)

Seems like OP is confusing graphics mode and text mode. 

Text mode comes first. If you can see the machine's BIOS, then text mode will be visible. It is possible to play with some colors in text mode, but the important part is that it's _text_. Normally, text mode is 80 characters wide and 23 characters tall. That means you can see at most 23 lines of text.

You can leave it at that, or you can play with *colors of text*. Oh, and ignore VT-x stuff altogether, it's irrelevant.

To get graphics mode going, it takes *starting in text mode*. I would suggest that OP install the graphics driver. Going by what was said earlier in the thread, that was done. However, _installing_ the driver is not the same as _turning it on_. From this point, as I said earlier, doing stuff *in order*, like 1, 2, 3, done - that will make a difference. So, without further ado:

`# pkg install xorg` // You gotta be root for that.
`# pkg install twm` // You gotta be root for that.
`# pkg install xdm` // Need a login manager for a graphic desktop.
`# pkg install nano` // Nano is a text editor that works in text mode, you'll need it.
`# nano /etc/rc.conf` // Add the following lines to /etc/rc.conf: 
`xdm_enable="YES"` //
`kld_list="/full/path/to/vesa.ko"` // vesa.ko part can be replaced with mga.ko. Full and correct filepath is recommended for your scenario to work.

`# reboot`
Following these instructions *in order* should get you to a working XDM login manager, which you use to log in and get to a working TWM desktop. 

Once all that is done, then you can play with resolution, and what not. Skipping steps and going straight to the part where you think resolution is specified - that approach has left countless users pretty frustrated with "why isn't this working for me?".


----------



## Sergei_Shablovsky (Nov 4, 2021)

Vull said:


> Looking at the link you provided to the PRIMERGY RX300 S7 System Configurator guide, there's an optional "NVIDIA NVS300" graphics card which you don't seem to have, according to your `pciconf` output.


You are absolutely right: I have no this card whatsoever. This is optional card for this servers line.



Vull said:


> This guide also mentions a "S26361-F2748-E637 PY VGA LP card 256MB PCI-e x1" which doesn't seem to show up in your output either.


I also not find any info on Fujitsu web (BTW very bad designed, part of info just absent or hard-to-find). And Googling also not give me more clarity what is this.
Anyway,  this "S26361-F2748-E637 PY VGA LP card 256MB PCI-e x1" card mean 256Mb, but Matrox G200e chip that included in Emulex Pilot 3 based iRMC S3 BMC are only 32Gb



Vull said:


> Maybe this is another name for the "Matrox MGA G200e" card you do have? I don't know, and it's all very confusing to me, too.


I am on 99,999% sure - no.


----------



## astyle (Nov 4, 2021)

Sergei_Shablovsky said:


> Anyway, this "S26361-F2748-E637 PY VGA LP card 256MB PCI-e x1" card mean 256Mb, but Matrox G200e chip that included in Melannox Pilot iRMC S3 BMC are only 32Gb


32 *GB*??? double-check that. Not even RTX 3090 has that much RAM. Some Quadro GPU's do, though.


----------



## Sergei_Shablovsky (Nov 4, 2021)

Vull said:


> This Remote Management Controller User's Guide I found includes a long list of Microsoft, Red Hat, SUSE, and Intel LANDesk operating systems, but doesn't mention FreeBSD as a supported operating system, and leaves me wondering if this iRMC server software has ever been successfully installed on any FreeBSD system. Do you know if it has?



Please take attention to p.71-72
(together with my comments)



> The Video Redirection does not support the following display mode:
> • The version earlier than iRMC S2
> Resolution that exceeds 1024 × 768, and 24-bit/32-bit color mode.


In this server *definitely iRMC S3*
(with latest fw update successfully of course)



> • iRMC S2 or later version
> 24bit/32bit color mode by resolution of 1280 × 1024 or more.
> Resolution that exceeds 1600 × 1200.


Monitor support 1680x1050, 60/75Hz as native, so this is a little bit below this iRMC restriction (no matter iRMC S2 or iRMC S3).



> • Using not standard VGA driver


Hm... So which exactly driver Fujitsu mean?



> When the Video Redirection is started repeatedly without closing the Web interface of the Remote Management Controller, Java error may occur or the Video Redirection may not make a response. In this case, close all browsers and start the Web interface of the Remote Management Controller again.
> When you enable a mouse and a keyboard with the Video Redirection, the server recognizes the mouse and the keyboard as of USB connection. When USB connection is not available (such as no USB driver exists) because of the server settings, you cannot use a mouse and a keyboard with the Video Redirection.


This all about crappy realization of video streaming in iRMC in conjunction with a Java realization in Win  
Just ignore this....


----------



## Vull (Nov 4, 2021)

Sergei_Shablovsky,​If I still had the 640x480 resolution working, I'd probably go ahead and attempt to install the server software, just to see if it worked.

If the server software fails to install, you can still recover by doing a quick re-install of whatever FreeBSD version you're using, from a USB installer.


----------



## Sergei_Shablovsky (Nov 4, 2021)

astyle said:


> 32 *GB*??? double-check that. Not even RTX 3090 has that much RAM. Some Quadro GPU's do, though.


Sorry *32Mb*, Of course, my misstyping


----------



## grahamperrin@ (Nov 6, 2021)

SirDice said:


> Try these in loader.conf(5):
> 
> …





Phishfry said:


> …
> From _*SirDice*_ example.
> …
> `set vbe_max_resolution="1280x720"`
> …



Rewind, to the opening post:



Sergei_Shablovsky said:


> … FreeBSD 12 / 13 …



– and:



Sergei_Shablovsky said:


> Thanks to Phishfry, ( he running FreeBSD 12.2) is found in /boot/kernel/mga.ko …



Compare:

<https://www.freebsd.org/cgi/man.cgi...manpath=FreeBSD+12.2-RELEASE#DEFAULT	SETTINGS> for 12.2-RELEASE
<https://www.freebsd.org/cgi/man.cgi...manpath=FreeBSD+13.0-RELEASE#DEFAULT	SETTINGS> for 13.0-RELEASE
– in particular, <https://cgit.freebsd.org/src/commit/?id=3630506b9daec9167a89bc4525638ea45a00769e> added the _vbe framebuffer for BIOS loader_. From corresponding <https://github.com/freebsd/freebsd-src/commit/3630506b9daec9167a89bc4525638ea45a00769e> we see that the enhancement is in *main* and *release/13.0.0* – not in any inferior version of the operating system.

So:



Vull said:


> … and
> `uname -a`
> Thanks



Knowing the version will be critical to some of what's discussed. From comments on previous pages, I _assume_ that Sergei_Shablovsky currently runs 12.2-RELEASE.

(I have no experience with Matrox, or things such as the iRMS (built-in server remote management card).)

HTH


----------



## grahamperrin@ (Nov 6, 2021)

Sergei_Shablovsky said:


> The Fujitsu PRIMERGY *server* motherboard D2939 have integrated video, exactly Matrox MGA G200e. …





T-Daemon said:


> It looks like "mga.ko" was provided from deleted port graphics/drm-legacy-kmod …



Source mga_drm.h exists in _main_ at <https://github.com/freebsd/drm-kmod/blob/master/include/uapi/drm/mga_drm.h> with _G200_ et cetera. 

I'm out of my depth, but I assume that modesetting(4) applies; <https://www.freebsd.org/cgi/man.cgi?query=modesetting&sektion=4&manpath=Ports>.



Sergei_Shablovsky said:


> … installing (and configuring properly) the x11-drivers/xf86-video-mga port …



<https://www.freshports.org/x11-drivers/xf86-video-mga/#config> no options to configure, and <https://cgit.freebsd.org/ports/tree/x11-drivers/xf86-video-mga> there is no (post-installation) package message. So if this package is appropriate or required, simply install. 

Available packages <https://www.freshports.org/x11-drivers/xf86-video-mga/#packages> do include those for FreeBSD:*13*:amd64. However (again, out of my depth) I don't know whether I'm losing sight of the iRMS remote management aspect.

If I understand correctly, an X.Org driver such as xf86-video-mga can be used without a DRM driver.


----------



## Sergei_Shablovsky (Nov 7, 2021)

grahamperrin said:


> Knowing the version will be critical to some of what's discussed. From comments on previous pages, I _assume_ that _*[FONT=monospace]Sergei_Shablovsky[/FONT]*_ currently runs 12.2-RELEASE.



Sorry, I just hate to be late 


> FreeBSD gate.local.lan 12.3-PRERELEASE FreeBSD 12.3-PRERELEASE devel-12-n226714-653c0e9f345 pfSense amd64



So, where and what exactly I need configure to receive 1024x760 (or more) on my local VGA-screen ?


----------



## astyle (Nov 7, 2021)

Sergei_Shablovsky said:


> So, where and what exactly I need configure to receive 1024x760 (or more) on my local VGA-screen ?


You can go to top of page 3 of this thread and follow the instructions in post #51, which happens to be my post.


----------



## Sergei_Shablovsky (Nov 8, 2021)

Phishfry said:


> Usually this is a bare bones VGA with small amount video RAM. Limited capacity.
> But for console use it works fine. It's meant for system management not gaming.
> 
> SuperMicro uses a similar arrangement with AST2400/2500 video chip tied to BMC.
> ...


I just try to running as a little as possible: *this is server for hi-load netflow, and I try to minimize unnecessary pressure on hardware.*
So I tough from this point of view *Xorg is not good solution. Am I wrong?*



Erichans said:


> Glancing trough both it seems more likely though that Fujitsu has an OS-specific driver that can manipulate from "the inside" the resolution of the graphics part of the iRMC. The graphics output can be directed through iRMC or not; set in the BIOS setup utility. With an extra seperate graphics card that last option should be chosen.


I check double twice: in iRMC settings in BIOS *no possible to set anything than “Enabled”* in “Onboard Video”.
This settings automatically switch to “Disabled” if any discrete video card installed and detected by BIOS during cold boot.



Sergei_Shablovsky said:


> From PRIMERGY RX300 S7 System Configurator:
> (page 11):
> 
> Graphics Controller integrated in iRMC S3 (integrated Remote Management Controller):
> ...


So is that mean I have *ability to using sc(4)* ?



Phishfry said:


> The Matrox MGA module is for X11. It will do nothing for console use.
> Consider trying the sc(4) driver.


Sorry my dumb question, *what the settings and in which files I need to do in my particular case*?


----------



## grahamperrin@ (Nov 8, 2021)

Condensed questions (apologies if I'm overlooking something):



Sergei_Shablovsky said:


> … integrated video, exactly Matrox MGA G200e. …





Sergei_Shablovsky said:


> … PHILIPS monitor that I have connected is 1680x1050, 60Hz native res …



Is output to the Philips display (at the remote location) good enough? 

If you disconnect the Philips display, and boot with onboard video enabled (without a discrete graphics card), then does the remote view of the headless computer become easier?


----------



## grahamperrin@ (Nov 8, 2021)

Phishfry said:


> The Matrox MGA module is for X11. It will do nothing for console use. …



The _Console Redirection_ section of the _Remote Management Controller User's Guide_ does mention X11 (in a Linux context). Is this relevant?


----------



## astyle (Nov 8, 2021)

Sergei_Shablovsky said:


> So I tough from this point of view *Xorg is not good solution. Am I wrong?*


If you want to run an app in graphics (not text) mode, you do need Xorg. The apps you listed earlier only run in graphics mode.



Sergei_Shablovsky said:


> PHILIPS monitor that I have connected is 1680x1050, 60Hz native res. So is that mean I have *ability to using sc(4)* ?


 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.



grahamperrin said:


> Is output to the Philips display (at the remote location) good enough?
> 
> If you disconnect the Philips display, and boot with onboard video enabled (without a discrete graphics card), then does the remote view of the headless computer become easier?


OP should get Xorg going locally first.

grahamperrin :  The remote view of a headless computer shouldn't care if that headless machine has a local monitor attached...


----------



## grahamperrin@ (Nov 8, 2021)

> > … Remote Management … (1280x1024x24bpp 60Hz only possible if local monitor … is off)


----------



## astyle (Nov 8, 2021)

I guess that depends on the software in use... the RM software OP uses is apparently not very friendly to locally attached monitors...


----------



## Vull (Nov 8, 2021)

Sergei_Shablovsky said:


> ...
> So, where and what exactly I need configure to receive 1024x760 (or more) on my local VGA-screen ?


Assuming that you still have the mga.ko driver, and that it works, put these lines in /boot/loader.conf

```
kern.vty=vt
kern.vt.fb.default_mode="1024x768"
```

... and this line in /etc/rc.conf

```
kld_list="mga"
```

The resolution you specify must be supported by your monitor. Use 1024x768, not 1024x760, which I'm guessing was a typo. Most modern monitors support 1024x768 but I know of no monitor which supports 1024x760.

I don't have a Matrox card, but have tested this using the radeonkms.ko driver on my system, based on Phishfry's previous recommendations in this thread, and it worked.


----------



## Sergei_Shablovsky (Nov 9, 2021)

Vull said:


> Assuming that you still have the mga.ko driver, and that it works, put these lines in /boot/loader.conf
> 
> ```
> kern.vty=vt
> ...



Thank You for time and passion to help with this “pesky Matrox battle”! 

I already try the configuration You write (even try different mode 800x600, 1024x768, 1680x1050, 1600x1200, 1280x1024,...) - no successful result. Sadly...


----------



## Vull (Nov 9, 2021)

Sergei_Shablovsky said:


> Thank You for time and passion to help with this “pesky Matrox battle”!
> 
> I already try the configuration You write (even try different mode 800x600, 1024x768, 1680x1050, 1600x1200, 1280x1024,...) - no successful result. Sadly...


That would seem to indicate that the mga.ko driver isn't working properly even though you are able to load it according to your kldstat output.

Have you attempted to install the iRMC software yet? Maybe it includes its own drivers for this purpose.


----------



## Sergei_Shablovsky (Nov 10, 2021)

Vull said:


> That would seem to indicate that the mga.ko driver isn't working properly even though you are able to load it according to your kldstat output.


I come to the same conclusion. 
Especially after see that XDM start in a 640x480 resolution... 



Vull said:


> Have you attempted to install the iRMC software yet? Maybe it includes its own drivers for this purpose.


Of course, ALL firmware (from official web) for motherboard BIOS, iRMC, RAIDs and discrete/embedded LAN cards updated correctly and *checked double twice*.


----------



## astyle (Nov 10, 2021)

Sergei_Shablovsky said:


> Especially after see that XDM start in a 640x480 resolution...


Congratulations, it looks like you do have the Xorg session finally going.  Now, the easiest way to get an application to show up on a remote screen is to allow the SSH server to run on your local machine, and enable X forwarding on both the server and remote client.  But that is a different topic, for a different thread.


----------



## Sergei_Shablovsky (Nov 10, 2021)

astyle said:


> Congratulations, it looks like you do have the Xorg session finally going.  Now, the easiest way to get an application to show up on a remote screen is to allow the SSH server to run on your local machine, and enable X forwarding on both the server and remote client.  But that is a different topic, for a different thread.


But screen looks like unusable - shifted left and bottom and blurred... 

So I am still not able achieve goal: to start Bpytop on local screen on at 1024x768pix and more.


----------



## astyle (Nov 10, 2021)

Sergei_Shablovsky said:


> But screen looks like unusable - shifted left and bottom and blurred...
> 
> So I am still not able achieve goal: to start Bpytop on local screen on at 1024x768pix and more.


Well, now that you have Xorg going, you can play with the resolution values and the driver being loaded. I'd suggest* taking some good notes* on  what you have, what you changed, and why. If one change didn't work, you gotta be able to change it back to the way it was, scratch your head, and try a different value in the config file.


----------



## Sergei_Shablovsky (Nov 11, 2021)

astyle said:


> Well, now that you have Xorg going, you can play with the resolution values and the driver being loaded.


So, is the Xorg *ONLY ONE possible solution* in my case?



astyle said:


> I'd suggest* taking some good notes* on what you have, what you changed, and why. If one change didn't work, you gotta be able to change it back to the way it was, scratch your head, and try a different value in the config file.



Thank You for suggestions, my personal experience tech me about making nots for each and everything more than 30y ago.


----------



## astyle (Nov 11, 2021)

Sergei_Shablovsky said:


> So, is the Xorg *ONLY ONE possible solution* in my case?


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. 

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. 

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.


----------



## Sergei_Shablovsky (Nov 11, 2021)

astyle said:


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



astyle said:


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



astyle said:


> 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 (Nov 11, 2021)

Sergei_Shablovsky said:


> 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 (Nov 11, 2021)

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 (Nov 11, 2021)

sko said:


> 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 (Jun 29, 2022)

astyle said:


> 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 (Jun 29, 2022)

Sergei_Shablovsky said:


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





Sergei_Shablovsky said:


> In */boot/loader.conf.local *
> ...
> i915kms_load="NO"
> mga_load="YES"
> ...


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 (Jun 29, 2022)

astyle said:


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



astyle said:


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



astyle said:


> 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 (Jun 30, 2022)

Sergei_Shablovsky said:


> In /boot/loader.conf.local
> ...
> mga_load="YES"
> kern.vty=sc
> ...


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

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


Sergei_Shablovsky said:


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


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


----------



## shkhln (Jun 30, 2022)

Sergei_Shablovsky said:


> 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 (Jun 30, 2022)

shkhln said:


> 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 (Jun 30, 2022)

astyle said:


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



astyle said:


> 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) ?



astyle said:


> 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 (Jun 30, 2022)

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?


----------

