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

[Mark Cave-Ayland]

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?


ATB,

Mark.