RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2026132 - RFE: set default video resolution to a more sensible modern size like 1280x800 (WXGA)
Summary: RFE: set default video resolution to a more sensible modern size like 1280x80...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: edk2
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Xueqiang Wei
URL:
Whiteboard:
Depends On: 2056910
Blocks: 2026955
TreeView+ depends on / blocked
 
Reported: 2021-11-23 20:34 UTC by Daniel Berrangé
Modified: 2022-11-15 10:25 UTC (History)
11 users (show)

Fixed In Version: edk2-20220221gitb24306f15d-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 09:56:33 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Win 11 installer username screen at 800x600 (117.04 KB, image/png)
2021-11-23 20:43 UTC, Daniel Berrangé 		no flags Details
Win 11 installer username screen at 1280x720 (165.23 KB, image/png)
2021-11-23 20:44 UTC, Daniel Berrangé 		no flags Details
Win 11 installer username screen at 1280x800 (179.26 KB, image/png)
2021-11-23 20:45 UTC, Daniel Berrangé 		no flags Details
Win 11 installer username screen at 1280x1024 (239.47 KB, image/png)
2021-11-23 20:46 UTC, Daniel Berrangé 		no flags Details
Proof of concept patch from Fedora 35 edk2 for increasing res (6.24 KB, text/plain)
2021-11-23 20:51 UTC, Daniel Berrangé 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-103711 0 None None None 2021-11-23 20:37:47 UTC
Red Hat Product Errata RHEA-2022:7971 0 None None None 2022-11-15 09:57:21 UTC

Description Daniel Berrangé 2021-11-23 20:34:18 UTC 
Description of problem:
If you boot up a Windows guest using EDK2 firmware, it will start off in 800x600 resolution and Windows default display driver will not permit you to set it any higher, despite having sufficient video RAM.

This resolution is hardwired into the EDK2 firmware build config for OVMF and AAVMF.

800x600 might be reasonable as a default in the 1990s where video RAM was very limited and monitors didn't do much higher either.

In 2020 though, this is unusable as most OS vendors don't test their user interface at 800x600 resolution, quite rightly assuming that all hardware sold today supports waaaaay higher resolutions.

Windows 11 can just about be installed in 800x600 if you know to blindly try scrolling at various points to get to off-screen buttons. It is not a pleasant experience to put users through though.

A more practical modern default would be one of the 1280 wide resolutions like 1280x720 (720p) / 1280x800 (WXGA) or 1280x1024 (SXGA).

All QEMU graphics cards provide enough video RAM for these, and even if they didn't, EDK2 would gracefully degrade trying smaller resolutions until it can fit in available video RAM.

I'm suggesting 1280x800 because:

  - It gives 33% more vertical space, and 60% more horizontal space than 800x600
  - Consumes 1 MB per channel, allowing double buffered framebuffer in 8 MB video RAM
  - Allows for extra vertical real estate consumed by window titlebars / menubars in virt-manager/virt-viewer/etc clients, when used on a 1280x1024 monitor
  - Size at which Windows 11 installer starts to be reasonably usable


Version-Release number of selected component (if applicable):
edk2-20210527gite1999b264f1f-7

How reproducible:
Always

Steps to Reproduce:
1. Boot a QEMU VM from Windows install CDROM media using EDK2 firmware. I tested Windows 11.
2. Experience the display resolution that is enabled

Actual results:
Party like it is 1999 in 800x600

Expected results:
Party like it is 2009 in 1280x800 (aka WXGA)

Additional info:
Comment 2 Daniel Berrangé 2021-11-23 20:43:37 UTC 
Created attachment 1843233 [details]
Win 11 installer username screen at 800x600
Comment 3 Daniel Berrangé 2021-11-23 20:44:32 UTC 
Created attachment 1843234 [details]
Win 11 installer username screen at 1280x720
Comment 4 Daniel Berrangé 2021-11-23 20:45:18 UTC 
Created attachment 1843236 [details]
Win 11 installer username screen at 1280x800
Comment 5 Daniel Berrangé 2021-11-23 20:46:36 UTC 
Created attachment 1843237 [details]
Win 11 installer username screen at 1280x1024
Comment 6 Daniel Berrangé 2021-11-23 20:49:33 UTC 
The screenshots illustrate how information is cut off below 800 pixels height, and above 800 pixels height it merely adds to the borders. From this we can infer it was designed for 800 pixel optimal min height. 

Of course every OS is going to be different, but it is reasonable demo of the expectations for display resolution from a very widely used desktop OS.
Comment 7 Daniel Berrangé 2021-11-23 20:51:09 UTC 
Created attachment 1843238 [details]
Proof of concept patch from Fedora 35 edk2 for increasing res
Comment 8 Daniel Berrangé 2021-11-24 09:51:57 UTC 
Note, everything I've written and tested assumes a non-awful video card is used with QEMU. ie VGA, virtio-vga, qxl.   If you have the misfortune to use Cirrus, then EDK2 will not do the higher resolutions. In such a case, EDK2 will ignore the requested default resolution and degrade automatically the best size the video card can manage. IOW, Cirrus users will be no worse off than they already are, while non-Cirrus users will benefit.
Comment 9 Gerd Hoffmann 2021-11-24 10:42:59 UTC 
> This resolution is hardwired into the EDK2 firmware build config for OVMF
> and AAVMF.

It's not hardwired.
Can be changed via firmware setup -> device manager -> ovmf platform configuration.

> A more practical modern default would be one of the 1280 wide resolutions
> like 1280x720 (720p) / 1280x800 (WXGA) or 1280x1024 (SXGA).

> I'm suggesting 1280x800 because:

Problem with 1280x800 is that the qemu default is 1024x768.
So linux guests will switch from 1280x800 to 1024x768 when
the drm driver takes over from efifb.

IMHO both qemu and edk2 should use the same default.
Comment 10 Daniel Berrangé 2021-11-24 10:49:59 UTC 
(In reply to Gerd Hoffmann from comment #9)
> > This resolution is hardwired into the EDK2 firmware build config for OVMF
> > and AAVMF.
> 
> It's not hardwired.
> Can be changed via firmware setup -> device manager -> ovmf platform
> configuration.

Going into the firmware menus is never a pleasant user experience though, especially if it will be needed every time you provision a guest OS.
 
> > A more practical modern default would be one of the 1280 wide resolutions
> > like 1280x720 (720p) / 1280x800 (WXGA) or 1280x1024 (SXGA).
> 
> > I'm suggesting 1280x800 because:
> 
> Problem with 1280x800 is that the qemu default is 1024x768.
> So linux guests will switch from 1280x800 to 1024x768 when
> the drm driver takes over from efifb.
> 
> IMHO both qemu and edk2 should use the same default.

Yes, we should align with QEMU.   Are you referring to the qemu_edid_generate() method which sets  prefx and prefy fields to 1024x768, or are there other places to look at too ?

I notice QEMU's edid_mode table doesn't have 1280x800 entry, so might need to extend that info too - the qxl_modes table has alot more entries.
Comment 11 Gerd Hoffmann 2021-11-24 11:46:49 UTC 
Related: bug 1749250.
Comment 12 Gerd Hoffmann 2021-11-24 11:50:10 UTC 
> Yes, we should align with QEMU.   Are you referring to the
> qemu_edid_generate() method which sets  prefx and prefy fields to 1024x768,
> or are there other places to look at too ?

I *think* that should be it.

There are also xres and yres properties for display devices.
I think they all default to zero so the qemu_edid_generate()
defaults should be used when unset.  Double-checking doesn't
hurt though 😎
Comment 13 Daniel Berrangé 2021-11-26 16:00:18 UTC 
(In reply to Gerd Hoffmann from comment #12)
> > Yes, we should align with QEMU.   Are you referring to the
> > qemu_edid_generate() method which sets  prefx and prefy fields to 1024x768,
> > or are there other places to look at too ?
> 
> I *think* that should be it.
> 
> There are also xres and yres properties for display devices.
> I think they all default to zero so the qemu_edid_generate()
> defaults should be used when unset.  Double-checking doesn't
> hurt though 😎

All except virtio-gpu had xres/yres set to zero. I've filed bug 2026955 with a demo QEMU patch.
Comment 14 Gerd Hoffmann 2021-11-29 11:21:18 UTC 
/me is confused.  Why does this block 2026955?  I don't think the bugs have a dependency.  If anything, then this bug depending on the qemu bug, because I think edk2 should just follow what upstream qemu is doing.

So my plan is for now: (1) wait how the upstream discussion on the qemu default resolution is going, and (2) flip the edk2 default to either 1024x768 or 1280x800 depending on how the discussion goes.

(independant from that continue working on bug 1749250).
Comment 15 Daniel Berrangé 2021-11-29 11:29:34 UTC 
(In reply to Gerd Hoffmann from comment #14)
> /me is confused.  Why does this block 2026955?  I don't think the bugs have
> a dependency.  If anything, then this bug depending on the qemu bug, because
> I think edk2 should just follow what upstream qemu is doing.

I wasn't sure which way around was best to put the dependency - I just wanted to express that we should do the same in both components, so linked them. If you think they're better flipped, feel free to reverse.

> So my plan is for now: (1) wait how the upstream discussion on the qemu
> default resolution is going, and (2) flip the edk2 default to either
> 1024x768 or 1280x800 depending on how the discussion goes.

Sure, that's fine.
Comment 18 Gerd Hoffmann 2022-02-01 11:01:35 UTC 
Merged upstream.
https://github.com/tianocore/edk2/pull/2454
Comment 19 Gerd Hoffmann 2022-02-15 09:58:02 UTC 
Set ITR to 9.1 (to sync with qemu 7.0 rebase which changes the default to 1280x800 too).
Comment 20 Gerd Hoffmann 2022-02-22 11:45:42 UTC 
9.1 rebase should pick up this one.
Comment 21 Klaus Heinrich Kiwi 2022-03-23 18:59:22 UTC 
After a discussion with Yash, moving to Assigned + TestOnly flag, as it reflects better that we're waiting for the rebase
Comment 22 Xueqiang Wei 2022-05-17 15:27:31 UTC 
Changes in edk2-2022-02 & newer: the default display resolution is 1280x800 now. This bug should be fixed, so set status to MODIFIED. If I'm wrong, please correct me. Thanks.
Comment 23 Xueqiang Wei 2022-06-01 15:37:58 UTC 
Check the default value with edk2-20220221gitb24306f15d-2.el9


1. Boot a guest with VGA device:

Press ESC in the initial boot splash screen, select 'Device Manager' -> 'OVMF Platform Configuration'

check the default value: Change Preferred <1280*800>


2. Boot a guest with bochs-display device:
Press ESC in the initial boot splash screen, select 'Device Manager' -> 'OVMF Platform Configuration'

check the default value: Change Preferred <1280*800>
Comment 24 Yash Mankad 2022-07-06 14:29:21 UTC 
(In reply to Xueqiang Wei from comment #22)
> Changes in edk2-2022-02 & newer: the default display resolution is 1280x800
> now. This bug should be fixed, so set status to MODIFIED. If I'm wrong,
> please correct me. Thanks.

Moving to ON_QA

TestOnly BZs should be either NEW, ASSIGNED or ON_QA, VERIFIED. 
As the development work for the BZ is already in a build, the TestOnly BZ is used to verify that the bug no longer exists in the build.

Hi Xueqiang - could you please set the ITM?
Comment 25 Xueqiang Wei 2022-07-06 15:42:10 UTC 
According to Comment 23 and https://bugzilla.redhat.com/show_bug.cgi?id=1749250#c49, set status to VERIFIED.
Comment 28 errata-xmlrpc 2022-11-15 09:56:33 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (edk2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:7971
Note You need to log in before you can comment on or make changes to this bug.