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."
Re:Attention Distros (Score:5, Insightful)
OTOH, please make it configurable to have a default of other than 80x24. Back in the days of 9" terminals, 80x24 is great. Today, when I have a 20" monitor attached, capable of displaying 1600x1280, please let me display more lines and columns.
Re:is any of this needed? (Score:5, Insightful)
you're aware that the BIOS and the linux boot screen are currently using HARDWARE ACCELERATED RENDERING for SIMPLE TEXT?
They call it "text mode"
Re:Attention Distros (Score:4, Insightful)
Don't you mean 80x25?
80x24 is vt100, xterm, and friends.
80x25 is CGA/EGA/VGA.
Kernel Mode Setting (Score:4, Insightful)
Dear god no (Score:3, Insightful)
I switched to Ubuntu a number of years ago and could never forgive them for trying to hide all the startup info from the console. It's become even more egregious with grub2 parameters/configuration, kernel video modes, even the old faithful boot command "linux single" no longer works to get to a console screen to fix something.
I don't know how many other distros have adopted this "windows mania" to run everything from gui but for the love of god, leave the console alone. It's the only thing that works anymore when nothing else (emergency sync, boot, etc).
A Real console (Score:4, Insightful)
is a Teletype ASR-33 hanging off the serial port.
Re:is any of this needed? (Score:4, Insightful)
That is why real operating systems all have a serial console. Be glad for that.
Re:is any of this needed? (Score:5, Insightful)
If you read the article (or was it the blog post?), you'll find answers.
First, kmscon has only one dependency - libudev. It can be compiled to use Pango for font rendering, or EGL for hardware-accelerated rendering, but those are optional. X11 is never used.
Second, the rationale for putting this in userspace was mainly for internationalization. In particular, some character tables (for Asian languages, especially) can be rather large. If it was in the kernel, that memory could not be swapped out. In userspace, you can.
Third, this seems aimed at regular console users, not primarily-X-users-that-use-a-terminal. There are plenty of good X11 terminal emulators (and just as many bad ones). This is aimed at people who don't need (or at least, don't want) X, but still want to use all the features of modern hardware. It also claims to interact well with both the kernel VT system, and with X - you can keep an X session on one virtual screen, keep the kernel terminal on another (for those few cases where it is needed, like kernel error messages), and put kmscon on the rest.
I will probably try this out, because I at least used to fit into that group of regular console users. I have on several occasions run out of virtual terminals. I'm not so much of one anymore, but maybe this will get me back into it.
Re:is any of this needed? (Score:5, Insightful)
this has nothing to do with gfx vendors by is piss-poor text mode EMULATION inside the kernel. your "text mode" console is actually graphics mode and emulated to be text by the kernel splatting out pixels that look like text chars - just like x does (and x apps).
it's piss-poor at this because it's poor unoptimized code that does some royally stupid things.
1. "blit" (copy region) to scroll 1 line at a time... and this ends up being almost always done by your cpu.
2. this blit will be done by cpu to/from video memory which often is on a discrete video card across a pcie bus or such
3. writes across this bus are fast, but reads can be in the order of just 10mb/sec. it's piss-poor at reads.
4. the kernel text console doesn't try and play catch-up and scroll multiple lines at a time. it scrolls 1 line at a time thus making the overhead of copying enforced per line scrolled, as opposed to internally skipping a bunch of lines and drawing 2, 5, 20 new lines and copying up only those that are not new.
it's entirely poorly performing because of poor kernel code. how poorly performing? well.
i recently decided to write a terminal emulator (for x). of course i went and used a toolkit i knew to help, and it so happens this toolkit can automatically work in the linux framebuffer just like it does in x11. it can use opengl, but doesn't need it and works fine on a dumb fbcon text console. so i now have the EXACT same terminal in bot x11 and fbcon. hell it even manages to provide me a mouse pointer in fbcon as it detects it's in fb and the toolkit emulates one itself. it looks the same pixel-for-pixel too. so i did some performance comparisons of it in fbcon vs kernel text console. it clocks in at being 55 TIMES faster than the kernel. 55 TIMES. that's how poor the kernel is. going through scads of toolkit layers and abstractions, code to alpha blend the text on top of backgrounds, blend and scale lighting overlays and more... and its still clocking in at 55 TIMES faster. (it happens to run at about the same speed in x11 - on the same machine).
it's not fast because it's amazing code or i'm a genius at all - it's fast because it just is NOT being royally stupid, which is what the kernel text console emulation is.
personally i was quite happy to know my terminal works both in x and in fb.. so if'm i'm ever stuck there.. i can use it and not be 100% grumpy that my text console is piss-slow anymore.