> On 12/12/2018 13:38, Gerd Hoffmann wrote: > >> On Wed, Dec 12, 2018 at 08:54:37AM +0000, Mark Cave-Ayland wrote: >>> On 12/12/2018 08:32, Gerd Hoffmann wrote: >>> >>>> On Fri, Dec 07, 2018 at 04:08:05PM +0000, Mark Cave-Ayland wrote: >>>>> This is in preparation for some upcoming QEMU NDRV driver changes that >>>>> pass >>>>> display information from the host to the guest. >>>> >>>>> - pci_vga_init(pci_bus); >>>>> + dev = qdev_create(BUS(pci_bus), "VGA"); >>>>> + qdev_prop_set_int32(dev, "addr", -1); >>>>> + qdev_prop_set_bit(dev, "edid", true); >>>>> + qdev_init_nofail(dev); >>>> >>>> Hmm. IMO you should not overwrite the device defaults here. >>>> >>>> edid is off by default only because it is new and I'm conservative. >>>> I want a release (or two) with it being available for user testing. >>>> If no issues pop up flip it to default on. >>> >>> Oh, okay. I already have some unreleased guest code that makes use of this, >>> so my >>> questions would be: how can EDID be enabled from the command line for >>> in-built VGA >>> devices, >> >> "-global VGA.edid=on" should do. >> >>> and how do I detect whether EDID support is present from the guest? >> >> Check whenever the header is present. The edid blob has a fixed 8 byte >> header (00 FF FF FF FF FF FF 00). The linux kernel driver is lazy and >> checks the first two bytes only. >> >>> Otherwise a guest driver that assumes it is always present and tries >>> to read from that area of memory will crash. >> >> Oh, reading should work no matter what. You just don't find valid edid >> data there if it is turned off. > > Thanks for the info. My current use case for this is passing a set of > possible guest > display resolutions from the host to the guest driver, rather than using an > internal > hard-coded list. I guess that over time QEMU could become "smarter" about > building > the list of supported resolutions depending upon the capabilities of the host?
Would could have both a hard-coded list and resolutions supported by the host.