[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/3] mac_newworld: enable access to E

From: Programmingkid
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/3] mac_newworld: enable access to EDID data for the VGA device
Date: Tue, 18 Dec 2018 06:31:28 -0500

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

reply via email to

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