Hi Zhichao,
On 04/13/19 09:52, Gao, Zhichao wrote:
>
>
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:[email protected]]
>> Sent: Friday, April 12, 2019 4:06 PM
>> To: [email protected]; Gao, Zhichao <[email protected]>
>> Cc: Wang, Jian J <[email protected]>; Wu, Hao A <[email protected]>;
>> Ni, Ray <[email protected]>; Zeng, Star <[email protected]>; Gao, Liming
>> <[email protected]>; Sean Brogan <[email protected]>;
>> Michael Turner <[email protected]>; Bret Barkelew
>> <[email protected]>
>> Subject: Re: [edk2-devel] [PATCH 0/2] MdeModulePkg: Make the screen
>> seamless
>>
>> On 04/12/19 05:14, Gao, Zhichao wrote:
>>> For now most platforms support display function at PEI phase.
>>> But the conspliter and graphics console driver would clear the screen
>>> at BDS connect console phase. Maybe some platforms would show logo in
>>> the next or maybe not. For consumers, it looks like the screen
>>> flashed.
>>> So change the behavior of graphics console devices while connect
>>> console devices to maintain seamless screen from PEI.
>>>
>>> Test has done on MinPlatform Kabylake-RVP3 which support PEI display.
>>>
>>> Cc: Jian J Wang <[email protected]>
>>> Cc: Hao Wu <[email protected]>
>>> Cc: Ray Ni <[email protected]>
>>> Cc: Star Zeng <[email protected]>
>>> Cc: Liming Gao <[email protected]>
>>> Cc: Sean Brogan <[email protected]>
>>> Cc: Michael Turner <[email protected]>
>>> Cc: Bret Barkelew <[email protected]>
>>>
>>> Aaron Antone (2):
>>> MdeModulePkg/ConSplitterDxe: Optimize the
>> ConSplitterTextOutSetMode
>>> MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen
>>>
>>> .../Console/ConSplitterDxe/ConSplitter.c | 34 +++++++++-----
>>> .../Console/ConSplitterDxe/ConSplitter.h | 4 +-
>>> .../GraphicsConsoleDxe/GraphicsConsole.c | 45 +++++++++----------
>>> 3 files changed, 48 insertions(+), 35 deletions(-)
>>>
>>
>> EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() is specified to clear the
>> screen to black. Is this series compatible with that?
>
> No. We only consider the console section.
You answered my question
"is this compatible with...?"
with "no", so I first thought you meant, "no, this series is
incompatible with the EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode()
specification".
But reading the rest of your reply, I think your answer is,
"EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() is not affected by this series".
Can you confirm that?
Because, I think I'd agree with that. This series modifies two drivers,
and from those, only ConSplitterDxe *produces* a GOP. Therefore my
original question is relevant only for patch#1 (which is the one
modifying ConSplitterDxe).
And in patch #1, indeed it looks like we don't touch the GOP.
(I guess this is also what you mean by "console section" -- that is, the
text console functionality.)
The rest of the discussion refers to patch #2 / GraphicsConsoleDxe:
> There are two pcds to control the graphics output mode
> PcdVideoHorizontalResolution and PcdVideoVerticalResolution. Usually
> we set them as zero to make the mode to be the max mode the graphics
> supported and the graphics output protocol would initialize the mode
> to be the max mode in general. If so the SetMode would not be runt.
> But that is done in the graphics output driver and the driver is
> usually a binary file. So we can't desire that the graphics driver
> would set the max mode, that is the graphics output driver's vendor
> decided.
> In the other condition, these two pcds would set a value and then
> graphics output driver would focus to set the mode and clear the
> screen. That is controlled by the consumer. By default the two pcds is
> initialized as 800 and 600. Because this resolution may be the most
> normal resolution and the screen would always be cleared.
>
> In my opinion, the behavior of graphics output section in this driver
> is fine and should not be changed. And also, it is hard for us to
> control it because the driver is usually not open source.
> The upon results are based on kabylake Rvp3 platform. Maybe I missed
> something. Any incorrect, please feel free to point out.
The above is all fine, thank you for the answer.
However, now having looked at patch#2 in a bit more detail, I have to
ask my question again, although a bit differently:
In patch #2, we modify the GraphicsConsoleConOutSetMode() function,
to omit clearing the display under some conditions.
The GraphicsConsoleConOutSetMode() function implements
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetMode().
According to the UEFI spec,
The SetMode() function sets the output device(s) to the requested
mode. On success the device is in the geometry for the requested
mode, and the device has been cleared to the current background
color with the cursor at (0,0).
So, if patch #2 implements a EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetMode()
member function that does not clear the screen on every call, does it
conform to the spec?
Now, if the "do not clear the screen" exception is not observable /
triggerable by any UEFI driver or UEFI application that is written
against the UEFI spec -- in other words, if the exception only applies
to platform / DXE modules --, then I guess the exception could be fine.
But I'd like to hear others' comments too, and if this behavior is
conformant, then this nuance should be mentioned in the commit message
and/or in a comment, in patch #2.
... Finally, what about controller disconnect/reconnect in the UEFI
shell (or in other UEFI applications)? I assume that the
(This->Mode->Mode == -1) exception would apply again, even though at
that time we wouldn't be starting up just after the PEI phase.
Thanks,
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#39096): https://edk2.groups.io/g/devel/message/39096
Mute This Topic: https://groups.io/mt/31038452/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
