Hi, > > The drivers are asic and platform specific. E.g., the driver for > > vangogh is different from renoir is different from skylake, etc. The > > display programming interfaces are asic specific. > > Cool, that makes sense! But if you (or anybody here) know some of these > GOP drivers, e.g. for the qemu/qxl device, OvmfPkg/QemuVideoDxe in tianocore source tree. > I'm just curious to see/understand how complex is the FW driver to > just put the device/screen in a usable state. Note that qemu has a paravirtual interface for vesa vga mode programming where you basically program a handful of registers with xres, yres, depth etc. (after resetting the device to put it into vga compatibility mode) and you are done. Initializing physical hardware is an order of magnitude harder than that. With qxl you could also go figure the current state of the hardware and fill screen_info with that to get a working boot framebuffer in the kexec'ed kernel. Problem with this approach is this works only in case the framebuffer happens to be in a format usable by vesafb/efifb. So no modifiers (tiling etc.) and continuous in physical address space. That is true for qxl. With virtio-gpu it wouldn't work though (framebuffer can be scattered), and I expect with most modern physical hardware it wouldn't work either. take care, Gerd _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
