Add UEFI support

[RossComputerGuy]

No description provided.

[notgull]

Thanks for the PR! Two things:

• raw_window_handle is intended to be a common types crate to be used by higher-level crates, rather than something that implements functionality on its own. So I would rather have it represent a Handle as a NonNull<T> since it's a raw pointer.
• From a quick glance at the docs, it seems that GraphicsOutput has a framebuffer of its own. So I think it would be better if GraphicsOutput was a property of the WindowHandle rather than the DisplayHandle.

[RossComputerGuy]

• From a quick glance at the docs, it seems that GraphicsOutput has a framebuffer of its own. So I think it would be better if GraphicsOutput was a property of the WindowHandle rather than the DisplayHandle.

The framebuffer is only available when the Graphics Output Protocol implements a framebuffer mode. Otherwise, you have to use blit mode.

[notgull]

Still, you draw to the GraphicsOutput, which in line with our earlier implementation for DRM/KMS. I think if you draw to it, it should be classified as a window.

[RossComputerGuy]

I'm not sure what you mean. When drawing in UEFI, you use a temporary buffer which you render to. Then whenever you present, you copy from that buffer to the memory mapped one if it is available. Otherwise, you use the blit function in the protocol. If the memory mapped buffer is not available, that means the GPU just doesn't give the ability for direct screen access.

I was wanting to use this with something like iced and have it like a compositor. Have multiple windows which get drawn and be able to manipulate them. At least in this crate and softbuffer, it shouldn't be anything special to make that possible.

[madsmtm]

Suggested change

	/// `EFI_GRAPHICS_OUTPUT_PROTOCOL`.
	/// [`EFI_GRAPHICS_OUTPUT_PROTOCOL`].
	///
	/// [`EFI_GRAPHICS_OUTPUT_PROTOCOL`]: https://uefi.org/specs/UEFI/2.10/12_Protocols_Console_Support.html#efi-graphics-output-protocol

Right?

[RossComputerGuy]

I'm not sure, idk the format of rust's doc comment that much.

[madsmtm]

Wrt. having it on WindowHandle vs DisplayHandle, I'm leaning towards agreeing with @notgull. The term "WindowHandle" that we use is a bit of a misnomer, it's closer to "drawable surface".

Unless there's something else in UEFI that more closely corresponds to a drawable surface?

[madsmtm]

Re-reading the docs for RawDisplayHandle, it says:

The display usually represents a connection to some display server, but it is not necessarily tied to a particular window. Some APIs can use the display handle without ever creating a window handle (e.g. offscreen rendering, headless event handling).

Which seems to indicate that perhaps display handles are better thought of as "connection handle" (they don't actually correspond to a physical "display"/monitor).

Idk., the analogies break down somewhat at this point. Maybe the best approach is to consider how things will be used? Maybe you could expand on how you produce this handle for softbuffer to consume it?

[RossComputerGuy]

Yeah, the EFI_GRAPHICS_OUTPUT_PROTOCOL doesn't indicate much of anything. It's quite opaque, it just gives us some way to interact with a framebuffer and change modes. Now, since the GPU provides the EFI_GRAPHICS_OUTPUT_PROTOCOL via the option ROM over the PCIe bus, it is possible for the method which provides a framebuffer pointer to return NULL. The solution is to use the blit function to write to the framebuffer.

So you could interpret this as a RawDisplayHandle quite easily. My idea for this working with softbuffer is work in either 1 of two ways:

1. A single window which represents the entire display
2. Running a "mock" window server (more of just placing windows in arbitrary places in which the package consuming softbuffer has to do the heavy lifting so softbuffer only does rendering)

[madsmtm]

This is blocked on rust-windowing/softbuffer#282 (review) (I'm still not convinced that this is better represented as a window/"surface" handles).