3 ms·
GOP functions aren't available after ExitBootServices() has been called, so the kernel doesn't get to take advantage of Blit() - the assumption is that the kern
by mjg59 6y ago
GOP functions aren't available after ExitBootServices() has been called, so the kernel doesn't get to take advantage of Blit() - the assumption is that the kernel will have a native driver for the hardware. Additionally, you can't really use off-screen graphics RAM in the EFI environment because GOP doesn't tell you how much video RAM is actually available, only the size of the framebuffer. You can guess which PCI device is associated with the framebuffer and look at the size of the BAR, but you have no way of knowing which addresses the EFI driver is using for its own purposes. Apple have enough control over their platform that they could possibly make this work, but it's tough when you're dealing with a vendor-provided driver on an add-in card.
- JdeBP 6y agoHah! I've been doing too much load-time stuff, obviously. (-: But if one is looking at PCI device IDs, then one is already at the level of the code having detailed knowledge of the specific hardware (even if only via some "miniport"-like system) and the point stands.
- mjg59 6y agoOh, you can look at the device that the GOP instance is bound to and get the PCI device from there. At that point you just walk the BARs looking for one that's mapped in a region that covers the framebuffer address that GOP gives you. This doesn't require you to know anything about the device in question, and most of the time you'd probably get lucky by throwing glyphs in space that exists outside the framebuffer and blitting them onto the screen - up until you find a driver that implements blt() by using the 3D engine and mapping some buffer objects on top of the space you're trying to use.
- JdeBP 6y agoThe code will still have to know about blitter hardware, as I said. Any design that depends from "you'd probably get lucky" is not a wise one. (-: