[Qemu-devel] Questions about EDID

[Qemu-devel] Questions about EDID

[G 3]

Hi Gerd, I was wondering if you have made any documentation for your EDID
patches. If you have could you provide a link please?

Also could a feature be added that allows the user to specify resolutions
to be made available to the guest?

Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320

Thank you.

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote:
> Hi Gerd, I was wondering if you have made any documentation for your EDID
> patches. If you have could you provide a link please?

No docs.

> Also could a feature be added that allows the user to specify resolutions
> to be made available to the guest?
> 
> Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320

A single resolution works (via xres + yres properties).

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[Programmingkid]

> On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote:
>> Hi Gerd, I was wondering if you have made any documentation for your EDID
>> patches. If you have could you provide a link please?
> 
> No docs.
> 
>> Also could a feature be added that allows the user to specify resolutions
>> to be made available to the guest?
>> 
>> Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320
> 
> A single resolution works (via xres + yres properties).

Could you send an example of the xres and yres properties please?
I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888

Thank you.

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 09:49:22PM -0500, Programmingkid wrote:
> 
> > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > 
> > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote:
> >> Hi Gerd, I was wondering if you have made any documentation for your EDID
> >> patches. If you have could you provide a link please?
> > 
> > No docs.
> > 
> >> Also could a feature be added that allows the user to specify resolutions
> >> to be made available to the guest?
> >> 
> >> Maybe it could work like this: -device VGA,edid=on,res=1366x768,7680x4320
> > 
> > A single resolution works (via xres + yres properties).
> 
> Could you send an example of the xres and yres properties please?
> I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888

That is correct.  But you also need a guest driver with edid support.

I think the macos driver got support for that, for linux support landed
in the 5.0 devel cycle.

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[G 3]

When I use edid=on, I do see a lot of extra resolutions available in Mac OS
9 and Mac OS X, just not the resolution I want to use. Is there some kind
of rule like the resolution value has to be divisible by a certain number?

On Tue, Feb 26, 2019 at 1:43 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Mon, Feb 25, 2019 at 09:49:22PM -0500, Programmingkid wrote:
> >
> > > On Feb 25, 2019, at 10:26 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > On Mon, Feb 25, 2019 at 09:05:30AM -0500, G 3 wrote:
> > >> Hi Gerd, I was wondering if you have made any documentation for your
> EDID
> > >> patches. If you have could you provide a link please?
> > >
> > > No docs.
> > >
> > >> Also could a feature be added that allows the user to specify
> resolutions
> > >> to be made available to the guest?
> > >>
> > >> Maybe it could work like this: -device
> VGA,edid=on,res=1366x768,7680x4320
> > >
> > > A single resolution works (via xres + yres properties).
> >
> > Could you send an example of the xres and yres properties please?
> > I tried this but it didn't work: -device VGA,edid=on,xres=999,yres=888
>
> That is correct.  But you also need a guest driver with edid support.
>
> I think the macos driver got support for that, for linux support landed
> in the 5.0 devel cycle.
>
> cheers,
>   Gerd
>
>

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> When I use edid=on, I do see a lot of extra resolutions available in Mac OS
> 9 and Mac OS X, just not the resolution I want to use. Is there some kind
> of rule like the resolution value has to be divisible by a certain number?

qemu doesn't have such a requirement.
Might be the guest drivers have.
Try making width/height multiple of 8 or 16.

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[Programmingkid]

> On Feb 27, 2019, at 12:27 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
>> When I use edid=on, I do see a lot of extra resolutions available in Mac OS
>> 9 and Mac OS X, just not the resolution I want to use. Is there some kind
>> of rule like the resolution value has to be divisible by a certain number?
> 
> qemu doesn't have such a requirement.
> Might be the guest drivers have.
> Try making width/height multiple of 8 or 16.


I counted 10 more added resolutions when using your edid feature on Mac OS 9.2 and on Mac OS 10.4. But when I tried adding one using the xres/yres properties, it didn't work. What operating system do you see success on? What is your command line you use?

I did try your suggestion by using 800x800 (16*50) resolution. It didn't work.'

Thank you.

Re: [Qemu-devel] Questions about EDID

[Mark Cave-Ayland]

On 27/02/2019 05:27, Gerd Hoffmann wrote:

> On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
>> When I use edid=on, I do see a lot of extra resolutions available in Mac OS
>> 9 and Mac OS X, just not the resolution I want to use. Is there some kind
>> of rule like the resolution value has to be divisible by a certain number?
> 
> qemu doesn't have such a requirement.
> Might be the guest drivers have.
> Try making width/height multiple of 8 or 16.

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.

The other issue to contend with is that some machines such as SPARC will reject
invalid bit depths (i.e. d != 8 || d != 24) during machine init to prevent screen
corruption, and I'm not yet sure how to enforce this with EDID.


ATB,

Mark.

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

  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.

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[Mark Cave-Ayland]

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.

Rather than duplicating these parameters, would it make sense to come up with a
custom QEMU extension block to hold the extra depth information?


ATB,

Mark.

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

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.

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

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[G 3]

On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
mark.cave-ayland@ilande.co.uk> wrote:

> On 27/02/2019 05:27, Gerd Hoffmann wrote:
>
> > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> >> When I use edid=on, I do see a lot of extra resolutions available in
> Mac OS
> >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> kind
> >> of rule like the resolution value has to be divisible by a certain
> number?
> >
> > qemu doesn't have such a requirement.
> > Might be the guest drivers have.
> > Try making width/height multiple of 8 or 16.
>
> 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.
>

Gerd, could the xres +yres numbers be added to the list of resolutions
then?

Re: [Qemu-devel] Questions about EDID

[Mark Cave-Ayland]

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.

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

  Hi,

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

That makes sense, sure.  Will be a bit tricky due to (I think) only ppc
and sparc actually looking at -g right now, to make sure current
behavior of the other archs doesn't change when -g is not specified.

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[Gerd Hoffmann]

On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote:
> On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
> mark.cave-ayland@ilande.co.uk> wrote:
> 
> > On 27/02/2019 05:27, Gerd Hoffmann wrote:
> >
> > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> > >> When I use edid=on, I do see a lot of extra resolutions available in
> > Mac OS
> > >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> > kind
> > >> of rule like the resolution value has to be divisible by a certain
> > number?
> > >
> > > qemu doesn't have such a requirement.
> > > Might be the guest drivers have.
> > > Try making width/height multiple of 8 or 16.
> >
> > 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.
> >
> 
> Gerd, could the xres +yres numbers be added to the list of resolutions
> then?

That is already the case:

qemu-edid -x 1234 -y 567 | edid-decode
[ ... ]
First detailed timing is preferred timing
Established timings supported:
  640x480@60Hz
  800x600@60Hz
  1024x768@60Hz
Standard timings supported:
  2048x1152@60Hz
  1920x1080@60Hz
Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm
               1234 1542 1579 1665 hborder 0
               ^^^^
                567  569  571  586 vborder 0
                ^^^
               -hsync -vsync 
[ ... ]

cheers,
  Gerd

Re: [Qemu-devel] Questions about EDID

[G 3]

If the value is already in the list, then something else must be happening
that prevents the custom resolution from reaching the guest. Would you know
where in the list the custom resolution is added? My guess right now is the
size of the list is being reported incorrectly - the custom resolution
isn't being counted. When the operating system iterates thru the list it
might stop right before the custom resolution value, preventing its
inclusion.

On Fri, Mar 1, 2019 at 12:47 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote:
> > On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
> > mark.cave-ayland@ilande.co.uk> wrote:
> >
> > > On 27/02/2019 05:27, Gerd Hoffmann wrote:
> > >
> > > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> > > >> When I use edid=on, I do see a lot of extra resolutions available in
> > > Mac OS
> > > >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> > > kind
> > > >> of rule like the resolution value has to be divisible by a certain
> > > number?
> > > >
> > > > qemu doesn't have such a requirement.
> > > > Might be the guest drivers have.
> > > > Try making width/height multiple of 8 or 16.
> > >
> > > 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.
> > >
> >
> > Gerd, could the xres +yres numbers be added to the list of resolutions
> > then?
>
> That is already the case:
>
> qemu-edid -x 1234 -y 567 | edid-decode
> [ ... ]
> First detailed timing is preferred timing
> Established timings supported:
>   640x480@60Hz
>   800x600@60Hz
>   1024x768@60Hz
> Standard timings supported:
>   2048x1152@60Hz
>   1920x1080@60Hz
> Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm
>                1234 1542 1579 1665 hborder 0
>                ^^^^
>                 567  569  571  586 vborder 0
>                 ^^^
>                -hsync -vsync
> [ ... ]
>
> cheers,
>   Gerd
>
>