Page MenuHomeFreeBSD

Add VT driver for VBE framebuffer device
ClosedPublic

Authored by tsoome on Nov 25 2020, 6:54 PM.

Details

Summary

Implement vt_vbefb to support Vesa Bios Extensions (VBE) framebuffer with VT. vt_vbefb is
built based on vt_efifb and is assuming similar data for initialization.
Therefore we can use the struct efi_fb, but with added field fb_bpp for
depth (UEFI is only supporting 32-bit depth and was not needing it) and we
use MODINFOMD_VBE_FB to identify the structure in kernel metadata.

struct efi_fb, is populated by boot loader, and is passed to kernel via metadata payload.

Test Plan

Tested along with updated loader, which can set and use VBE framebuffer mode.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Implement vt_vbefb to support VBE framebuffer with VT

Please spell out uncommon acronyms the first time they're used:

"Implement vt_vbefb to support Vsomething Bsomething Esomething (VBE) framebuffer with VT"

Also: it looks like the value of fb_bpp is populated from the preloaded module, but what it setting that? The bootloader? If so, where are the bootloader changes which actually populate it? The firmware? If so, please document that as well. The way I read this code, it seems like you're saying that some non-EFI firmware is using the same structure as EFI, and tacking fb_bpp onto it, which seems unlikely to me.

Implement vt_vbefb to support VBE framebuffer with VT

Please spell out uncommon acronyms the first time they're used:

"Implement vt_vbefb to support Vsomething Bsomething Esomething (VBE) framebuffer with VT"

Also: it looks like the value of fb_bpp is populated from the preloaded module, but what it setting that? The bootloader? If so, where are the bootloader changes which actually populate it? The firmware? If so, please document that as well. The way I read this code, it seems like you're saying that some non-EFI firmware is using the same structure as EFI, and tacking fb_bpp onto it, which seems unlikely to me.

This structure is stored in preloaded module, the fields are to be populated by boot loader in exactly the same way as currently is done by efi loader. To reduce confusion, we maybe should pick better name to replace "efi_fb". The VT internal state is filled from this structure.

To reduce confusion, we maybe should pick better name to replace "efi_fb". The VT internal state is filled from this structure.

Perhaps rename struct efi_fb to struct common_fb, and then have:

struct efi_fb {
        struct common_fb    fb_com;
};

struct vbe_fb {
        struct common_fb    fb_com;
        uint32_t            fb_bpp;
};

That would introduce a small amount of additional indirection, but would clarify things considerably, and also leave open the possibility of adding EFI-specific things in the future.

create vbe_fb structure for vbe driver.

To reduce confusion, we maybe should pick better name to replace "efi_fb". The VT internal state is filled from this structure.

Perhaps rename struct efi_fb to struct common_fb, and then have:

struct efi_fb {
        struct common_fb    fb_com;
};

struct vbe_fb {
        struct common_fb    fb_com;
        uint32_t            fb_bpp;
};

That would introduce a small amount of additional indirection, but would clarify things considerably, and also leave open the possibility of adding EFI-specific things in the future.

I guess it is better just to keep them all separate.

I guess it is better just to keep them all separate.

I'm fine with that too. :-)

Code change looks good to me; please update any manual pages.

Code change looks good to me; please update any manual pages.

There seems to be no manuals about vt backends.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 30 2020, 8:22 AM
This revision was automatically updated to reflect the committed changes.