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
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
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
On 19 January 2017 at 12:35, Anindya Mukherjee <anindy...@hotmail.com> 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?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"