From nobody Mon May 15 12:41:19 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QKfBN260dz4BZRS for ; Mon, 15 May 2023 12:41:32 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKfBN0d6Lz4KBY; Mon, 15 May 2023 12:41:32 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-61cd6191a62so57537166d6.3; Mon, 15 May 2023 05:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684154491; x=1686746491; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m8CtwdOn4rDmqDgBttN1wu2ioPEOII92rnpePSKMFqU=; b=L7+FVip5tC5fjeTS73jNkOrpHU4qvQ8rKi4nsQKt3GTxUJkt2/XQhroV1AradUyLR9 A8UPMrn9WscmkJMSBT9F4YKWV0G1K/lxZRdldINEmX1OhKOJQ4u5PVGGi2ouyog6Y/V3 4ffukqKs4jDGLx1MF3oxLxPauhXGii8FlEn5XqyR68Yoe7guFpnxf6FzFb3R4B9P9WQJ tPHjWLtRJLxyJH+3YcI0NrxqkpqUa/ZGHlV8wyMqWrdvrHannL69hDR5q0I2+I8pvlMP bNgksiFXSd+ga/AmPMJ0wr84LvagYvoW2oif/W0WHtf8JwtnY370k0BmQY+Voab0n7Vl gCCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684154491; x=1686746491; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m8CtwdOn4rDmqDgBttN1wu2ioPEOII92rnpePSKMFqU=; b=a3JkzQWYe5beqJTGei2ze+GILmqtm1BqwpCTdaNSBW5UQehob7EUMiBM5RDUFKnIqe f02Yo4zeJwDwDkfEd5Cly8lS+oFc3Ih0lv+GHzYTkhx1aug9ilfDl6GJK+Ls/VhMb5OM qc9P5HVsipOI2rG8HY4HBXkQIPZYfK86a3kG92Efc6k6hRXzMdK2q0Z+GqdeqWXQ2lpF JhQlHLWGIcSrypyMjQ7J7la+OGIht+JrudNc3VdCsWheU2YCyhzU2uGtxECmCmjlm7pX +vx2rfXWgEXgqrEG46IPZIN3CiCkcpjRvW4EvcnPXCmzmY5SIhyjCumSKUq2msOCZQIw qXZA== X-Gm-Message-State: AC+VfDxxgryuD0b9SLbh0rrHhvuh957AjrOvNhKJTb2pILlPNYFFhLuk 0xaZ6TkMXxuUGt4c+va7iFyRebt1Zohxcmu6gOk= X-Google-Smtp-Source: ACHHUZ54Sy9LNlM06ZHgAjb+QqyjU6dg3DhFAmI/H4EWGC64JjsiTK+qINNTjUWjirNDrr56ye5ujPSU18PlOnxiY6g= X-Received: by 2002:a05:6214:27ee:b0:623:6e9b:cba7 with SMTP id jt14-20020a05621427ee00b006236e9bcba7mr1309082qvb.24.1684154491214; Mon, 15 May 2023 05:41:31 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3B658415-3AD0-4E8B-8CBE-F13FA70CBDC8@me.com> <20230512070557.859671981b7c616c0da7d666@bidouilliste.com> <4F0D21B1-58B6-413D-8499-11AF0E338C78@me.com> <4AC4F6EE-CE18-4D67-A7F7-9328DAB3E1AB@me.com> In-Reply-To: <4AC4F6EE-CE18-4D67-A7F7-9328DAB3E1AB@me.com> From: Oleg Lelchuk Date: Mon, 15 May 2023 08:41:19 -0400 Message-ID: Subject: 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? To: Toomas Soome Cc: Warner Losh , Ed Maste , Emmanuel Vadot , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000003221d105fbbac64a" X-Rspamd-Queue-Id: 4QKfBN0d6Lz4KBY X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000003221d105fbbac64a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I got it. On Mon, May 15, 2023, 8:32 AM Toomas Soome wrote: > > > On 15. May 2023, at 15:22, Oleg Lelchuk wrote: > > Adding screen.font=3D"16=C3=9732" to loader.conf fixed that tiny issue me= ntioned > in the previous email message... I find it a bit surprising that I only h= ad > 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 ca= n > choose =E2=80=9Cgood enough=E2=80=9D variant and then some people are hap= py 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 scree= n > space we want to leave unused, we can get different dimensions for termin= al. > > 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 yo= u > 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 wrote: > >> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced >> ConOut with ConIn in this line: rv =3D 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 m= y >> computer screen? My monitor is 1080p and the setting >> efi_max_resolution=3D1080p in loader.conf only affects what happens afte= r 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=E2=80=AFAM Warner Losh wro= te: >> >>> >>> >>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk >>> 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 primar= y >>>> if a >>>> UEFI graphics device is detected, or the serial console as primar= y >>>> 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 Graphic= s >>>> 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 yo= u >>>> guys already implied that the UEFI specification doesn't mandate havin= g >>>> 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 syst= em >>> without it... such systems exist but they are quite new... >>> >>> Warner >>> >>> On Fri, May 12, 2023 at 7:55=E2=80=AFPM Oleg Lelchuk >>>> wrote: >>>> >>>>> I got it. Thanks. >>>>> >>>>> On Fri, May 12, 2023 at 7:45=E2=80=AFPM Ed Maste = wrote: >>>>> >>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk >>>>>> 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 implemen= tation. >>>>>> 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 >>>>>> >>>>> > --0000000000003221d105fbbac64a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I got it.

On Mon, May 15, 2023, 8:32 AM Toomas Soome <<= a href=3D"mailto:tsoome@me.com">tsoome@me.com> wrote:

<= div>
On 15. May 2023, at 15:22, Oleg Lelc= huk <oleglelchuk@gmail.com> wrote:

Adding screen.font=3D"16=C3=9732" to loader.conf fixed that = tiny issue mentioned in the previous email message... I find it a bit surpr= ising that I only had to make one tiny change to the source code of stand t= o make the graphical logo appear, to start playing with the EFI resolution,= and etc.

The font size/resolut= ion is difficult topic. The implementation itself can choose =E2=80=9Cgood = enough=E2=80=9D variant and then some people are happy and some people are = unhappy.

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

And since there i= s quite a variation of displays, the challenge is to get decent enough visu= al on most commonly used displays - so there can be pressure to use fixed r= esolution etc. And this is also the reason, why you see very simple boot sc= reens with something like spinning wheel on some other systems.
<= br>
rgds,
toomas


On S= un, 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:=C2=A0rv =3D efi_global_getenv("ConIn", buf, &s= z); . Now I am able to see the beautiful graphical logo in the efi boot men= u! But why are the boot menu and the logo shown in the top left corner of m= y computer screen? My monitor is 1080p and the setting efi_max_resolution= =3D1080p in loader.conf only affects what happens after the kernel starts b= ooting 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 c= ase? You can see the photo in the provided attachment... And thank you, guy= s, for your work!

On Sat, May 13, 2023 at 9:35=E2=80=AFAM Warner Losh <imp@bsdimp.com> wrote:


On Sat, May 13, 2023, 6:26 AM Oleg = Lelchuk <oleglelchuk@gmail.com> wrote:
I've be= en reading the documentation for loader.efi and it says this: "If ther= e is no ConOut variable, both serial and video are attempted.
=C2=A0 =C2= =A0 =C2=A0loader.efi uses the "efi" console for the video (which = may or may not
=C2=A0 =C2=A0 =C2=A0work) and "comconsole" for = the serial on COM1 at the default baud rate.
=C2=A0 =C2=A0 =C2=A0The ker= nel will use a dual console, with the video console primary if a
=C2=A0 = =C2=A0 =C2=A0UEFI graphics device is detected, or the serial console as pri= mary if
=C2=A0 =C2=A0 =C2=A0not."
I find this language confusin= g because I don't know what is meant by "a UEFI graphics device&qu= ot;. 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 UE= FI graphics? I think lots of people whose native language is English will f= ind the documentation describing loader.efi confusing. The documentation pa= ge also mentions this: "BUGS
=C2=A0 =C2=A0 =C2=A0Systems that do = not have a ConOut variable set are not conformant with
=C2=A0 =C2=A0 =C2= =A0the 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.= =C2=A0 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=E2=80=AFPM Oleg Lelchuk <oleglelchuk@g= mail.com> wrote:
I got it. Thanks.

On Fri, May 12, 2023 at 7:45=E2= =80=AFPM Ed Maste <emaste@freebsd.org> wrot= e:
On Fri, 12 Ma= y 2023 at 09:26, Oleg Lelchuk <oleglelchuk@gmai= l.com> wrote:
>
> I don't want to go through the hassle of filling a bug with my ven= dor. I will just wait for you, guys, to update the stand implementation. Th= ank 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<= br>

--0000000000003221d105fbbac64a--