Multiple monitors TTY configuration

branthebuilder · 2022-07-25 16:03:23

I have two monitors of different size and resolution. TTYs are mirrored on each display, meaning the same text shows up on both and any interaction is shown on both. During post the smaller, lower resolution monitor appears to be set as the primary with both BIOS and kernel boot messages showing up full screen on both but not at full resolution on the larger monitor. Shortly before the display manager (ly) launches the screen flashes and the larger, higher resolution monitor displays at full resolution but using only the portion of the screen that appears to correspond to the size of the smaller screen. Once ly launches this arrangement continues. Once X11 starts up the displays work independently as expected, but switching to TTYs demonstrates the same weird restriction in size of the display.

Any idea how to have both monitors use the full screen? I don't care as much that they are mirrored, but if there is a way to limit it to a single display that would be even better.

I've tried adding a kernel parameter at boot for fbcon=map:1 with no joy.

seth · 2022-07-25 16:37:15

I've tried adding a kernel parameter at boot for fbcon=map:1 with no joy.

You've been looking at the wrong kernel documentaiton link ;-)
(Unless this is also a multi-GPU setup)

https://raw.githubusercontent.com/torva … modedb.rst

They'll display the same stuff, you can either disable one of them or align the resolutions (what should™ give you fullscreen output, though the handling of resolutions below the physical one is completely up to the monitor - it might run the lower resolution in a letterbox)
If you care more about the console than X11 you might want to look into https://wiki.archlinux.org/title/KMSCON but I'm not sure that you could eg. run one VT per output even this way.

branthebuilder · 2022-07-27 15:22:35

Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=2282bec7-74b0-4f0c-a0d5-d1e67e818c6b rw loglevel=3 video=HDMI2:1920x1080RD video=VGA1:1360x768e

Did not work. I've also tried with a hyphen for HDMI-2 and VGA-1 without success.

#fbset --show

mode "1360x768"
    geometry 1360 768 1920 1080 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

That looks to me like the correct settings but I'm not getting the full 1920x1080 size on the HDMI monitor.

Last edited by branthebuilder (2022-07-27 16:01:29)

seth · 2022-07-27 15:30:42

I've also tried with a hyphen

Again: look at the output of "xrandr -q"

Did not work.

What was the plan of

video=HDMI2:1920x1080RD video=VGA1:1360x768e

cause

seth wrote:

you can either disable one of them or align the resolutions

and that won't do either…

zaxdan69 · 2022-07-27 15:55:27

I also have this issue and already tried the video parameter. The alignment of resolutions means that the lower resolution used for both monitors and for this the sceen of the high resolution monitor doesn't used all. And if disable used then the monitor cannot be enabled afterwards in graphical environment(unless there is a way which I didn't find).
I managed to change the resolution to the high resolution monitor' s via xset. I put the command in .profile to run when I login. Text doesn't fit in lower resolution monitor' s screen though, but I don't care to much about that.

seth · 2022-07-27 16:11:33

"xset" doesn't control the screen resolution in any way shape or form and X11 commands don't belong into ~/.profile and also the OP cares about the console, not X11.
The state of the output during the framebuffer or vga console is irrelevant and xrandr would allow you to enable the output (and actually change the resolution…) in X11, but so would also an xorg.conf.d configlet, https://wiki.archlinux.org/title/Multih … _xorg.conf (there's an "Enable" option, but actually Xorg will automatically enable every output that's attached at startup - whether it's previously active or not)

For anything wayland™ related reg. the output configuration, the actualy compositor (wayland implementation) would be very relevant.
At best you might have meant "fbset", but that has the same impact as the kernel parameters - just later.

The alignment of resolutions means that the lower resolution used for both monitors and for this the sceen of the high resolution monitor doesn't used all

No, it means to use a resolution that's supported by both outputs - in doubt XGA (which will be supported by the VAST majority of outputs, though recently and esp. on eDPs, the VESA resolutions seem to have fallen out of fashion…)

branthebuilder · 2022-07-27 16:11:41

seth wrote:

I've also tried with a hyphen
Again: look at the output of "xrandr -q"

There is no hyphen. I tried that first but the documentation for the video parameter all the examples had hyphenated designations so I tried it just in case X11 was assigning labels differently than the kernel.

What was the plan of
video=HDMI2:1920x1080RD video=VGA1:1360x768e
cause
seth wrote:
you can either disable one of them or align the resolutions
and that won't do either…

From the kernel docs here.

video
This kernel boot options tells the kernel KMS driver on what resolution and/or frequency to use. For this to work, KMS must not be disabled (see above). The format of the option is as follows:
video=conn:res[M][R][-bpp][@refresh][_i][m][eDd]
This option can be specified multiple times, one for each different connection name - so you can have on settings for VGA, one for HDMI, etc.

That led me to believe I could set the resolution for each monitor individually.

seth · 2022-07-27 16:20:17

Yes you can, but afaiu you want is to use the same resolution on both, not FullHD and WXGA - or disable one of them?
Maybe that's a misunderstanding.
Why exactly did you put the "D" there?

branthebuilder · 2022-07-27 16:40:19

If possible I would like each monitor to use its full native resolution, but if that is not possible, I would like the HDMI monitor to utilize the full screen real estate. The current situation is something like this:

┌─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐    ┌─ ─ ─ ── ┐
│               xxxxxxx│    │         │ 
│               xxxxxxx│    │         │ 
│xxxxxxxxxxxxxxxxxxxxxx│    └─ ─ ─ ── ┘
└─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
HDMI                                VGA

The documentation suggested the D option was for enabling digital output, such as for HDMI, but is essentially equivalent to the 'e' option if the monitor does not take digital signal.

Last edited by branthebuilder (2022-07-27 16:41:24)

seth · 2022-07-27 19:33:33

"D" and "e" explicitly enable an output that could not be detected - they should be irrelevant to your situation.
Look up the monitor manuals (or their "xrandr -q" output) for the supported resolutions and chose a common (or at least very similar, eg. 1366x768 should be fine, too) one, so eg. (guesstimating)

video=HDMI2:1360x768 video=VGA1:1360x768

The console will paint the same pixels on either output, so if they have different amounts of pixels, they'll display different stuff.
Also, reiterating, what happens w/ the non-native resolution is up to the monitor. Some will letterbox it, some will stretch it any many actually let you configure that.

branthebuilder · 2022-07-27 20:10:21

I think I understand what you are saying, but I have installed now 4 different distros on this machine over the years, including a previous Arch installation, all with the dual monitor setup with the same monitors, and this is the first time I'm encountering this issue. I'm just trying to figure out what is different. It seems no matter what parameters I pass to the kernel at boot the mode is set to 1360x768. I have tried a host of resolutions without success, with or without the additional flags like R and D.

seth · 2022-07-27 20:24:50

Did you previously maybe run VGA (that's not about the output jack, but a text oriented 80x25 terminal) consoles?

It seems no matter what parameters I pass to the kernel at boot the mode is set to 1360x768.

For the VGA monitor? Can it do higher (assuming that's what you tried) resolutions?

xrandr -q

Also try the LTS kernel, 5.18.13 saw some related patches that seem to have completely broken the nvidia driver itr.

branthebuilder · 2022-07-27 22:38:27

Could this be at all related to the display manager? In the earliest boot sequence messages are printed to both monitors with the HDMI monitor using the whole screen. Then there's a flicker just before the display manager launches and the HDMI monitor switches to higher resolution but limited area. Then the display manager launches. I'm using ly as the DM, which I have not used before.

EDIT: Nope. Same with lxdm.

Last edited by branthebuilder (2022-07-27 22:42:16)

seth · 2022-07-28 06:29:22

n the earliest boot sequence messages are printed to both monitors with the HDMI monitor using the whole screen.

Most likely before KMS kicks in (and you're seeing soem VGA console)

To investigate the non-GUI behavior,
1. remove the "quiet" parameter from the kernel commandline
2. boot the multi-user.target (2nd link below)

the HDMI monitor switches to higher resolution but limited area. Then the display manager launches.

If you actually don't care about the console, but the display server (X11) it's more the X11 configuration and less the display manager that's relevant here and

you wrote:

Once X11 starts up the displays work independently as expected

letterlock · 2022-08-28 19:27:24

So, I'm uncertain if this is exactly the problem that branthebuilder was describing, but if it was, I have it too, and I might have a fresh guess as to what the issue is.

I have two different sized monitors (2560x1440; 1920x1080), and my tty's are also duplicated (not a problem) with the smaller monitor at the correct resolution, and the larger monitor at the same resolution, with letterboxing around the right and bottom of the resolution.

I don't think the issue is with the kernel at all, as whatever kernel parameters I have tried have changed nothing once the system finally reaches the login prompt.

That's why my guess is that this issue is with something that kicks in before X or Wayland, but after the kernel has it's say, so something around systemd taking over from the bootloader? As is probably obvious, I still have much to learn about the linux boot order, so I hope this isn't a totally stupid thought.

It seems like the type of console used also isn't the problem, unless both agetty and kmscon independently have the same issue, which leads me to believe that its an issue with where they're pulling their data from. That made me check fbset, which disappointingly provided the following:

mode "1920x1080"
    geometry 1920 1080 2560 1440 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

But ultimately makes sense, as the tty appears to be technically scaling to the correct resolution, just only populating the monitor to the resolution of it's little brother.

So yeah. I'm stumped. I don't have the right keywords to find this problem anywhere but here.

Fwiw, here's the output of

# systemctl status

  systemd: 251.4-1-arch
   CGroup: /
           ├─init.scope
           │ └─1 /sbin/init splash
           ├─system.slice
           │ ├─NetworkManager.service
           │ │ └─353 /usr/bin/NetworkManager --no-daemon
           │ ├─dbus.service
           │ │ └─351 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │ ├─polkit.service
           │ │ └─469 /usr/lib/polkit-1/polkitd --no-debug
           │ ├─rtkit-daemon.service
           │ │ └─465 /usr/lib/rtkit-daemon
           │ ├─systemd-journald.service
           │ │ └─249 /usr/lib/systemd/systemd-journald
           │ ├─systemd-logind.service
           │ │ └─352 /usr/lib/systemd/systemd-logind
           │ ├─systemd-udevd.service
           │ │ └─udev
           │ │   └─263 /usr/lib/systemd/systemd-udevd
           │ ├─upower.service
           │ │ └─1316 /usr/lib/upowerd
           │ └─wpa_supplicant.service
           │   └─424 /usr/bin/wpa_supplicant -u -s -O /run/wpa_supplicant

with the user.slice omitted as there are no services running there that run before I log in, and none of them change the tty after. If it helps I can post the full output, just figured this was already a bit of a wall of text.

seth · 2022-08-29 06:25:45

That's why my guess is that this issue is with something that kicks in before X or Wayland

Yes, did you see #10?
It seems to be branthebuilder kinda insisted on setting the HDMI output to 1920x1080 what will not work. Both outputs need to run at the smaller resolution.
(Edit: what in your case actually would be 1920x1080, but for him that's the bigger resolution - so don't get confused by that. Also the output names will likely be different)

Last edited by seth (2022-08-29 06:27:31)

letterlock · 2022-08-29 08:54:07

So I should try and look at my monitor's configuration specifically to address the issue?

If my monitor doesn't have the option, is there any way to control how the tty displays the output it sends? I tried disabling the smaller monitor via kernel params, but once it reached the login prompt it just went back to normal. I would also be fine just centering the output in some way, but I suppose if it's the monitor itself that's the issue there may be no way to fix that from the software side of things.

EDIT: I don't seem to be able to change the monitor's aspect ratio or the placement of the screen for some reason. The image ratio option is grayed out.

Last edited by letterlock (2022-08-29 08:57:31)

seth · 2022-08-29 13:37:08

No, you're supposed to tell the kernel to run the output at a different resolution.
Right now it'll run one at FullHD and the other one at WQHD but the framebuffer/console is only FullHD
You want therefore both outputs to operate at FullHD.

letterlock · 2022-08-30 10:14:21

Okay, just to confirm, do I want to add a kernel param to GRUB or does it have to be somewhere else? I'll try it with GRUB now either way, just wanted to make sure I wasn't doing things wrong from the start.

EDIT: So, as before, the kernel params seem to be overwritten after a second on the tty login prompt. Until then it works as expected, but changes back to the problematic setting immediately after.
If it helps, here is my /etc/default/grub:

# GRUB boot loader configuration

GRUB_DEFAULT=0
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=DisplayPort-0:1920x1080x32 video=HDMI-A-0:d"

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Set to 'countdown' or 'hidden' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE=countdown

# Uncomment to use basic console
#GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1920x1080x32

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
#GRUB_COLOR_NORMAL="light-blue/black"
#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
#GRUB_SAVEDEFAULT=true

# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU=y

# Probing for other operating systems is disabled for security reasons. Read
# documentation on GRUB_DISABLE_OS_PROBER, if still want to enable this
# functionality install os-prober and uncomment to detect and include other
# operating systems.
#GRUB_DISABLE_OS_PROBER=false

Last edited by letterlock (2022-08-30 10:20:28)

seth · 2022-08-30 13:49:22

"cat /proc/cmndline" - did you just edit /etc/default/grub or also run grub-mkconfig?
If the parameters are in the cmdline
1. try to remove "splash" (no idea what that's gonna do to your framebuffers)
2. post your system journal

Edit: fyi, there're two GRUB_CMDLINE_LINUX_DEFAULT definitions, idk whether grub-mkconfig parses them bash-style or sticks w/ the first definition.

Last edited by seth (2022-08-30 13:50:43)

letterlock · 2022-08-30 14:16:09

The cat command returns:

BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=6e1a29ea-aac5-481a-86c0-e5491751abab rw quiet splash

So that immediately looks like it's missing the parameters, but I ran grub-mkconfig after every change (specifically "grub-mkconfig -o /boot/grub/grub.cfg").
I also just removed splash, commented out the first GRUB_CMDLINE_LINUX_DEFAULT, ran grub-mkconfig and rebooted, still no dice. Catting the same file produces the same result, weirdly enough also including splash. Are there multiple places I could have kernel params set that are activated at different times? Can kernel params even be changed after boot?

I'm assuming you mean journalctl, right? Here's the output of journalctl -b link.

seth · 2022-08-30 14:23:16

BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=6e1a29ea-aac5-481a-86c0-e5491751abab rw quiet splash

You're booting from the root partition, but

Aug 30 16:00:15 thursday systemd[1]: boot.mount: Directory /boot to mount over is not empty, mounting anyway.
Aug 30 16:00:15 thursday systemd[1]: Mounting /boot...
…
Aug 30 16:00:15 thursday systemd[1]: Mounted /boot.

There's a stale boot partition and that's where you're writing the grub changes.
Updating the kernel will likewise cause you trouble since you'll end up booting an older kernel.
Since a boot partition isn't strictly necessary, you can just umount /boot, grub-mkconfig and should™ get the updated commandline.

letterlock · 2022-08-30 15:37:22

Huh. Seems I beansed that up during the install. Unmounted it and ran grub-mkconfig, cat now reports the correct kernel params, but the problem still persists. Weirdly though, grub seems to be appearing in 2560x1440, while the few seconds of login prompt at the "correct" resolution (before it goes back to 2560x1440) seem to listen to whatever I tell them.

Out of curiosity, I double checked videoinfo in grub's command line, and it appears that 1920x1080 isn't one of the options it recognised. Thinking that might be the issue, I set it to an option that was supported by both what xrandr outputs and what grub tells me, but no dice there either.

Here's an updated journal after unmounting that boot partition and turning off automount for it: link.

branthebuilder · 2022-08-31 16:39:30

seth wrote:

That's why my guess is that this issue is with something that kicks in before X or Wayland
Yes, did you see #10?
It seems to be branthebuilder kinda insisted on setting the HDMI output to 1920x1080 what will not work. Both outputs need to run at the smaller resolution.
(Edit: what in your case actually would be 1920x1080, but for him that's the bigger resolution - so don't get confused by that. Also the output names will likely be different)

This does seem to be the same issue I was having, but I'd like to clarify that I wasn't insisting on the resolution. I did exactly as you suggested and it did not work. I don't care about the resolution exactly. I just want to get rid of the letter boxing effect on the larger monitor.

letterlock · 2023-07-12 13:11:33

Sorry if I'm necroing this thread, but I finally found a workaround. Figured I'd post in case someone else stumbles onto this.
It's a bit long, but since this is the newbie corner I'd rather be too verbose than not enough.

So - as far as I can tell - framebuffer (tty) size is set twice during boot. Once by the bootloader, and once again later, overriding any flags passed from grub. This happens somewhere before the framebuffer (tty) presents a login prompt, but after(?) early userspace (initramfs). It could be possible that its actually set some time during early userspace, towards the end, but it's difficult for me to follow the logs and the visuals to be sure, because a lot of the kernel/firmware/early boot stuff is, to be quite honest, beyond me.

This causes the first issue, which is that if you have a multihead setup with different screen sizes, the framebuffer might default to a screen size that is not your primary monitor, causing letterboxing on the larger one, as well as a smaller text size. This has a direct "fix": one can use fbset at some point before the login prompt is shown to manually set the framebuffer to a desirable setting. Since I'm currently experimenting with Void Linux, I just put the following in /etc/rc.local:

fbset -xres 2560 -yres 1440

I don't rc.local is executed under systemd however, so it would have to go somewhere else in Arch.
The font size might remain too small, but the letterboxing is now fixed, and the font can be easily fixed with something like this. NOTE: At least on Void, I had to actually set the font after fbset, because for some reason setting the font the way the documentation suggested broke the fbset.

This leads me to the second issue, which I couldn't find a full workaround for. There doesn't seem to be a way to control which monitors the framebuffer outputs to. I did find some very old blog/forum posts about setting up multihead with one monitor running X and the other running the fb console, or having one tty per monitor. However, they didn't seem to address controlling the resolution of the monitors independently (aside from obviously using xrandr or w/e to adjust the monitor running X). Not only that, they required patching the kernel and other such wizardry that I am woefully unequipped for, and I feared would be outdated or deprecated regardless. I also don't really even need the second screen until I'm in a graphical session, so I started to just search for a way to disable the monitor.
The best solution I was able to discover was ddcutil. It requires some setup (it needs a special kernel module to be enabled), and apparently there's a very slight possibility of bricking the monitor in question, so proceed with some caution. Once it's set up, I used (execute these commands:

ddcutil detect

To figure out the number ddcutil assigned to the monitor in question.
Then, with the monitor powered on I ran:

ddcutil getvcp scan --display [DISPLAY NUMBER]

Which will return a bunch of lines (and will take a second, according to the docs, communication with the monitor can be kinda slow), and eventually something like this:

VCP code 0xd6 (Power mode): DPM: On,  DPMS: Off (sl=0x01)

What we're interested in is the two codes after the '0x', so 'D6', which is the code of the monitor's power setting, and '01', which is what 'D6' is currently set to.
Now that we have these two codes, we run the above command again, but this time once the monitor is in standby mode. I forced this by turning off the automatic input select and changing the input to something with nothing plugged in. Note that standby is not quite the same as off. In my research, some people said that if you were to tell it to turn off instead of standby, you might end up not being able to turn it back on without using the physical buttons, which would not be useful for us. My monitor was able to receive commands from fully off, so give it a try even if your monitor doesn't have a standby mode.
Once that command was run, I got back 02 as the code for the setting. So now we can finally use:

ddcutil setvcp [XX] [YY] --display [DISPLAY NUMBER]

Where [XX] is the setting's code, and [YY] is the code of the state we want. For me this was:

ddcutil setvcp D6 01 --display 1

To turn the monitor on and:

ddcutil setvcp D6 02 --display 1

At this point I added the standby command to my rc.local just like the fbset command above, and I'm finally met with no letterboxing on the primary monitor and no 'overscanning' on the secondary monitor at login. Then I added the on command to my autostart script so the monitor turns back on when I log in. Finally, I made a little 'script' that runs when I press the keybind or use the menu option to log out:

#!/bin/bash

ddcutil setvcp D6 02 --display 1
labwc -e

To turn the monitor to standby again.
Unfortunately, this doesn't cover the case of dropping to console while a graphical session is active (like with CTRL+ALT+F-keys)... If anyone who reads this has any ideas for that I'm all ears. I suppose it would have to be some kind of script run as a daemon that reacts to keyboard input or something? That's a problem for another day.

Hope this helps someone!

Last edited by letterlock (2023-07-12 13:11:56)

Arch Linux

#1 2022-07-25 16:03:23

Multiple monitors TTY configuration

#2 2022-07-25 16:37:15

Re: Multiple monitors TTY configuration

#3 2022-07-27 15:22:35

Re: Multiple monitors TTY configuration

#4 2022-07-27 15:30:42

Re: Multiple monitors TTY configuration

#5 2022-07-27 15:55:27

Re: Multiple monitors TTY configuration

#6 2022-07-27 16:11:33

Re: Multiple monitors TTY configuration

#7 2022-07-27 16:11:41

Re: Multiple monitors TTY configuration

#8 2022-07-27 16:20:17

Re: Multiple monitors TTY configuration

#9 2022-07-27 16:40:19

Re: Multiple monitors TTY configuration

#10 2022-07-27 19:33:33

Re: Multiple monitors TTY configuration

#11 2022-07-27 20:10:21

Re: Multiple monitors TTY configuration

#12 2022-07-27 20:24:50

Re: Multiple monitors TTY configuration

#13 2022-07-27 22:38:27

Re: Multiple monitors TTY configuration

#14 2022-07-28 06:29:22

Re: Multiple monitors TTY configuration

#15 2022-08-28 19:27:24

Re: Multiple monitors TTY configuration

#16 2022-08-29 06:25:45

Re: Multiple monitors TTY configuration

#17 2022-08-29 08:54:07

Re: Multiple monitors TTY configuration

#18 2022-08-29 13:37:08

Re: Multiple monitors TTY configuration

#19 2022-08-30 10:14:21

Re: Multiple monitors TTY configuration

#20 2022-08-30 13:49:22

Re: Multiple monitors TTY configuration

#21 2022-08-30 14:16:09

Re: Multiple monitors TTY configuration

#22 2022-08-30 14:23:16

Re: Multiple monitors TTY configuration

#23 2022-08-30 15:37:22

Re: Multiple monitors TTY configuration

#24 2022-08-31 16:39:30

Re: Multiple monitors TTY configuration

#25 2023-07-12 13:11:33

Re: Multiple monitors TTY configuration

Board footer