riscv/qemu - qemu - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Sebastian Mitterle	82a628f887	qemu-edid: Restrict input parameter -d to avoid division by zero A zero value for dpi will lead to a division by zero in qemu_edid_dpi_to_mm(). Tested by runnig qemu-edid -dX, X = 0, 100. Resolves: qemu-project/qemu#1249 Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Sebastian Mitterle <smitterl@redhat.com> Message-Id: <20221011151216.64897-1-smitterl@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>	4 years ago
Daniel P. Berrangé	de72c4b7cd	edid: set default resolution to 1280x800 (WXGA) 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> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211129140508.1745130-1-berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>	4 years ago
Gerd Hoffmann	bdbe824b7e	qemu-edid: use qemu_edid_size() So we only write out that part of the edid blob which has been filled with data. Also use a larger buffer for the blob. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20210427150824.638359-1-kraxel@redhat.com Message-Id: <20210427150824.638359-2-kraxel@redhat.com>	5 years ago
Gerd Hoffmann	c7146542b1	qemu-edid: drop cast Not needed and makes some compilers error out with: qemu-edid.c:15:1: error: initializer element is not constant Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20201013091615.14166-1-kraxel@redhat.com	6 years ago
Marc-André Lureau	fd36eade01	edid: use physical dimensions if available Replace dpi with width_mm/height_mm in qemu_edid_info. Use it when set (non-zero) to compute the DPI and generate the EDID. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200927145751.365446-3-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>	6 years ago
Markus Armbruster	a8d2532645	Include qemu-common.h exactly where needed No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]	7 years ago
Gerd Hoffmann	72d277a70e	display/edid: add edid generator to qemu. EDID is a metadata format to describe monitors. On physical hardware the monitor has an eeprom with that data block which can be read over i2c bus. On a linux system you can usually find the EDID data block in /sys/class/drm/$card/$connector/edid. xorg ships a edid-decode utility which you can use to turn the blob into readable form. I think it would be a good idea to use EDID for virtual displays too. Needs changes in both qemu and guest kms drivers. This patch is the first step, it adds an generator for EDID blobs to qemu. Comes with a qemu-edid test tool included. With EDID we can pass more information to the guest. Names and serial numbers, so the guests display configuration has no boring "Unknown Monitor". List of video modes. Display resolution, pretty important in case we want add HiDPI support some day. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180925075646.25114-2-kraxel@redhat.com	8 years ago