Message ID | 20211129140508.1745130-1-berrange@redhat.com |
---|---|
State | New |
Headers | show |
Series | edid: set default resolution to 1280x800 (WXGA) | expand |
On Mon, Nov 29, 2021 at 02:05:08PM +0000, Daniel P. Berrangé wrote: > Currently QEMU defaults to a resolution of 1024x768 when exposing EDID > info to the guest OS. The EDID default info is important as this will > influence what resolution many guest OS will configure the screen with > on boot. It can also potentially influence what resolution the firmware > will configure the screen with, though until very recently EDK2 would > not handle EDID info. edk2 support is at "patches exist" level right now, not even merged, will hopefully land in the next stable tag (feb 22). Independent from that we plan to change the edk2 default resolution from the current 800x600 to whatever qemu 7.0 will use, be that 1280x800 (as suggested by this patch) or 1024x768 (current qemu default). > One important thing to bear in mind is that the default graphics card > driver provided by Windows will leave the display set to whatever > resolution was enabled by the firmware on boot. Even if sufficient > VRAM is available, the resolution can't be changed without installing > new drivers. IOW, the default resolution choice is quite important > for usability of Windows. It's not that simple. With uefi firmware windows sticks to whatever resolution the firmware has initialized (without installing guest drivers). The resolution can be changed in the firmware setup. With bios firmware windows can change the resolution at runtime using vgabios calls, i.e. after completing the install you can right-click on the desktop, pick display config in the popup menu, then change the resolution. So there are ways to use other resolutions. They are not exactly intuitive though and I think it makes sense to modernize the qemu defaults. > In considering what possible new default could be suitable, choices > considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA). > > In many ways, vertical space is the most important, and so 720p was > discarded due to loosing vertical space, despite being 25% wider. > > The SXGA resolution would be good, but when taking into account > window titlebars/toolbars and window manager desktop UI, this might > be a little too tall for some users to fit the guest on their physical > montior. Yes, with FullHD (1920x1080) being a popular resolution these days having a 1280x1024 guest display would leave only 56 pixes for title bar and menus. > This patch thus suggests a modest change to 1280x800 (WXGA). This > only consumes 1 MB per colour channel, allowing double buffered > framebuffer in 8 MB of VRAM. Width wise this is 25% larger than > QEMU's current default, but height wise this only adds 5%, so the > difference isn't massive on the QEMU side. Looks like a good pick to me. In case someone wants pick that up: Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Failing that I'll add that to my first post-freeze pull request. take care, Gerd
On Mon, 29 Nov 2021 at 14:13, Daniel P. Berrangé <berrange@redhat.com> wrote:
> This patch thus suggests a modest change to 1280x800 (WXGA).
Does this change need to be versioned so as to not change
behaviour for older machine types ?
thanks
-- PMM
On Thu, Dec 02, 2021 at 11:00:53AM +0000, Peter Maydell wrote: > On Mon, 29 Nov 2021 at 14:13, Daniel P. Berrangé <berrange@redhat.com> wrote: > > This patch thus suggests a modest change to 1280x800 (WXGA). > > Does this change need to be versioned so as to not change > behaviour for older machine types ? I don't think the EDID defaults change needs it. It just means that VM will get a updated res next time it queries EDID, which should be OK. The virtio-gpu change I'm not so sure about - it feeds into the EDID code, but not sure if it has other consequences that matter from a guest ABI pov. Regards, Daniel
Hi, > The virtio-gpu change I'm not so sure about - it feeds into the > EDID code, but not sure if it has other consequences that matter > from a guest ABI pov. virtio-gpu has two ways to query the display resolution (one predating edid support), the change will affect both. The effect will be simliar in both cases: The next time the guest queries the resolution (typically on reboot) it'll get the new default. take care, Gerd
diff --git a/hw/display/edid-generate.c b/hw/display/edid-generate.c index f2b874d5e3..6f5ac6a38a 100644 --- a/hw/display/edid-generate.c +++ b/hw/display/edid-generate.c @@ -401,10 +401,10 @@ void qemu_edid_generate(uint8_t *edid, size_t size, info->name = "QEMU Monitor"; } if (!info->prefx) { - info->prefx = 1024; + info->prefx = 1280; } if (!info->prefy) { - info->prefy = 768; + info->prefy = 800; } if (info->prefx >= 4096 || info->prefy >= 4096) { large_screen = 1; diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h index acfba7c76c..2179b75703 100644 --- a/include/hw/virtio/virtio-gpu.h +++ b/include/hw/virtio/virtio-gpu.h @@ -147,8 +147,8 @@ struct VirtIOGPUBaseClass { DEFINE_PROP_UINT32("max_outputs", _state, _conf.max_outputs, 1), \ DEFINE_PROP_BIT("edid", _state, _conf.flags, \ VIRTIO_GPU_FLAG_EDID_ENABLED, true), \ - DEFINE_PROP_UINT32("xres", _state, _conf.xres, 1024), \ - DEFINE_PROP_UINT32("yres", _state, _conf.yres, 768) + DEFINE_PROP_UINT32("xres", _state, _conf.xres, 1280), \ + DEFINE_PROP_UINT32("yres", _state, _conf.yres, 800) typedef struct VGPUDMABuf { QemuDmaBuf buf; diff --git a/qemu-edid.c b/qemu-edid.c index c3a9fba10d..20c958d9c7 100644 --- a/qemu-edid.c +++ b/qemu-edid.c @@ -10,8 +10,8 @@ #include "hw/display/edid.h" static qemu_edid_info info = { - .prefx = 1024, - .prefy = 768, + .prefx = 1280, + .prefy = 800, }; static void usage(FILE *out)
Currently QEMU defaults to a resolution of 1024x768 when exposing EDID info to the guest OS. The EDID default info is important as this will influence what resolution many guest OS will configure the screen with on boot. It can also potentially influence what resolution the firmware will configure the screen with, though until very recently EDK2 would not handle EDID info. One important thing to bear in mind is that the default graphics card driver provided by Windows will leave the display set to whatever resolution was enabled by the firmware on boot. Even if sufficient VRAM is available, the resolution can't be changed without installing new drivers. IOW, the default resolution choice is quite important for usability of Windows. Modern real world monitor hardware for desktop/laptop has supported resolutions higher than 1024x768 for a long time now, perhaps as long as 15+ years. There are quite a wide variety of native resolutions in use today, however, and in wide screen form factors the height may not be all that tall. None the less, it is considered that there is scope for making the QEMU default resolution slightly larger. In considering what possible new default could be suitable, choices considered were 1280x720 (720p), 1280x800 (WXGA) and 1280x1024 (SXGA). In many ways, vertical space is the most important, and so 720p was discarded due to loosing vertical space, despite being 25% wider. The SXGA resolution would be good, but when taking into account window titlebars/toolbars and window manager desktop UI, this might be a little too tall for some users to fit the guest on their physical montior. This patch thus suggests a modest change to 1280x800 (WXGA). This only consumes 1 MB per colour channel, allowing double buffered framebuffer in 8 MB of VRAM. Width wise this is 25% larger than QEMU's current default, but height wise this only adds 5%, so the difference isn't massive on the QEMU side. Overall there doesn't appear to be a compelling reason to stick with 1024x768 resolution. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- hw/display/edid-generate.c | 4 ++-- include/hw/virtio/virtio-gpu.h | 4 ++-- qemu-edid.c | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-)