diff options
author | Gerd Hoffmann | 2018-06-13 14:29:45 +0200 |
---|---|---|
committer | Gerd Hoffmann | 2018-06-18 11:22:15 +0200 |
commit | 995b30179bdc97a01ff2e4e0dce07f3e9b7d7d7d (patch) | |
tree | 468a74359814e0efb133d46a1d2943bd7ff0163a /hw/display/ramfb-standalone.c | |
parent | configure: print virglrenderer version (diff) | |
download | qemu-995b30179bdc97a01ff2e4e0dce07f3e9b7d7d7d.tar.gz qemu-995b30179bdc97a01ff2e4e0dce07f3e9b7d7d7d.tar.xz qemu-995b30179bdc97a01ff2e4e0dce07f3e9b7d7d7d.zip |
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>
Diffstat (limited to 'hw/display/ramfb-standalone.c')
0 files changed, 0 insertions, 0 deletions