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?

I got it.

On Mon, May 15, 2023, 8:32 AM Toomas Soome <tsoome@me.com> wrote:

>
>
> 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> 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> wrote:
>>
>>>
>>>
>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk <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>
>>>> wrote:
>>>>
>>>>> I got it. Thanks.
>>>>>
>>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste <emaste@freebsd.org> wrote:
>>>>>
>>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk <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
>>>>>>
>>>>>
>