Is there any way to change to the text console scrolling speed without rebooting? Currently using Fedora, but non-distribution-specific answers appreciated. https://www.kernel.org/doc/Documentation/fb/vesafb.txt I'd like to use 'ywrap' in the above documented kernel parameters for vesafb without having to reboot the kernel to try it.

This is a pretty straightforward question. I am writing a Qt program that looks to render graphics in the terminal. To do that, I utilize Sixel Graphics which has a large overhead. I would rather render directly to the frame buffer, but can that be done while X and Wayland are running? Or do I have to strictly be in a headless environment, meaning no active desktop environment, to be able to access this? Does X or Wayland perhaps have functions allowing me to use it to render graphics through it? Thanks.

Under Linux/Ubuntu: I had an impression that to have video output (either in console mode or GUI mode), there must be a fbdev listed in /proc/fb. But today on my system, I installed a NVIDIA GTX1650 card, and under /etc/modprobe.d, the options nvidia-drm modeset=1 and options nvidia-drm fbdev=1 are disabled. After reboot, the system shows that /proc/fb is empty, but the X11/Gnome desktop is showing up correctly. I guess I must have a mis-understanding of the implications of /proc/fb content. Can you please give me some hints on that?

I'm trying to get console output on **both the onboard iGPU (Intel i915, HDMI output)** and **the AST BMC (IPMI remote display)** on my headless server setup. #### Hardware and OS * **Motherboard**: ASUS Pro WS W680-ACE IPMI * **CPU**: Intel i9-14900 * **OS**: Ubuntu 24.04.2 LTS (Pro), kernel 6.8.0-60-generic, UEFI boot * systemd is in use and default GRUB is installed #### BIOS Settings All relevant GPU-related options are enabled:

Primary Display       [CPU Graphics]
iGPU Multi-Monitor    [Enabled]
DVMT Pre-Allocated    [64M]
RC6 (Render Standby)  [Enabled]

When I boot into the BIOS firmware setup, **both HDMI and IPMI outputs mirror the BIOS screen correctly**, confirming that hardware-level multi-display support is working. #### Framebuffer Devices After booting Linux:

$ ls /dev/fb*
/dev/fb0  /dev/fb1

$ cat /sys/class/graphics/fb*/name
i915drmfb
astdrmfb

So: * /dev/fb0 = Intel iGPU (HDMI) * /dev/fb1 = AST BMC (IPMI) #### What I’ve Tried I’ve tried modifying /etc/default/grub with various combinations of fbcon=map: and console=ttyX: 1. GRUB_CMDLINE_LINUX_DEFAULT="fbcon=map:1,0 console=tty1 console=tty2" → **Only IPMI (fb1) works**, HDMI stays black. 2. GRUB_CMDLINE_LINUX_DEFAULT="fbcon=map:0,1 console=tty1 console=tty2" → **Only HDMI (fb0) works**, IPMI stays black. 3. GRUB_CMDLINE_LINUX_DEFAULT="fbcon=map:both console=tty1 console=tty2" → **Nothing appears on either display**. (Yes, I realize fbcon=map:1,0 maps tty1 to fb1 and tty2 to fb0 — that behavior is expected.) I also enabled getty@tty2.service and confirmed it’s running. --- ### What I Want * Ideally: **Same console output mirrored** on both HDMI and IPMI * Acceptable: **Separate virtual terminals** (e.g., tty1 on IPMI, tty2 on HDMI) But so far I can only get one to work at a time, depending on how I order fbcon=map. Any suggestions? Is this a limitation in fbcon, the kernel, or something I can work around with udev, early KMS, or a boot service?

I can successfully display images using the following command: sudo fbi -T 1 /home/pi/photo-screen/photos/*.jpg -t 4 I now want to start a slide show of those pictures as soon as the Raspberry PI boots up. So I added a systemd file like so:

`service
[Unit]
Wants=graphical.target
After=graphical.target

[Service]
Type=simple
User=pi
Group=pi
WorkingDirectory=/home/pi/photo-screen
ExecStart=sudo bash -c "fbi -T 1 -d /dev/fb0 photos/*"
Restart=always
RestartSec=20

[Install]
WantedBy=multi-user.target

`

● photo-screen.service
     Loaded: loaded (/etc/systemd/system/photo-screen.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-12-11 15:12:07 CET; 61ms ago
   Main PID: 1080 (sudo)
      Tasks: 2 (limit: 472)
        CPU: 23ms
     CGroup: /system.slice/photo-screen.service
             ├─1080 sudo bash -c fbi -T 1 -d /dev/fb0 photos/*
             └─1082 fbi -T 1 -d /dev/fb0 photos/0058966c-7ee5-4fc0-80ec-55885809567b.jpg photos/04669eb7-bf5e-4cbf-ab8f-fc7b3566186d.jpg photos/0cc1ad40-1b05-4f1c-beae-0c285d6b62>

Dec 11 15:12:07 foto systemd: Started photo-screen.service.
Dec 11 15:12:07 foto sudo:       pi : PWD=/home/pi/photo-screen ; USER=root ; COMMAND=/usr/bin/bash -c fbi -T 1 -d /dev/fb0 photos/*
Dec 11 15:12:07 foto sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)

Please note that I am signed in via SSH so assigning the right tty does work fine with the -T 1 parameter. I tried: - Including chvt 1; in my script - Running it as root - Adding the option -d /dev/fb0 to my script - Using fim but there I have the exact same problem - Using non-relative paths I have a screen attached and the login prompt does at some point get black but I don't see any images. I did get OOPS Terminated at some point on the screen above the login prompt. Also when I fill the screen with random stuff then it will be overwritten after some time with a black bar that fills around 80% of the screen: cat /dev/random > /dev/fb0 I tried replacing my fbi-script with cat /dev/random > /dev/fb0 but that did not fill the screen either. I thought that giving an elevated bash terminal might fix the problem: sudo bash -c "chvt 1; fbi -T 1 -d /dev/fb0 images/*" That again works via my ssh terminal but not using systemd.

I have one of those 7" HDMI diplays from eBay, driving it with a Q1900 board running Ubuntu 20. I can write to the display using fbi: sudo fbi -a -T 1 --noverbose -d /dev/fb0 -t 5 --blend 1000 "${PICTURE}" But the images seem to stay in the framebuffer, or the panel. When I write a second image, the display alternates between showing the two. I've tried dd if=/dev/nul of=/dev/fbo and just /dev/fbo. Neither work though. I haven't tried powercycling the Linux box, but powercycling the panel does nothing. If I have to reset the computer it's just not going to work for me. Is there some command to flush the framebuffer, or is that not what I have to do? TI

This -geometry 256x144+1095+600 work to show video in rigth bottom: mplayer -ontop -noborder -geometry 256x144+1095+600 -loop 0 -idle -fixed-vo -msglevel all=-1 2>/dev/null video.mp4 But this one (-vo caca) always stay in same position with same width and height regardless of -geometry any_value: mplayer -vo caca -ontop -noborder -geometry 256x144+1095+600 -loop 0 -idle -fixed-vo -msglevel all=-1 2>/dev/null video.mp4 My ultimate goal is display it in virtual console, so i wanted to know the equivalent format of -geometry for -vo caca. (It could be nice to know -vo fbdev too :)

When I boot my Linux machine with UEFI and grub2, I get only few graphic modes (resolution modes) available. And both of them are really smaller than my monitor/screen. For example, the boot console resolution gets set to 800x600 while my screen is 1920x1080, and the picture looks really bad. My GPU is Nvidia, but **I don't want to install, insert or use any GPU-specific drivers. At least, not at boot**. > **I am interested in changing the initial EFI/VGA boot console (and GRUB2) resolution to match my full screen.** Some sources say that **I can not**, because it is only possible to use resolutions supported by the GPU in VESA-extensions mode. **Is it true? Does it apply to my case? Or do I just need to *change some UEFI settings*?** I would like to have the full resolution enabled right from the moment when GRUB starts. Is it possible?

I am trying to get the boot splash I built into my unified kernel image to remain on screen for more of the boot process. Currently the transition from the UEFI logo to the boot splash is completely seamless, but the boot splash shuts off a considerable amount of time before my login screen appears. I'm not expecting a perfectly seamless transition from splash to login, as nice as that would be, but there must be some way to at least hang onto it for a little longer while things that don't need the display are initializing. As far as I can tell based on the research I've done, some process is clearing the initial frame buffer set up by the kernel, which I've taken a few steps to address, but I'm not entirely sure if I've done everything I can. Here's a quick overview of all my different settings. Splash built into the unified kernel image using /etc/mkinitcpio.d/linux.preset default_uki="/boot/arch-linux.efi" default_options="--splash=/etc/mkinitcpio.d/bootsplash.bmp" KMS removed from mkinitcpio.conf hooks to prevent early modesetting by the GPU HOOKS=(systemd autodetect microcode modconf keyboard sd-vconsole block filesystems) amdgpu.seamless=1 added to kernel parameters to smooth the transition to amdgpu when it inevitably does takeover, as well as various output silencing parameters quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3 vt.global_cursor_default=0 amdgpu.seamless=1 I've also added the line TTYVTDisallocate=no to both systemd-vconsole-setup.service and getty@tty1.service Can anyone think of anything else I should be changing/adding/trying? Please refrain from suggesting I use Plymouth, it is notoriously buggy unless you specifically use software and hardware that integrates well with it. I tried for two days straight, the only way I could get a seamless transition from UEFI to splash was by configuring it to use the simpledrm driver which completely borked the resolution. Opting for the amdgpu driver and kernel mode setting with Plymouth causes there to be a black screen between the UEFI logo and the splash screen due to the time it takes for the amdgpu to actually initialize. This is a well documented problem if you take the time to look into it. Again, please do not suggest I use Plymouth. I'm not looking for splash screen alternatives, I'm looking for an answer to the question in the post title. It may be that there is no way to do so, and if that is the case then so be it, but that's what I'm here to find out. Thank you for taking the time to read.

I have a RTSP viewer on a small local network that I would like to use as a monitor. I'ts really just to access the CLI in the event that an automated service on a Rspberry pi doesn't start or run correctly. so far I have this script using gstreamer, but I can't seem to connect to it. It appears that the server is running but I can't connect to it. I have shutdown the firewall and have verified that the port is open with netstat. I'mnot sure what do try next. import gi gi.require_version('Gst', '1.0') gi.require_version('GstRtspServer', '1.0') from gi.repository import Gst, GstRtspServer, GLib class CLI_RTSPServer(GstRtspServer.RTSPMediaFactory): def __init__(self): super(CLI_RTSPServer, self).__init__() #self.set_launch("( fbdevsrc device=/dev/fb0 ! videoconvert ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )") self.set_launch("( fbdevsrc device=/dev/fb0 ! videoscale ! video/x-raw,width=640,height=480 ! videoconvert ! x264enc tune=zerolatency bitrate=500 ! rtph264pay name=pay0 pt=96 )") if __name__ == "__main__": Gst.init(None) server = GstRtspServer.RTSPServer() factory = CLI_RTSPServer() factory.set_shared(True) server.set_service("554") # Bind to the default RTSP port 554 server.get_mount_points().add_factory("/cli", factory) server.attach(None) print("RTSP server is running at rtsp://localhost:8554/cli") loop = GLib.MainLoop() loop.run()

Upon rebooting my laptop today it appears to boot normally and then xorg is started. This immediately locks it into a loop where this message is displayed indefinitely. - I would add the log file but stack exchange keeps reporting me as spam :( All the solutions I've come across so far consist of some combination of apt update(sometimes with backports), reinstall nvidia drivers, dist-upgrade to reset version headers, or run configure xorg. Unfortunately these all require a terminal if I understand correctly, and I've no idea how to get one. My grub menu has no recovery option, and I'm using a non-systemd Debian; but from my research, I've tried booting after hitting 'e' in grub, and then with the following parameters appended to the 'linux' line: 1, 3, recovery -- which all do nothing. single -- which gives me this error:

Cannot open access to console, the root account is locked.

See sulogin(8) man page for more details.

Press Enter to continue.

No I haven't messed with fstab, nor any system critical files, as far as I know. If there's an option to fix the xorg error without accessing a text interface, please let me know. Although I would also like to know how I'm even supposed to get a text interface, because that seems like a useful skill. Any help would be deeply appreciated, since I'm at a loss for what to try next. Thank you, Note: The distro I'm using is AntiX23 runit 64bit

I'm installing Debian 10 but I cannot startx nor have a GUI. I think the problem is about some driver. Here are the errors I've got in /var/log/Xorg.0.log : 1. [drm] Failed to open DRM device for pci:0000:01:00.0 - 19 2. open /dev/dri/card0: No such file or directory 3. Unable to find a valid framebuffer device 4. Screen 0 deleted because of no matching config section 5. Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices. If someone can help I will be extremely thankful.

THIS IS NOT A PROBLEM ABOUT XORG I have a singleboard PC with Intel N100 with 2 HDMI ports. When arch boots, the color range changes to limited after i915 takeing over the display from UEFI framebuffer which is always full range. When I changed display settings in Plasma Wayland session. Full color range will apply to not only the GUI session but also Plymouth and tty. I want to change the color range when i915 is loaded or use commands to achieve this at startup. I am working with OLED monitor so grey background caused by limited range is quite a problem for me to test stuffs on tty. fbset -i 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        : i915drmfb
    Address     : (nil)
    Size        : 8294400
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 7680
    Accelerator : No

I have a server in production which was booted with a 1080p widescreen monitor attached and it used that when it automatically selected that resolution for the console on boot. Currently, it is attached with a standard 1280x1024-capable monitor, but it did not change the resolution to match so long lines go off the edges of the screen. How do I have it redetect the monitor or manually switch the resolution without requiring a reboot of this production server? The console is only needed for certain maintenance and other core operations and we have been able to get by without seeing everything we are typing, but I would like to see if I can fix this sooner than the next, scheduled reboot of the server. Most answers seem to discuss using the obsolete fbset command, but their package was dropped from Fedora about 5 years ago and their official website is defunct now. Also, it looks like CONFIG_FB_DEVICE was not defined in the standard Fedora kernel so there's no /dev/fb* interface to even talk to. What is the current method to change the resolution used by the Linux framebuffer console? I did see some mentions of KMS (Kernel Mode Setting), but no way to use that from the command-line. Also, I did confirm that running startx loads the correct resolution while inside X11, but I would prefer not to keep that running for the time being.

I'm using Xorg with the FBDEV driver, configuration:

Section "Device"
    Identifier "Device0"
    Driver "fbdev"
    Option "fbdev" "/dev/fb0"
    Option "ShadowFB" "false"
EndSection

I got a new framebuffer device to my system, it's /dev/fb1. I adjusted the config:

Section "Device"
    Identifier "Device0"
    Driver "fbdev"
    Option "fbdev" "/dev/fb1"
    Option "ShadowFB" "false"
EndSection

But it doesn't work, it still uses /dev/fb0, and doesn't even open /dev/fb1. I'm using Ubuntu-based (jammy-based) OS with xserver-xorg-video-fbdev package installed. Everything works if I do

mount --bind /dev/fb1 /dev/fb0

But it's not an option because I want to have access to both the framebuffers (so I did umount /dev/fb0 to undo it).
Thanks for any help

from my previous question https://unix.stackexchange.com/questions/615080/empty-screen-after-booting-from-live-persistent-usb?noredirect=1#comment1150102_615080 , I am able after boot to access all files and folders, but the X-server is unable to load (so I get only to tty1). From the previous question I was able to get to /var/log/Xorg.0.log and took a photo of it : Now I have to somehow specify "busIDs for all framebuffer devices" (as from the file error). So how can I do that? What config file should I edit? I get the very same error from startx (the fatal error of unable to run framebuffer mode). How to connect to X-server?

This used to be the default some years ago: Linux would boot up on a text console, 80x25 characters. I want to get back to that - this is for a number of servers that boot over the net (with PXE) - some of them have a GPU (NVIDIA) installed and need to use the non-free NVIDIA driver, so nouveau is not and option. The servers have no need for GUI - the GPUs are for computation only - and they will not normally have a monitor attached, but it may occasionally be useful to see the console, say if there is an error at boot. Is it possible to start linux without framebuffer, but keeping the text console? ==== ***EDIT*** ==== Forgot to mention which linux I'm using: Debian 11 ==== ***EDIT 2*** ==== Just to round this off, it would appear that this may be an error in the linux kernel version 5.x. The efifb driver is compiled in, and it just can't handle it, so I have decided to give up for now. So why not try a version 6 kernel? Well, I need to mount a lustre filesystem, and the client doesn't compile (yet) on that version, so I am stuck with this, at least for now.

I am trying to boot a Linux system (Debian 11) with an NVIDIA GPU; I need to avoid loading the nouveau driver, which I can do if I include some options on the linux command line (in grub.cfg):

terminal_input console
terminal_output console
set gfxmode=text
set timeout=5

menuentry 'Debian 11' {
  linux /debian11/boot/vmlinuz-5.10.0-22-amd64 console=tty0 ip=dhcp root=/dev/nfs ro nfsroot=192.168.50.111:/image/debian11,vers=3,nolock panic=60 ipv6.disable=1 rootwait vga=normal nofb nomodeset video=vesafb:off
  initrd /debian11/boot/initrd.img-5.10.0-22-amd64
}

The reason for doing this is that I need to load NVIDIA's proprietary modules, and it works OK, as far as it goes. The unfortunate consequence of this is that I no longer have the VTYs available - not a huge problem, since this is for a server that is mostly accessed via ssh, but sometimes it is necessary to look at the text console, so I'd like to have it back - but without loading the nouveau module. This used to be perfectly easy in the past, but it seems the kernel insists on loading a framebuffer device instead of just printing text. Is there a way to fix this?

I need to work on the framebuffer to record what is being rendered. Now, I figure out how to convert the framebuffer in an image, I'm currently unable to obtain a constant stream of data from the fb to create a video. /dev/fb > fb When I do something like this my redirection just drops me and I honestly don't know how to work in another way with the framebuffer. How I can obtain a stream?

I'm confused about what is what nowadays with Linux and video support for the console interface vs X. Do the /dev/fb* items only relate to the old original framebuffer support? Does DRM create/support /dev/fb* items. How does KMS fit in to all of this? Do you still need at least the generic frame buffer support for VESA or EFI to have console support? TIA!!