Bug 2026132
| Summary: | RFE: set default video resolution to a more sensible modern size like 1280x800 (WXGA) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Daniel Berrangé <berrange> |
| Component: | edk2 | Assignee: | Gerd Hoffmann <kraxel> |
| Status: | CLOSED ERRATA | QA Contact: | Xueqiang Wei <xuwei> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | berrange, coli, jinzhao, juzhang, kkiwi, kraxel, pbonzini, redhat-bugzilla, virt-maint, xuwei, ymankad |
| Target Milestone: | rc | Keywords: | FutureFeature, TestOnly, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | edk2-20220221gitb24306f15d-1.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 09:56:33 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2056910 | ||
| Bug Blocks: | 2026955 | ||
| Attachments: | |||
|
Description
Daniel Berrangé
2021-11-23 20:34:18 UTC
Created attachment 1843233 [details]
Win 11 installer username screen at 800x600
Created attachment 1843234 [details]
Win 11 installer username screen at 1280x720
Created attachment 1843236 [details]
Win 11 installer username screen at 1280x800
Created attachment 1843237 [details]
Win 11 installer username screen at 1280x1024
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. Created attachment 1843238 [details]
Proof of concept patch from Fedora 35 edk2 for increasing res
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. > 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. (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. Related: bug 1749250. > 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 😎
(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. /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). (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. Merged upstream. https://github.com/tianocore/edk2/pull/2454 Set ITR to 9.1 (to sync with qemu 7.0 rebase which changes the default to 1280x800 too). 9.1 rebase should pick up this one. After a discussion with Yash, moving to Assigned + TestOnly flag, as it reflects better that we're waiting for the rebase 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. 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> (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? According to Comment 23 and https://bugzilla.redhat.com/show_bug.cgi?id=1749250#c49, set status to VERIFIED. 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 |