qemu/include/hw/display/ramfb.h

#ifndef RAMFB_H
#define RAMFB_H

/* ramfb.c */
typedef struct RAMFBState RAMFBState;
void ramfb_display_update(QemuConsole *con, RAMFBState *s);
RAMFBState *ramfb_setup(DeviceState *dev, Error **errp);

/* ramfb-standalone.c */
#define TYPE_RAMFB_DEVICE "ramfb"

#endif /* RAMFB_H */
hw/display: add ramfb, a simple boot framebuffer living in guest ram The boot framebuffer is expected to be configured by the firmware, so it uses fw_cfg as interface. Initialization goes as follows: (1) Check whenever etc/ramfb is present. (2) Allocate framebuffer from RAM. (3) Fill struct RAMFBCfg, write it to etc/ramfb. Done. You can write stuff to the framebuffer now, and it should appear automagically on the screen. Note that this isn't very efficient because it does a full display update on each refresh. No dirty tracking. Dirty tracking would have to be active for the whole ram slot, so that wouldn't be very efficient either. For a boot display which is active for a short time only this isn't a big deal. As permanent guest display something better should be used (if possible). This is the ramfb core code. Some windup is needed for display devices which want have a ramfb boot display. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180613122948.18149-2-kraxel@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 2018-06-13 15:29:45 +03:00			`#ifndef RAMFB_H`
			`#define RAMFB_H`

			`/* ramfb.c */`
			`typedef struct RAMFBState RAMFBState;`
			`void ramfb_display_update(QemuConsole con, RAMFBState s);`
hw/display/ramfb: initialize fw-config space with xres/ yres If xres / yres were specified in QEMU command line, write them as an initial resolution to the fw-config space on guest reset, which a later BIOS / OVMF patch can take advantage of. Signed-off-by: HOU Qiming <hqm03ster@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-id: 20190513115731.17588-4-marcel.apfelbaum@gmail.com [fixed malformed patch] Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 2019-05-13 14:57:31 +03:00			`RAMFBState ramfb_setup(DeviceState dev, Error **errp);`
hw/display: add ramfb, a simple boot framebuffer living in guest ram The boot framebuffer is expected to be configured by the firmware, so it uses fw_cfg as interface. Initialization goes as follows: (1) Check whenever etc/ramfb is present. (2) Allocate framebuffer from RAM. (3) Fill struct RAMFBCfg, write it to etc/ramfb. Done. You can write stuff to the framebuffer now, and it should appear automagically on the screen. Note that this isn't very efficient because it does a full display update on each refresh. No dirty tracking. Dirty tracking would have to be active for the whole ram slot, so that wouldn't be very efficient either. For a boot display which is active for a short time only this isn't a big deal. As permanent guest display something better should be used (if possible). This is the ramfb core code. Some windup is needed for display devices which want have a ramfb boot display. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180613122948.18149-2-kraxel@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 2018-06-13 15:29:45 +03:00
hw/display: add standalone ramfb device Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180613122948.18149-3-kraxel@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 2018-06-13 15:29:46 +03:00			`/* ramfb-standalone.c */`
			`#define TYPE_RAMFB_DEVICE "ramfb"`

hw/display: add ramfb, a simple boot framebuffer living in guest ram The boot framebuffer is expected to be configured by the firmware, so it uses fw_cfg as interface. Initialization goes as follows: (1) Check whenever etc/ramfb is present. (2) Allocate framebuffer from RAM. (3) Fill struct RAMFBCfg, write it to etc/ramfb. Done. You can write stuff to the framebuffer now, and it should appear automagically on the screen. Note that this isn't very efficient because it does a full display update on each refresh. No dirty tracking. Dirty tracking would have to be active for the whole ram slot, so that wouldn't be very efficient either. For a boot display which is active for a short time only this isn't a big deal. As permanent guest display something better should be used (if possible). This is the ramfb core code. Some windup is needed for display devices which want have a ramfb boot display. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180613122948.18149-2-kraxel@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 2018-06-13 15:29:45 +03:00			`#endif /* RAMFB_H */`