From nobody Sat May 13 12:26:24 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 4QJPy5466Zz4BKlx for ; Sat, 13 May 2023 12:26:37 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4QJPy43NK8z40XD; Sat, 13 May 2023 12:26:36 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=QnSDC5HU; spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-757756e2eefso392649185a.3; Sat, 13 May 2023 05:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683980795; x=1686572795; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9hXk/fFg4WnEslfkG4j5T/bs7yMM3Z4PMKcotaOiSzg=; b=QnSDC5HUbnH7gLFf4sVNGQ36tMvQHm+aNrBNGlJV+i5Fqd2KEtqDroihlbs3/mJUWt blk9ahcai97Xm6ng46xPGogj5aP000emmi8AJrxRF/euzN2Rue+y67rNwo0G6b6uVRo5 zFQger4UDLB+aYyywEBgyEpwvCfFpTSTB5B+HvQNo65fc35NumKinPtsafM3GN7D0/42 cfkzLweGdi1s1ICQW+Cj2eaYfVnLFaYcmifnmvhFTqAN5KMCWt3vgAtLrbGult04OJOP d1zpz2OYphQ9tVuoKM4kralIyMIOW9qIypIWmLguGlsl24Ue+njrrPRfO8xRHfJmwZDq c8mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683980795; x=1686572795; 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=9hXk/fFg4WnEslfkG4j5T/bs7yMM3Z4PMKcotaOiSzg=; b=h+mPFIlasMr1qtQhMxi+rlfy8dHMuOUe8YM/hHw2eKJPY3Aurho2jGk3wukiSd/pf9 +gsYqHvV4FSIcTx/6mXAHSBhm6IEQICd+DA7Df1/QzynPybBen5DePy7EK7cd9JaoZ9n cW3B0W7bgX/nF039XAMeFfUlBWDLGojmSKz2VJ0yYU/kE5FOVJe5OQmExEM75rx16Jnn FqfCpOJL+zY8kHUAKFFzPEh7jeyzu1E4hbGdsFxHlzFpOJQ2063/HfSq/BWy59Umx4NP UZc6Hfo/NpaLEyAuf5oLn/n9IAWLEsK74JmgH96yStWH/mRbtG1NYMPAt1T9Y13nrlSH QPyA== X-Gm-Message-State: AC+VfDyJKbvPOY5A/glGi0kIs8QanONWqKNxjI8UfH36Fr3fX08kIdiQ 6oMt2MmVnxx3xFYECK+oHedA5Dz4PuXnlpsgQICf9DZDceSv4EWe X-Google-Smtp-Source: ACHHUZ5kmUBmhuX3W7SMQvBSmc9LWL3hSabL7fX+QUvFpdH8Jhe2f3Z65bhoZcxkqoYKmPpsYrTpeBISHDkQQ5P78wo= X-Received: by 2002:a05:6214:4018:b0:5df:4d3e:b8e0 with SMTP id kd24-20020a056214401800b005df4d3eb8e0mr36631129qvb.4.1683980795142; Sat, 13 May 2023 05:26:35 -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> In-Reply-To: From: Oleg Lelchuk Date: Sat, 13 May 2023 08:26:24 -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: Ed Maste Cc: Toomas Soome , Emmanuel Vadot , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001a670705fb9255b6" X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72a:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_CC(0.00)[me.com,bidouilliste.com,freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QJPy43NK8z40XD X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000001a670705fb9255b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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 wro= te: > >> 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 implementation. Than= k >> 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 >> > --0000000000001a670705fb9255b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.
=C2=A0 =C2=A0 =C2=A0loader.efi uses the "efi" c= onsole 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 kernel will use a dual console, with the video con= sole primary if a
=C2=A0 =C2=A0 =C2=A0UEFI 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 &qu= ot;a UEFI graphics device". In my situation, is my Intel Integrated Gr= aphics card an UEFI graphics device? Does it mean that once i915kms is load= ed, 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 con= fusing. The documentation page also mentions this: "BUGS
=C2=A0 = =C2=A0 =C2=A0Systems that do not have a ConOut variable set are not conform= ant with
=C2=A0 =C2=A0 =C2=A0the standard, and likely have unexpected re= sults." But I think you guys already implied that the UEFI specificati= on doesn't mandate having such a variable.

On Fri, May 12, 2023 at 7:55= =E2=80=AFPM Oleg Lelchuk <olegl= elchuk@gmail.com> wrote:
I got it. Thanks.

On Fri, May 12, 2023 at 7= :45=E2=80=AFPM Ed Maste <emaste@freebsd.org> wrote:
On Fri, 12 May 2023 at 09:26, Oleg Lelchuk <<= a href=3D"mailto:oleglelchuk@gmail.com" target=3D"_blank">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
--0000000000001a670705fb9255b6--