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:is any of this needed? (Score:5, 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.
Re:What's proper multi-seat support? (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:is any of this needed? (Score:5, 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.
Re:What's proper multi-seat support? (Score:5, 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
Re:is any of this needed? (Score:4, 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.
Re:is any of this needed? (Score:4, 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
RTFM (Score:4, Informative)
edit the boot parameters, remove "quiet" and replace with "nosplash debug"
is it really THAT hard???
Re:Attention Distros (Score:4, Informative)
Re:is any of this needed? (Score:5, 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.