You are not logged in.
terminus-font is already installed, this is where ter-112n comes from.
here is fbset -i output :
mode "1024x768-76"
# D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz
geometry 1024 768 1024 768 32
timings 12714 128 32 16 4 128 4
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name : EFI VGA
Address : 0xf1000000
Size : 3145728
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 0
YPanStep : 0
YWrapStep : 0
LineLength : 4096
Accelerator : Noif you want to compare with another machine plugged on the same screen, "fbset -i" produces this output:
mode "1920x1080"
geometry 1920 1080 1920 1080 32
timings 0 0 0 0 0 0 0
rgba 8/16,8/8,8/0,0/0
endmode
Frame buffer device information:
Name : radeondrmfb
Address : (nil)
Size : 8294400
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 1
YPanStep : 1
YWrapStep : 0
LineLength : 7680
Accelerator : NoOffline
Tbc, you'look looking for a font smaller than 6x12?
https://aur.archlinux.org/packages?K=tamsyn
https://aur.archlinux.org/packages/miniwi-font-git
Edit: does "video=efifb:width:1920,height:1080" work?
Last edited by seth (2025-02-04 22:48:30)
Offline
does "video=efifb:width:1920,height:1080" work?
no, it doesn't; Linux stops loading after printing "Loading initial ramdisk"
miniwi seems "dead":
fatal: remote error: access denied or repository not exported: /miniwi
==> ERROR: Failure while downloading miniwi-font-git git repo
Aborting...I'm gonna give a try to tamsyn, thanks.
edit: tamsyn-5x9 is really tiny and quite unreadable. he immediate bigger size is 6x12 that is teh same as ter-112n.
Last edited by sukolyn (2025-02-04 23:41:36)
Offline
useless self quoting. cannot delete.
Last edited by sukolyn (2025-02-05 17:09:20)
Offline
There isn't much between 5x9 and 6x12
You're running on the efifb and yuro EFI seems to only do XGA - there isn't much you could do about that w/ the 470xx drivers (except for an UEFI udpate to hopefully allow FullHD - I'm pretty sure linux doesn't "stop loading", efifb just cannot display that resolution)
I will point out that enforcing the FullHD efifb has the same effect as the FullHD simpledrmfb - the only thing that works for you is/was nouveaudrmfb and for that you'd probably need to compile a custom kernel resp. file a bug against the simpledrmfb (since the 470xx drivers will not see any feature updates)
Offline
file a bug against the simpledrmfb
there https://gitlab.freedesktop.org/drm ?
edit:
I'm pretty sure linux doesn't "stop loading", efifb just cannot display that resolution
even after a while, the machine is unreachable through ssh.
a kind of black dot appears between the two L of Loading lines, then disk's led doesn't blink anymore.
edit2: I tried "video=efifb:list", and it list three modes, the maximum resolution being 1024x760.
efifb comes from nvidia's driver installation?
Last edited by sukolyn (2025-02-05 17:26:09)
Offline
forget about it all : nvidia-kms doesn't solve the initial problem, it leads to other (deeper) problems.
LTS has been updated to 6.12.
never mind I reinstalled 6.6-LTS from cache, and marked it as not being updated in pacman.conf
and so, I've got my TTY back to "1920x1080", and X11 as well, **with "linux-6.6-lts"**, but screen di·e·sconnects with 6.13
what do I do now ?
file a bug against the simpledrmfb there https://gitlab.freedesktop.org/drm ?
Last edited by sukolyn (2025-02-05 20:57:11)
Offline
efifb comes from nvidia's driver installation?
No, but it's (next to vesafb) the only FB driver compatible w/ the older nvidia drivers.
Looking again at your earlier journals, you've been running on efifb there too - what happens if you add "nvidia_drm.modeset=1 video=efifb:off" to block simpledrm AND efifb?
Does nouveaudrmfb take over again?
forget about it all : nvidia-kms doesn't solve the initial problem, it leads to other (deeper) problems.
Does 6.13/nouveau allow you to run X11/wayland at FullHD?
Offline
Does 6.13/nouveau allow you to run X11/wayland at FullHD?
no. As usual since 6.10, screen disconects, and doesn't "resume" when I run sx.
Looking again at your earlier journals, you've been running on efifb there too - what happens if you add "nvidia_drm.modeset=1 video=efifb:off" to block simpledrm AND efifb?
Does nouveaudrmfb take over again?
wait a moment, please, so I reinstall nvidia-470xxx-dkms...
Last edited by sukolyn (2025-02-06 17:02:38)
Offline
No! That's for nouveau - nvidia_drm.modeset=1 will block the simpledrm driver regardless whether you're actually using Nvidia.
Offline
<edit:> crossing posts </edit>
Looking again at your earlier journals, you've been running on efifb there too - what happens if you add "nvidia_drm.modeset=1 video=efifb:off" to block simpledrm AND efifb?
machine seems stuck at "Loading...", but boot completes : I can login through ssh.
no TTY is reachable using Ctrl-Alt-Fn.
Does nouveaudrmfb take over again?
I'd say no:
[root@OptiPlex7010 ~]# journalctl -b -g nouveau
-- No entries --
[root@OptiPlex7010 ~]# journalctl -b -g drm
févr. 06 18:25:29 archlinux kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=29073ff0-9a95-4719-a1b8-19fbb7ce0bc7 rw nvidia_drm.modeset=1 video=efifb:off loglevel=3 resume=UUID=7bbffdae-84b2-48cd-9ca3-33fdfe07eb2b
févr. 06 18:25:29 archlinux kernel: The simpledrm driver will not be probed
févr. 06 18:25:29 archlinux kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=29073ff0-9a95-4719-a1b8-19fbb7ce0bc7 rw nvidia_drm.modeset=1 video=efifb:off loglevel=3 resume=UUID=7bbffdae-84b2-48cd-9ca3-33fdfe07eb2b
févr. 06 18:25:29 archlinux kernel: ACPI: bus type drm_connector registered
févr. 06 18:25:34 OptiPlex7010 systemd[1]: Starting Load Kernel Module drm...
févr. 06 18:25:34 OptiPlex7010 systemd[1]: modprobe@drm.service: Deactivated successfully.
févr. 06 18:25:34 OptiPlex7010 systemd[1]: Finished Load Kernel Module drm.
févr. 06 18:25:39 OptiPlex7010 kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
févr. 06 18:25:39 OptiPlex7010 kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 0
févr. 06 18:25:39 OptiPlex7010 kernel: Registered the nv-hotplug-helper DRM client.here's complete journal: http://0x0.st/8PcM.txt
Last edited by sukolyn (2025-02-06 17:31:54)
Offline
No! That's for nouveau - nvidia_drm.modeset=1 will block the simpledrm driver regardless whether you're actually using Nvidia.
ouch. I don't understand.
I don't reinstall nvidia, and I simply add "nvidia_drm.modeset=1 video=efifb:off" to regular 6.13 kernel, is that it ?
Offline
anyway, uninstalled "nvidia-470xx-dkms" leaving kernel's parameters "nvidia_drm.modeset=1 video=efifb:off" in place, with no changes : screen keeps on disconnecting to never wake again, even I blindly start X11.
Offline
That was the plan, the nvidia paramer blocks the simpledrm device, the efifb parameter that driver - can you post a journal from such boot?
Offline
here it is: http://0x0.st/8P2f.txt
Offline
There's neither efifb, nor vesafb nor simpledrm nor nouveaudrmfb and the result is
févr. 07 18:15:48 archlinux kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes
févr. 07 18:15:48 archlinux kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes
févr. 07 18:15:48 archlinux kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes1. nvidia (+efifb): XGA console (but afaiu X11 works at FullHD)
2. nouveau + whatever: no console.
Back to square one.
Have we tried to inject the edid along nouveau + simpledrm (no other kernel parameters) but also adding the edid to the initramfs or have you only loaded it (possibly too late) from the root partition AND enforce a mode w/ the "video" parameter?
Offline
added edid.bin to mkinitcpio.conf:
# grep ^FILE /etc/mkinitcpio.conf
FILES=(/usr/lib/firmware/edid/HDMIedid.bin)did "mkinitcpio -p linux"
added "drm.edid_firmware=HDMI-1:edid/HDMIedid.bin" to kernel parameters by editing grub at boot
here are the journals
6.6.72-1-lts x86_64: http://0x0.st/8PyZ.txt ending with console and X11 OK
6.13.1-arch1-1 x86_64: http://0x0.st/8Pyb.txt ending with no screen
Offline
You didn't add some "video=HDMI-1:1920x1080@60Re" parameter?
But nouveau and simpledrm are unimpressed by the edid ![]()
févr. 08 13:25:19 archlinux kernel: DMI: Dell Inc. OptiPlex 7010/0GXM1W, BIOS A08 09/19/2012And you'll probably also not get any BIOS updates for that system either…
So let's throw some shit at the wall: "nouveau.config=NvGspRm=0 nouveau.runpm=0 nouveau.ignorelid=1 nouveau.nofbaccel=1 nouveau.noaccel"
You need to load the nouveadrmfb driver what likely fails somewhwere here: https://elixir.bootlin.com/linux/v6.13/ … drm.c#L835
Another thing would be to blacklist nouveau resp. take it (and/or the kms hook) out of the initramfs to have it load late in case the PCI device isn't yet ready.
Offline
here are journals with video and edid_firmware, but yet no shit on the wall (i trying to find one... wall
)
6.6.72-1-lts x86_64 http://0x0.st/8Pxw.txt
6.13.1-arch1-1 x86_64 http://0x0.st/8PxE.txt
Offline
found a wall ! it's covered with dirt, now. ![]()
6.6.72-1-lts x86_64 http://0x0.st/8PYs.txt bad resolution 1024x768
6.13.1-arch1-1 x86_64 http://0x0.st/8PYo.txt bad resolution 1024x768, so is X11, too, but screen survives.
Last edited by sukolyn (2025-02-08 19:58:17)
Offline
nouveau.config=NvGspRm=0 ->can't find NvGspRm there. removed with no effects.
nouveau.runpm=0 ->removed with no (bad) effects
nouveau.ignorelid=1 ->no lid. removed with no (bad) effects
nouveau.nofbaccel, nouveau.noaccel ->leaving both with no parameters (default seems to be "disable", right?) renders bad resolution.
Last edited by sukolyn (2025-02-11 23:39:34)
Offline
The repsonse in the journals in #45 is that nouveau doesn't seem to load at all and you're getting the simpledrm device.
nofbaccel gets ignore on either kernel, try only "nouveau.noaccel=1" …
Edit: and please post the journal for that.
Last edited by seth (2025-02-12 09:01:01)
Offline
"nouveau.noaccel=1" ends with no screen.
here is the journal: http://0x0.st/8ZJm.txt
Offline
Restore "nouveau.runpm=0 nouveau.ignorelid=1" into that configuration (afaiu you had only tried them w/ the bogus parameter leading to the simpledrm/vesa condition?)
Offline
# journalctl -b -n +2
févr. 14 17:38:35 archlinux kernel: Linux version 6.13.2-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000
févr. 14 17:38:35 archlinux kernel: Command line: <snip...> nouveau.runpm=0 nouveau.ignorelid=1 nouveau.noaccel=1 loglevel=3 resume=UUID=7bbffdae-84b2-48cd-9ca3-33fdfe07eb2bhere is complete log: http://0x0.st/8NZI.txt
here's /etc/mkinitcpio.conf (in case I did something wrong in it):
# grep -v '^\(#\|$\)' /etc/mkinitcpio.conf
MODULE=()
BINARIES=()
FILES=()
HOOKS=(base systemd udev autodetect microcode modconf sd-vconsole keyboard keymap consolefont block filesystems resume fsck)X starts
$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
None-1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.00*+I tried to suspend, and at resume the screen doesn't "connect" back.
I can still ssh to the machine.
Offline