Re: vt(4) chops off the leftmost three columns

From: Adrian Chadd <adrian.chadd_at_gmail.com>
Date: Tue, 24 Jan 2017 12:55:58 -0800
hi!

Well, give it a go. I can only be supportive. :)


-a


On 24 January 2017 at 10:31, Anindya Mukherjee <anindya49_at_hotmail.com> wrote:
> Hi again,
>
> I have been switching back and forth between exploring the code and reading J. Kong's Device Drivers book. As you explained, the first thing to tackle is the coupling between vesa and sc. Right now I can't even load vesa unless the kern.vty=sc, and then I cannot unload it.
>
> vesa depends on vesa.c and pulls in scvesactl.c for two functions: vesa_load_ioctl() and vesa_unload_ioctl(). Although these are used only in vesa.c, they depend on several structures (for example the virtual screen structure scr_stat, and others) defined in syscons.h, which makes these two systems coupled.
>
> I was wondering what would be a good way to decouple these dependencies. I want to do the right thing even if it takes longer. Really appreciate you taking the time to respond, thanks!
>
> Anindya
> ________________________________________
> From: Adrian Chadd [adrian.chadd_at_gmail.com]
> Sent: January 20, 2017 3:11 PM
> To: Anindya Mukherjee
> Cc: freebsd-current_at_freebsd.org
> Subject: Re: vt(4) chops off the leftmost three columns
>
> 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_at_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
Received on Tue Jan 24 2017 - 19:56:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC