Allow use of `FrameBufferInfo` as a compositing template

[kennystrawnmusic]

In order to allow things like compositing, for instance, in kernel mode, the framebuffer must be capable of being duplicated in some way. For example, something like the following is not possible in the current state:

pub static COMPOSITING_TABLE: Mutex<Vec<FrameBuffer>> = Mutex::new(Vec::new());
// use embedded_graphics to render entries in multiple distinct buffers stored in this Vec and render them all on top of one another

So I'm submitting this PR to allow one to use a given FrameBufferInfo struct to allow kernel developers to create a new FrameBuffer using the data from the one already present, so said developers can then decorate their own framebuffer copies and merge them down. Should make compositing support on the kernel end that much easier to implement.

[phil-opp]

Thanks for the PR! I'm not sure if we should support features like this. The main purpose of the boot information is to get the information from the bootloader to the kernel. For advanced use cases, it is recommended to transform that information into kernel-specific types.

Is there any reason against using your own frame buffer type in your case? From a quick look, it seems like you could get a &'static mut [u8] (and thus a *mut u8 pointer) and the FrameBufferInfo via the info()/buffer_mut() methods and then init your custom framebuffer struct with it?

[kennystrawnmusic]

Thanks for the PR! I'm not sure if we should support features like this. The main purpose of the boot information is to get the information from the bootloader to the kernel. For advanced use cases, it is recommended to transform that information into kernel-specific types.

Is there any reason against using your own frame buffer type in your case? From a quick look, it seems like you could get a &'static mut [u8] (and thus a *mut u8 pointer) and the FrameBufferInfo via the info()/buffer_mut() methods and then init your custom framebuffer struct with it?

Good point. I'll try that, but that would require refactoring things like the printk crate to allow such.

Sorry for the late reply; been very busy this week.