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 2026955 - RFE: set default resolution/EDID info to a more sensible modern size like 1280x800 (WXGA)
Summary: RFE: set default resolution/EDID info to a more sensible modern size like 128...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On: 2026132
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-26 15:58 UTC by Daniel Berrangé
Modified: 2022-11-15 10:16 UTC (History)
10 users (show)

Fixed In Version: qemu-kvm-7.0.0-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 09:53:29 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:
zhguo: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-104049 0 None None None 2021-11-26 15:58:51 UTC
Red Hat Product Errata RHSA-2022:7967 0 None None None 2022-11-15 09:54:15 UTC

Description Daniel Berrangé 2021-11-26 15:58:14 UTC 
This bug was initially created as a copy of Bug #2026132, to track the QEMU changes equivalent to what's proposed for EDK2.

QEMU needs to get its default EDID info to match the default EDK resolution, in order to avoid resolution changes from the firmware default during boot up when the guest OS processes EDID info.

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
qemu-kvm-6.1.0-6

How reproducible:
Always

Steps to Reproduce:
1. Acquire the EDK2 firmware with the change associated with bug 2026132
2. Boot a RHEL/Fedora graphical desktop VM with virtio-vga device

Actual results:
Boot starts in 1280x800 res defined by EDK2, and then switches down to 1024x768 during OS boot up

Expected results:
Resolution stays in 1280x800 all the way through boot up.

Additional info:
Comment 3 jinl 2022-06-01 08:58:30 UTC 
Verify with edk2-20220221gitb24306f15d-2.el9 qemu-kvm-7.0.0-4.el9

check the resolution of both rhel and windows vm in different scenarios

rhel 9.1 VM:
q35 + ovmf + bochs-display: 1280x800
q35 + ovmf + virtio-vga: 1280x800
q35 + seabios + VGA: 1280x800
q35 + seabios + virtio-vga: 1280x800
pc + seabios + virtio-vga: 1280x800
pc + seabios + VGA: 1024x768

win 10 VM:
q35 + ovmf + bochs-dispaly: 1280x800
q35 + ovmf + virtio-vga(viodod): 1024x768
q35 + ovmf + virtio-vga: 1280x800
q35 + seabios + VGA: 1024x768
q35 + seabios + virtio-vga(viodod): 1024x768
q35 + seabios + virtio-vga: 1024x768
pc + seabios + virtio-vga(viodod): 1024x768
pc + seabios + virtio-vga: 1024x768
pc + seabios + VGA: 1024x768

based on the result, the resolution may be 1024x768 in some scenarios, I'm not sure if it meets expectations.Can you help confirm it? Thanks.
Comment 4 jinl 2022-06-01 09:10:00 UTC 
additional info:
virtio-vga(viodod) means using virtio-vga device and having virtio driver in vm
Comment 5 Guo, Zhiyi 2022-06-01 10:50:23 UTC 
(In reply to jinl from comment #3)
> Verify with edk2-20220221gitb24306f15d-2.el9 qemu-kvm-7.0.0-4.el9
> 
> check the resolution of both rhel and windows vm in different scenarios

Gerd, could you also help to check the list? 
> 
> rhel 9.1 VM:
> q35 + ovmf + bochs-display: 1280x800
> q35 + ovmf + virtio-vga: 1280x800
> q35 + seabios + VGA: 1280x800
> q35 + seabios + virtio-vga: 1280x800
> pc + seabios + virtio-vga: 1280x800
> pc + seabios + VGA: 1024x768
> 
> win 10 VM:
> q35 + ovmf + bochs-dispaly: 1280x800
> q35 + ovmf + virtio-vga(viodod): 1024x768

I think we need to file a bug for virtio-win to select 1280x800 as default resolution for virtio-vga/virtio-gpu ?

> q35 + ovmf + virtio-vga: 1280x800
> q35 + seabios + VGA: 1024x768
> q35 + seabios + virtio-vga(viodod): 1024x768
> q35 + seabios + virtio-vga: 1024x768
> pc + seabios + virtio-vga(viodod): 1024x768
> pc + seabios + virtio-vga: 1024x768
> pc + seabios + VGA: 1024x768
> 
> based on the result, the resolution may be 1024x768 in some scenarios, I'm
> not sure if it meets expectations.Can you help confirm it? Thanks.

I think we also need a qemu bug to track none virtio-win issue?

Thanks!

Zhiyi
Comment 6 Guo, Zhiyi 2022-06-02 02:17:41 UTC 
Looks like manually customizing resolution also has similar behavior as comment 3, here is the result:

resolution manually set to 1920x1080 via -device xxx,xres=1920,yres=1080

rhel 9.1 VM:
q35 + ovmf + bochs-display: work 
q35 + ovmf + virtio-vga: work 
q35 + seabios + VGA: work 
q35 + seabios + virtio-vga: work 
pc + seabios + virtio-vga: work 
pc + seabios + VGA: not work, resolution is still 1024x768 

win 10 VM:
q35 + ovmf + bochs-dispaly: work 
q35 + ovmf + virtio-vga(viodod): not work, resolution is still 1024x768
q35 + ovmf + virtio-vga: not work, resolution is still 1280x800
q35 + seabios + VGA: not work, resolution is still 1024x768
q35 + seabios + virtio-vga(viodod): not work, resolution is still 1024x768)
q35 + seabios + virtio-vga: not work, resolution is still 1024x768
pc + seabios + virtio-vga(viodod): not work, resolution is still 1024x768
pc + seabios + virtio-vga: not work, resolution is still 1024x768
pc + seabios + VGA: not work, resolution is still 1024x768
Comment 7 Gerd Hoffmann 2022-06-02 12:32:32 UTC 
> > rhel 9.1 VM:
> > q35 + seabios + VGA: 1280x800
> > pc + seabios + VGA: 1024x768

Hmm, that is strange, can you double-check?  The machine type
shouldn't make a difference here, also can't reproduce this.

> > win 10 VM:
> > q35 + ovmf + bochs-dispaly: 1280x800
> > q35 + ovmf + virtio-vga(viodod): 1024x768
> 
> I think we need to file a bug for virtio-win to select 1280x800 as default
> resolution for virtio-vga/virtio-gpu ?

Looks like the windows driver doesn't query the host for the resolution.
I guess setting a resolution via xres+yres doesn't work either?

Yes, please open a bug for that.

> > based on the result, the resolution may be 1024x768 in some scenarios, I'm
> > not sure if it meets expectations.Can you help confirm it? Thanks.

When running with seabios and not using the windows driver windows
seems ask the vgabios for 1024x768 no matter what, and I don't think
we can do much about it.
Comment 8 jinl 2022-06-07 03:35:36 UTC 
(In reply to Gerd Hoffmann from comment #7)
> > > rhel 9.1 VM:
> > > q35 + seabios + VGA: 1280x800
> > > pc + seabios + VGA: 1024x768
> 
> Hmm, that is strange, can you double-check?  The machine type
> shouldn't make a difference here, also can't reproduce this.
> 
Hi, double-check with these scenarios, the result is the same.
Comment 9 Guo, Zhiyi 2022-06-22 15:25:25 UTC 
(In reply to jinl from comment #8)
> (In reply to Gerd Hoffmann from comment #7)
> > > > rhel 9.1 VM:
> > > > q35 + seabios + VGA: 1280x800
> > > > pc + seabios + VGA: 1024x768
> > 
> > Hmm, that is strange, can you double-check?  The machine type
> > shouldn't make a difference here, also can't reproduce this.
> > 
> Hi, double-check with these scenarios, the result is the same.

Have double checked pc + seabios + VGA with rhel 9.1 VM, vm default resolution is indeed 1024x768.
What's more, vm default resolution is still 1024x768 even has qemu option -device '{"driver":"VGA","id":"video0","vgamem_mb":16,"xres":1920,"yres":1080,"bus":"pci.0","addr":"0x2"}'

Gerd, should we file a bug about this behavior?
Comment 10 Gerd Hoffmann 2022-06-23 08:01:22 UTC 
> Have double checked pc + seabios + VGA with rhel 9.1 VM, vm default
> resolution is indeed 1024x768.
> What's more, vm default resolution is still 1024x768 even has qemu option
> -device
> '{"driver":"VGA","id":"video0","vgamem_mb":16,"xres":1920,"yres":1080,"bus":
> "pci.0","addr":"0x2"}'

Ok, it's because 'pc' is deprecated and doesn't get new machine types:

  ⬢[kraxel@toolbox ~]$ /usr/libexec/qemu-kvm -M help
  Supported machines are:
  pc                   RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0)
  pc-i440fx-rhel7.6.0  RHEL 7.6.0 PC (i440FX + PIIX, 1996) (default) (deprecated)
  q35                  RHEL-9.0.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel9.0.0)
  pc-q35-rhel9.0.0     RHEL-9.0.0 PC (Q35 + ICH9, 2009)
  pc-q35-rhel8.6.0     RHEL-8.6.0 PC (Q35 + ICH9, 2009) (deprecated)
  [ ... snip ... ]

So all the new goodies added since 7.6 are disabled by default for backward
compatibility reasons.  Specifically edid support is turned off, which is
used to tell the guest what resolution it should use.

Using '/usr/libexec/qemu-kvm -M pc -device VGA,edid=on' works for me.
Comment 11 Guo, Zhiyi 2022-06-23 14:29:52 UTC 
(In reply to Gerd Hoffmann from comment #10)
> 
> Using '/usr/libexec/qemu-kvm -M pc -device VGA,edid=on' works for me.

Yep, this indeed works. I think based on above comments, we have already verified this bug. Gerd, could you help to set the proper flags to this bug so we can mark this bug verified?

Zhiyi
Comment 12 Yanan Fu 2022-06-27 08:21:37 UTC 
Gating test pass with 'qemu-kvm-7.0.0-4.el9', add 'Verified:Tested,SanityOnly' accordingly
Comment 13 Guo, Zhiyi 2022-06-28 05:55:27 UTC 
Verified per comment 3, 7, 10
Comment 18 errata-xmlrpc 2022-11-15 09:53:29 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 (Moderate: qemu-kvm security, 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/RHSA-2022:7967
Note You need to log in before you can comment on or make changes to this bug.