On 28/02/2019 06:38, Gerd Hoffmann wrote: > On Thu, Feb 28, 2019 at 06:01:30AM +0000, Mark Cave-Ayland wrote: >> On 28/02/2019 05:49, Gerd Hoffmann wrote: >> >>> Hi, >>> >>>> Right, at the moment all the MacOS driver does is parse the resolution >>>> list from the >>>> EDID and add them to the dropdown list - it doesn't support the xres and >>>> yres properties. >>> >>>> The main reason for this that OpenBIOS currently makes use of the -g XxYxD >>>> parameter >>>> to set up the display resolution and bit depth, and AFAICT we currently >>>> only have >>>> access to the X and Y resolutions via the EDID blob. So it's not clear >>>> whether EDID >>>> can completely replace the existing mechanism yet. >>> >>> EDID can only propagate x + y, not depth. >> >> Right - my quick reading online was that there was very limited depth >> capability, and >> certainly nothing greater than 16-bit. > > That is another depth, it's the bits *per color* the monitor is able to > display.
Ah I see - my mistake. >> Rather than duplicating these parameters, would it make sense to come up >> with a >> custom QEMU extension block to hold the extra depth information? > > Well, not really. EDID is about monitor capabilities. The monitor will > see 8 bit per color channel, no matter whenever your GPU composes that > signal using a 8bpp mode + color palette or 24bpp mode with direct > color. Hmmm okay. Perhaps it might still be worth hooking -g XxYxD to also put X and Y into xres and yres within the EDID so at least everything is consistent between OpenBIOS and the client driver when it eventually loads? ATB, Mark.