From nobody Thu Dec 28 22:48:12 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 4T1Nvs3nc9z54pg8 for ; Thu, 28 Dec 2023 22:48:25 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 4T1Nvr1vzLz3HJ6; Thu, 28 Dec 2023 22:48:24 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=WetP4k6Z; spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-67f9f24e7b1so43680476d6.0; Thu, 28 Dec 2023 14:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703803703; x=1704408503; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Kz/BsD7UYj7FxbW+RKt8tO2Xk18Dpms76TRZvLMiXrA=; b=WetP4k6ZboFpWlUOayi7Kk4FMjosnUhN8+4ixymgmkGiSz9PfTm5dWSTxo6XM4SNvD yQIeNsbvfHYebid2gmhZWi3VUUnp95I66XWxxHPawe2p/24xYZOHKWPv2nnM783GallO ybdcmmTFRpwsSSByTCVvIngqUA9mhJUKyP0+r6WhEPvkomfyPg/7FKQ3qz6Uvxl3j1LH r1/8cxqfXo0/HQnqfFIzZnorl/d0CQXp9Ihop2jcMIN3Wt44uLK5QMOzTOk3b1nQrlp5 fXtfdjzlSy5RCFWr3qYcsE62vDzFum9Ab7xOoGRTLJAOKgZhkVNIJOayPffTkLutRPhM 9gJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703803703; x=1704408503; 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=Kz/BsD7UYj7FxbW+RKt8tO2Xk18Dpms76TRZvLMiXrA=; b=Ve4hADI6rb4y6ijqOKL9brScGzICRsgz0H5j07vwMlQ7sTkcAPNNXNzo1Cn8AIrTVy Gk5YAvsUPdDpc3yHNCso1Hr9DEBKf02TEqu3qOQu48dCMnVnUUE40TqDS56+dOTK/ugc WM/aR9NaR7BtHorTLGuQvvni8H1BwT/z7eVswvb9p/h15AYhBSJHy32qMTSehoY1aBYt ljlMXOQdu+tFVa1ZBk6+ih5ZziaXQcXyPq27opTfmL2lr/iI+s7y1VzCR3nNSU4o9R09 LukD+D0xH+mmM/eU604z8GAunSDFklc7q4SFNxBsZ+BXrC5bauo8yr4aS0DGOW0WA0EU I6/Q== X-Gm-Message-State: AOJu0YwQvDCDquWONoA97ejwEwAJMJKh28PHzVTndUYMQRGX6a4TQr1o CG0Mk0hgWJ82IThUHdak4Y2mjV1JbBH4QY5lrHc= X-Google-Smtp-Source: AGHT+IFChxC310Tk8mm4oBD3P+P8VA2cnMY9AmW9gd8TKHuenqgCTMYeZpWI9ayXOughd0J4a01L0kmtSijxNQH0asc= X-Received: by 2002:ad4:4d0f:0:b0:67f:aed5:1195 with SMTP id l15-20020ad44d0f000000b0067faed51195mr11268721qvl.106.1703803702909; Thu, 28 Dec 2023 14:48:22 -0800 (PST) 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: From: Oleg Lelchuk Date: Thu, 28 Dec 2023 17:48:12 -0500 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="0000000000007ab221060d99b60f" X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_TO(0.00)[me.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4T1Nvr1vzLz3HJ6 X-Spamd-Bar: -- --0000000000007ab221060d99b60f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am still using the same workaround: instead of rv =3D efi_global_getenv("ConOut", buf, &sz); I have rv =3D efi_global_getenv("ConIn", buf, &sz); Happy New Year! On Mon, May 15, 2023 at 8:41=E2=80=AFAM Oleg Lelchuk wrote: > 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 m= entioned >> 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 graphica= l >> logo appear, to start playing with the EFI resolution, and etc. >> >> >> The font size/resolution is difficult topic. The implementation itself >> can choose =E2=80=9Cgood enough=E2=80=9D variant and then some people ar= e 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 scre= en >> space we want to leave unused, we can get different dimensions for termi= nal. >> >> And since there is quite a variation of displays, the challenge is to ge= t >> 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 y= ou >> 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 men= u! >>> 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=3D1080p in loader.conf only affects what happens aft= er 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 wr= ote: >>> >>>> >>>> >>>> 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 ma= y >>>>> not >>>>> work) and "comconsole" for the serial on COM1 at the default bau= d >>>>> 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 Gra= phics >>>>> card an UEFI graphics device? Does it mean that once i915kms is loade= d, I >>>>> no longer deal with UEFI graphics? I think lots of people whose nativ= e >>>>> 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 conforman= t >>>>> 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 sys= tem >>>> 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 impleme= ntation. >>>>>>> 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 >>>>>>> >>>>>> >> --0000000000007ab221060d99b60f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am still using the same workaround: instead of=C2=A0rv = =3D efi_global_getenv("ConOut", buf, &sz); I have=C2=A0rv =3D= efi_global_getenv("ConIn", buf, &sz);
Happy New Year!

On Mon, May 15, 2023 at 8:41=E2=80=AFAM Oleg Lelchuk <oleglelchuk@gmail.com> wrote:
I got it.<= /div>
O= n Mon, May 15, 2023, 8:32 AM Toomas Soome <tsoome@me.com> wrote:


On 15. May 2023, at 15:22, Oleg Lelchuk <oleglelchuk@gmail.c= om> wrote:

Adding screen.font=3D&quo= t;16=C3=9732" to loader.conf fixed that tiny issue mentioned in the pr= evious 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 appe= ar, to start playing with the EFI resolution, and etc.

The font size/resolution is difficult topic. The im= plementation itself can choose =E2=80=9Cgood enough=E2=80=9D variant and th= en some people are happy and some people are unhappy.

<= div>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 termina= l.

And since there is quite a variation of display= s, the challenge is to get decent enough visual on most commonly used displ= ays - so there can be pressure to use fixed resolution etc. And this is als= o the reason, why you see very simple boot screens with something like spin= ning 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 /us= r/src/stand/efi/loader/main.c , and I replaced ConOut with ConIn in this li= ne:=C2=A0rv =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 my computer = screen? My monitor is 1080p and the setting efi_max_resolution=3D1080p in l= oader.conf only affects what happens after the kernel starts booting up, bu= t 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 w= ork!

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


On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk <<= a href=3D"mailto:oleglelchuk@gmail.com" rel=3D"noreferrer noreferrer" targe= t=3D"_blank">oleglelchuk@gmail.com> wrote:
I've been reading th= e documentation for loader.efi and it says this: "If there is no ConOu= t variable, both serial and video are attempted.
=C2=A0 =C2=A0 =C2=A0loa= der.efi uses the "efi" console for the video (which may or may no= t
=C2=A0 =C2=A0 =C2=A0work) and "comconsole" for the serial on= COM1 at the default baud rate.
=C2=A0 =C2=A0 =C2=A0The kernel will use = a dual console, with the video console primary if a
=C2=A0 =C2=A0 =C2=A0= UEFI graphics device is detected, or the serial console as primary if
= =C2=A0 =C2=A0 =C2=A0not."
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? Do= es 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 doc= umentation describing loader.efi confusing. The documentation page also men= tions 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 stan= dard, and likely have unexpected results." But I think you guys alread= y implied that the UEFI specification doesn't mandate having such a var= iable.

That's unclear. The standard refers to it many times. Earlier= versions especially. It doesn't say it's optional, unlike some oth= er variables. Yet later versions don't say it's mandatory.=C2=A0 I&= #39;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@gmail.com> wrote:
I got it. Thanks.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">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 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>

--0000000000007ab221060d99b60f--