Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?

> On 15. May 2023, at 15:22, Oleg Lelchuk <oleglelchuk@gmail.com> wrote:
> 
> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned in the previous email message... I find it a bit surprising that I only had to make one tiny change to the source code of stand to make the graphical logo appear, to start playing with the EFI resolution, and etc.

The font size/resolution is difficult topic. The implementation itself can choose “good enough” variant and then some people are happy and some people are unhappy.

The current loader UI is built on terminal dimensions (which depend on glyph size and resolution), and there the traditional assumption is that we have 80x24 terminal. With different fonts and depending on how much screen space we want to leave unused, we can get different dimensions for terminal.

And since there is quite a variation of displays, the challenge is to get decent enough visual on most commonly used displays - so there can be pressure to use fixed resolution etc. And this is also the reason, why you see very simple boot screens with something like spinning wheel on some other systems.

rgds,
toomas

> 
> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk <oleglelchuk@gmail.com <mailto:oleglelchuk@gmail.com>> wrote:
>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced ConOut with ConIn in this line: rv = efi_global_getenv("ConIn", buf, &sz); . Now I am able to see the beautiful graphical logo in the efi boot menu! But why are the boot menu and the logo shown in the top left corner of my computer screen? My monitor is 1080p and the setting efi_max_resolution=1080p in loader.conf only affects what happens after the kernel starts booting up, but it doesn't affect what happens before it: the boot menu and the logo remain in the top left corner of the screen. Why is this the case? You can see the photo in the provided attachment... And thank you, guys, for your work!
>> 
>> On Sat, May 13, 2023 at 9:35 AM Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>>> 
>>> 
>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk <oleglelchuk@gmail.com <mailto:oleglelchuk@gmail.com>> wrote:
>>>> I've been reading the documentation for loader.efi and it says this: "If there is no ConOut variable, both serial and video are attempted.
>>>>      loader.efi uses the "efi" console for the video (which may or may not
>>>>      work) and "comconsole" for the serial on COM1 at the default baud rate.
>>>>      The kernel will use a dual console, with the video console primary if a
>>>>      UEFI graphics device is detected, or the serial console as primary if
>>>>      not."
>>>> I find this language confusing because I don't know what is meant by "a UEFI graphics device". In my situation, is my Intel Integrated Graphics card an UEFI graphics device? Does it mean that once i915kms is loaded, I no longer deal with UEFI graphics? I think lots of people whose native language is English will find the documentation describing loader.efi confusing. The documentation page also mentions this: "BUGS
>>>>      Systems that do not have a ConOut variable set are not conformant with
>>>>      the standard, and likely have unexpected results." But I think you guys already implied that the UEFI specification doesn't mandate having such a variable.
>>> 
>>> 
>>> That's unclear. The standard refers to it many times. Earlier versions especially. It doesn't say it's optional, unlike some other variables. Yet later versions don't say it's mandatory.  I've yet to own or use a system without it... such systems exist but they are quite new...
>>> 
>>> Warner
>>> 
>>>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk <oleglelchuk@gmail.com <mailto:oleglelchuk@gmail.com>> wrote:
>>>>> I got it. Thanks.
>>>>> 
>>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste <emaste@freebsd.org <mailto:emaste@freebsd.org>> wrote:
>>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk <oleglelchuk@gmail.com <mailto:oleglelchuk@gmail.com>> wrote:
>>>>>> >
>>>>>> > I don't want to go through the hassle of filling a bug with my vendor. I will just wait for you, guys, to update the stand implementation. Thank you for explaining to me what causes this issue.
>>>>>> 
>>>>>> This issue is tracked in PR 265980 if you want to follow it.
>>>>>> https://bugs.freebsd.org/265980