You are not logged in.
Pages: 1
I am using Nvidia drivers, with GRUB installed with efibootmgr. Switching between TTYs is fine when they are text based, but slow (~5 seconds) when a desktop environment (KDE Plasma) is running.
I've tried fixing this for two hours now, and read many wiki/forum pages, but I can't seem to fix this. FWIW when I started the resolution in the startup screen and text TTYs is quite low. Here is what I've tried. I restarted after each attempt, but TTY switching never improved.
1. Changing kernel mode settings via late KMS start. Edited /etc/default/grub, adding nvidia-drm.modeset=1 to GRUB_CMDLINE_LINUX_DEFAULT, then sudo grub-mkconfig -o /boot/grub/grub.cfg.
2. Early KMS start, editing /etc/mkinitcpio.conf, adding nvidia nvidia_modeset nvidia_uvm nvidia_drm to MODULES, then sudo mkinitcpio -P.
3. Set the Nvidia framebuffer resolution in GRUB. sudo hwinfo --framebuffer gave me a long list, but videoinfo on the GRUB command line gave me a poor selection, with the highest resolution being 1280 x 1024. Adding the higher resolution failed.
4. Disabled CSM in BIOS. Now GRUB's videoinfo reported the full 1920 x 1200. Oddly enough sudo hwinfo --framebuffer now gives me no output. I edited /etc/default/grub, adding GRUB_GFXMODE=1920x1200x32,auto, then sudo grub-mkconfig -o /boot/grub/grub.cfg. Now the text TTY resolution was much better, but the TTY switching was unimproved.
5. The kernel mode settings wiki page suggests disabling "vga= options in your bootloader". Technically, above I used the newer GRUB_GFXMODE format, but I wasn't sure if this was also not recommended. I tried disabling this, but the text TTY resolution was once again poor, and TTY switching unaffected.
6. The wiki page also says "Tip: If you encounter problems with the resolution, you can check whether enforcing the mode helps.", but my understanding is that this is to fix poor resolution, which GRUB_GFXMODE already fixed, so I didn't go down this confusing path.
How can I improve the speed of my TTY switching?
EDIT: I'm not using a display manager, but manually startx instead.
Last edited by Salkay (2021-07-04 23:34:07)
Offline
Try
https://wiki.archlinux.org/title/GRUB/T … ramebuffer
Also "vga=31b"
You want to use a text console (really shitty resolution), no frambuffer.
If you use the linux console a lot, you're probably better off w/ the slow speed.
You may also want to check whether suspending the compositor (shift+alt+12 in kde) has impact, because it's likely blocking for vblank signals which won't come after switching the VT.
Online
Thanks @seth. I looked at /etc/default/grub for your first suggestion, but realised that I already had GRUB_TERMINAL_OUTPUT=console uncommented for some reason. In any case, I added vga=31b to GRUB_CMDLINE_LINUX_DEFAULT, and tested again with that line commented and uncommented (running grub-mkconfig -o /boot/grub/grub.cfg and restarting) but it made no difference.
I also wasn't sure if you meant for me to revert my other changes, so I tested two more permutations with both the late KMS start (1. above) and GRUB_GFXMODE (4. above) disabled, with and without GRUB_TERMINAL_OUTPUT=console commented.
Also, I forgot to mention, but I'm not using a display manager, but startx instead. I also tried turning the compositor off in both sessions, but it made no difference.
I don't spend a lot of time in the linux console, so I'd prefer to fix the speed if possible.
Offline
As long as you end w/ a 80x25 console, your settings should™ be ok.
Do you change from one GUI to another or between GUI and text console?
Is either slow?
Is it faster to switch eg. between an openbox and an IceWM session (ie. no GL contexts around at all)?
Online
Do you change from one GUI to another or between GUI and text console?
Is either slow?
Moving from GUI to GUI is slow, as is moving from GUI to/from text console. In all cases, I get a black screen for a few seconds after pressing Ctrl+Alt+#. Moving from text console to text console is super quick.
As long as you end w/ a 80x25 console, your settings should™ be ok.
Oh right! I totally misunderstood. I thought I would want the console to be high res, so that it was easier for the hardware/software to switch from one high-res GUI to another.
Is it faster to switch eg. between an openbox and an IceWM session (ie. no GL contexts around at all)?
Erm, I only have KDE Plasma installed, but I can investigate those if they might be useful for testing.
Offline
Are you switching from one plasma session to another?
Different users or same?
(The implication is to yes, please: try some lightweight session)
Online
I'm switching from one plasma session to another with different users.
Okay, I'll try installing one of those WMs. Thank you again.
Offline
I installed Openbox, but I'm still seeing the same issue. I've also noticed that whenever I startx, there is a black screen for a few seconds before it actually starts. This occurs for both Plasma and Openbox, and is the same black screen I see when switching GUI TTYs.
My configs have a combination of the settings in my first post now, but I tested both with the native high-resolution, and the low resolution (by switching GRUB_GFXMODE). Both failed.
As long as you end w/ a 80x25 console, your settings should™ be ok.
I also noticed that my low resolution console is actually 128x48. I'm not sure if that is important.
Offline
Doesn't sound like a text console…
fbset -i # should™ be an error messageOnline
I get no error and the same output whether I'm in the GUI or the console.
$ fbset -i
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 : 0xc0000000
Size : 3145728
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 0
YPanStep : 0
YWrapStep : 0
LineLength : 4096
Accelerator : NoI tested another two other non-NVIDIA Arch systems, and fbset -i worked without an error message on both in the console.
Offline
That's a framebuffer console and nvidia traditionally doesn't like those.
It's also from your EFI so I'm not sure whether you can really avoid that ![]()
Online
Ah bummer. So basically there's no way around it? I'll just have to deal with the slow switching?
Offline
You could try BIOS settings around the legacy mode - either try booting legacy mode or deactivating the compatibility layer or so.
(Also notice that at this point the framebuffer console being the cause of the slowdown is still speculative)
Online
You could try BIOS settings around the legacy mode - either try booting legacy mode or deactivating the compatibility layer or so.
(Also notice that at this point the framebuffer console being the cause of the slowdown is still speculative)
I think that's what I did in #4 in the original post, disabling CSM? I had another look through the BIOS, but I couldn't see anything else that looked relevant. I tried enabling CSM again just in case, but TTY switching is still slow.
EDIT: on a whim I tried using SDDM instead of startx, but that made no difference either.
Last edited by Salkay (2021-06-05 04:58:42)
Offline
For the record, I also tried booting with the kernels linux-lts54 and linux-lts419, but the problem still persists.
Offline
How can I improve the speed of my TTY switching?
I've yet to encounter a nvidia card that does fast tty switcihng when using nvidia proprietary driver .
Try the nouveau driver or replace the videocard by one not from nvidia .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Yep, me too thinks you should complain with nvidia devs.
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline
Try the nouveau driver
Brilliant! TTY switching is instantaneous now. As an added benefit, I get an excellent resolution in TTYs! Thanks all!
Now to fix the screen tearing… I seem to remember suffering a few other issues the last time I used Nouveau several years ago too.
Last edited by Salkay (2021-07-04 23:35:21)
Offline
I seem to remember suffering a few other issues the last time I used Nouveau
Brace yourself. Latest occasion was https://bbs.archlinux.org/viewtopic.php … 4#p1981094
You'll probably also face decreased overall performance and/or more heat.
Switching VTs is actually fast-ish for me on nvidia, but the GL clients (eg. chromium) hang - and KDE/plasma probably runs at least a dozen, from the desktop all the way up to the compositor…
Online
You'll probably also face decreased overall performance and/or more heat.
Thanks for that info. I might not last too long then.
Switching VTs is actually fast-ish for me on nvidia, but the GL clients (eg. chromium) hang
You've probably tried this, but Chromium worked much better after I disabled hardware acceleration. Not sure if that's an option for you. Slightly different, but without this I would return to graphical corruption, not a hang.
Offline
Chromium worked much better after I disabled hardware acceleration
"Better" in what regard? You won't face the slow gl context recovery issues when waking from S3 or switching the VT but in everyday use, chromium performs much better (lower CPU overhead) w/ HW acceleration enabled.
Online
"Better" in what regard?
Just in terms of the specific graphical corruption that I experienced. White pages, parts of the toolbar missing, etc.
Offline
Pages: 1