From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>, edk2-devel@lists.01.org
Subject: Re: [PATCH 3/4] OvmfPkg: add QemuRamfb to platform console
Date: Mon, 11 Jun 2018 18:24:35 +0200 [thread overview]
Message-ID: <aec79a27-56a5-34f7-2439-fbb3f80fa0c5@redhat.com> (raw)
In-Reply-To: <20180608113942.17009-4-kraxel@redhat.com>
On 06/08/18 13:39, Gerd Hoffmann wrote:
> Add QemuRamfbDxe device path to the list of platform console devices,
> so ConSplitter will pick up the device even though it isn't a PCI GPU.
This explanation is not wrong, but I'll list more details, just in case.
By adding the devpath to "gPlatformConsole" with CONSOLE_OUT,
technically we push the devpath into the ConOut UEFI variable, as
follows:
BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBootManagerBeforeConsole() [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
PlatformInitializeConsole() [OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c]
EfiBootManagerUpdateConsoleVariable() [MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]
After this, BdsEntry goes on to actually connect the device (i.e., it
makes the QemuRamfbDxe driver bind the device):
BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
EfiBootManagerConnectAllDefaultConsoles() [MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c]
Binding drivers to keyboard, serial and graphics devices, so that text
input, text output, and graphics output protocols are produced, isn't
per se sufficient for ConSplitterDxe to multiplex to/from those
protocols. For that, ConPlatformDxe needs to "tag" the handles with
EfiConsole(In|Out)DeviceGuid|EfiStandardErrorDeviceGuid --
ConSplitterDxe depends on those protocols. It's ConPlatformDxe that
needs the devpath to be in ConIn/ConOut/ErrOut, for the "tagging" to
occur.
In total, we add the ramfb devpath to "gPlatformConsole" so that our
PlatformInitializeConsole() function puts it in ConOut, despite ramfb
not being a PCI display device. Binding the device to QemuRamFbDxe, and
multiplexing from/to it happen "automatically" from there, thanks to
BdsDxe, and ConPlatformDxe/ConSplitterDxe respectively.
(1) I don't mind if you stick with the current commit message; I just
wanted to provide more details for this discussion.
More comments below:
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> .../Library/PlatformBootManagerLib/PlatformData.c | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> index a50cd7bcaf..6202516971 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
> @@ -14,6 +14,7 @@
> **/
>
> #include "BdsPlatform.h"
> +#include <Guid/QemuRamfb.h>
>
> //
> // Debug Agent UART Device Path structure
> @@ -37,6 +38,17 @@ typedef struct {
> } USB_KEYBOARD_DEVICE_PATH;
> #pragma pack ()
>
> +//
> +// QemuRamfb Device Path structure
> +//
> +#pragma pack(1)
> +typedef struct {
> + VENDOR_DEVICE_PATH Vendor;
> + ACPI_ADR_DEVICE_PATH AcpiAdr;
> + EFI_DEVICE_PATH_PROTOCOL End;
> +} VENDOR_RAMFB_DEVICE_PATH;
> +#pragma pack()
(2) Please add a space character between each "pack" and "(".
> +
> ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard;
> ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort;
> UART_DEVICE_PATH gUartDeviceNode = gUart;
> @@ -100,6 +112,34 @@ STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = {
> gEndEntire
> };
>
> +STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = {
> + {
> + {
> + HARDWARE_DEVICE_PATH,
> + HW_VENDOR_DP,
> + {
> + (UINT8) (sizeof (VENDOR_DEVICE_PATH)),
> + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> + }
> + },
> + QEMU_RAMFB_GUID,
> + },
> + {
> + {
> + ACPI_DEVICE_PATH,
> + ACPI_ADR_DP,
> + {
> + (UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)),
> + (UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8)
> + }
> + },
> + ACPI_DISPLAY_ADR (1, 0, 0, 1, 0,
> + ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL,
> + 0, 0)
(3) Urgh. On one hand, I dislike this dump of constants; on the other
hand, I don't want to ask you to repeat all the parameter comments that
I asked for in the previous patch.
OK, let's stick with the dump of constants, just make sure the
indentation is idiomatic.
> + },
> + gEndEntire
> +};
> +
> //
> // Predefined platform default console device path
> //
> @@ -113,6 +153,10 @@ PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = {
> CONSOLE_IN
> },
> {
> + (EFI_DEVICE_PATH_PROTOCOL *)&gQemuRamfbDevicePath,
> + CONSOLE_OUT
> + },
Right, this is consistent with PreparePciDisplayDevicePath().
Thanks,
Laszlo
> + {
> NULL,
> 0
> }
>
next prev parent reply other threads:[~2018-06-11 16:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-08 11:39 [PATCH 0/4] Add QemuRamfbDxe driver Gerd Hoffmann
2018-06-08 11:39 ` [PATCH 1/4] OvmfPkg: add QEMU_RAMFB_GUID Gerd Hoffmann
2018-06-11 13:06 ` Laszlo Ersek
2018-06-08 11:39 ` [PATCH 2/4] OvmfPkg: add QemuRamfbDxe Gerd Hoffmann
2018-06-10 5:57 ` Ard Biesheuvel
2018-06-11 15:56 ` Laszlo Ersek
2018-06-12 9:15 ` Gerd Hoffmann
2018-06-12 13:01 ` Laszlo Ersek
2018-06-08 11:39 ` [PATCH 3/4] OvmfPkg: add QemuRamfb to platform console Gerd Hoffmann
2018-06-11 16:24 ` Laszlo Ersek [this message]
2018-06-11 16:58 ` Laszlo Ersek
2018-06-08 11:39 ` [PATCH 4/4] ArmVirtPkg: add QemuRamfbDxe Gerd Hoffmann
2018-06-11 16:29 ` Laszlo Ersek
2018-06-11 16:35 ` [PATCH 0/4] Add QemuRamfbDxe driver Laszlo Ersek
2018-06-12 9:21 ` Gerd Hoffmann
2018-06-12 12:53 ` Laszlo Ersek
2018-06-13 7:40 ` Gerd Hoffmann
2018-06-13 16:16 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aec79a27-56a5-34f7-2439-fbb3f80fa0c5@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox