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.

[notgull]

Suggested change

#[cfg(target_os = "uefi")]

We avoid target conditionals here.

[RossComputerGuy]

Done

[notgull]

Suggested change

#[cfg(target_os = "uefi")]

Ditto

[RossComputerGuy]

Done

[notgull]

Suggested change

	impl DisplayHandle<'static> {
	/// Create a UEFI-based display handle.
	///
	/// As no data is borrowed by this handle, it is completely safe to create. This function
	/// may be useful to windowing framework implementations that want to avoid unsafe code.
	///
	/// # Example
	///
	/// ```
	/// # use raw_window_handle::{DisplayHandle, HasDisplayHandle};
	/// # fn do_something(rwh: impl HasDisplayHandle) { let _ = rwh; }
	/// let handle = DisplayHandle::uefi();
	/// do_something(handle);
	/// ```
	pub fn uefi() -> Result<Self, HandleError> {
	let proto = boot::get_handle_for_protocol::<GraphicsOutput>()
	.or_else(|_| Err(HandleError::Unavailable))?;
	// SAFETY: No data is borrowed.
	Ok(unsafe { Self::borrow_raw(UefiDisplayHandle::new(proto).into()) })
	}
	}

This level of functionality is too high for this crate.

[RossComputerGuy]

Done

[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.