Kmscon Project Seeks To Replace Linux Virtual Terminal 182
An anonymous reader writes "Phoronix reports on the progress of kmscon, David Herrmann's virtual console project that aims to supersede the Linux kernel's virtual terminal. kmscon takes advantage of modern Linux features such as kernel mode setting, direct rendering, and udev to provide hardware-accelerated rendering, full internationalization, monitor hot-plugging, and proper multi-seat support. A recent blog post by Herrmann addresses some of his frequently heard questions and criticisms about the kmscon project."
is any of this needed? (Score:3, Interesting)
Hardware accelerated rendering for simple text? Why is any of that needed?
Attention Distros (Score:2, Interesting)
Please don't take this as an excuse to default the console to anything other than 80x24. Not only is it annoying, but when arch went to this default, I struggled for days trying to figure out how to undo it. I finally did, but a month later it somehow reverted.
Please don't do that. Thanks.
Re:Attention Distros (Score:5, Interesting)
Have you ever used 80x24 on a 22" monitor with 1680x1050 native res? The letters are so huge as to be unreadable. Ubuntu et al handle it correctly by letting the X driver do KMS to the native res, which carries over to the console.
I'd be happy with defaulting to whatever the video hardware can handle and then having an easy way to configure it for other resolutions.
Re:is any of this needed? (Score:5, Interesting)
Framebuffer consoles are (or were), in some cases, surprisingly slow. Huge amounts of output at least used to overwhelm them, only catching up if you swapped back and forth between VTs -- this didn't happen in non-framebuffer consoles or in terminal emulators in X.
I think it has improved significantly over the past few years, but that's probably partly from already working some hardware-accelerated rendering into some of the framebuffer console drivers. Though I'm not sure why they're not just working on improving the framebuffer drivers further -- the project seems to aim to put every damn piece into userspace, which seems like a terrible idea for something so essential as the basic console. If you break one of the things it depends on (such as xkb -- yes, really, a piece of X11 for a console system), then you lose any ability to interact with your system, or even view the boot output.
I'm really not sure who it's aimed at. If you break your install and you don't have an old kernel-based VT fallback, you're screwed. If you don't break it and it works fine, what benefit is it? You'll more than likely just be starting up X11 momentarily anyway.
Re:is any of this needed? (Score:4, Interesting)
I remember a while back, (Like a decade or so) I did some simple benchmark tests.
In essence display all the numbers from 1 to 1,000,000
And depending on the video Card, this program would run faster in X-Windows or just in Text Mode.
Most new video cards have the performance in the GUI stuff, and not much work in making text mode faster. So I would expect with hardeare acceleration rendering for simple text you may be able to see a major speed improvement noticeable in application that blurt out data to the screen (Such application that blurt are normally meant to be piped to an other app for better detail, But sometime we just let it run... That I/O is slowing down the application running speed.
That said what I would really like to see out of a Frame Buffer Text Mode is better support for other terminal types. No longer restricted to the BIOS text rules. We can emulate other formats such as the higher number VT that allows for different font sizes on the same screen (well wide, narrow, and normal). Form based Terminal Emulation such at 3270.
I am not dissing the command line, I really like it, but PC Text mode is an ancient fossil now that need to be gone.
Re:is any of this needed? (Score:5, Interesting)
Totally unrelated... except to show how relative a term "slow" can be.
This reminds me of reading the docs for a Perl DNS module once when I was writting an internal app that needed to do a lot of DNS lookups. The docs said it was "pure perl" and "slow". So, if the docs said it was slow....I figured I would use the system resolver instead.
I wrote my app, came to test it.... and DOSd my own system as my program began trying to slam the system resolver with 6 parallel workers (batch resolving IPs based on logs)...each of which had to open several files (nsswitch.conf, hosts, hosts.allow, resolv.conf.....and I think a few others if memory servers) for EACH LOOKUP.... my poor system was no match for it (this was back in the single core days)
I switched to the "slow" dns module, and maybe it was slow by some standards, but compared to the system resolver...it was lightweight and fast.
"Slow" is always a relative term.
Re:is any of this needed? (Score:4, Interesting)
Looking into the source briefly suggests it actually doesn't have a hard dependency on udev, but has optional dependencies on: systemd, udev, dbus, libdrm, gbm, egl (mesa), glesv2 (mesa), xkbcommon (a part of X11), freetype2, and pango. This means if you don't intentionally build it with the minimal of requirements (presumably making it no richer in features than the default VT system), it would be linked against all those and break if any of them broke during an upgrade or for any other reason.
This seems like a niche-of-a-niche market, so to speak. I greatly prefer terminal applications, but I always run them under X (using a minimal window manager, etc.) so that I have access to more complex things like PDF viewing or web browsing (beyond links) when needed.
Ah, I guess the Slashdot, Phoronix, and author's blog posts are a bit sensationalist, then -- all three of them make repeated references to completely replacing the standard kernel VT system, including the author recommending disabling CONFIG_VT entirely.