OvmfPkg/QemuVideoDxe: Zero out PixelInformation in QueryMode Ensure that the PixelInformation field of the EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is PixelBlueGreenRedReserved8BitPerColor. According to UEFI 2.9 Section 12.9, PixelInformation field of the EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if PixelFormat is PixelBitMask. This means that firmware is not required to fill out the PixelInformation field for other PixelFormat types, which implies that the QemuVideoDxe implementation is technically correct. However, not zeroing out those fields will leak the contents of the memory returned by the memory allocator, so it is better to explicitly set them to zero. In addition, the SCT test suite relies on PixelInformation always having a consistent value, which causes failures. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
OvmfPkg/QemuVideoDxe: simplify InitializeBochsGraphicsMode struct QEMU_VIDEO_MODE_DATA has all the data needed to set the video mode, there is no need to take the extra indirection and use struct QEMU_VIDEO_BOCHS_MODES. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
OvmfPkg: Apply uncrustify changes REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
OvmfPkg: Change OPTIONAL keyword usage style REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760 Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ ones Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: Replace BSD License with BSD+Patent License https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: simply use the Bochs interface for vmsvga BAR | std vga | vmsvga --------------------------------- 0 | Framebuffer | I/O space 1 | Reserved | Framebuffer 2 | MMIO | FIFO - We cannot recognize VMW SVGA as BOCHS because that would confuse the IsQxl setting in QemuVideoControllerDriverStart(), - We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA is not the BOCHS MMIO BAR (we can only use port IO). Therefore the list of reasons for which we should introduce QEMU_VIDEO_VMWARE_SVGA should name three reasons: (1) Get framebuffer from correct PCI BAR (2) Prevent using BAR2 for MMIO (3) Prevent mis-recognizing VMW SVGA as QXL Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2. The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU -- falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA FIFO. To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA FIFO setup feature. It means our current VMW SVGA driver code is basically dead. To simplify the problem, we will replace the old VMWare SVGA driver to Bochs interface. It should work on all QEMU version. The first step for using Bochs interface is to revert old driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 98856a724c2acdc0094220d4de615a557dad0f88) Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reapply "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" This reverts commit 98856a724c2acdc0094220d4de615a557dad0f88, reapplying c137d95081690d4877fbeb5f1856972e84ac32f2. Note that the commit now being reverted is technically correct; the only reason we're reverting it is because it should not have been pushed past the Soft Feature Freeze for the edk2-stable201811 tag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: yuchenlin <yuchenlin@synology.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: yuchenlin <yuchenlin@synology.com>
Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2. The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU -- falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA FIFO. To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA FIFO setup feature. It means our current VMW SVGA driver code is basically dead. To simplify the problem, we will replace the old VMWare SVGA driver to Bochs interface. It should work on all QEMU version. The first step for using Bochs interface is to revert old driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg/QemuVideoDxe: round up FrameBufferSize to full page Guests do the same, because the framebuffer is mapped somewhere, which obviously works with page granularity only. When not rounding up to full page size we get messages like this one (linux kernel): efifb: framebuffer at 0x80000000, using 1876k, total 1875k ^^^^^ ^^^^^ Also sysfb is confused and throws an error: sysfb: VRAM smaller than advertised Cc: Phil Dennis-Jordan <phil@philjordan.eu> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix coding style]
OvmfPkg/QemuVideoDxe: handle invalid BltOperation gracefully According to the UEFI spec, EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is supposed to catch an invalid BltOperation, and report it with EFI_INVALID_PARAMETER. Remove the assertion from QemuVideoGraphicsOutputBlt() that prevents this from working in NOOPT and DEBUG builds. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Rocky <xingrong.ni@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Reported-by: Rocky <xingrong.ni@intel.com> Analyzed-by: Ruiyu Ni <ruiyu.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=897 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
OvmfPkg/Gop: clear the screen to black in SetMode() Today's implementation forgot to clear the screen to black in SetMode(). It causes SCT SetMode() test fails. The patch adds the clear screen operation in SetMode() to fix the SCT failure. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
OvmfPkg/QemuVideoDxe: VMWare SVGA device support In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements a basic version of VMWare's SVGA display device. Drivers for this device exist for some guest OSes which do not support Qemu's other display adapters, so supporting it in OVMF is useful in conjunction with those OSes. This change adds support for the SVGA device's framebuffer to QemuVideoDxe's graphics output protocol implementation, based on VMWare's documentation. The most basic initialisation, framebuffer layout query, and mode setting operations are implemented. The device relies on port-based 32-bit I/O, unfortunately on misaligned addresses. This limits the driver's support to the x86 family of platforms. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg/QemuVideoDxe: Frame buffer config size may change in new mode https://bugzilla.tianocore.org/show_bug.cgi?id=339 The patch removes the assumption in QemuVideoDxe driver that it wrongly assumes the frame buffer configure size is the same in different video modes. The assumption is true in old FrameBufferBltLib but is false in new implementation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg/QemuVideoDxe: remove useless QEMU_VIDEO_PRIVATE_DATA.LineBuffer This field is (re)allocated in QemuVideoGraphicsOutputSetMode(), released in QemuVideoGraphicsOutputDestructor(), and used for nothing else. Remove it. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: fix conversion specifiers in DEBUG format strings Cc: Scott Duplichan <scott@notabs.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18095 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuVideoDxe: clarify QEMU_VIDEO_MODE_DATA.ModeNumber The field name "ModeNumber" in QEMU_VIDEO_MODE_DATA is misleading -- it is not immediately obvious whether this field carries a client-visible mode number, in the GOP sense, or an internal, card type specific mode index. After checking all references, rename the field to "InternalModeIndex". Also, when filling in the card type independent QEMU_VIDEO_MODE_DATA array from the card type specific mode array, distinguish the GOP mode number from the internal mode index in the debug message. This patch effects no functional changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15287 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuVideoDxe: eliminate useless Private->HardwareNeedsStarting Currently, QemuVideoGraphicsOutputQueryMode() reports EFI_NOT_STARTED when this boolean field is set. However, QemuVideoGraphicsOutputQueryMode() is only available to callers after the GOP interface has been installed. That in turn implies that the following partial call tree has succeeded without errors: QemuVideoControllerDriverStart() QemuVideoGraphicsOutputConstructor() QemuVideoGraphicsOutputSetMode(... 0 ...) HardwareNeedsStarting = FALSE InstallMultipleProtocolInterfaces(... GOP ...) That is, when QemuVideoGraphicsOutputQueryMode() is reached, HardwareNeedsStarting is always FALSE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15286 6f19259b-4bc3-4df7-8a09-765794883524