Re: Framebuffer console support for i386 and amd64

["Jared D. McNeill" <jmcneill%invisible.ca@localhost>]

Andrew Doran wrote:
> Hi,
>
> Thanks for doing this!
>
> On Sat, Feb 14, 2009 at 03:58:22PM -0500, Jared D. McNeill wrote:
>
> > My goal is to nuke vesafb, and replace it with genfb in the i386 and 
> > amd64 kernels. This is a prereq to having proper splash screen support. 
> > I would like to check in the following changes to the x86 bootloader and 
> > kernel. Any objections?
> >
> >   http://www.invisible.ca/~jmcneill/outgoing/x86fb/
>
> - rasops_cmap[] has a TNF copyright.

Thanks, I will add it.

> - Can you add 3 or 4 spare uint32_t's to btinfo_framebuffer? Just in case
>   there is an issue with adding to the structure later. Probably won't be an
>   issue, but..

I have added a few fields since I dropped those patches:

struct btinfo_framebuffer {
        struct btinfo_common common;
        uint64_t physaddr;
        uint32_t width;
        uint32_t height;
        uint16_t stride;
        uint8_t depth;
        uint32_t flags;
        uint8_t rnum;
        uint8_t gnum;
        uint8_t bnum;
        uint8_t rpos;
        uint8_t gpos;
        uint8_t bpos;
};

I will add some more just to be safe. Do you think there's any need to 
make physaddr 64-bit?

> - command_vesa should go into vbe.c since the other loaders will want it.

Will do.

> Some observations:
>
> - The growing collection of stubs is silly, it would be nice to copy the DOS
>   int86() call at some point in the future. Just an observation, I don't
>   object to adding the VESA stubs.

Yeah it's a royal pain, I'm not clued enough to pull it off though.

> - x86_genfb_set_mapreg - probably safe to assume that it will work
>   everywhere but I'd like to get some test coverage with different hardware.

Not really sure how else to do this without bioscalls, I guess if it 
doesn't work you are stuck with the rasops/splash colour palette unless 
you boot in 16 or 32bpp modes. Alternately a native display driver will 
have to beat out genfb and provide its own set_mapreg callback.

The other option here is to use VBE PMI where available, but I'm not 
entirely sure how that would work on amd64.

>   I think this means setting fb console by default during the 6.0 cycle (in
>   boot.cfg). We could also look at ditching the vga driver and using the
>   simpler pcdisplay for fallback, and look at how it is going to interact
>   with drm. No point having pcdisplay+vga+genfb in the kernel.

I have checked in changed to genfb that makes it work with drm.

> - We don't allow fb console to be hardwired into the loader binary with
>   installboot. But since it's really just an extension to the PC console
>   type, I don't think it matters.
>
> Otherwise it looks OK to me.

Thanks Andrew,
Jared