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 <oleglelc...@gmail.com> wrote:
> I got it.
>
> On Mon, May 15, 2023, 8:32 AM Toomas Soome <tso...@me.com> wrote:
>
>>
>>
>> On 15. May 2023, at 15:22, Oleg Lelchuk <oleglelc...@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 <oleglelc...@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 <i...@bsdimp.com> wrote:
>>>
>>>>
>>>>
>>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk <oleglelc...@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 <oleglelc...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I got it. Thanks.
>>>>>>
>>>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste <ema...@freebsd.org> wrote:
>>>>>>
>>>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk <oleglelc...@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
>>>>>>>
>>>>>>
>>
