Commit Graph

12 Commits

Author SHA1 Message Date
Laszlo Ersek b1bc305cf4 OvmfPkg/QemuVideoDxe: rebase to ARRAY_SIZE()
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>
2016-10-27 11:10:59 +02:00
Laszlo Ersek 4dd8787a20 OvmfPkg/QemuVideoDxe: upgrade VERBOSE debug messages to INFO
In commit 5b2291f956 ("OvmfPkg: QemuVideoDxe uses
MdeModulePkg/FrameBufferLib"), QemuVideoDxe was rebased to
FrameBufferBltLib.

The FrameBufferBltLib instance added in commit b1ca386074
("MdeModulePkg: Add FrameBufferBltLib library instance") logs many
messages on the VERBOSE level; for example, a normal boot with OVMF can
produce 500+ "VideoFill" messages, dependent on the progress bar, when the
VERBOSE bit is set in PcdDebugPrintErrorLevel. While FrameBufferBltLib is
certainly allowed to log such messages on the VERBOSE level, we should
separate those frequent messages from the (infrequent) ones produced by
QemuVideoDxe itself.

QemuVideoDxe logs VERBOSE messages in three locations (in two functions)
at the moment. All of them are infrequent: both QemuVideoBochsModeSetup()
and InstallVbeShim() are called from QemuVideoControllerDriverStart(),
that is, when a device is bound. Upgrade these messages to INFO level, so
that VERBOSE can be disabled in PcdDebugPrintErrorLevel -- perhaps
selectively for OvmfPkg/QemuVideoDxe -- without hiding these infrequent
messages.

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>
2016-10-16 21:42:47 +02:00
Laszlo Ersek 9ebb7ce8dd OvmfPkg/QemuVideoDxe: drop QEMU_VIDEO_CIRRUS_MODES.RefreshRate
Thanks to the previous patch, this field is also unnecessary now. Remove
it.

The patch is best reviewed with "git show --word-diff".

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>
2016-10-16 21:42:29 +02:00
Laszlo Ersek 0ccc97e9c8 OvmfPkg/QemuVideoDxe: drop useless QEMU_VIDEO_MODE_DATA.RefreshRate
This field is never used beyond assignment and debug-logging. 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>
2016-10-16 21:42:16 +02:00
Laszlo Ersek b37bcfd6bd OvmfPkg: QemuVideoDxe: work around misreported QXL framebuffer size
When setting up the list of GOP modes offered on QEMU's stdvga ("VGA") and
QXL ("qxl-vga") video devices, QemuVideoBochsModeSetup() filters those
modes against the available framebuffer size. (Refer to SVN r15288 / git
commit ec88061e.)

The VBE_DISPI_INDEX_VIDEO_MEMORY_64K register of both stdvga and QXL is
supposed to report the size of the drawable, VGA-compatibility
framebuffer. Instead, up to and including qemu-2.1, this register actually
reports the full video RAM (PCI BAR 0) size.

In case of stdvga, this happens to be correct, because on that card the
full PCI BAR 0 is usable for drawing; there is no difference between
"drawable framebuffer size" and "video RAM (PCI BAR 0) size".

However, on the QXL card, only an initial portion of the video RAM is
suitable for drawing, as compatibility framebuffer; and the value
currently reported by VBE_DISPI_INDEX_VIDEO_MEMORY_64K overshoots the
valid size. Beyond the drawable range, the video RAM contains buffers and
structures for the QXL guest-host protocol.

Luckily, the size of the drawable QXL framebuffer can also be read from a
register in the QXL ROM BAR (PCI BAR 2), so let's retrieve it from there.

Without this fix, OVMF offers too large resolutions on the QXL card (up to
the full size of the video RAM). If a GOP client selects such a resolution
and draws into the video RAM past the compatibility segment, then the
guest corrupts its communication structures (which is invalid guest
behavior).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15978 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-29 17:27:20 +00:00
Laszlo Ersek bb97e78852 OvmfPkg: QemuVideoDxe: add further BOCHS modes
This brings the list of BOCHS video modes to par with the QEMU QXL
implementation.

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@15289 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03 08:41:15 +00:00
Laszlo Ersek ec88061ec8 OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer size
In the next patch we'll add many new BOCHS modes, some of which require
large frame buffers.

The size of the QXL VGA compatibility framebuffer can be changed with the

  -global qxl-vga.vgamem_mb=$NUM_MB

QEMU option.

If $NUM_MB would exceed 32, then the following two QEMU options are
necessary instead:

  -global qxl-vga.vgamem_mb=$NUM_MB         \
  -global qxl-vga.ram_size_mb=$((NUM_MB*2))

because the compatibility framebuffer can't cover more than half of PCI
BAR #0. The latter defaults to 64MB in size, and is controlled by
"ram_size_mb".

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@15288 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03 08:41:08 +00:00
Laszlo Ersek cd15261014 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
2014-03-03 08:40:59 +00:00
Laszlo Ersek d89186bc86 OvmfPkg: QemuVideoDxe: tidy up error checking/handling in & under Start()
In QemuVideoControllerDriverStart():
- remove redundant zero-initialization of:
  - Private->Handle (2 locations)
  - Private->GopDevicePath (when at devpath end)

- remove fields used for error handling only:
  - PciAttributesSaved

- tigthen scope of temporaries:
  - MmioDesc
  - AcpiDeviceNode

- supplement missing error checks:
  - AppendDevicePathNode() can fail with out-of-memory (2 locations)
  - when installing GopDevicePath
  - retval of QemuVideoGraphicsOutputConstructor() (can justifiedly fail
    with out-of-resources)

- plug leaks on error:
  - free GopDevicePath (AppendDevicePathNode() allocates dynamically)
  - uninstall GopDevicePath
  - free Private->ModeData
  - call QemuVideoGraphicsOutputDestructor()
  - uninstall GOP

In QemuVideoGraphicsOutputConstructor(), called by Start():
- supplement missing error checks:
  - QemuVideoGraphicsOutputSetMode() retval (it can fail with
    out-of-resources)

- plug leaks on error:
  - free Mode->Info
  - free Mode

In QemuVideoCirrusModeSetup() and QemuVideoBochsModeSetup(), both called
by Start():
- supplement missing error checks:
  - AllocatePool() can fail in both

In QemuVideoGraphicsOutputDestructor(), called by Start() on the error
path:
- plug leaks:
  - free Private->LineBuffer, which is allocated in
    Start() -> Constructor() -> SetMode()

In QemuVideoGraphicsOutputSetMode(), called by Start() indirectly:
- remove redundant zero-assignment to:
  - Private->LineBuffer

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@15282 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03 08:40:19 +00:00
jljusten 54f9b9accb QemuVideo: Add support for the bochs dispi interface
Add code to handle qemu-emulated vga cards supporting the bochs dispi
interface (standard vga, qxl vga).  This requires qemu 1.3+ which
provides the bochs dispi interface data register on a aligned io
address.  See
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=df9ffb726ff13f850b8829be1bc85ed621b903ac

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13968 6f19259b-4bc3-4df7-8a09-765794883524
2012-11-27 19:11:29 +00:00
jljusten 212aac55fd QemuVideo: prepare to support more hardware
Move to a table-driven hardware detection.  Add a table with PCI IDs,
card name and variant enum.  Use the table for hardware detection and
initialization.  Rename Cirrus-specific data and code to carry "cirrus"
in the name.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13967 6f19259b-4bc3-4df7-8a09-765794883524
2012-11-27 19:11:11 +00:00
jljusten eaf4f336ea OvmfPkg: Add QemuVideoDxe driver
This driver provides a UEFI Graphics Output Protocol (GOP) driver
for the QEMU Cirrus VGA hardware.  It enables 24-bit color,
and uses the standard 32-bit GOP pixel format whenever possible.

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11524 6f19259b-4bc3-4df7-8a09-765794883524
2011-04-12 15:08:51 +00:00