hiya, 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. -adrian 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? > > Thanks, > Anindya _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
