aboutsummaryrefslogtreecommitdiff
path: root/hw/display/edid-generate.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-04edid: Fix clock of Detailed Timing DescriptorAkihiko Odaki1-34/+32
The clock field is 16-bits in EDID Detailed Timing Descriptor, but edid_desc_timing assumed it is 32-bit. Write the 16-bit value if it fits in 16-bit. Write DisplayID otherwise. Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <20220213021529.2248-1-akihiko.odaki@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-13edid: Added support for 4k@60 Hz monitorSatyeshwar Singh1-0/+3
Previously, the large modes (>1080p) that were generated by Qemu in its EDID were all 50 Hz. If we provide them to a Guest OS and the user selects one of these modes, then the OS by default only gets 50 FPS. This is especially true for Windows OS. With this patch, we are now exposing a 3840x2160@60 Hz which will allow the guest OS to get 60 FPS. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Satyeshwar Singh <satyeshwar.singh@intel.com> Message-Id: <20211116221103.27128-1-dongwon.kim@intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-13edid: set default resolution to 1280x800 (WXGA)Daniel P. Berrangé1-2/+2
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>
2021-05-10edid: add support for DisplayID extension (5k resolution)Konstantin Nazarov1-5/+73
The Detailed Timing Descriptor has only 12 bits to store the resolution. This limits the guest to 4095 pixels. This patch adds support for the DisplayID extension, that has 2 full bytes for that purpose, thus allowing 5k resolutions and above. Based-on: <20210303152948.59943-2-akihiko.odaki@gmail.com> Signed-off-by: Konstantin Nazarov <mail@knazarov.com> Message-Id: <20210315114639.91953-3-mail@knazarov.com> [ kraxel: minor workflow tweaks ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20210427150824.638359-1-kraxel@redhat.com Message-Id: <20210427150824.638359-9-kraxel@redhat.com>
2021-05-10edid: allow arbitrary-length checksumsKonstantin Nazarov1-5/+5
Some of the EDID extensions like DisplayID do checksums of their subsections. Currently checksums can be only applied to the whole extension blocks which are 128 bytes. This patch allows to checksum arbitrary parts of EDID, and not only whole extension blocks. Based-on: <20210303152948.59943-2-akihiko.odaki@gmail.com> Signed-off-by: Konstantin Nazarov <mail@knazarov.com> Message-Id: <20210315114639.91953-2-mail@knazarov.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20210427150824.638359-1-kraxel@redhat.com Message-Id: <20210427150824.638359-8-kraxel@redhat.com>
2021-05-10edid: move timing generation into a separate functionKonstantin Nazarov1-24/+44
The timing generation is currently performed inside the function that fills in the DTD. The DisplayID generation needs it as well, so moving it out to a separate function. Based-on: <20210303152948.59943-2-akihiko.odaki@gmail.com> Signed-off-by: Konstantin Nazarov <mail@knazarov.com> Message-Id: <20210315114639.91953-1-mail@knazarov.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20210427150824.638359-1-kraxel@redhat.com Message-Id: <20210427150824.638359-7-kraxel@redhat.com>
2021-05-10edid: Make refresh rate configurableAkihiko Odaki1-4/+5
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20210427150824.638359-1-kraxel@redhat.com Message-Id: <20210427150824.638359-6-kraxel@redhat.com>
2021-05-10edid: use dta extension block descriptorsGerd Hoffmann1-0/+8
When the 4 descriptors in the base edid block are filled, jump to the dta extension block. This allows for more than four descriptors. Happens for example when generating an edid blob with a serial number (qemu-edid -s $serial). 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-5-kraxel@redhat.com>
2021-05-10edid: move xtra3 descriptorGerd Hoffmann1-9/+11
Initialize the "Established timings III" block earlier. Also move up edid_fill_modes(). That'll make sure the offset for the additional descriptors in the dta block don't move any more, which in turn makes it easier to actually use them. 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-4-kraxel@redhat.com>
2021-05-10edid: edid_desc_nextGerd Hoffmann1-15/+26
Add helper function to find the next free desc block. Needed when we start to use the dta descriptor entries. 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-3-kraxel@redhat.com>
2021-03-23edid: prefer standard timingsGerd Hoffmann1-7/+8
Windows guests using the "Basic Display Adapter" don't parse the "Established timings III" block. They also don't parse any edid extension. So prefer the "Standard Timings" block to store the display resolutions in edid_fill_modes(). Also reorder the mode list, so more exotic resolutions (specifically the ones which are not supported by vgabios) are moved down and the remaining ones have a better chance to get one of the eight slots in the "Standard Timings" block. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20210316143812.2363588-6-kraxel@redhat.com>
2020-09-29edid: use physical dimensions if availableMarc-André Lureau1-11/+25
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>
2020-09-29edid: fix physical display size computationMarc-André Lureau1-2/+2
Divide the resolution by the DPI, and multiply to mm. Note the computation done for edid[21/22] is correct (in cm). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200927145751.365446-2-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-02Arithmetic error in EDID generation fixedAnton V. Boyarshinov1-2/+2
To calculate screen size in centimeters we should calculate: pixels/dpi*2.54 but not pixels*dpi/2540 Using wrong formula we actually get 65 DPI and very small fonts. Signed-off-by: Anton V. Boyarshinov <boyarsh@altlinux.org> Message-id: 20200226122054.366b9cda@table.localdomain Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster1-1/+0
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]
2018-11-12edid: silence a stringop-overflow warningMarc-André Lureau1-1/+1
Simplify the code that doesn't need strncpy() since length of string is already computed. /home/elmarco/src/qemu/hw/display/edid-generate.c: In function 'edid_desc_text': /home/elmarco/src/qemu/hw/display/edid-generate.c:168:5: error: 'strncpy' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] strncpy((char *)(desc + 5), text, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/elmarco/src/qemu/hw/display/edid-generate.c:164:11: note: length computed here len = strlen(text); ^~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: 20181110111623.31356-1-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-10-15edid: fix alignment issuesGerd Hoffmann1-4/+4
Use stl_le_p() & friends instead of casts. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20181015055333.32030-1-kraxel@redhat.com
2018-10-05edid: fix vendor defaultGerd Hoffmann1-1/+1
"EMU" actually is "Emulex Corporation", so not a good idea to use that by default. Lets use the Red Hat vendor id instead, which is in line with the pci ids which are allocated from Red Hat vendor ids too. Vendor list is available from http://www.uefi.org/pnp_id_list Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20181005091934.12143-1-kraxel@redhat.com
2018-09-27display/edid: add qemu_edid_size()Gerd Hoffmann1-0/+14
Helper function to figure the size of a edid blob, by checking how many extensions are present. Both the base edid blob and the extensions are 128 bytes in size. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180925075646.25114-3-kraxel@redhat.com
2018-09-27display/edid: add edid generator to qemu.Gerd Hoffmann1-0/+425
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
generated by cgit v1.1 at 2024-08-18 02:16:48 +0000