Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/3] mac_newworld: enable access to EDID data for the VGA device

[Programmingkid]

> 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.