Date: Fri, 20 Jan 2017 15:11:40 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Anindya Mukherjee <anindya49@hotmail.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: vt(4) chops off the leftmost three columns Message-ID: <CAJ-Vmo=bRJvkX9JM0CmLcQexpPF%2B6X8GDB3urCTjAAS6Tzro1Q@mail.gmail.com> In-Reply-To: <BN6PR22MB0802DB657D97A1F6C8EB3F34B67E0@BN6PR22MB0802.namprd22.prod.outlook.com> References: <BN6PR22MB0802DB657D97A1F6C8EB3F34B67E0@BN6PR22MB0802.namprd22.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <anindya49@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=bRJvkX9JM0CmLcQexpPF%2B6X8GDB3urCTjAAS6Tzro1Q>