From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by mx.groups.io with SMTP id smtpd.web11.2249.1587541987810454680 for ; Wed, 22 Apr 2020 00:53:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tL8ZriwB; spf=pass (domain: gmail.com, ip: 209.85.222.177, mailfrom: hqm03ster@gmail.com) Received: by mail-qk1-f177.google.com with SMTP id s63so1497308qke.4; Wed, 22 Apr 2020 00:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fYeL9vUWeChobEKoh6rG429sf9VPqrXbw/mMaENVjmg=; b=tL8ZriwBDCdUqaABNUofVRwE8aHc3cNNOXd1pFoyC3MdEg5abt5q7lST1v6qh/XNBS uUKFqUIQp47kzmQHmPand/Pt8D05kK4m8NdTjdxCN1MZEsyTv/EWT7a1OS7w1YuK6I7u 1BocZk5XcVM7BfVPDgOZt2uW1wKGwRfYtc0keZOZ7ZqH22+tvDgqZrExUwJwtYnTyEH1 MFpoDCyqkkbf70Y3/Ot+CHTt5jIOtrg5UC3waWNJdp6PAFn+usHIyS5c5awG+/eYvy7j AYpQo/VGRib17Sk0h17UW6fe8wCs2ZZZHwQkbp7Wt/9tCCCQDLUXRdv/29innhnVsxZK f9VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fYeL9vUWeChobEKoh6rG429sf9VPqrXbw/mMaENVjmg=; b=sXejhcr1DDDkrO4oNU6gTuQf1qj1I6Q+fRiDTspZFcKDYD0LdPMwe9wrwzBVN4npeK 752xuRCDKwLXIqi3Q8ZKXiUhKdGrdS9JFzVCMy+QBB5gQkGs5H1b7hWpi23t1O6HGk7Q 0e1MNS0dYzWg9I34kJQS3sDhht/5dTFwB3A4gXM+jXMOvNxI2gYE/zhan9aijoGvMnlX bp8RR75HvKCMs98M1FNQyC6hEE8pxLaXsDTVX0d6ZqmOJJR8F4VHUl+WYRYAdFDeg2v6 gxTX9pbjlt4VT6xF4DF5RsMwOLqcpRe+XC/U1C1dwbBy334mn+FKvTLvHkEWqeTEgNsr 1WJg== X-Gm-Message-State: AGi0PubLGhhqhCp6HUTphq6OMacdRn/ihb+vPYb2fR3MI8H30ILuzs2u IKIvu6Ok+gYnAJR35FsGgHsLmaXR5l0wOHfMdaI= X-Google-Smtp-Source: APiQypJdDamshdABJXoB5xF+xPVeUfJGOGvJUQ98JtH4ACzANIdBsyDAV+qBbx4zwFklVRCSbAVSiGyV9RwcEXEassc= X-Received: by 2002:a05:620a:22b1:: with SMTP id p17mr25349293qkh.249.1587541986972; Wed, 22 Apr 2020 00:53:06 -0700 (PDT) MIME-Version: 1.0 References: <623b1855-285c-cce3-c806-c17e5fd217ea@redhat.com> <5211.1586899245384995995@groups.io> <20200420141303.dxjqgvmzglrjtsly@sirius.home.kraxel.org> <9aed493a-2187-cacd-5631-54fb9973509c@redhat.com> In-Reply-To: <9aed493a-2187-cacd-5631-54fb9973509c@redhat.com> From: Hou Qiming Date: Wed, 22 Apr 2020 15:42:34 +0800 Message-ID: Subject: Re: [edk2-discuss] Load Option passing. Either bugs or my confusion. To: Laszlo Ersek Cc: Gerd Hoffmann , valerij zaporogeci , discuss@edk2.groups.io, "Marcel Apfelbaum (GMail address)" , edk2-devel-groups-io , qemu devel list Content-Type: multipart/alternative; boundary="0000000000003319d205a3dc6c48" --0000000000003319d205a3dc6c48 Content-Type: text/plain; charset="UTF-8" A little off topic thing: isn't the default resolution supposed to be 1024x768? This is the Microsoft regulation which all my physical devices seem to follow: https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/6afc8979-df62-4d86-8f6a-99f05bbdc7f3 And when the user provides an EDID one should parse it and set the default resolution to match it. But that's a less important feature. On Tue, Apr 21, 2020 at 9:03 PM Laszlo Ersek wrote: > On 04/20/20 16:13, Gerd Hoffmann wrote: > > Hi, > > > >> So I would say that the symptom you see is a QEMU v4.1.0 regression. > >> The QemuRamfbGraphicsOutputSetMode() function in the OVMF ramfb > >> driver certainly needs the QemuFwCfgWriteBytes() call to work, for > >> changing the resolution. > > > > Oh? QemuRamfbGraphicsOutputSetMode() can be called multiple times? > > How does that happen? > > QemuRamfbGraphicsOutputSetMode() is the "SetMode" member function of the > EFI_GRAPHICS_OUTPUT_PROTOCOL instance that QemuRamfbDxe produces. > > This is a standard protocol; UEFI drivers and applications are free to > locate it and to use it. > > (1) When you launch OVMF, you get the splash screen in a particular > resolution. This resolution: > - is configured by OvmfPkg/PlatformDxe, > - is inherited by an OS boot loader, > - is reconfigurable with OvmfPkg/PlatformDxe, for the next boot, via the > Setup TUI, > - defaults to 800x600 (taking effect when no particular choice is > configured). > > (2) UiApp -- the Setup TUI itself -- uses its own resolution. Under > OVMF, this resolution is fixed 640x480. When UiApp is entered, > ultimately a call is made to QemuRamfbGraphicsOutputSetMode() -- i.e., a > GOP.SetMode() member function -- for setting this 640x480 resolution. > > Using the following command: > > qemu-system-x86_64 \ > -nodefaults \ > -boot menu=on,splash-time=5000 \ > -enable-kvm \ > -device ramfb \ > -drive > if=pflash,readonly,format=raw,file=$PREFIX/share/qemu/edk2-x86_64-code.fd \ > -drive > if=pflash,snapshot,format=raw,file=$PREFIX/share/qemu/edk2-i386-vars.fd \ > -debugcon file:ovmf.log \ > -global isa-debugcon.iobase=0x402 > > when you first see the progress bar, the graphical resolution (1) is > 800x600. Accordingly, QEMU prints to stderr: > > > ramfb_fw_cfg_write: 800x600 @ 0x6702000 > > Once you hit ESC to interrupt the progress bar and to enter the Setup > TUI, UiApp switches to resolution (2), 640x480. QEMU prints: > > > ramfb_fw_cfg_write: 640x480 @ 0x6702000 > > ramfb_fw_cfg_write: resolution locked, change rejected > > And you get garbage in the Setup window. > > Thanks, > Laszlo > > --0000000000003319d205a3dc6c48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A little off topic thing: isn't the default resol= ution supposed to be 1024x768? This is the Microsoft regulation which all m= y physical devices seem to follow:

And when the user provides an EDID one should parse it and set= the default resolution to match it. But that's a less important featur= e.


On Tue, Apr 21, 2020 at 9:03 PM Laszlo Ersek <= ;lersek@redhat.com> wrote:
<= /div>
On 04/20/20 16:13, G= erd Hoffmann wrote:
>=C2=A0 =C2=A0Hi,
>
>> So I would say that the symptom you see is a QEMU v4.1.0 regressio= n.
>> The QemuRamfbGraphicsOutputSetMode() function in the OVMF ramfb >> driver certainly needs the QemuFwCfgWriteBytes() call to work, for=
>> changing the resolution.
>
> Oh?=C2=A0 QemuRamfbGraphicsOutputSetMode() can be called multiple time= s?
> How does that happen?

QemuRamfbGraphicsOutputSetMode() is the "SetMode" member function= of the
EFI_GRAPHICS_OUTPUT_PROTOCOL instance that QemuRamfbDxe produces.

This is a standard protocol; UEFI drivers and applications are free to
locate it and to use it.

(1) When you launch OVMF, you get the splash screen in a particular
resolution. This resolution:
- is configured by OvmfPkg/PlatformDxe,
- is inherited by an OS boot loader,
- is reconfigurable with OvmfPkg/PlatformDxe, for the next boot, via the =C2=A0 Setup TUI,
- defaults to 800x600 (taking effect when no particular choice is
=C2=A0 configured).

(2) UiApp -- the Setup TUI itself -- uses its own resolution. Under
OVMF, this resolution is fixed 640x480. When UiApp is entered,
ultimately a call is made to QemuRamfbGraphicsOutputSetMode() -- i.e., a GOP.SetMode() member function -- for setting this 640x480 resolution.

Using the following command:

=C2=A0 qemu-system-x86_64 \
=C2=A0 =C2=A0 -nodefaults \
=C2=A0 =C2=A0 -boot menu=3Don,splash-time=3D5000 \
=C2=A0 =C2=A0 -enable-kvm \
=C2=A0 =C2=A0 -device ramfb \
=C2=A0 =C2=A0 -drive if=3Dpflash,readonly,format=3Draw,file=3D$PREFIX/share= /qemu/edk2-x86_64-code.fd \
=C2=A0 =C2=A0 -drive if=3Dpflash,snapshot,format=3Draw,file=3D$PREFIX/share= /qemu/edk2-i386-vars.fd \
=C2=A0 =C2=A0 -debugcon file:ovmf.log \
=C2=A0 =C2=A0 -global isa-debugcon.iobase=3D0x402

when you first see the progress bar, the graphical resolution (1) is
800x600. Accordingly, QEMU prints to stderr:

> ramfb_fw_cfg_write: 800x600 @ 0x6702000

Once you hit ESC to interrupt the progress bar and to enter the Setup
TUI, UiApp switches to resolution (2), 640x480. QEMU prints:

> ramfb_fw_cfg_write: 640x480 @ 0x6702000
> ramfb_fw_cfg_write: resolution locked, change rejected

And you get garbage in the Setup window.

Thanks,
Laszlo

--0000000000003319d205a3dc6c48--