Setting console resolution gives error message of mode not supported

[sidetone]

When setting the resolution for two monitors to "1024x768" or to "1280x720" (720p) the desired effect takes place,
/boot/loader.conf

kern.vt.fb.default_mode="1280x720"

but the following error message repeats, which can also be seen with dmesg:

drmn0: [drm] User-defined mode not supported: "1024x768": 60 64127 1024 1080 1184 1344 768 769 772 795 0x20 0x6

These two resolutions seem to be supported according to xrandr, when I use Xorg. This has happened since I installed graphics/drm-61-kmod. Leaving this blank doesn't cause this error message, however, both monitor resolutions don't have the appropriate resolution in this case. How can I fix this?

Also, trying to find the specific monitor or output for kern.vt.modes doesn't show from dmesg output. Could the output device for this be "drmn0", because that doesn't seem correct?

Also, it's odd that later when I turned off xdm from ttys, this error message went away. I checked what I inserted in xrandr settings. Also, when removing the setting from loader.conf, this error message also goes away. Could this be a bug?

Previously, I had a similar error, when X didn't work at all, but installing the proper xf86 driver for Intel graphics for X made it work. Still getting error messages though.

 

[Phishfry]

These two resolutions seem to be supported according to xrandr, when I use Xorg.

What I see is xrandr reports resolutions not really available.

Try gop list from loader prompt (Beastie Menu #3). For EFI Framebuffer those are the resolutions actually available.
They seem to correspond to modesetting driver resolutions for X11 that actually work with 915drm in EFI mode.

 

[sidetone]

From the "Welcome to FreeBSD" menu, to option "3. Escape to loader prompt"?

gop list didn't work, and I didn't see anything like it when typing ?.

 

[vmisev]

That's strange... Which version of FreeBSD you are running? Did you update loader in the EFI partition after upgrading? Easiest way to check is:

diff /boot/loader.efi /boot/efi/EFI/Boot/bootx64.efi

If there is no diff output, all is fine, but if there is a message that they differ do:

sudo cp /boot/loader.efi /boot/efi/EFI/Boot/bootx64.efi

and then

shutdown –r now

Part of my /boot/loader.conf

efi_max_resolution="1600x1200"
vbe_max_resoulition="1600x1200"
kern.vty=vt
kern.vt.fb.default_mode="1600x1200"
screen.textmode="0"

For me, it works on bare metal install with Nvidia GTX 970 and also on every VirtualBox VM's on Win hosts I have around.

 

[Phishfry]

gop list didn't work, and I didn't see anything like it when typing ?.

Perhaps you are running LegacyBIOS and not UEFI mode?

sysctl machdep.bootmethod

 

[T-Aoki]

GOP is defined in UEFI spec, so if booted using legacy BIOS, loader command gop should not be available.
Another source here.

 

[vmisev]

I didn't even consider that we are potentially talking here about legacy and not efi boot, silly me In my defense, I didn't see FreeBSD booting in legacy BIOS mode for ages now; mind the GUI, it's vt(4) that needs efi boot to set native resolution and proper size fonts.
Phishfry - good tip on machdep.bootmethod, that's definitely first thing to check here.
T-Aoki - thanks for the first link, it's very informative

 

[T-Aoki]

There still people who have some issues with vt while sc is sane.
And sc does not work (except at least a function to determine it's active or not) when booted using UEFI boot.
sc is deprecated but not yet removed from src tree and built by default, so we still need to consider about legacy BIOS boots.

And at least x11/nvidia-driver[-304|-340|-390|-470|-devel] depends on one of sc-related function to check the existence of sc.
We who are maintaining x11/nvidia-driver and related ports are still wondering what's the way to go, until sc dissappears from all supported versions of FreeBSD. See PR 277365 if you're interested.

 

[sidetone]

Which version of FreeBSD you are running?

FreeBSD 14.3. Additionally, using
x11-drivers/xf86-video-intel with graphics/drm-61-kmod. The previous versions of drm kmod which were a default for 14.2 and previous releases didn't have this problem.

Did you update loader in the EFI partition after upgrading?

sudo cp /boot/loader.efi /boot/efi/EFI/Boot/bootx64.efi

Perhaps you are running LegacyBIOS and not UEFI mode?
sysctl machdep.bootmethod

machdep.bootmethod: BIOS

The next question is, can I still use vt with legacy bios? If not, this could be a bug. Or at minimum, how would one suppress the error message?

Or can I adjust my install to UEFI without reinstalling?

Back to finding the correct output, it doesn't show with dmesg, but shows when using grep on /var/log/Xorg.0.log. Inserting this into the appropriate line in loader.conf still didn't work for the monitor I needed it for.

There still people who have some issues with vt while sc is sane.

And sc does not work (except at least a function to determine it's active or not) when booted using UEFI boot.

sc is deprecated

It's better to go with VT. If it means filing a bug report, so it can be fixed to work with BIOS. It works enough, but there's an error message.

sc worked enough when used with VESA, but it didn't seem to work with newer graphics drm-*-kmod kernel modules from previous FreeBSD versions.


I reiterate, that when I set my desired loader.conf resolution settings, the desired setting takes place, and the error message goes away when xdm/Xorg is disabled. Alternatively, the error message also goes away when I remove loader.conf resolution settings, and enable xdm/xorg. This implies, there's a mismatch between the newer kernel drm modules for graphics, and the xf86 driver or xorg.conf.d/. Still, while a lot of functions from loader.conf don't work on mine, enough limited functions do.

 

[vmisev]

T-Aoki I know that's doesn't matter for English only speaking people, but thing that made me strong advocate for the vt(4)() (and the newcons as it was called in the beginning) was support for UTF and custom fonts. I know that there were some problems with vt leaking dmseg info into unprivileged accounts under some rare conditions (I complained about that to the smarter folks than me up the chain, that was in 11 or 12 - I can't remember now), but since 13, personally I had no problems with vt. As for Nvidia, I 'm not using drivers from ports, I'm compiling&installing drivers downloaded from Nvidia site.

sidetone As for the moving from BIOS to the UEFI install without OS reinstalling, this might be good starting point (note: you'll need a spare disk for that), but I never did that, so no guaranties:
https://web.archive.org/web/2024102...graphica.com.au/tips/converting-freebsd-bios/

Good luck!

 

[SirDice]

As for Nvidia, I 'm not using drivers from ports, I'm compiling&installing drivers downloaded from Nvidia site.

It's the same driver. NVidia site might have a slightly newer version but the port downloads and installs the driver from the NVidia site.

 

[T-Daemon]

The next question is, can I still use vt with legacy bios?

Sure you can, vt(4) is not limited to UEFI, your BIOS system is using it (if not set explicitly to sc(4)) , check sysctl kern.vty.

Or can I adjust my install to UEFI without reinstalling?

If there is some free space left on the disk (it can be the last sectors of the disk), you can easily add an ESP, ~ 1M will do:

% ls -lA /boot/loader.efi
-r-xr-xr-x  2 root wheel 662016 Jun  9 13:30 /boot/loader.efi

When there is not enough free space left, and if there is a swap partition, delete it, take a few MB (5-10M should be sufficient), recreate swap, create ESP.

The default size of the ESP is 260m when the system is menu guided installed. For comparison, the FreeBSD installer .iso images have a efi partition size of 2M, and 33M on .img.

 

[vmisev]

It's the same driver. NVidia site might have a slightly newer version but the port downloads and installs the driver from the NVidia site.

I know, it's just a habit – there (some time ago) used to be a problem with pkg/ports drivers install, like when .ko was still put in /boot/loader.conf instead of /etc/rc.conf even if it was too big to load from boot loader, nvidia-settings being a version back (4 vs 5), etc.

Even when there was change in <sys/param.h> (AFAIR around ~13.1), and Nvidia didn't catch up to the change in FreeBSD for some time, I posted simple ed(1) to fix that:
"in 'src/nvidia-modeset/' do:
printf '%s\n' 14m11 w q | ed -s nvidia-modeset-freebsd.c" /q

 

[vmisev]

Sure you can, vt(4) is not limited to UEFI, your BIOS system is using it (if not set explicitly to sc(4)) , check sysctl kern.vty.


If there is some free space left on the disk (it can be the last sectors of the disk), you can easily add an ESP, ~ 1M will do:

% ls -lA /boot/loader.efi
-r-xr-xr-x  2 root wheel 662016 Jun  9 13:30 /boot/loader.efi

When there is not enough free space left, and if there is a swap partition, delete it, take a few MB (5-10M should be sufficient), recreate swap, create ESP.

The default size of the ESP is 260m when the system is menu guided installed. For comparison, the FreeBSD installer .iso images have a efi partition size of 2M, and 33M on .img.

I can't remember, was it 11 to 12 transition, but there was problem with efi partition being too small for the new loader.efi? Since, I'm going with 1G for efi, just to be safe for future upgrades ...

 

[T-Aoki]

I know that's doesn't matter for English only speaking people, but thing that made me strong advocate for the vt(4) (and the newcons as it was called in the beginning) was support for UTF and custom fonts.

It's why I'm using vt (trying from quite early phase it was introduced into HEAD (currently called main after transition from subversion to git), thanks to b16.fnt. So I have remnants I needed to switch between sc and vt in my /etc/rc.conf when vt was quite unstable.

if [ "vt" = `sysctl -n -q kern.vty` ]
then
  keymap="jp.kbd"
#  vidcontrol -f /usr/share/vt/fonts/b16.fnt
  allscreens_flags="-f /usr/share/vt/fonts/b16.fnt"
else
  keymap="jp.106.kbd"
fi

I know, it's just a habit – there (some time ago) used to be a problem with pkg/ports drivers install, like when .ko was still put in /boot/loader.conf instead of /etc/rc.conf even if it was too big to load from boot loader, nvidia-settings being a version back (4 vs 5), etc.

A problem that official tarball has is that it officially does NOT support main branch (aka -Current) version of FreeBSD and has version check to reject it.
But actually, it "usually" runs on main. And ports has REINPLACE (actually a sed RE) to kill the version check. And if any build error happenes on main, fix is introduced by us as patches and/or REINPLACE on ports side.

Another thing you may be overlooking would be a workaround for a tunable in graphics/nvidia-drm-*-kmod and GSP related workarounds relatively recently introduced.

And currently, latest New Feature Branch of driver 575.64.03 as -devel variant. Latest Production Branch of driver 570.172.08 is under review as D51407.

 

[vmisev]

It's why I'm using vt (trying from quite early phase it was introduced into HEAD (currently called main after transition from subversion to git), thanks to b16.fnt. So I have remnants I needed to switch between sc and vt in my /etc/rc.conf when vt was quite unstable.

if [ "vt" = `sysctl -n -q kern.vty` ]
then
  keymap="jp.kbd"
#  vidcontrol -f /usr/share/vt/fonts/b16.fnt
  allscreens_flags="-f /usr/share/vt/fonts/b16.fnt"
else
  keymap="jp.106.kbd"
fi

A problem that official tarball has is that it officially does NOT support main branch (aka -Current) version of FreeBSD and has version check to reject it.
But actually, it "usually" runs on main. And ports has REINPLACE (actually a sed RE) to kill the version check. And if any build error happenes on main, fix is introduced by us as patches and/or REINPLACE on ports side.

Another thing you may be overlooking would be a workaround for a tunable in graphics/nvidia-drm-*-kmod and GSP related workarounds relatively recently introduced.

And currently, latest New Feature Branch of driver 575.64.03 as -devel variant. Latest Production Branch of driver 570.172.08 is under review as D51407.

Thanks for that, that's very useful info and important to know about. TBH, I stopped updating Nvidia drivers some time ago, because I was under wrong impression that 970, which I have, went into legacy status. Just now I checked again and saw that I was wrong about that. Thanks again

 

[sidetone]

I'm not going to go the route of using UEFI on this computer. Enough users also use VT with BIOS, that it needs a solution.

It seems like some have overlooked, that settings from VT conflicted with xdm and xorg. When resolutions from VT were set, the error message only popped up when xdm/xorg were enabled. When xdm/xorg were enabled, the error message only popped up when resolution settings under VT were set. It was either or, that caused this. On the terminal console, the resolution needed to be the appropriate size and span for each monitor, in this case both monitors are intended to show the same (mirror) output on the terminal console. This is with FreeBSD 14.3, with drm-61-kmod. Previous kmod drm versions didn't have this problem. PR 288372

When XGA resolution (1024x768) was set for both xdm through xrandr and for vt, error messages came up, every time the xdm screen came on. Both monitors supported this resolution, and for the same refresh rate. Both of my monitors also supported 720p resolution (1280x720), but at slightly different refresh rates, and error messages occurred more frequently here.

PR 288373, for setting individual monitor resolutions in VT for BIOS isn't working.

I wanted both monitors to have an acceptable resolution for use in terminal console mode, so that both had the same output in sizes that matched the monitors. On the larger monitor, the default setting would have the display fill 3/4 of the screen and has a tiny resolution compared to the monitor: PR 288397. It would make sense that the text size is the same across both monitors, however, two monitors are used to mirror each other, and one isn't to carry the left over of text, and multihead isn't available in terminal console. Setting the larger mentioned resolutions gave the previously mentioned error message.

Maybe adding a configuration file under xorg.conf.d would work, but I've never been successful setting xorg.conf, and other ways always worked before when that file was ignored or broke things.

For now, I won't set the resolution in loader.conf through vt, so I can bypass the error message and any potential problems surrounding it. Those bug fixes may take a while. I'll use two X server sessions, one with x11-wm/fswm with terminal emulators to do what I used to do on the terminal console. I'll mainly use the terminal console for emergencies for now.