Kmscon Project Seeks To Replace Linux Virtual Terminal

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

Comments

is any of this needed?

[Anonymous Coward]

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

Re:is any of this needed?

[FranTaylor]

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:is any of this needed?

[JabberWokky]

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:is any of this needed?

[broken_chaos]

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?

[FranTaylor]

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:is any of this needed?

[h4rr4r]

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

Re:is any of this needed?

[mynis01]

I have to agree. This seems kinda pointless, just connect to your TTYs with tmux or screen, problem solved. Why are we worried about improving something that is deliberately a fall back to a simpler system?

Re:is any of this needed?

[gman003]

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?

[jellomizer]

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?

[Nimey]

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?

[FranTaylor]

compatibility issues are you kidding

your video card boots up in EGA text mode

every video card has done the same for decades now

Re:is any of this needed?

[snemarch]

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

Re:is any of this needed?

[TheCarp]

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?

[VortexCortex]

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 serial on another machine. If you're using it as a desktop machine, then use a damn desktop rendering system. If that's too heavyweight, the answer isn't to make a special purpose low level textmode rendering system, the answer is to make the rendering pipeline lightweight.

I can give you a multi font hardware accelerated terminal emulator with full Unicode support, but what I need is a way to throw textures and polygons on the screen -- NOT YET ANOTHER TEXT API.

Re:is any of this needed?

[fisted]

and how many real laptops have serial ports these days? USB doesn't count since compared to RS232 it's complex and a pain in the ass to use.

Re:is any of this needed?

[snemarch]

"wasn't exactly being a good neighbor"? That's the way you did stuff under DOS, and it was just fine in those days. It was a single-tasking environment, and writing directly to the 0xB800 segment when you needed fast textmode operations was just fine. ANSI.SYS was slow as hell compared to handling ANSI escape sequences yourself - even if you resorted to BIOS character output routines and not doing direct 0xB800 access... But since redirecting ANSI escape codes to files often didn't make sense, it made more sense doing direct access. Not everybody had the luxury of affording one of those insanely fast 80386 processors ;)

Re:is any of this needed?

[Barefoot Monkey]

Triggering a separate interrupt for individual characters was the slow way of rendering text. There's the overhead of the IRQ jump itself, handling cursor movement, window wrapping, scrolling - all that is OK if done once for a batch of characters but too much work when repeated for each character. Most programs used DOS or BIOS calls to print out strings of text at a time. Those occasional programs that had need to twiddle random characters on the screen would edit segment $B800 directly. Whether using BIOS, DOS or the text buffer, you're still using text mode. And believe me - it was much faster just setting the byte for a character and letting the hardware figure it out than plotting the pixels for the text in software. That's what text mode was - hardware-accelerated graphics that increased speed and reduced memory usage at the expense of limiting you to a set of pre-defined characters always arranged in a grid. There weren't compatibility issues because the protocol (the location and format of the text buffer in segment $B800) was kept sufficiently consistent from CGA to EGA to VGA.

Re:is any of this needed?

[snemarch]

Ah yes, a serial console is superior to supporting an external monitor. Definietely a lot faster and easier to hook up as well ;)

Re:is any of this needed?

[fisted]

>> [...] in X-Windows[...]
your point is void

Re:is any of this needed?

[broken_chaos]

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.

Re:is any of this needed?

[Nimey]

It was, but if you had a TSR, device driver, or possibly a memory manager that expected things to be a certain way then you could cause trouble by not going through the proper channels.

IIRC one of the reasons why WordPerfect was so popular was its speed, and it got this way by getting keyboard input straight from the 8042 keyboard controller. If you had too many programs in memory (EMM386, maybe one or two other types) that also read keyboard input directly and then passed it through, you'd get random characters in your WP document. Other word processors that went through DOS or BIOS didn't have that problem, but weren't as fast.

Re:is any of this needed?

[snemarch]

I never had a problem with direct 8042 access, as long as the IRQ1 handler was properly written - this includes running a TSR that had direct keyboard handling (to detect it's hotkey) as well as direct textmode access through segment 0xB800. I don't think EMM386 (the EMS memory manager) had anything to do with keyboard access (though it did use the 8042 to reprogram Gate A20 in order to access >1meg memory addresses), you might be thinking of DesqView? (DOS multitasking environment - I only used it very briefly, but didn't have trouble with direct keyboard access or text mode memory access there, either).

The worst that could happen from accessing 0xB800 directly was not being able to redirect text output to files, possibly garbled text because other programs were also writing to text memory, or nothing happening because the system was running in a mode where 0xB800 wasn't used (like, graphics modes, or monochrome 0xB000 output, or a virtualized environment where you didn't have access to physical address 0xB8000) - but it certainly couldn't mess up stuff, as long as you weren't adding other things to the mix, like changing video modes or setting a different cursor position.

Re:is any of this needed?

[shutdown -p now]

For text mode, I don't see how you'd possibly be interfering with any TSR, device driver or memory manager if you directly addressed the video memory in text mode. It's always there, it's in a fixed place where nothing else can be, and every other piece of code in the system knows about it. What can go wrong?

Re:is any of this needed?

[Eravnrekaree]

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.

Re:is any of this needed?

[epyT-R]

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 to stick with 80x50 character mode for this reason, and if I"m forced to use framebuffer, start the task and then switch to an idle vterm. Also, these text and VESA modes look terrible on LCD panels because they aren't native to the display.

Re:is any of this needed?

[Miamicanes]

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 user within a single window at the same time.

Side note: the reason I found this out is because I was wondering how Linux magically managed to render bitmap penguins onto a textmode display. I originally thought that somebody figured out how to bitbang a VGA card into changing modes mid-scanline a-la-c64/AppleII/Atari/Amiga through pure software-timed brute force. Apparently, though, even if you ignore the BIOS and try writing directly to the hardware registers for a specific known VGA chip, there's some hardwired implementation-level reason why it wouldn't work (at least, not on any video card from the past century). Anyway, that's the story of how I found out that most/all modern Linux distros actually fake character mode with a frame buffer.

Re:is any of this needed?

[Miamicanes]

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

Re:is any of this needed?

[oursland]

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?

Re:is any of this needed?

[raster]

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.

Re:is any of this needed?

[raster]

x doesnt introduce firewall issues. there is no requirement you have it listen on a tcp port externally - its an option turned off on many linxu distros these days (its a cmdline option for x).

x also is not that large. i've included it PLUS base x libs PLUS kernel, libc and everything else needed inside a 4mb filesystem image for my ipaq many years back. i'ts only bloated if you choose to make it so.

Re:is any of this needed?

[epyT-R]

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

Re:is any of this needed?

[theArtificial]

I see you haven't managed to lock X before.

Re:is any of this needed?

[epyT-R]

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 modern hardware...at least the kind that have their own hardware interrupts and can be slaved to character IO by the bios. Serial is fine for embedded systems, but debugging issues with desktop machines is far easier with textmode 80x25/50 et al.

All framebuffer modes on typical x86 machines are rendered completely in software. The framebuffer driver just enumerates the VESA modes the VGA bios exposes. There are a few drivers that offer partial acceleration for some chipsets, but these are not compatible with the X11 drivers, making them largely useless. VESA offers some buffer manipulation, but no acceleration for drawing characters. This is workable on today's 2-3ghz cpus, but only for low resolutions. Since VESA doesn't enumerate 16:10/9 ratio modes, most LCD panels are not running natively, making the result blurry and ugly as hell too. Moving this stuff to userspace will slow it down further, for no gain, and make this issue worse.

Re:is any of this needed?

[epyT-R]

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 seriously impact performance of the rest of the machine, say during a software build or 'tail -f' on a fast moving log.

Re:is any of this needed?

[epyT-R]

using X11 with kms requires X11 drivers that support it. If you use the nvidia binary drivers, you can't use kms.

Re:is any of this needed?

[theArtificial]

I was hinting at the usefulness of SSH in situations like that.

Re:is any of this needed?

[Compaqt]

When I hit CtrlAltF1, both laptop and external monitors go to the terminal (Ubuntu on a late model Lenovo with Intel graphics.) What are you using?

Re:is any of this needed?

[Zontar The Mindless]

and how many real laptops have serial ports these days?

Mine does, and it's less than 4 months old. (It also has USB and HDMI.)

Re:is any of this needed?

[Zontar The Mindless]

I was hinting at the usefulness of SSH in situations like that.

That was what I assumed.

(I wish the AC Good luck with that attitude of his when his keyboard locks up, heh.)

Re:is any of this needed?

[Anonymous Coward]

text mode is very fast, faster than any other possible implementation, because it only has to push characters, rather than pixels to the graphics memory.

But you are wrong, text mode works by writing to VGA memory at 0xB800 (physical address), it doesn't involve IO ports at all, the IO ports are only used to set vga mode and the cursor position. You can of course make it faster by not updating the cursor position when there is still data to be written to the display. You can also make it faster, at the expense of asynchronous updates by setting the MTRR to make that region write-back instead of writethrough cached.

There is a caveat that although this method of drawing to the display is impossibly fast on real hardware, on virtual hardware it can be quite slow, as every write to the VGA memory causes a pagefault to trap and emulate. This can be optimised so that the VGA memory is shadowed in the virtual machine and updated asynchronously by a timer interrupt, or ideally by the VGA Vertical retrace interrupt of the host.

Re:is any of this needed?

[galanom]

The fastest way to print text in DOS is to write directly to the VGA video memory at B800:0000

Re:is any of this needed?

[konoame]

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.

I have many files written in East-Asian character sets. I can't access them using regular terminal while not in X. This internationalization support would be very helpful for many users, and it would be awesome if the developers can make something like iBus/SCIM on it.

Re:is any of this needed?

[Zontar The Mindless]

Some of us actually have processes running on our computers that take quite a while to finish, and we tend to balance "don't feel like re-running a good chunk of the day's work" vs "don't feel like setting down the Cheetos to reach for something else" a bit more strongly in favour of the former than you do, I guess.

But suit yourself, friend.

Re:is any of this needed?

[Zontar The Mindless]

When you get done rewriting gcc and friends, along with the codebase and accompanying test suite that we've evolved over the last 15 years or so, and...

... When you get done rewriting xsltproc, fop, and friends, along with the 10,000+ pages of end-user documentation that depend on these,...

... Please call me.

Until then, I'll continue to do things the way that means my work gets done and that I get paid, and you can continue to reboot and then with one hand spam our user forums with complaints about our online manuals not being updated since yesterday, whilst masturbating to your own reflection in the screen with the other without interruption.

Have a nice day!

Attention Distros

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

Re:Attention Distros

[the_B0fh]

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

[ciggieposeur]

Don't you mean 80x25?

80x24 is vt100, xterm, and friends.

80x25 is CGA/EGA/VGA.

Re:Attention Distros

[Nimey]

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:Attention Distros

[WaywardGeek]

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.

Re:Attention Distros

[the_B0fh]

If you want anything more than 9600 baud, go back to the 1980s.

Re:Attention Distros

[the_B0fh]

AC2 meet AC1 who thinks this should require X... :)

Re:Attention Distros

[truedfx]

If you don't use the console, this shouldn't bother you, since it shouldn't affect you.

Re:Attention Distros

[jedidiah]

I was running X in the 80s.

I agree with the other guy about the fancier terminal options. If you want a fancier terminal, perhaps it's finally time for you to leave the 70s and start using X.

Re:Attention Distros

[jedidiah]

You are being intentionally obtuse.

He does use the console. He just uses it as an emergency fallback mechanism. As such, it should be as simple as possible. Trying to give it the "trans-warp" treatment is just stupid and really bad engineering.

Re:Attention Distros

[randomencounter]

Sometimes you have a need for a minimal terminal interface.

For me it's usually because I managed to break X playing with new drivers (again!) and I need something to fix it in.

So I should be crippled to 80x24 while I do that when better could be available?

Re:Attention Distros

[truedfx]

What makes you think it will no longer be useful as an emergency fallback mechanism? Actually, what I mainly objected to, although I didn't state so in my message, was the "this is pointless since I won't use it". The code isn't written for the personal benefit of this particular Anonymous Coward.

Re:Attention Distros

[snemarch]

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.

Re:Attention Distros

[shutdown -p now]

I agree with the other guy about the fancier terminal options. If you want a fancier terminal, perhaps it's finally time for you to leave the 70s and start using X.

That's like saying that if you want a fancier email client, perhaps it's finally time for you to start using Emacs. Yeah, but what about us Vim fetishists??

Re:Attention Distros

[the_B0fh]

Because I don't need anything else that requires X. For example, it could be that all I'm interested in are console logs. More lines to the console is good.

My 1980s OSF/1 box did that on the nice 20" black and white monitor (damn, that display was crisp). Why can't linux catch up to the 1980s?

Re:Attention Distros

[phorm]

And add the overhead of an X environment, plus the possible security issues, just for console access?

Re:Attention Distros

[epyT-R]

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.

Re:Attention Distros

[the_B0fh]

I used to use vga=6 or something like that for lots and lots of characters.

But I thought this was something NEW and IMPROVED ? If it hooked back to the vga=x stuff, that'd be just great.

Re:Attention Distros

[epyT-R]

the problem is, the old text modes ran at 640x400 for the most part and were rendered by the card. The framebuffer driver doesn't. KMS allows acceleration but only if there's a hardware driver for it. If you use the nvidia binary, you can't use KMS.

Re:Attention Distros

[fa2k]

You can configure most monitors to show a small 640x480 image in the centre of the screen instead of stretching it, if it's truly unreadable

Re:Attention Distros

[Nimey]

Not often enough to rely on that. Mine can't, for instance.

What's proper multi-seat support?

[Anonymous Coward]

Dumb question, but what do they mean by proper multi-seat support?

Re:What's proper multi-seat support?

[Anonymous Coward]

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:What's proper multi-seat support?

[fuzzyfuzzyfungus]

A 'multiseat' setup(in the contemporary sense) takes advantage of the fact that putting a decent number of video outs on a single computer is cheaper than ever, and the number of USB HID and/or sound devices you can support is pretty large, and puts multiple independent monitor/keyboard/mouse users on a single host system.

I haven't had the... pleasure... of testing this myself; but I assume that non-X display scenarios, including virtual terminals, are painfully graceless under such a scheme. Certainly, all the multi-head systems I've used do something brutally ugly during the BIOS display, something slightly less ugly(generally at least mirroring) on GRUB, and don't actually start working properly until X is up and going.

Re:What's proper multi-seat support?

[FranTaylor]

multi seats
multi displays
multi keyboards
multi mice

everyone sits down, everyone logs in. it's the old fashioned "time sharing" system back again.

With USB display adaptors, it's "plug and play".

Re:What's proper multi-seat support?

[timeOday]

With USB display adaptors, it's "plug and play".

In principle, or in fact?

I've had a multi-seat linux system for many years and always found it difficult to set up and incredibly brittle to each new video card driver, Xorg release, and OS version (and likely not workable unless you disable the Gnome or KDE display manager). Once you get it working you do not touch it until you have at least a weekend to spend editing inittab, Xorg.conf, and so on.

I have concluded there isn't critical mass of user interest to keep it working and properly supported, and so given up hope that it will ever improve for good.

Anybody have a different experience?

If I could just say, "anything that hangs off USB hub 2001:f103 is part of a separate console" (including accelerated video replay and a usb sound card) I would be delirious with joy.

Re:What's proper multi-seat support?

[FranTaylor]

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:What's proper multi-seat support?

[Medievalist]

I've had a multi-seat linux system for many years and always found it difficult to set up and incredibly brittle to each new video card driver, Xorg release, and OS version (and likely not workable unless you disable the Gnome or KDE display manager). Once you get it working you do not touch it until you have at least a weekend to spend editing inittab, Xorg.conf, and so on.

My experience has been the same as yours. I want multi-seat so that I can have a dedicated console in the basement next to the actual server hardware, but also have the ability to use the mouse and keyboard in the living room where the entertainment center are. I don't want the server in the living room, I want it directly below, in the basement where I can dump its heat into the stone foundation.

Re:What's proper multi-seat support?

[nullchar]

I run multiseat and it's exactly that. One seat may have some boot display, but all other seats are blank until X starts. If X fails to start, only seat0 has a VT. Once X starts, VT switching is usually disabled in the xorg parameters so no VTs may be used on any seats.

Thus, it would be rad if ctrl-mod-f12 would launch kmscon on each seat! Then if X is hosed, you have an option besides ssh-ing in.

Re:What's proper multi-seat support?

[timeOday]

It sounds so close, except... " we recommend playing motion video and 3D games on the computer's main screen."

Watching (streaming) TV on the computer is such a staple application these days, at least in my household.

Still, I wonder if there are any similar products with hardware accelerated video decoding built into the USB (or thunderbolt?) video card?

Re:What's proper multi-seat support?

[timeOday]

Replying to my own post, I just spent some more time digging, and I don't think it exists.

The USB3 solutions may be the answer eventually, but the best chipset appears to be the Displaylink 3900 which is currently Windows only (not even Mac). Even then they are still based on compression/decompression. Maybe Optical Thunderbolt will happen one day and really solve the problem by taking extending the PCI Express bus across many meters.

Until then I'll just have to stick with my two fanless Geforce 210 cards... one in a hacked PCI-express X2 slot.

Re:What's proper multi-seat support?

[dbIII]

Yes, thunderbolt stands to change all that but the USB devices I've seen haven't a hope of keeping up. Maybe some USB3 devices may work now or soon.

Re:What's proper multi-seat support?

[fa2k]

There are video cards that support 3 outputs. I hope Fedora would expose the multi-seat setup interface to people who don't use USB video. If I was setting up something like that, I'd buy two video cards (I know some ATI can support 3 outputs, but I'd goocle it to see if it has support for multiple cards too)

Kernel Mode Setting

[andydread]

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

Re:Kernel Mode Setting

[diegocg]

Sadly, yes.

Re:Kernel Mode Setting

[whoever57]

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.

Re:Kernel Mode Setting

[gman003]

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.

Re:Kernel Mode Setting

[fa2k]

Presumably, you will get into GRUB because that's run before Linux. Hopefully, there will be some kernel command line option you can specify to use a standard graphics mode. I have an old laptop that shows a vertical stripe pattern when the fancy boot screen is enabled, and doesn't get better in X (if it actually gets that far, I don't know), but it will boot when I change the kernel options. It would be madness and extreme hubris to trust in the driver quality enoung to not haev a fallback option.

Re:Kernel Mode Setting

[Eravnrekaree]

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 drivers. If you want graphics, fonts and all of that, load X. This kmscon is not going to save you much RAM considering that X itself uses only a few megabytes and you can use a lightweight window manager that uses a few MB. What we see going on here is a terrible idea. This project should NOT be be placed into the standard linux kernel. It makes it harder to get to a BIOS video fallback if the video card drivers are not working, and needlessly duplicates functionality already provided by X.

There is no need for this project and its really amazing people are wasting time on this.

Dear god no

[sl4shd0rk]

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

Re:Dear god no

[h4rr4r]

Is a serial console not an option for you?

Re:Dear god no

[gstoddart]

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.

Re:Dear god no

[bigtrike]

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

Re:Dear god no

[h4rr4r]

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.

Re:Dear god no

[FranTaylor]

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.

Re:Dear god no

[euxneks]

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?

Re:Dear god no

[Yetihehe]

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

Re:Dear god no

[Desler]

Select 'Plain Old Text'. This option has been there since, basically, forever.

Re:Dear god no

[geminidomino]

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.

Re:Dear god no

[h4rr4r]

Not even the Universal Serial Bus type?

I thought those were pretty Universal.

Re:Dear god no

[FranTaylor]

"only occasionally"

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

Re:Dear god no

[h4rr4r]

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

Re:Dear god no

[h4rr4r]

This is a fallback that works.

Just because you don't know what you are doing does not mean you can't know this and have a social life.

Re:Dear god no

[tlhIngan]

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 debugging, or soon thunderbolt (both firewire and thunderbolt can give access to the internal bus and memory, which is the basics of debugging).

Re:Dear god no

[skids]

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 plug it in and hope that it gets properly initialized after the fact, you are only going to succeed with that part of the time. If you further need materials from userspace to initialize your console, the odds decrease substantially.

With rs232 ports disappearing from laptops, that basically leaves good old vgacon/fbcon as the most reliable way to deal with early boot problems. Which means it will pretty much always have to be compiled into the kernel when you have video hardware, unless you are an end user who wouldn't know what oriface to put a debug log into in the first place.

Re:Dear god no

[h4rr4r]

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.

Re:Dear god no

[Eravnrekaree]

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?

Re:Dear god no

[geminidomino]

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.

Re:Dear god no

[geminidomino]

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

Re:Dear god no

[dbIII]

They tend to have the little sockets that look like network ports to save space for connections that are really serial ports. It just means using an adapter in that case.
Desktop machines are a different story. There are a lot of motherboards without headers to attach a serial connection.

Re:Dear god no

[IAmR007]

And now, there's a push from the udev group to merge /usr into /. For years, /bin and /lib had everything needed to boot to the first stage, but now, udev is starting to drag in dependencies from /usr in the preliminary boot stage. This means that in order to have a separate /usr partition (such as on an ssd), it will be mandatory to also maintain an initramfs with all the files required for the particular udev configuration. An initramfs shouldn't be required for a basic boot. If a feature isn't mandatory to boot, put it later in the boot process. udev and systemd also merged, so this behemoth could become even more restrictive, especially due to the fact that NetworkManager doesn't save its data in a human readable format; what's next, a Linux version of the Registry? This is the opposite direction to how I want to see Linux going. The Unix philosophy of simple parts that can be chained together is getting completely trashed. If anything, I would like to see some of the ideas from (lan9 implement, like /net, where network connections are done by talking to control files, eg. /net/tcp/2/{ctl,data,listen,local,remote,status}. Fancy new features are very nice, but they should always be optional so as to not be restricting.

Re:Dear god no

[Unknown Lamer]

I looked a lot of Intel and AMD motherboards over the last year (my ancient AthlonMP might be getting a bit obsolete and all) and all of them had pins on the board for serial ports. Of course, you had to get a cable and wire it up to a backplate... but they're there if you really want 'em. You're SOL on laptops AFAICT though.

Amusingly enough, I discovered that most of them ran the serial and floppy ports from the temperature sensor mcu :-X

And... since I decided to keep that AthlonMP alive with a SATA card (oh yeah PCI baby) I then discovered that KMS, AGP, and SMP are not friends, and now know the joys of using KGDB over a serial console during boot to figure out why in the Hell the machine dies during card to host transfers or sometimes during modesetting ... but only when both processors are up. LET ME TELL YOU ABOUT THE FUN I'VE HAD. Not that I've gotten far since whatever problem it is causes even the hardware NMI watchdog to go out for an extended lunch.

Re:Dear god no

[Electricity Likes Me]

Also if we want to discuss fallbacks, these days I'd say the minimum we should be aiming for is KBaM input, a web browser and net access since that's the minimum you need to solve computer related problems IMO these days.

Honestly that stuff should be burned into BIOS ROM.

Re:Dear god no

[h4rr4r]

For that you need another computer.
Burning it into ROM is just begging for that to be hacked.

Re:Dear god no

[Rich0]

And this is why your X server shouldn't be run as root - there is no reason that a userspace program should be able to lock your ability to switch virtual terminals. For whatever reason X11 has been allowed to be the big exception to the whole kernel-manages-the-hardware thing.

A Real console

[stox]

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

Re:A Real console

[gman003]

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)

Re:A Real console

[FranTaylor]

you're wrong

just put the serial params on the boot command line

every linux I've tried works fine with a serial console

you will need to pxe boot or burn your own boot media to get the params there in the first place

Re:A Real console

[FranTaylor]

if you have multiple systems then you can prepare boot media on another system or use it to pxe boot

Re:A Real console

[Cramer]

I guess that makes me decadent since I have VT420s. (and no MMJ crimps :-()

Re:A Real console

[FranTaylor]

pxe booting is hard?

actually keeping track of what you do is hard?

pxe boot makes life easier because you CAN save the boot configurations for all your machines in one directory

Re:A Real console

[fisted]

You posting as AC makes me wonder what that ubiquitous software of yours actually is, which we allegedly all rely on.
Must be something embarrassing...perhaps MS Outlook?

Re:A Real console

[Bert64]

If you do that, then you only have serial access while the OS is running...
You need firmware redirection, or a lights out card. I would never buy a server without lights out, it has its own ip which i can ssh to and get a virtual serial console which also provides access to the firmware.

Re:A Real console

[Bert64]

It's not enabled by default because it would spam your logs if you loaded it on a box (or vm) that didn't actually have the serial ports present...

On the other hand, its trivially turned on or enabled from the bootloader... And i don't believe BSD has serial consoles enabled by default any more than linux does, its only systems like Solaris which are pretty much expected to be used with only a serial console, and comes supplied with hardware that always has one.

Serial console use has always been uncommon on x86, due to the traditional lack of firmware access via serial and the fact that windows seems not to support serial consoles at all. Personally i always use a lights out card on my servers, with serial access (because its MUCH faster than sending video over the network and doesnt require any nonstandard clients).

Re:A Real console

[Bert64]

Fully agree with keeping it simple...

Unfortunately, you can't sell "simplicity" as a product, most (generally not very clued up) people want complex because they think the added complexity means its somehow more valuable. As a result, we have entire industries geared up to adding layer upon layer of extra complexity to "secure" your network, any of which could contain an exploitable vulnerability.

Re:A Real console

[Bert64]

Some of the lights out boards are linux based (eg the old sun ones on the v20z servers run on an embedded ppc linux)...
The Soekris comBIOS is not open source.

Userspace?

[Skapare]

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

Re:Userspace?

[tobiasly]

e.g. "cat image.jpg" and get a picture

I think you meant "image cat.jpg"

Re:Userspace?

[Lussarn]

Thats already possible..

cat image.jpg

I don't even see the code. All I see is blonde, brunette, redhead..

RTFM

[FranTaylor]

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

is it really THAT hard???

Re:RTFM

[Carewolf]

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.

Slightly updated

[jabberw0k]

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

It's not removing the console

[marcosdumay]

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. Yeah, it may be better to just not install Ubuntu. There is still Mint, or if you don't like that (I never used Mint, so I don't know), plain Debian.

Re:It's not removing the console

[jedidiah]

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.

From the "FAQ", video driver fail

[fa2k]

And even if your video-driver fails, then your kernel-console cannot recover as you probably run fbcon which uses the same drivers as user-space.

Not if I can help it! I don't need a fancy console, I have X for that.

The only fallback would be vgacon which is only accessible from the kernel, but recovering via text-mode doesn’t work in most video-driver-failure-cases either.

Is that fact or guesswork/anecdote? And if it works in 4 out of 10 cases I'd still want it.

Therefore, this whole argument is simply wrong, but most of you probably know that already.

Well it adds more complexity, and at the very least it increases the possibility for bugs . I'm just really skeptical, because I have had the graphical boot screens fail on multiple computers. It seems like a nice project, but it should be an additional service like X11, it shouldn't replace the kernel consote. [Though with systemd, the kernel console isn't very useful anyway, as if something goes wrong, you are hosed]

Finally!

[ilsaloving]

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

Remote KVM?

[phorm]

Most servers I know of support remote KVM.
HP has iLO.
Dell has DRAC
Etc

That application is easier

[dbIII]

You don't need full multiseat for that since you're only using one mouse+keyboard at a time. Just plug everything in and set the screens to be independant instead of twinview or xinerama. If you use panels or whatever put them on both screens. If you sit down at one screen and the mouse pointer is on the other one, no problem, just move the mouse pointer until you can see it. I use that sort of setup with a bluetooth keyboard+mouse in front of the TV across the hall, with the TV working as a monitor by HDMI.
With a nvidia card and their nvidia-settings GUI tool it took less than ten seconds in total to configure the screens.

Re:That application is easier

[Medievalist]

Hey, thanks for the tipoff! Last time I tried that (quite a few years ago) it was just as brittle as multiseat - every other update broke it - but I was using the NTSC TV-out on my hodgepodge card at the time, and now I'm all HDMI at the entertainment center. I'll try it again (although not with nVidia - I prefer to spend my money on companies that have a less contentious relationship with Open Source).

Re:That application is easier

[dbIII]

I probably shouldn't have mentioned nvidia, since to get such a setup to work involves not using their twinview and just having X as normal (no xinerama either) which will work on any hardware that can handle X. Other GUI X setup tools or a very simple setup in xorg.conf gets the job done. I use E17 since it treats the screens as completely independant (eg. each screen has it's own set of virtual desktops), but many other window managers can cope apparently.
The only downside is both keyboards and mice are always active so it's a single person solution in two places.

Re:That application is easier

[Medievalist]

The only downside is both keyboards and mice are always active so it's a single person solution in two places.

That won't be a problem for me; the basement KB has an integrated trackball instead of a separate mouse, and I keep a cover over the whole thing since a certain calico cat believes it's her god-given right to dance and sleep on keyboards (including piano kbs, at 4AM). The upstairs KB/mouse is a wireless logitech dinovo edge, so it's turned off when not in use. No conflicts.

perverse needs

[jjohn_h]

>>>
We now have small laptops with 2880x1880 screens built in that are plugged into multiple monitors.
>>>

You have got perverse needs on your planet. I'm glad we still look normal on planet Earth.

>>>
Heck, a simple one: I have a laptop with a dead built-in monitor.
>>>

Get it repaired.

my text console doesn't work already

[Blaskowicz]

it's pitch black when I switch to a text console, well the monitor thinks the frequency are unknown, then switches off. so, the text mode is a low class citizen already. thanks to the discussion I know it's perhaps about using nvidia driver, and the poor console thing trying to do KMS even though it's unavaible. I'm running ubuntu 12.04 (mint 13 mate)

so, I should configure myself but it's so boring. try vga=normal as kernel boot parameter, I've been told. well, I didn't yet, because I know I'll have to navigate the grub2 dynamic maze after that. I would be fine with real 80x50. which I never got to use by the way on linux, it always was 80x25 until they decided we would get the monitor's max resolution (this isn't very fun on a low end CRT). there wasn't a command like "mode" in DOS/windows, or I was never told about it. I just couldn't care enough to learn guru things that would never matter to anyone else

one redeeming quality for this madness is a video projector can not support the text modes (and graphical 320x200, etc.) ; dunno what happens with TV used as monitor.

kanji on the console

[reiisi]

Installed debian with Japanese as the default system language and the console dumps Japanese messages at me.

Currently, they are not renderable, and I have spent some time trying to fix that.

Yeah, I can change the environment variables, etc., but I would like to be able to just leave it as is and get readable Japanese in the console.

Non-Latin on the console

[reiisi]

For people who would prefer to interact with bash on the console in languages that have large character sets -- Japanese, in my case.

Alternate writings

[DrYak]

with limited character sets {...} 80x50 textmode is perfectly fine for me, but other people might have different needs.

Yup. An accelerated texcon could enable the display of full unicode.

A classic text modes lets you use either 1 set of 255 caracters, or 2 sets if you reduce the number of colors to 8 (remove the other highlighted 8). Hence the whole codepage madness.
- That's okay if your language use latin script: latin alphabet is part of the default ASCII caracters, and you can cram all the needed accented characters in the remaining upper 128 caracters, if you sacrifice the box drawing characters (most text user interface will switch to drawing boxes with only regular ascii. +, -, and | ). Although you would have to limit yourself to a few select subset of language (latin and slavic use a completely different set of accented characters, leading to 2 different code-pages)
- That's okay for some non-latin scripts too like modern greek or cyrillic (you can cram both the lower and cap cases in the last 128 entry of the character set).
- But for other scripts, specially ideographic ones (chinese) or using several writing systems (japanese uses 2 syllabes alphabets AND a subset of chinese ideograms) the place left in the 128 chars starts to be limited (although it could be theoretically possible to cram a very limited subset, by using 2 simultaneous character sets, with only 1 containing the needed ASCII part) (and how to paint complex ideograms with only 8x16 pixels is left to the imagination of the reader).
- Now if you need to mix languages on screen and/or keeping the box-drawing characters at the same time, that "2 codepages at the same time" is going to be really an uncomfortable limit.

Now factor in also all the mumbo-jumbo necessary to map the internal internationalised representation of strings (utf8, most likely) to the chimera you got by abusing the 2 simul. charset method.

Well at that point being able to just display UTF8 (on a 256-color terminal, with background and/or logo) starts to be rather interesting.

And that's not an unrealistic situation:
you use Linux in another language as english, but (very likely) not every single program has been localised to your language and might need to fall-back to alternative. So you might end up with several different language at the same time on screen.
If you don't have a running X server (because the machine is a server and doesn't need one, or because the X server crashed and you need to dig the logs to see what caused it), you'll need to run command-line and scan logs on the console. if the text console can't handle all the involved language your debugging-/configuring- session is going to suck.