Kmscon Project Seeks To Replace Linux Virtual Terminal

← Back to Stories (view on slashdot.org)

Kmscon Project Seeks To Replace Linux Virtual Terminal

Posted by timothy on Tuesday August 21, 2012 @05:37AM from the that's-a-big-itch-you've-got dept.

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."

26 of 182 comments (clear)

Min score:

Reason:

Sort:

is any of this needed? by Anonymous Coward · 2012-08-21 05:42 · Score: 3, Interesting

Hardware accelerated rendering for simple text? Why is any of that needed?
1. Re:is any of this needed? by FranTaylor · 2012-08-21 05:53 · Score: 4, 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"
2. Re:is any of this needed? by JabberWokky · 2012-08-21 05:56 · Score: 4, Informative
  
  Because monitors aren't VGA anymore. We now have small laptops with 2880x1880 screens built in that are plugged into multiple monitors. If you want to drive that at a snappy response, or if you want to select a primary monitor and switch between them, you should take advantage of the hardware.
  Heck, a simple one: I have a laptop with a dead built-in monitor. I use an external monitor, which works fine with X, but the console is on the internal screen.
  
  --
  "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
3. Re:is any of this needed? by broken_chaos · 2012-08-21 05:59 · Score: 4, 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.
4. Re:is any of this needed? by FranTaylor · 2012-08-21 06:09 · Score: 4, Informative
  
  no it is worse
  text mode performance is unimportant to graphics vendors, they do the bare minimum to make it work, they don't lift a finger to make it faster.
  nursing the dynamic data flow to potentially slow I/O devices (like USB displays) is a job for user space. Data is queued to be sent to the device for display but it might be modified while in the queue by graphics events. You don't want to put this stuff in the kernel.
  you are actually making good arguments to remove this functionality from the kernel
  you don't lose the ability to interact with your system or view the boot output, if you have SSH enabled, or if you dump the log messages to the serial port.
  embedded people have been working on screenless systems for years, they are not necessary for interacting with the computer. There are plenty of other ways.
5. Re:is any of this needed? by h4rr4r · 2012-08-21 06:20 · Score: 3, Insightful
  
  That is why real operating systems all have a serial console. Be glad for that.
6. Re:is any of this needed? by gman003 · 2012-08-21 06:23 · 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.
7. Re:is any of this needed? by jellomizer · 2012-08-21 06:26 · Score: 3, 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.
  
  --
  If something is so important that you feel the need to post it on the internet... It probably isn't that important.
8. Re:is any of this needed? by Nimey · 2012-08-21 06:37 · Score: 3, Informative
  
  Hah. Going straight to BIOS was actually faster than using the DOS API. What you'd do for speed was use something like ANSI.SYS (or NNANSI.COM) or just write your own video driver, but that last wasn't exactly being a good neighbor.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
9. Re:is any of this needed? by FranTaylor · 2012-08-21 06:43 · Score: 3, Informative
  
  compatibility issues are you kidding
  your video card boots up in EGA text mode
  every video card has done the same for decades now
10. Re:is any of this needed? by TheCarp · 2012-08-21 07:47 · Score: 4, 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.
  
  --
  "I opened my eyes, and everything went dark again"
11. Re:is any of this needed? by broken_chaos · 2012-08-21 08:41 · Score: 3, Interesting
  
  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.
  
  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 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.
  
  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.
  
  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.
  
  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.
12. Re:is any of this needed? by Miamicanes · 2012-08-21 10:37 · Score: 4, Informative
  
  > and how many real laptops have serial ports these days?
  Don't remind me. Two weeks ago, I spent the better part of a day troubleshooting a nonexistent bug in an embedded hardware project that was caused by a malfunctioning USB virtual fucking serial port on the computer I was using to view the debugging info I was outputting to the MCU's serial port.
  Now I know why so many guys have built their own serial terminals with a 4x20 LCD and a microcontroller. It's the only way left to reliably and infallably render serial input straight to a display without risking stupid errors caused by Windows or its USB subsystem.
  When you're dealing with bare metal embedded hardware, USB anywhere along the signal chain really sucks.
13. Re:is any of this needed? by raster · 2012-08-21 11:57 · Score: 4, 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.
  
  --
  --------------- Codito, ergo sum - "I code, therefore I am" --------------------
Re:Attention Distros by the_B0fh · 2012-08-21 05:47 · Score: 4, 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:Attention Distros by ciggieposeur · 2012-08-21 05:54 · Score: 3, Insightful

Don't you mean 80x25?
80x24 is vt100, xterm, and friends.
80x25 is CGA/EGA/VGA.
Re:What's proper multi-seat support? by Anonymous Coward · 2012-08-21 05:57 · Score: 5, Informative

Dumb question, but what do they mean by proper multi-seat support?
http://www.x.org/wiki/Development/Documentation/Multiseat
> Multiseat is a model of computing that supports multiple local users using their sessions in a totally independent way. This looks quite similar to the old mainframe computer model, but with the "terminals" connected directly to single PC box. There's a lot of people that use and sell multiseat Linux systems due its low cost which qualifies it as a wonderful "techno-social" model of computing.
Re:Attention Distros by Nimey · 2012-08-21 05:59 · Score: 4, 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.

--
Hail Eris, full of mischief...

E pluribus sanguinem
Kernel Mode Setting by andydread · 2012-08-21 06:02 · Score: 3, Insightful

Does this mean that when KMS is broken on "insert graphics card of the month here" I won't be able to get to the console? ooo nooo...
Dear god no by sl4shd0rk · 2012-08-21 06:06 · 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).

--
Join the Slashcott! Feb 10 thru Feb 17!
A Real console by stox · 2012-08-21 06:07 · Score: 3, Insightful

is a Teletype ASR-33 hanging off the serial port.

--
"To those who are overly cautious, everything is impossible. "
Re:What's proper multi-seat support? by FranTaylor · 2012-08-21 06:33 · Score: 4, Informative

In principle, or in fact?
I've had a multi-seat linux system for many years

Fedora 17 documentation:
For the first time Fedora 17 provides completely automatic multi-seat configuration.
To use this feature, simply plug in a USB dock such as the Plugable Docking Station, with a monitor, mouse and keyboard, and a new desktop appears.

I would be delirious with joy.
well I guess I just made your day
RTFM by FranTaylor · 2012-08-21 06:53 · Score: 3, Informative

edit the boot parameters, remove "quiet" and replace with "nosplash debug"
is it really THAT hard???
Re:Userspace? by Lussarn · 2012-08-21 07:27 · Score: 4, Funny

Thats already possible..
cat image.jpg
I don't even see the code. All I see is blonde, brunette, redhead..
Finally! by ilsaloving · 2012-08-21 08:38 · Score: 3, Funny

I can't wait to see vi rendered in 32-bit photorealistic glory!
Re:Attention Distros by snemarch · 2012-08-21 08:55 · Score: 3, Informative

You're right - the default textmode when booting an x86 system "since pretty much forever" is 80x25, BIOS video mode 3.. A lot of distros are evil and change to other textmodes, or framebuffer modes, without asking you, though.

--
Coffee-driven development.