NetBSD-Desktop archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Framebuffer console support for i386 and amd64

Andrew Doran wrote:

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?

- 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,

Home | Main Index | Thread Index | Old Index