Thanks! I needed a breakdown like this. I'll need to study the code a bit more.

From: Adrian Chadd []
Sent: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Subject: Re: vt(4) chops off the leftmost three columns


Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


On 19 January 2017 at 12:35, Anindya Mukherjee <> wrote:
> Hi Adrian,
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
> Also, how dependent is splash/screensaver support on the VESA implementation?
> Thanks,
> Anindya
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to