From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by mx.groups.io with SMTP id smtpd.web11.763.1587611764480290847 for ; Wed, 22 Apr 2020 20:16:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Hq2GofDP; spf=pass (domain: gmail.com, ip: 209.85.160.172, mailfrom: hqm03ster@gmail.com) Received: by mail-qt1-f172.google.com with SMTP id k12so3737147qtm.4; Wed, 22 Apr 2020 20:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OB9OTvstqtb6HGcd0Td8y0gSItB1DlBtyYkYV9ML6VM=; b=Hq2GofDP/1AA/mah67XdfR9lOlSEhtpNuWABsbxGj0AQscbMapqXDqiHEB7xcvF9I7 tFRH9b3VhQYe05RYODdzBTH59cDaY9zweOmagWyL82YEIhwHeCMZqjm0QuCBez7MHlFL FMTfZfVCEpVxvIwx3EDjW+iByRiXVP7qPBi1vYqq03T6mLnkIm/UZSBF0F+am+Dh3eZS 7PNBj9XnTBYZAiPopeNIcMHOWfOjfw0HoFFpi7GWmVTCsNfptAqPoIEckwpk9ABkPFfZ htfnqCTwN2/743ayxy8xEMQdNCzRhAfNH8L/L7IU0gd49F9i7PIArlN4loKWDWGSOmdT QSqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OB9OTvstqtb6HGcd0Td8y0gSItB1DlBtyYkYV9ML6VM=; b=uXm29ivKStyMeywn/+vV+b0Lf+nR8DQbohkX+XhAWCE828uGUECCvr0BLt7THIF6wJ xKgCwbmU/bpt+qdtlrlYyHsaS9UirWXGRXRAqh6g3l62fVCXNm3R6jgjHgvn0nZoeknO 6mLbNWXWDrc7OtFeTArryFjQ1pvi+6mEgQCwOZSErQVq64BcWDpIF6lJ1L4EyJDF/4rD b+lTQbD5tC5Jlx8knWGh/QK8forY0po2XfsAQvRrNLRUzE9Od8frw1nRuPs8u7m/T7iv 69oGlPBcgDa+Lcr6XsBhwZOTG6ix74/bi4miCtNi23kmnv4UOixsqoM7qjkitrwcj4RO fTkg== X-Gm-Message-State: AGi0Puab2aOQsU66I9CKuhov7f9kjrXe8Ax2UCjplznqD61bAsj4rNDr 3OGZstXTHcTG9Cy9qm9H0dFfC+mZvuj+nguoyYw= X-Google-Smtp-Source: APiQypIvGTV96hbJ64cOqZLG8Q/fZyp2vVqXzClIlzX3OhDMyTyFq+TgBbwgkKpoEKp5yiEC05r3nmd1kMVEw78SF2k= X-Received: by 2002:ac8:162f:: with SMTP id p44mr1871446qtj.75.1587611763617; Wed, 22 Apr 2020 20:16:03 -0700 (PDT) MIME-Version: 1.0 References: <623b1855-285c-cce3-c806-c17e5fd217ea@redhat.com> <5211.1586899245384995995@groups.io> <20200420141303.dxjqgvmzglrjtsly@sirius.home.kraxel.org> <9aed493a-2187-cacd-5631-54fb9973509c@redhat.com> In-Reply-To: From: Hou Qiming Date: Thu, 23 Apr 2020 11:15:50 +0800 Message-ID: Subject: Re: [edk2-discuss] Load Option passing. Either bugs or my confusion. To: Laszlo Ersek Cc: Gerd Hoffmann , valerij zaporogeci , discuss@edk2.groups.io, "Marcel Apfelbaum (GMail address)" , edk2-devel-groups-io , qemu devel list Content-Type: multipart/alternative; boundary="00000000000036331605a3ecabe9" --00000000000036331605a3ecabe9 Content-Type: text/plain; charset="UTF-8" > > > > And when the user provides an EDID one should parse it and set the > default > > resolution to match it. But that's a less important feature. > > It's more complex than you might think, and (to me personally) it seems > to require more time than its importance justifies. > > https://bugzilla.redhat.com/show_bug.cgi?id=1749250 > > Read the thread. Actually, I wrote some EDID parsing code a while ago, but that's before QEMU supporting EDID so I had to do it outside QEMU and pass my parsing result to ramfb as the now-removed starting_width / starting_height. In the context QEMU, the EDID actually reflects the user preference since the whole structure is usually made up from the user-specified resolution. And I think most guest OSes initialize first-time-seen monitors to their EDID resolution, which should have motivated QEMU to provide an EDID for a virtual monitor. But at this point it's kind of awkward to do the EDID / resolution handling (that I need) in the ramfb driver as the kvmgt EDID has to be read out from the i915 MMIO just like a physical GPU. Guess now my use case is better covered with a fully functional i915 framebuffer driver for OVMF. If I had the time... --00000000000036331605a3ecabe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> And when the user provides an EDID one should parse it and set the def= ault
> resolution to match it. But that's a less important feature.

It's more complex than you might think, and (to me personally) it seems=
to require more time than its importance justifies.

https://bugzilla.redhat.com/show_bug.cgi?id=3D1= 749250


Read the thread. Actually, I wrote som= e EDID parsing code a while ago, but that's before QEMU supporting EDID= so I had to do it outside QEMU and pass my parsing result to ramfb as the = now-removed starting_width / starting_height. In the context QEMU, the EDID= actually reflects the user preference since the whole structure is usually= made up from the user-specified resolution. And I think most guest OSes in= itialize first-time-seen monitors to their EDID resolution, which should ha= ve motivated QEMU to provide an EDID for a virtual monitor.
<= br>
But at this point it's kind of awkward to do the EDID / r= esolution handling (that I need) in the ramfb driver as the kvmgt EDID has = to be read out from the i915 MMIO just like a physical GPU. Guess now my us= e case is better covered with a fully functional i915 framebuffer driver fo= r OVMF. If I had the time...

--00000000000036331605a3ecabe9--