[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] mac_newworld: enable access to EDID data fo

From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH 2/3] mac_newworld: enable access to EDID data for the VGA device
Date: Mon, 17 Dec 2018 13:09:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

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 
display resolutions from the host to the guest driver, rather than using an 
hard-coded list. I guess that over time QEMU could become "smarter" about 
the list of supported resolutions depending upon the capabilities of the host?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]