The Linux Kernel Console Is Being Killed Off

[dvdhrm]

Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
Fetching a proper tarball worked, but there's more issues:
KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
Patch that, and try...oops, --with-fonts=8x16 isn't supported.
Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!

Why didn't you try out kmscon-6? If you use git-builds, please don't complain if the documentation isn't up to date. I usually update documentation before doing a release. 8x16 font is now built-in so you no longer need to pass it to --with-fonts. libudev-172 is required (as mentioned in the README) because it introduced udev_device_has_tag().

udev is currently used in one single file (uterm_monitor.c). The TODO list includes an item "make udev optional". I haven't done this yet, because no-one showed me good reasons to do so and I am still working on more important stuff. Please note, kmscon is still experimental. I haven't advertised it anywhere, so please consider it experimental.

And please, if you have issues with it, open a bug-report, write an email or contact me via any other medium. But don't complain in public forums and expect the developers to find this and fix stuff.
For instance, why didn't you open a bug-report that autoconf 2.67 is enough?


Regarding the problem with plymouth:
You cannot use plymouth together with any other application that uses graphics devices. Why do you want to use plymouth --show-splash from the console? It simply acquires all input/video devices and shows the splash screen. This doesn't work if another application (like xserver or kmscon) currently uses the devices.
I don't understand why anyone would want that? Could you elaborate a bit more?

Regards
David

[cl91]

A huge bless to the CJK community

I hope this project takes off. Please ignore all the dirty neckbeards crying over this project.

When can we start using this project? Or when it will be implemented in distros like archlinux, etc?

Now. Archlinux already packages it. Link: https://www.archlinux.org/packages/c...x86_64/kmscon/

I have been using KMSCON as my main console since last December. The experience has been very smooth.

People in the west might not realize this, but this project is a huge blessing to the entire CJK community.
The good old linux-console is practically useless to us except as the emergency console, 'cause it has no
capability of displaying CJK characters. There's been various efforts within the CJK community, but none has
worked out well. KMSCON is the first proper solution to this problem.

[Ericg]

Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
Fetching a proper tarball worked, but there's more issues:
KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
Patch that, and try...oops, --with-fonts=8x16 isn't supported.
Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!

I do have a response but since we have the developer here in the forums I won't derail things and just let him respond since its a choice of dependency issue. Dvdhrm, response?

[Ibidem]

You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)

Anytime I need something newer in Debian, I get a backport or make my own. I don't pull stuff from multiple releases.

I'm currently running a patched mesa ~8.0, with libdrm 2.4.39 backported from git, and kernel 3.4.24.
I don't want to move to a current distro, since I have a Radeon HD3200M. Newer Mesa doesn't currently work here, and I keep seeing the claim that Radeon is broken for the HD3xxx series (I could try debugging, but after I bisected they moved the problem code for me from Mesa to libdrm without fixing anything, and I really prefer a system that is functional), while you probably have read about the state of the proprietary drivers...

That post was because xkbcommon (the tarball autocreated by cgit for the 0.2.0 tag) didn't build.
Fetching a proper tarball worked, but there's more issues:
KMSCON wants autoconf 2.68 (2.67 what's in Squeeze), which is easily fixed because it's someone who just decided to require what they had rather than what they needed.
Patch that, and try...oops, --with-fonts=8x16 isn't supported.
Read configure, OK, it seems it changed names to unifont. That's not documented, of course. Fair enough, since I'm building from git.
And it thinks I don't have libudev...because it expects 172 or higher. I have 168. I missed that in the README, since they put it so concisely.
OK, that was added 1 day after kmscon-6 was released, but it seems to be a fix rather than a new dependency.

All right, I don't care enough about getting the size of a static binary enough to bother with this. I would be surprised if it's under 1.5MB linked to glibc.
If one of you wants to get that information yourself, it would be informative. But to me, this post by Luc Verhaegen seems to be somewhat relevant: The linux desktop is dead!

[Akka]

huu, it was extremely fast and smooth output relative the old console. Nice looking printing is good

[Ericg]

Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
I can't get any numbers on size of a static binary though:

$ ./autogen.sh 
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force --warnings=all -I m4
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: configure.ac: tracing
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
autoreconf2.50: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to disable maintainer-specific portions of Makefiles... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
checking whether to build documentation... yes
checking for doxygen... /usr/bin/doxygen
checking for inline... inline
checking for typeof syntax and keyword spelling... typeof
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for bison... bison -y
checking for bison... /usr/bin/bison
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for eaccess... yes
checking for euidaccess... yes
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'

Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
Somehow this doesn't look promising.

You're running your impression off of software that you're pulling in across multiple releases...from Debian? Try running Arch and see how "stable" or "Buggy" it is, then get back to me. Or Gentoo. Or Ubuntu with up-to-date-PPA's. Arch even has it packaged in Community or Extra, tried running it today on my new laptop. Works great. The only issue I had was when I did Linux-VT -> Kmscon -> plymouthd && plymouth --show-splash I got a soft-lockup. (Keyboard wouldnt respond but one press of the power button had systemd doing a clean shutdown) Which I'm thinking was caused by KMSCON and Plymouth both fighting over the DRM simultaneously. (Dvdhrm, if youre reading this. This was a fully updated Arch system, so latest versions across the board, KMSCON stable, not from git. Plymouth from stable, not git.)

[Ibidem]

Well, it looks like they intend to make libudev optional, it just hasn't been done yet.
I can't get any numbers on size of a static binary though:

$ ./autogen.sh 
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force --warnings=all -I m4
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: configure.ac: tracing
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: /usr/bin/autoconf --force --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: /usr/bin/autoheader --force --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
autoreconf2.50: running: automake --add-missing --copy --force-missing --warnings=all
configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=libxkbcommon
Makefile.am:90: user target `src/xkbcomp/parser.h' defined here...
automake: ... overrides Automake target `src/xkbcomp/parser.h' defined here
autoreconf2.50: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to disable maintainer-specific portions of Makefiles... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11156: XORG_MEMORY_CHECK_FLAGS: command not found
checking whether to build documentation... yes
checking for doxygen... /usr/bin/doxygen
checking for inline... inline
checking for typeof syntax and keyword spelling... typeof
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for bison... bison -y
checking for bison... /usr/bin/bison
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for eaccess... yes
checking for euidaccess... yes
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: syntax error near unexpected token `CFLAGS,'
/mnt/mesa/src/BRK/xkbcommon-0.2.0/configure: line 11683: `XORG_TESTSET_CFLAG(CFLAGS, -fvisibility=hidden)'

Debian squeeze doesn't have libxkbcommon, so I can't just apt-get it.

Edit: Nor does wheezy, just experimental--and libxkbcommon is tagged rc-buggy.
Somehow this doesn't look promising.

[rofl0r]

UDEV

The entire project FAQ, if youre gonna bash the project atleast have the developers side of the story:

the dependency to UDEV is completely unacceptable; any distro based on busybox uses mdev instead of udev.
for example, sabotage linux [1]

in short, kmscon is a very BAD idea until there's a very simple, very portable core that has no external deps at all.
ideally, some statically linked fallback version would be automatically compiled while building the kernel


also a hardcoded dependency to glibc makes it impossible to use a modern kernel with any other C library, such as musl libc[2]

[1] https://github.com/rofl0r/sabotage
[2] http://www.musl-libc.org

[Rexilion]

First, I should clarify that I don't object to KMSCON.
I do object to it being considered a full replacement for CONFIG_VT. It is a good thing to have, but there are problems it won't work for.

Ok.

Actually it's this, and it was a case where init would not mount / at all.

Ah, would have been nice you mentioned that you were not using stock configuration. But alas, point taken.

He posted it while I was writing my post, and I made the mistake of believing Micheal's list of dependencies.

Yes, it was not mentioned they are optional. It would have been nice if it has been.

I really should know better than that, by now.

lol

I'm not asking whether it's buggy, but whether there are points where it failed to allow basic input. I can't tell from the commit messages whether that's the case there. Or did those break VT?
If I can start a shell and enter commands, that's useable, regardless how many races there are in the design.

Again, this will lower maintainance cost. This is a tradeoff between user and developer. More on this below.

You really think that VESA/framebuffer always works? I guess you've been rather limited in your reading.
Real-world cases I've heard of:
-Some gfx cards (especially SIS/S3, IIRC) don't work with vesa; it loads, but you get an unuseable display.
-Drivers that break after enablement

[practical joke]Accusing me of limited reading and then mentioning things you *heard* off. Interesting...[/practical joke]

Yes, things break. But I take that as a part of Linux by now.

That is why I argue it well never be a mainstream system. I now know the concepts of building a kernel, compiling code and doing a git bisect. Things I would never know (and supposed not to know as an end user) when I sticked to using Windows. But those are the things that are part of using Linux (in my opinion).

As for the unsupported SiS and S3 hardware and other 'drivers that break after enablement'. Yeah, that just sucks about Linux. But can you blame them? Not really... . For me, the advantages outweight the disadvantages.

Real problems I've encountered with framebuffer and KMS drivers:
-radeonfb gets loaded by Debian because they don't ship microcode. Unuseable display.
-Intel black screen (2.6.32 or so, Lucid testing)
And then there's the whole problem with AMD and Nvidia proprietary drivers (no framebuffer/kms, only X), and some installers won't run if the kms drivers are loaded...

Practical jokes aside, yes some hardware is not well supported. But that should not inhibit developers from making better decisions higher up the stack. If it's broken now, it will be broken later. I think you know that regressions are not accepted. Furthermore, it will be a long while before CONFIG_VT will be removed (and all of it's necessary code). This should not inhibit progress.

Aside from that, the open source drivers are making quite some progress these days (and 2.6.32 is pretty old!). It will be nice to take advantage of all this hard work.

I'm not against proprietary drivers, but I have no mercy to them when it comes to 'compatibility'. People are free to develop drivers outside of the tree, but end users have no right to expect that they will work with every new piece of technology that comes around. I know that not everyone has the privilege of using open source drivers. But you don't HAVE to use Linux. You could stick with Windows. I'm totally fine with that. In fact, I would not *ever* recommend Linux to anyone else as it stands now. I introduces this OS to my parents and we ran into so many little subtle things. It will probably be never worth it for the majority of people to use it!

[Ibidem]

First, I should clarify that I don't object to KMSCON.
I do object to it being considered a full replacement for CONFIG_VT. It is a good thing to have, but there are problems it won't work for.

Yeah (link!), cute.. Did I already mention that fsck is not in initramfs. So it must be in the kernel right? Yeah...

Reading a library/program to render your console/fix your fs does not imply rw access to the medium where this library comes from. Moving on...

Actually it's this, and it was a case where init would not mount / at all.

Read the FAQ EricG posted. And that would not be pixman but pango. And look! -> both optional.

He posted it while I was writing my post, and I made the mistake of believing Micheal's list of dependencies.

I really should know better than that, by now.

Read the Phoronix article. They are working on DRM for Vesa and UEFI based systems. No GPU support -> Framebuffer!

X will not start. Rebuild it. Does nothing (link!) to do with KMSCON (yet).


Look here (link!). This would not be needed, were VT correctly designed from the start. One more example here (link!).

I'm not asking whether it's buggy, but whether there are points where it failed to allow basic input. I can't tell from the commit messages whether that's the case there. Or did those break VT?
If I can start a shell and enter commands, that's useable, regardless how many races there are in the design.

You really think that VESA/framebuffer always works? I guess you've been rather limited in your reading.
Real-world cases I've heard of:
-Some gfx cards (especially SIS/S3, IIRC) don't work with vesa; it loads, but you get an unuseable display.
-Drivers that break after enablement
Real problems I've encountered with framebuffer and KMS drivers:
-radeonfb gets loaded by Debian because they don't ship microcode. Unuseable display.
-Intel black screen (2.6.32 or so, Lucid testing)
And then there's the whole problem with AMD and Nvidia proprietary drivers (no framebuffer/kms, only X), and some installers won't run if the kms drivers are loaded...