Forgot your password?
typodupeerror
Software Upgrades Linux

Kmscon Project Seeks To Replace Linux Virtual Terminal 182

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Kmscon Project Seeks To Replace Linux Virtual Terminal

Comments Filter:
  • by Anonymous Coward on Tuesday August 21, 2012 @01:42PM (#41070415)

    Hardware accelerated rendering for simple text? Why is any of that needed?

    • by FranTaylor (164577) on Tuesday August 21, 2012 @01:53PM (#41070655)

      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"

      • by snemarch (1086057)

        ...at very limited resolutions (yes, there's the extended VGA text modes, but those are still limited and look horrible), with limited character sets, and either display cloned across all connected monitors, or limited to a single monitor output.

        80x50 textmode is perfectly fine for me, but other people might have different needs... and the unaccelerated framebuffer modes are definitely horribly slow.

        • by epyT-R (613989)

          still, the extended text modes are far faster than the framebuffer. I wish more modern cards still supported them.

    • by JabberWokky (19442) <slashdot.com@timewarp.org> on Tuesday August 21, 2012 @01:56PM (#41070701) Homepage Journal

      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.

      • by h4rr4r (612664) on Tuesday August 21, 2012 @02:20PM (#41071093)

        That is why real operating systems all have a serial console. Be glad for that.

        • by snemarch (1086057)
          Ah yes, a serial console is superior to supporting an external monitor. Definietely a lot faster and easier to hook up as well ;)
    • by broken_chaos (1188549) on Tuesday August 21, 2012 @01:59PM (#41070761)

      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.

      • by FranTaylor (164577) on Tuesday August 21, 2012 @02:09PM (#41070903)

        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.

        • by oursland (1898514)

          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.

          You're absolutely right. We often rely upon serial ports to debug. Last thing I want is my local PC console to be limited to 9600 baud! How do you plan on debugging a bootloader problem or initialization problem with SSH?

        • by raster (13531) on Tuesday August 21, 2012 @07:57PM (#41075751) Homepage

          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.

          • by epyT-R (613989)

            Real text mode is quite fast because all the kernel has to do is push bytes at an IO port and the video card takes care of the rest. The framebuffer is slow because there is no way to accelerate blitting without interfering with the X11 driver. There are drivers in the kernel that offer partial acceleration, but because of this limitation they aren't used much. It might be possible to alleviate some of this with sse-enhanced routines, but in the end, spamming the console in framebuffer mode would still se

        • by epyT-R (613989)

          With a framebuffer console, you lose the preboot output from the kernel, IE anything that's printed to the default mode before the switch. This is especially problematic with systems using uvesafb (like x86_64 where 16 bit instructions are not allowed), where the vga bios code is run inside a userspace 8086 emu (v86d). Sometimes you need the boot output to see what's going on and it's impossible to get at it later because the system didn't even get to userspace yet. Serial ports are a passe thing on moder

      • by gman003 (1693318) on Tuesday August 21, 2012 @02:23PM (#41071157)

        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.

        • by broken_chaos (1188549) on Tuesday August 21, 2012 @04:41PM (#41073355)

          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.

        • All it does is duplicate features of X. If someone wants these features, why not just use X? The fact is there is no or insignificant savings in memory by basically duplicating what X does, this kmscon is not going to save you much memory over using X, considering that you can use X and a lightweight window manager while using a very small amount of ram and that X itself does not take up much ram.

    • by jellomizer (103300) on Tuesday August 21, 2012 @02:26PM (#41071197)

      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.

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

        So, basically you want GUI features without having a GUI system. Graphical changes: Wide, Narrow, Normal. My video game has a terminal emulator that's fully hardware accelerated -- It can even use 3D "glyphs". What we really need is just OpenGL without X11. Gimme that at boot: standardised API to low level GPU stuff. That's all we really need. Canonical is going in that direction... Textmode is essentially a fallback mode for when shit hits the fan. If you're using a server, connect via SSH or seri

    • by epyT-R (613989)

      If the console renders in character text mode, no it's not required because in text mode, the graphics card handles the rendering. All the kernel has to do is stream single bytes to an IO port. This has been true since the days of the original CGA on x86. If it's rendered in bitmap/framebuffer mode using the cpu, it can get really slow, especially with high resolutions, to the point where it adds 10%+ to the build times of large software or any task that streams large amounts of text. I've always tried t

    • As I understand it, most mainstream Linux distros (Ubuntu, Debian, and CentOS among them) have rendered "text mode" as bitmaps for years, probably a decade or more. I think the motive was partly to get proper support for UTF8, and partly so Linux could gracefully deal with use cases where a user runs one app that requres something like ISO-8859-1, then runs another app that uses Russian Cyrillic (ISO-8859-2?), and both are within scrollback distance and have output that could conceivably be visible to the u

  • Attention Distros (Score:2, Interesting)

    by Anonymous Coward

    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.

    • by the_B0fh (208483) on Tuesday August 21, 2012 @01:47PM (#41070525) Homepage

      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.

      • by epyT-R (613989)

        in character mode, the kernel command line 'vga' can alter the mode. to get a list of available modes use vga=?
        0 is 80x25
        1 is 80x50 which is what I use..
        the rest of the list will depend on what modes your card supports. I've been doing this since the 1990s, so it's been around a long time.

        Alternatively, you can use setfont alt-8x8 (or some other 8x8 font) to get a similar effect. This also works in framebuffer consoles.

    • by ciggieposeur (715798) on Tuesday August 21, 2012 @01:54PM (#41070665)

      Don't you mean 80x25?

      80x24 is vt100, xterm, and friends.

      80x25 is CGA/EGA/VGA.

    • Re:Attention Distros (Score:5, Interesting)

      by Nimey (114278) on Tuesday August 21, 2012 @01:59PM (#41070759) Homepage Journal

      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.

    • Also, please don't take away the consoles as they work now without making sure there's a compatible screen reader available that will read the console boot messages in real time. There are a number of blind sys admins who would be out of a job if they could not hear boot messages during boot. A user space console could be a good thing, but if it harms this small tech community, overall it would be a very bad thing.

  • by andydread (758754) on Tuesday August 21, 2012 @02:02PM (#41070801)
    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...
    • by diegocg (1680514)

      Sadly, yes.

      • by whoever57 (658626)
        And if I have KMS disabled because the in-kernel drivers don't support my graphics chipset? I guess that means no console at all? If so, then a giant FAIL for this project.
        • by gman003 (1693318)

          Then just don't use it. Nobody is trying to make this replace the Linux kernel console, much in the same way nobody is trying to make Emacs replace ed.

    • You make a good point, users absolutely should be able to use the consoles as they are now, without all of this KMS, DRI junk that is dependant on specific video card. As has been said, one of the great uses of the consoles has been able to get a command prompt without a video card driver loaded and if the video card drivers are not working properly. The console is meant to provide a text based interface, and all you need for that is to call some VGA BIOS calls, no need for all of these complex video driver

  • Dear god no (Score:3, Insightful)

    by sl4shd0rk (755837) on Tuesday August 21, 2012 @02:06PM (#41070859)

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

    • by h4rr4r (612664)

      Is a serial console not an option for you?

      • by gstoddart (321705)

        Why would I need one? The virtual console and safe mode have always given me this ability.

        Having a serial terminal laying around to work on your Linux box in case something goes wrong seems like a giant leap backwards ... unless you have some fetish for old TTY devices. :-P

        Sometimes, you need the lowest possible denominator in order to be able to do these things.

        • by h4rr4r (612664)

          In 2012, heck in 1999, you use a null modem cable and a laptop instead of a dedicated serial console.

          Since I would assume any geek has at least another computer and can easily get a null modem cable and a usb to serial adaptor this really is pretty simple.

          That approach is great when for one reason or another you cannot get any display out of a machine.

        • not when your x server stops processing keyboard events
          you're not flipping to the virtual console or doing anything else

          got news for you: remote debugging is alive and well. read the gdb manual, its use over a serial port is fully supported and documented.

      • by Yetihehe (971185)

        I don't even have serial ports in my laptop :(

        • by h4rr4r (612664)

          Not even the Universal Serial Bus type?

          I thought those were pretty Universal.

          • by skids (119237)

            USB serial dongles make horrible debug ports when trying to debug, for example, udev problems, or capture early messages from the kernel (the USB system takes a very long time to come up, and though you can cache debug message these days, there's no guarantee the kernel will make it all the way to the point of spitting them out before it abends.) The whole reason serial debug ports are effective is because you turn them on at kernel boot and they just sit there running at the kernel level. If you have to

            • by h4rr4r (612664)

              I thought you meant using the laptop as the debug device, not as the failing machine.

              For use as a serial console they work fine.

      • Considering that I haven't seen new hardware in the home or "prosumer" level (and only "occasionally" at the server level) with a serial port for years, I think that's a pretty poor assumption for them to make.

        • "only occasionally"

          how about Supermicro's entire product line? All of their servers still have serial ports.

          • by h4rr4r (612664)

            PCI/PCIe cards that add serial ports are not hard to find either.

          • I'll have to look. I have some Supermicros waiting for provisioning at work, but I don't remember seeing serial ports. Admittedly, I wasn't looking for them, either.

            Still, that's only one brand.

        • by tlhIngan (30335)

          Considering that I haven't seen new hardware in the home or "prosumer" level (and only "occasionally" at the server level) with a serial port for years, I think that's a pretty poor assumption for them to make.

          Most have serial ports if they have a real docking station (read: not USB). I've got a new-ish Dell i7 laptop with a serial port in the dock that works great.

          Of course, there are other debug methods available - serial being the old standby, but I would be surprised if GDB didn't support firewire debug

          • For that matter, I can't remember the last time I've seen a docking station, either, and desktops don't tend to have docking stations.

            Hell, even if they did, where the hell are you going to get a serial terminal these days? That's the problem. I don't know where GDB comes into play on a machine that's failing to even boot...

      • Are you kidding me? Are you saying that someone has to use a serial terminal to do something that they have been able to do on Linux for decades, that is get a simple virtual terminal?

    • by bigtrike (904535)

      init=/bin/bash still works with grub2 in Debian.

    • by euxneks (516538)

      They are trying to make Ubunutu more user friendly, showing console information on bootup is "scary" for a non technical user.

      Whether they succeed in making it user friendly is another discussion entirely. However, you can disable the non-console bootup by removing "silent" from the grup parameters (as far as I remember, anyway, they may have changed it again)

      sidenote: seriously slashdot? I have to format my comments in some pidgin html?

    • RTFM (Score:4, Informative)

      by FranTaylor (164577) on Tuesday August 21, 2012 @02:53PM (#41071663)

      edit the boot parameters, remove "quiet" and replace with "nosplash debug"

      is it really THAT hard???

      • by Carewolf (581105)

        is it really THAT hard???

        Try to do that when grub has been configured by default to start up in the same stupid framebuffer mode. Blind hacking in grub is really really tricky.

    • Why are you even complaining about that? This project is not to remove the console, it is to make a new console.

      By the way, "linux single" still works on grub by default, Ubuntu must have added some weard config to it, just reconfigure the beast, and it will be back. The kernel video modes are there for a reason, the console gets much better in high definition. If you like big letters, just setup a big font. And the startup screen, it is just matter of removing one package, but I don't remember its name. Ye

      • by jedidiah (1196)

        A new console? Why bother?

        Apparently it's working to well (like ALSA, init, GNOME, and X).

        The road to hell is paved with good intentions and quite often the relevant parties are completely blind. Hire some guys to write video drivers or improve one of the NLE's.

        Leave the boring stuff alone.

  • A Real console (Score:4, Insightful)

    by stox (131684) on Tuesday August 21, 2012 @02:07PM (#41070875) Homepage

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

    • by gman003 (1693318)

      serial port.

      A what now? "Serial port"? Is that anything like USB?

      (I kid, I kid - I still have a null modem cable in my big bag o' cables)

    • If you were really snazzy you had a DECwriter II (LA-36)... zzzt! zzdedezzzt! zzzzzt! (....[pause].....hummmmmm as the head vibrates in the 'view' position)...
  • The reason I use virtual terminals is because they are NOT user space. Otherwise xterm and similar programs work well enough. But if this would add a graphical layer that can mix cleanly with the text mode, then it might be interesting (e.g. "cat image.jpg" and get a picture).

  • Finally! (Score:4, Funny)

    by ilsaloving (1534307) on Tuesday August 21, 2012 @04:38PM (#41073269)

    I can't wait to see vi rendered in 32-bit photorealistic glory!

Help stamp out Mickey-Mouse computer interfaces -- Menus are for Restaurants!

Working...