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?
Date: Thu, 28 Dec 2023 22:48:12 UTC
I am still using the same workaround: instead of rv = efi_global_getenv("ConOut", buf, &sz); I have rv = efi_global_getenv("ConIn", buf, &sz); Happy New Year! On Mon, May 15, 2023 at 8:41 AM Oleg Lelchuk <oleglelchuk@gmail.com> wrote: > 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 >>>>>>> >>>>>> >>