From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: G 3 <programmingkidx@gmail.com>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Questions about EDID
Date: Thu, 28 Feb 2019 16:57:09 +0000 [thread overview]
Message-ID: <d2b28d19-0533-e467-013d-66427c307126@ilande.co.uk> (raw)
In-Reply-To: <20190228063812.b75cqgoacf32bri4@sirius.home.kraxel.org>
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.
next prev parent reply other threads:[~2019-02-28 16:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 14:05 [Qemu-devel] Questions about EDID G 3
2019-02-25 15:26 ` Gerd Hoffmann
2019-02-26 2:49 ` Programmingkid
2019-02-26 6:43 ` Gerd Hoffmann
2019-02-26 21:11 ` G 3
2019-02-27 5:27 ` Gerd Hoffmann
2019-02-27 21:22 ` Programmingkid
2019-02-28 5:01 ` Mark Cave-Ayland
2019-02-28 5:49 ` Gerd Hoffmann
2019-02-28 6:01 ` Mark Cave-Ayland
2019-02-28 6:38 ` Gerd Hoffmann
2019-02-28 16:57 ` Mark Cave-Ayland [this message]
2019-03-01 5:43 ` Gerd Hoffmann
2019-02-28 16:53 ` G 3
2019-03-01 5:47 ` Gerd Hoffmann
2019-03-01 14:41 ` G 3
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2b28d19-0533-e467-013d-66427c307126@ilande.co.uk \
--to=mark.cave-ayland@ilande.co.uk \
--cc=kraxel@redhat.com \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.