kmscon: replacing CONFIG_VT

kmscon: replacing CONFIG_VT

[David Herrmann]

Hi

I am currently working on replacing the VT layer with a user-space
implementation called "kmscon". It is based on KMS/DRM to control the
video display. I can now successfully run it with CONFIG_VT disabled
and a few hacks to avoid using /dev/ttyX in kmscon.

The idea is to move UI code out of the kernel and getting a full VT520
terminal (full Unicode/font support) implemented in user-space. There
are some other advantages that I will skip here.

I am now working on replacing missing features of the kernel VT. I've
had some deeper look into drivers/tty/vt/ and drivers/video/console/.
The main feature that is missing with CONFIG_VT=n is definitely an
(early-)boot console driver. fbcon and vgacon both provide the consw
driver which then provides the console driver. However, without consw
(tied to VTs) there will also be no
console driver.

I was wondering what the best way to replace them is. I could rewrite
fbcon.c to provide a "struct console" driver instead of a whole consw
driver. Or I could write a drmcon driver that uses the drm api to
provide a console driver. As KMSCON currently runs with DRM only, it
wouldn't matter that drmcon would depend on DRM, too. In short: I need
some shortcut from vgacon/fbcon directly to "struct console" and
dropping the VT-layer in between.

The driver itself would be pretty simply. It would have a ring-buffer
for the messages that are currently printed to the screen and rotate
it as new messages come in. It could then print it via drm
mode-setting if there is currently no other drm application running.
That is, if X/wayland/kmscon shows up, the drmcon driver will go to
sleep and do nothing. kmscon can then read /dev/kmsg and print the
messages if it wants to. If kmscon exits, drmcon will take over and
print the messages again.

Other parts missing with CONFIG_VT=n are probably some ioctls which
won't work with pty. However, all applications that run in xterm will
also run in kmscon. Only applications that use linux ioctl's will not.
However, I don't think that these are needed, but I will watch
carefully while testing it.
That's just some of my ideas on this topic. Maybe you can give me some
hints whether it actually makes sense ;)

Regards
David

Re: kmscon: replacing CONFIG_VT

[Alan Cox]

> That's just some of my ideas on this topic. Maybe you can give me some
> hints whether it actually makes sense ;)

For a lot of hardware it may not matter. If it goes bang you boot with a
debugging kernel (one containing a vt driver)

If your user space goes castors up early then you are going to need input
facilities anyway (consider the fedora rescue mode in dracut for example) 

As far as compatibility goes we have the ttyprintk driver which just
provides a fake tty which types nothing and whose output goes to the
console.

Alan

Re: kmscon: replacing CONFIG_VT

[David Herrmann]

Hi Alan

On Wed, May 16, 2012 at 6:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> That's just some of my ideas on this topic. Maybe you can give me some
>> hints whether it actually makes sense ;)
>
> For a lot of hardware it may not matter. If it goes bang you boot with a
> debugging kernel (one containing a vt driver)
>
> If your user space goes castors up early then you are going to need input
> facilities anyway (consider the fedora rescue mode in dracut for example)

So you are basically saying that such an drmcon driver isn't needed,
anyway? If we keep backwards compatibility to CONFIG_VT, everyone who
wants a boot-log on the display just needs to enable CONFIG_VT. Sounds
reasonable.

> As far as compatibility goes we have the ttyprintk driver which just
> provides a fake tty which types nothing and whose output goes to the
> console.

I haven't found any applications that fail without /dev/tty, however,
thanks for the hint.

> Alan

Thanks for the answers. So I can concentrate on the user-space parts
and maybe later implement some drmcon'ish driver.

Regards
David

Re: kmscon: replacing CONFIG_VT

[Alan Cox]

> So you are basically saying that such an drmcon driver isn't needed,
> anyway? If we keep backwards compatibility to CONFIG_VT, everyone who
> wants a boot-log on the display just needs to enable CONFIG_VT. Sounds
> reasonable.

For a lot of applications I think this will be true.

> > As far as compatibility goes we have the ttyprintk driver which just
> > provides a fake tty which types nothing and whose output goes to the
> > console.
> 
> I haven't found any applications that fail without /dev/tty, however,
> thanks for the hint.

There are quite a few, but ttyprintk means that if you've got a printk
console you've got a console "tty" at least for output. End of problem
therefore.

> Thanks for the answers. So I can concentrate on the user-space parts
> and maybe later implement some drmcon'ish driver.

I think so. And bear in mind a "drmcon'ish driver" for rescue could be a
shared library you can link the boot environment with, one that makes
minimal use of drm and /dev/input to implement a very basic vt.

Alan

Re: kmscon: replacing CONFIG_VT

[Alan Cox]

As a PS:

"tty is a library" has been done in experimental exokernel work in the
past.